सॉफ्टवेयर फ्रेमवर्क
कंप्यूटर प्रोग्रामिंग में, सॉफ्टवेयर फ्रेमवर्क अमूर्त (कंप्यूटर विज्ञान) है जिसमें सॉफ्टवेयर, सामान्य कार्यक्षमता प्रदान करते हुए, अतिरिक्त उपयोगकर्ता-लिखित कोड द्वारा श्रेष्ठ रूप से बदला जा सकता है, इस प्रकार एप्लिकेशन-विशिष्ट सॉफ़्टवेयर प्रदान करता है। यह एप्लिकेशन को बनाने और नियुक्त करने का मानक विधिा प्रदान करता है और सार्वभौमिक, पुन: प्रयोज्य सॉफ़्टवेयर वातावरण (बहुविकल्पी) है जो सॉफ़्टवेयर एप्लिकेशनों, उत्पादों और समाधानों के विकास को सुविधाजनक बनाने के लिए बड़े सॉफ्टवेयर मंच के भाग के रूप में विशेष कार्यक्षमता प्रदान करता है।
सॉफ्टवेयर फ्रेमवर्क में समर्थन प्रोग्राम, संकलनकर्ता, कूट भाषा पुस्तकालय, टूलसेट और एप्लिकेशन प्रोग्रामिंग अंतरफलक (एपीआई) सम्मिलित हो सकते हैं जो सॉफ्टवेयर परियोजना या सॉफ्टवेयर प्रणाली के विकास को सक्षम करने के लिए सभी अलग-अलग सॉफ्टवेयर घटकों को साथ लाते हैं।
फ्रेमवर्क में मुख्य विशिष्ट विशेषताएं होती हैं जो उन्हें सामान्य पुस्तकालय (कम्प्यूटिंग) से अलग करती हैं:
- नियंत्रण का व्युत्क्रम: फ्रेमवर्क में, पुस्तकालयों या मानक उपयोगकर्ता एप्लिकेशनों के विपरीत, समग्र कार्यक्रम का नियंत्रण प्रवाह कॉलर द्वारा निर्धारित नहीं किया जाता है, किन्तु रूपरेखा द्वारा निर्धारित किया जाता है।[1] यह सामान्यतः टेम्पलेट विधि पैटर्न के साथ प्राप्त किया जाता है।
- डिफ़ॉल्ट व्यवहार: यह अमूर्त वर्ग में टेम्पलेट विधि पैटर्न के अपरिवर्तनीय विधियों के साथ प्रदान किया जा सकता है जो फ्रेमवर्क द्वारा प्रदान किया जाता है।
- प्रसारण क्षमता: उपयोगकर्ता फ्रेमवर्क का विस्तार कर सकता है - सामान्यतः चयनात्मक अधिभावी द्वारा - या प्रोग्रामर विशिष्ट कार्यक्षमता प्रदान करने के लिए विशेष उपयोगकर्ता कोड जोड़ सकते हैं। यह सामान्यतः उपवर्ग में हुक विधि द्वारा प्राप्त किया जाता है जो अधिवर्ग में टेम्पलेट विधि को अधिभावी करता है।
- गैर-संशोधित फ्रेमवर्क कोड: उपयोगकर्ता द्वारा प्रायुक्त किए गए एक्सटेंशन को स्वीकार करते समय फ्रेमवर्क कोड को सामान्य रूप से संशोधित नहीं किया जाना चाहिए। दूसरे शब्दों में, उपयोगकर्ता फ्रेमवर्क का विस्तार कर सकते हैं, किन्तु इसके कोड को संशोधित नहीं कर सकते हैं।
उपपत्ति
सॉफ्टवेयर फ्रेमवर्क के डिजाइनरों का लक्ष्य कार्य प्रणाली प्रदान करने के अधिक मानक निम्न-स्तरीय विवरणों से निपटने के अतिरिक्त डिजाइनरों और प्रोग्रामरों को सॉफ्टवेयर आवश्यकताओं को पूरा करने के लिए अपना समय समर्पित करने की अनुमति देकर सॉफ्टवेयर विकास को सुविधाजनक बनाना है, जिससे समग्र विकास समय कम हो जाता है।[2] उदाहरण के लिए, बैंकिंग वेबसाइट विकसित करने के लिए वेब फ्रेमवर्क का उपयोग करने वाली टीम अनुरोध प्रबंधन और राज्य प्रबंधन के यांत्रिकी के अतिरिक्त विशेष रूप से बैंकिंग के लिए कोड लिखने पर ध्यान केंद्रित कर सकती है।
फ्रेमवर्क अधिकांश कार्यक्रमों के आकार में वृद्धि करते हैं, घटना जिसे कोड ब्लोट कहा जाता है। ग्राहक-मांग-संचालित एप्लिकेशनों की जरूरतों के कारण, प्रतिस्पर्धी और पूरक फ्रेमवर्क दोनों कभी-कभी उत्पाद में समाप्त हो जाते हैं। इसके अतिरिक्त, उनके एपीआई की जटिलता के कारण, फ्रेमवर्क का उपयोग करने के लिए अतिरिक्त समय सीखने की आवश्यकता के कारण समग्र विकास समय में इच्छित कमी प्राप्त नहीं की जा सकती है; यह आलोचना स्पष्ट रूप से मान्य है जब विकास कर्मचारियों द्वारा पहली बार विशेष या नए फ्रेमवर्क का सामना किया जाता है।[citation needed] यदि इस प्रकार के फ्रेमवर्क का उपयोग बाद के कार्य कार्यों में नहीं किया जाता है, तो फ्रेमवर्क को सीखने में लगने वाला समय परियोजना के कर्मचारियों से परिचित उद्देश्य-लिखित कोड से अधिक खर्च हो सकता है; कई प्रोग्रामर आम जरूरतों के लिए उपयोगी बॉयलरप्लेट कोड की प्रतियां रखते हैं।
चूँकि, बार रूपरेखा सीख लेने के बाद, भविष्य की परियोजनाएँ तेज़ और आसानी से पूरी हो सकती हैं; फ्रेमवर्क की अवधारणा आकार-फिट-सभी समाधान सेट बनाना है, और परिचितता के साथ, कोड उत्पादन तार्किक रूप से बढ़ना चाहिए। कोड के आकार के बारे में ऐसा कोई प्रमाणित नहीं किया गया है, जो अंततः आउटपुट उत्पाद के साथ बंडल किया गया है, न ही इसकी सापेक्ष दक्षता और संक्षिप्तता। किसी भी पुस्तकालय समाधान का उपयोग आवश्यक रूप से अतिरिक्त और अप्रयुक्त बाहरी गुणों को खींचता है जब तक कि सॉफ़्टवेयर संकलनकर्ता-ऑब्जेक्ट लिंकर नहीं है जो तंग (छोटा, पूर्ण नियंत्रित और निर्दिष्ट) निष्पादन योग्य मॉड्यूल बनाता है।
उद्देश्य जारी है, किन्तु उद्योग के दशक से अधिक का अनुभव[citation needed] ने दिखाया है कि सबसे प्रभावी फ्रेमवर्क वे होते हैं जो सामान्य उद्देश्यों के लिए तीसरे पक्ष द्वारा विकसित सामान्य आकार-फिट-सभी फ्रेमवर्क का उपयोग करने के अतिरिक्त कोड रीफैक्टरिंग|उद्यम के सामान्य कोड को फिर से फैक्टरिंग से विकसित होते हैं। इसका उदाहरण यह होगा कि ऑफिस सूट जैसे एप्लिकेशन पैकेज में यूजर इंटरफेस कैसे सामान्य रूप, अनुभव और डेटा-साझाकरण विशेषताओं और विधियों के लिए बढ़ता है, बार अलग-अलग बंडल किए गए एप्लिकेशनों के रूप में, सूट में एकीकृत हो जाता है जो सख्त है। और छोटा; नया/विकसित सुइट ऐसा उत्पाद हो सकता है जो अभिन्न उपयोगिता पुस्तकालयों और उपयोगकर्ता इंटरफेस को साझा करता है।
विवाद में यह प्रवृत्ति रूपरेखाओं के बारे में महत्वपूर्ण उद्देश्य उठाती है। ऐसा फ्रेमवर्क बनाना जो सुरुचिपूर्ण हो, बनाम वह जो केवल समस्या का समाधान करता हो, अभी भी विज्ञान के अतिरिक्त शिल्प है। सॉफ्टवेयर लालित्य का तात्पर्य स्पष्टता, संक्षिप्तता और थोड़ी बर्बादी (अतिरिक्त या बाहरी कार्यक्षमता, जिनमें से अधिकांश उपयोगकर्ता-परिभाषित है) है। उन रूपरेखाओं के लिए जो कोड उत्पन्न करते हैं, उदाहरण के लिए, लालित्य का अर्थ कोड का निर्माण होता है जो उचित जानकार प्रोग्रामर (और जो आसानी से परिवर्तनीय है) के लिए स्वच्छ और समझने योग्य है, जो केवल सही कोड उत्पन्न करता है। लालित्य का उद्देश्य यह है कि अपेक्षाकृत कुछ सॉफ्टवेयर फ्रेमवर्क समय की कसौटी पर खरे उतरे हैं: सबसे अच्छी रूपरेखाएँ अंतर्निहित विधि के रूप में विकसित होने में सक्षम हैं, जिस पर वे उन्नत बनाए गए थे। वहां भी, विकसित होने के बाद, ऐसे कई पैकेज अंतिम सॉफ्टवेयर को फुलाते हुए विरासत की क्षमताओं को बनाए रखेंगे क्योंकि अन्यथा बदले गए विधियों को नए विधियों के साथ समानांतर में रखा गया है।
उदाहरण
सॉफ़्टवेयर फ्रेमवर्क में सामान्यतः बूटस्ट्रैप उपयोगकर्ता एप्लिकेशनों की सहायता के लिए अधिक हाउसकीपिंग और उपयोगिता कोड होते हैं, किन्तु सामान्यतः विशिष्ट समस्या डोमेन पर ध्यान केंद्रित करते हैं, जैसे कि:
- कलात्मक ड्राइंग, संगीत रचना, और यांत्रिक कंप्यूटर एडेड डिजाइन[3][4]
- वित्तीय मॉडलिंग अनुप्रयोग[5]
- पृथ्वी प्रणाली मॉडलिंग अनुप्रयोग[6]
- निर्णय समर्थन प्रणाली[7]
- मीडिया प्लेबैक और संलेखन
- वेब फ्रेमवर्क
- मध्यस्थ
- कैक्टस फ्रेमवर्क - उच्च प्रदर्शन वैज्ञानिक कंप्यूटिंग।
- आवेदन फ्रेमवर्क - सामान्य जीयूआई अनुप्रयोग।
- एंटरप्राइज आर्किटेक्चर फ्रेमवर्क
- ओरेकल एप्लीकेशन डेवलपमेंट फ्रेमवर्क
- लारावेल (पीएचपी फ्रेमवर्क)
- मैलवेयर, उदाहरण के लिए पाइपड्रीम (टूलकिट)
वास्तु
प्री के अनुसार,[8] सॉफ्टवेयर फ्रेमवर्क में फ्रोजन स्पॉट और हॉट स्पॉट होते हैं। जमे हुए धब्बे एक सॉफ्टवेयर प्रणाली के समग्र आर्किटेक्चर को परिभाषित करते हैं जो इसके मूल घटकों और उनके बीच संबंधों को कहते हैं।। ये एप्लिकेशन फ्रेमवर्क के किसी भी तात्कालिकता में अपरिवर्तित (जमे हुए) रहते हैं। हॉट स्पॉट उन हिस्सों का प्रतिनिधित्व करते हैं जहां फ्रेमवर्क का उपयोग करने वाले प्रोग्रामर अपने स्वयं के प्रोजेक्ट के लिए विशिष्ट कार्यक्षमता जोड़ने के लिए अपना कोड जोड़ते हैं।
वस्तु-उन्मुख वातावरण में, रूपरेखा में अमूर्त वर्ग और वर्ग (कंप्यूटर विज्ञान) कंक्रीट वर्ग (कंप्यूटर विज्ञान) होते हैं। इस प्रकार के फ्रेमवर्क के उदाहरण (कंप्यूटर विज्ञान) में मौजूदा वर्ग की वस्तु रचना और उपवर्ग (कंप्यूटर विज्ञान) सम्मिलित हैं।[9]
टेम्पलेट विधि पैटर्न का उपयोग करके आवश्यक कार्यक्षमता को प्रायुक्त किया जा सकता है जिसमें जमे हुए स्पॉट को अपरिवर्तनीय विधियों के रूप में जाना जाता है और हॉट स्पॉट को प्रकार या हुक विधियों के रूप में जाना जाता है। अधिवर्ग में अपरिवर्तनीय विधियाँ डिफ़ॉल्ट व्यवहार प्रदान करती हैं चूँकि प्रत्येक उपवर्ग में हुक विधियाँ कस्टम व्यवहार प्रदान करती हैं।
सॉफ़्टवेयर फ्रेमवर्क के साथ ठोस सॉफ़्टवेयर प्रणाली विकसित करते समय, डेवलपर्स प्रणाली की विशिष्ट आवश्यकताओं और आवश्यकताओं के अनुसार हॉट स्पॉट का उपयोग करते हैं। सॉफ्टवेयर फ्रेमवर्क हॉलीवुड सिद्धांत पर निर्भर करता है: हमें कॉल न करें, हम आपको कॉल करेंगे।[10][11] इसका अर्थ है कि उपयोगकर्ता-परिभाषित वर्ग (उदाहरण के लिए, नए उपवर्ग) पूर्वनिर्धारित रूपरेखा वर्गों से संदेश प्राप्त करते हैं। डेवलपर्स सामान्यतः अधिवर्ग (कंप्यूटर साइंस) अमूर्त विधियों को प्रायुक्त करके इसे संभालते हैं।
यह भी देखें
- कक्षा (कंप्यूटर विज्ञान)
- डिजाइन पैटर्न (कंप्यूटर विज्ञान)
- अपने आप को मत दोहराओ
- निहित आह्वान
- सॉफ्टवेयर इंजन
संदर्भ
- ↑ Riehle, Dirk (2000), Framework Design: A Role Modeling Approach (PDF), Swiss Federal Institute of Technology
- ↑ "Framework". DocForge. Archived from the original on 7 October 2018. Retrieved 15 December 2008.
- ↑ Vlissides, J M; Linton, M A (1990), "Unidraw: a framework for building domain-specific graphical editors", ACM Transactions on Information Systems, 8 (3): 237–268, doi:10.1145/98188.98197, S2CID 11248368
- ↑ Johnson, R E (1992), "Documenting frameworks using patterns", Proceedings of the Conference on Object Oriented Programming Systems Languages and Applications, ACM Press: 63–76
- ↑ Birrer, A; Eggenschwiler, T (1993), "Proceedings of the European conference on object-oriented programming", Frameworks in the financial engineering domain: an experience report, Springer-Verlag, pp. 21–35
- ↑ Hill, C; DeLuca, C; Balaji, V; Suarez, M; da Silva, A (2004), "Architecture of the Earth System Modeling Framework (ESMF)", Computing in Science and Engineering, 6: 18–28, doi:10.1109/MCISE.2004.1255817, S2CID 9311752
- ↑ Gachet, A (2003), "Software Frameworks for Developing Decision Support Systems – A New Component in the Classification of DSS Development Tools", Journal of Decision Systems, 12 (3): 271–281, doi:10.3166/jds.12.271-280, S2CID 29690836
- ↑ Pree, W (1994), "Meta Patterns: A Means for Capturing the Essentials of Reusable Object-Oriented Design", Proceedings of the 8th European Conference on Object-Oriented Programming, Lecture Notes in Computer Science, Springer-Verlag, 821: 150–162, CiteSeerX 10.1.1.74.7935, doi:10.1007/BFb0052181, ISBN 978-3-540-58202-1
- ↑ Buschmann, F (1996), Pattern-Oriented Software Architecture Volume 1: A System of Patterns. Chichester, Wiley, ISBN 978-0-471-95869-7
- ↑ Larman, C (2001), Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd ed.), Prentice Hall, ISBN 978-0-13-092569-5
- ↑ Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1994). Design Patterns. Addison-Wesley. ISBN 0-201-63361-2.
बाहरी संबंध
The dictionary definition of software framework at Wiktionary
Media related to Software frameworks at Wikimedia Commons
