सॉफ्टवेयर फ्रेमवर्क: Difference between revisions

From Vigyanwiki
No edit summary
 
(9 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{short description|Type of library that helps structure other software}}
{{short description|Type of library that helps structure other software}}
{{Redirect|Framework (computer science)||Framework (disambiguation)}}
{{Redirect|फ्रेमवर्क (कंप्यूटर विज्ञान)||फ्रेमवर्क (बहुविकल्पी)}}
{{Use dmy dates|date=December 2021}}
[[कंप्यूटर प्रोग्रामिंग]] में, सॉफ्टवेयर फ्रेमवर्क [[अमूर्त (कंप्यूटर विज्ञान)]] है जिसमें सॉफ्टवेयर, सामान्य कार्यक्षमता प्रदान करते हुए, अतिरिक्त उपयोगकर्ता-लिखित कोड द्वारा श्रेष्ठ रूप से बदला जा सकता है, इस प्रकार एप्लिकेशन-विशिष्ट [[सॉफ़्टवेयर]] प्रदान करता है। यह एप्लिकेशन को बनाने और नियुक्त करने का मानक विधिा प्रदान करता है और सार्वभौमिक, पुन: प्रयोज्य सॉफ़्टवेयर वातावरण (बहुविकल्पी) है जो सॉफ़्टवेयर एप्लिकेशनों, उत्पादों और समाधानों के विकास को सुविधाजनक बनाने के लिए बड़े [[सॉफ्टवेयर मंच]] के भाग के रूप में विशेष कार्यक्षमता प्रदान करता है।
[[कंप्यूटर प्रोग्रामिंग]] में, एक सॉफ्टवेयर ढांचा एक [[अमूर्त (कंप्यूटर विज्ञान)]] है जिसमें सॉफ्टवेयर, सामान्य कार्यक्षमता प्रदान करते हुए, अतिरिक्त उपयोगकर्ता-लिखित कोड द्वारा चुनिंदा रूप से बदला जा सकता है, इस प्रकार एप्लिकेशन-विशिष्ट [[सॉफ़्टवेयर]] प्रदान करता है। यह अनुप्रयोगों को बनाने और तैनात करने का एक मानक तरीका प्रदान करता है और एक सार्वभौमिक, पुन: प्रयोज्य सॉफ़्टवेयर वातावरण (बहुविकल्पी) है जो सॉफ़्टवेयर अनुप्रयोगों, उत्पादों और समाधानों के विकास को सुविधाजनक बनाने के लिए एक बड़े [[सॉफ्टवेयर मंच]] के हिस्से के रूप में विशेष कार्यक्षमता प्रदान करता है।


सॉफ्टवेयर फ्रेमवर्क में सपोर्ट प्रोग्राम, कंपाइलर, कोड लाइब्रेरी, टूलसेट और [[अप्लिकेशन प्रोग्रामिंग अंतरफलक]] | एप्लिकेशन प्रोग्रामिंग इंटरफेस (एपीआई) शामिल हो सकते हैं जो एक [[सॉफ्टवेयर परियोजना]] या [[सॉफ्टवेयर सिस्टम]] के विकास को सक्षम करने के लिए सभी अलग-अलग [[सॉफ्टवेयर घटक]]ों को एक साथ लाते हैं।
सॉफ्टवेयर फ्रेमवर्क में समर्थन प्रोग्राम, संकलनकर्ता, कूट भाषा पुस्तकालय, टूलसेट और [[अप्लिकेशन प्रोग्रामिंग अंतरफलक|एप्लिकेशन प्रोग्रामिंग अंतरफलक]] (एपीआई) सम्मिलित हो सकते हैं जो [[सॉफ्टवेयर परियोजना]] या [[सॉफ्टवेयर सिस्टम|सॉफ्टवेयर प्रणाली]] के विकास को सक्षम करने के लिए सभी अलग-अलग [[सॉफ्टवेयर घटक|सॉफ्टवेयर घटकों]] को साथ लाते हैं।


फ्रेमवर्क में मुख्य विशिष्ट विशेषताएं होती हैं जो उन्हें सामान्य [[पुस्तकालय (कम्प्यूटिंग)]] से अलग करती हैं:
फ्रेमवर्क में मुख्य विशिष्ट विशेषताएं होती हैं जो उन्हें सामान्य [[पुस्तकालय (कम्प्यूटिंग)]] से अलग करती हैं:


* ''नियंत्रण का व्युत्क्रम'': एक ढांचे में, पुस्तकालयों या मानक उपयोगकर्ता अनुप्रयोगों के विपरीत, समग्र कार्यक्रम का नियंत्रण प्रवाह कॉलर द्वारा निर्धारित नहीं किया जाता है, बल्कि रूपरेखा द्वारा निर्धारित किया जाता है।<ref>{{citation|url= http://www.riehle.org/computer-science/research/dissertation/diss-a4.pdf|first= Dirk|last= Riehle|title= Framework Design: A Role Modeling Approach|publisher= [[ETH Zurich|Swiss Federal Institute of Technology]]|year= 2000|postscript= <!--none-->}}</ref> यह आमतौर पर Template Method Pattern के साथ हासिल किया जाता है।
* ''नियंत्रण का व्युत्क्रम'': फ्रेमवर्क में, पुस्तकालयों या मानक उपयोगकर्ता एप्लिकेशनों के विपरीत, समग्र कार्यक्रम का नियंत्रण प्रवाह कॉलर द्वारा निर्धारित नहीं किया जाता है, किन्तु रूपरेखा द्वारा निर्धारित किया जाता है।<ref>{{citation|url= http://www.riehle.org/computer-science/research/dissertation/diss-a4.pdf|first= Dirk|last= Riehle|title= Framework Design: A Role Modeling Approach|publisher= [[ETH Zurich|Swiss Federal Institute of Technology]]|year= 2000|postscript= <!--none-->}}</ref> यह सामान्यतः टेम्पलेट विधि पैटर्न के साथ प्राप्त किया जाता है।
* डिफ़ॉल्ट व्यवहार: यह एक सार वर्ग में [[टेम्पलेट विधि पैटर्न]] के अपरिवर्तनीय तरीकों के साथ प्रदान किया जा सकता है जो ढांचे द्वारा प्रदान किया जाता है।
* डिफ़ॉल्ट व्यवहार: यह अमूर्त वर्ग में [[टेम्पलेट विधि पैटर्न]] के अपरिवर्तनीय विधियों के साथ प्रदान किया जा सकता है जो फ्रेमवर्क द्वारा प्रदान किया जाता है।
* [[तानाना]]: एक उपयोगकर्ता फ्रेमवर्क का विस्तार कर सकता है - आमतौर पर चयनात्मक ओवरराइडिंग द्वारा - या प्रोग्रामर विशिष्ट कार्यक्षमता प्रदान करने के लिए विशेष उपयोगकर्ता कोड जोड़ सकते हैं। यह आमतौर पर एक उपवर्ग में एक हुक विधि द्वारा प्राप्त किया जाता है जो सुपरक्लास में एक टेम्पलेट विधि को ओवरराइड करता है।
* [[तानाना|प्रसारण क्षमता]]: उपयोगकर्ता फ्रेमवर्क का विस्तार कर सकता है - सामान्यतः चयनात्मक अधिभावी द्वारा - या प्रोग्रामर विशिष्ट कार्यक्षमता प्रदान करने के लिए विशेष उपयोगकर्ता कोड जोड़ सकते हैं। यह सामान्यतः उपवर्ग में हुक विधि द्वारा प्राप्त किया जाता है जो अधिवर्ग में टेम्पलेट विधि को अधिभावी करता है।
* खुला/बंद सिद्धांत | गैर-संशोधित फ्रेमवर्क कोड: उपयोगकर्ता द्वारा लागू किए गए एक्सटेंशन को स्वीकार करते समय फ्रेमवर्क कोड को सामान्य रूप से संशोधित नहीं किया जाना चाहिए। दूसरे शब्दों में, उपयोगकर्ता ढांचे का विस्तार कर सकते हैं, लेकिन इसके कोड को संशोधित नहीं कर सकते।
* गैर-संशोधित फ्रेमवर्क कोड: उपयोगकर्ता द्वारा प्रायुक्त किए गए एक्सटेंशन को स्वीकार करते समय फ्रेमवर्क कोड को सामान्य रूप से संशोधित नहीं किया जाना चाहिए। दूसरे शब्दों में, उपयोगकर्ता फ्रेमवर्क का विस्तार कर सकते हैं, किन्तु इसके कोड को संशोधित नहीं कर सकते हैं।


== औचित्य ==
== उपपत्ति ==
{{Multiple issues|section=yes|
सॉफ्टवेयर फ्रेमवर्क के डिजाइनरों का लक्ष्य कार्य प्रणाली प्रदान करने के अधिक मानक निम्न-स्तरीय विवरणों से निपटने के अतिरिक्त डिजाइनरों और प्रोग्रामरों को सॉफ्टवेयर आवश्यकताओं को पूरा करने के लिए अपना समय समर्पित करने की अनुमति देकर सॉफ्टवेयर विकास को सुविधाजनक बनाना है, जिससे समग्र विकास समय कम हो जाता है।<ref>{{cite web |url=http://docforge.com/wiki/Framework |title=Framework |accessdate=15 December 2008 |work=DocForge |archive-date=7 October 2018 |archive-url=https://web.archive.org/web/20181007003315/http://www.docforge.com/wiki/Framework |url-status=dead }}</ref> उदाहरण के लिए, बैंकिंग वेबसाइट विकसित करने के लिए [[वेब ढांचा|वेब फ्रेमवर्क]] का उपयोग करने वाली टीम अनुरोध प्रबंधन और [[राज्य प्रबंधन]] के यांत्रिकी के अतिरिक्त विशेष रूप से बैंकिंग के लिए कोड लिखने पर ध्यान केंद्रित कर सकती है।
{{More citations needed|section|date=April 2011}}
{{Summarize section|date=April 2020}}
{{Weasel|section|date=April 2020}}
{{Essay-like|section|date=April 2020}}
}}
सॉफ्टवेयर फ्रेमवर्क के डिजाइनरों का लक्ष्य कार्य प्रणाली प्रदान करने के अधिक मानक निम्न-स्तरीय विवरणों से निपटने के बजाय डिजाइनरों और प्रोग्रामरों को सॉफ्टवेयर आवश्यकताओं को पूरा करने के लिए अपना समय समर्पित करने की अनुमति देकर सॉफ्टवेयर विकास को सुविधाजनक बनाना है, जिससे समग्र विकास समय कम हो जाता है।<ref>{{cite web |url=http://docforge.com/wiki/Framework |title=Framework |accessdate=15 December 2008 |work=DocForge |archive-date=7 October 2018 |archive-url=https://web.archive.org/web/20181007003315/http://www.docforge.com/wiki/Framework |url-status=dead }}</ref> उदाहरण के लिए, एक बैंकिंग वेबसाइट विकसित करने के लिए [[वेब ढांचा]] का उपयोग करने वाली एक टीम अनुरोध प्रबंधन और [[राज्य प्रबंधन]] के यांत्रिकी के बजाय विशेष रूप से बैंकिंग के लिए कोड लिखने पर ध्यान केंद्रित कर सकती है।


फ्रेमवर्क अक्सर कार्यक्रमों के आकार में वृद्धि करते हैं, एक घटना जिसे [[कोड ब्लोट]] कहा जाता है। ग्राहक-मांग-संचालित अनुप्रयोगों की जरूरतों के कारण, प्रतिस्पर्धी और पूरक ढांचे दोनों कभी-कभी एक उत्पाद में समाप्त हो जाते हैं। इसके अलावा, उनके एपीआई की जटिलता के कारण, ढांचे का उपयोग करने के लिए अतिरिक्त समय सीखने की आवश्यकता के कारण समग्र विकास समय में इच्छित कमी हासिल नहीं की जा सकती है; यह आलोचना स्पष्ट रूप से मान्य है जब विकास कर्मचारियों द्वारा पहली बार एक विशेष या नए ढांचे का सामना किया जाता है।{{citation needed|date=April 2011}} यदि इस तरह के ढाँचे का उपयोग बाद के कार्य कार्यों में नहीं किया जाता है, तो ढाँचे को सीखने में लगने वाला समय परियोजना के कर्मचारियों से परिचित उद्देश्य-लिखित कोड से अधिक खर्च हो सकता है; कई प्रोग्रामर आम जरूरतों के लिए उपयोगी [[बॉयलरप्लेट कोड]] की प्रतियां रखते हैं।
फ्रेमवर्क अधिकांश कार्यक्रमों के आकार में वृद्धि करते हैं, घटना जिसे [[कोड ब्लोट]] कहा जाता है। ग्राहक-मांग-संचालित एप्लिकेशनों की जरूरतों के कारण, प्रतिस्पर्धी और पूरक फ्रेमवर्क दोनों कभी-कभी उत्पाद में समाप्त हो जाते हैं। इसके अतिरिक्त, उनके एपीआई की जटिलता के कारण, फ्रेमवर्क का उपयोग करने के लिए अतिरिक्त समय सीखने की आवश्यकता के कारण समग्र विकास समय में इच्छित कमी प्राप्त नहीं की जा सकती है; यह आलोचना स्पष्ट रूप से मान्य है जब विकास कर्मचारियों द्वारा पहली बार विशेष या नए फ्रेमवर्क का सामना किया जाता है।{{citation needed|date=April 2011}} यदि इस प्रकार के फ्रेमवर्क का उपयोग बाद के कार्य कार्यों में नहीं किया जाता है, तो फ्रेमवर्क को सीखने में लगने वाला समय परियोजना के कर्मचारियों से परिचित उद्देश्य-लिखित कोड से अधिक खर्च हो सकता है; कई प्रोग्रामर आम जरूरतों के लिए उपयोगी [[बॉयलरप्लेट कोड]] की प्रतियां रखते हैं।


हालाँकि, एक बार रूपरेखा सीख लेने के बाद, भविष्य की परियोजनाएँ तेज़ और आसानी से पूरी हो सकती हैं; एक ढांचे की अवधारणा एक आकार-फिट-सभी समाधान सेट बनाना है, और परिचितता के साथ, कोड उत्पादन तार्किक रूप से बढ़ना चाहिए। कोड के आकार के बारे में ऐसा कोई दावा नहीं किया गया है, जो अंततः आउटपुट उत्पाद के साथ बंडल किया गया है, न ही इसकी सापेक्ष दक्षता और संक्षिप्तता। किसी भी पुस्तकालय समाधान का उपयोग आवश्यक रूप से अतिरिक्त और अप्रयुक्त बाहरी संपत्तियों को खींचता है जब तक कि सॉफ़्टवेयर एक कंपाइलर-ऑब्जेक्ट लिंकर नहीं है जो एक तंग (छोटा, पूर्ण नियंत्रित और निर्दिष्ट) निष्पादन योग्य मॉड्यूल बनाता है।
चूँकि, बार रूपरेखा सीख लेने के बाद, भविष्य की परियोजनाएँ तेज़ और आसानी से पूरी हो सकती हैं; फ्रेमवर्क की अवधारणा आकार-फिट-सभी समाधान सेट बनाना है, और परिचितता के साथ, कोड उत्पादन तार्किक रूप से बढ़ना चाहिए। कोड के आकार के बारे में ऐसा कोई प्रमाणित नहीं किया गया है, जो अंततः आउटपुट उत्पाद के साथ बंडल किया गया है, न ही इसकी सापेक्ष दक्षता और संक्षिप्तता। किसी भी पुस्तकालय समाधान का उपयोग आवश्यक रूप से अतिरिक्त और अप्रयुक्त बाहरी गुणों को खींचता है जब तक कि सॉफ़्टवेयर संकलनकर्ता-ऑब्जेक्ट लिंकर नहीं है जो तंग (छोटा, पूर्ण नियंत्रित और निर्दिष्ट) निष्पादन योग्य मॉड्यूल बनाता है।


मुद्दा जारी है, लेकिन उद्योग के एक दशक से अधिक का अनुभव{{citation needed|date=April 2011}} ने दिखाया है कि सबसे प्रभावी ढांचे वे होते हैं जो सामान्य उद्देश्यों के लिए तीसरे पक्ष द्वारा विकसित सामान्य एक आकार-फिट-सभी ढांचे का उपयोग करने के बजाय [[कोड रीफैक्टरिंग]]|उद्यम के सामान्य कोड को फिर से फैक्टरिंग से विकसित होते हैं। इसका एक उदाहरण यह होगा कि ऑफिस सूट जैसे एप्लिकेशन पैकेज में यूजर इंटरफेस कैसे सामान्य रूप, अनुभव और डेटा-साझाकरण विशेषताओं और विधियों के लिए बढ़ता है, एक बार अलग-अलग बंडल किए गए अनुप्रयोगों के रूप में, एक सूट में एकीकृत हो जाता है जो सख्त है। और छोटा; नया/विकसित सुइट एक ऐसा उत्पाद हो सकता है जो अभिन्न उपयोगिता पुस्तकालयों और उपयोगकर्ता इंटरफेस को साझा करता है।
उद्देश्य जारी है, किन्तु उद्योग के दशक से अधिक का अनुभव{{citation needed|date=April 2011}} ने दिखाया है कि सबसे प्रभावी फ्रेमवर्क वे होते हैं जो सामान्य उद्देश्यों के लिए तीसरे पक्ष द्वारा विकसित सामान्य आकार-फिट-सभी फ्रेमवर्क का उपयोग करने के अतिरिक्त [[कोड रीफैक्टरिंग]]|उद्यम के सामान्य कोड को फिर से फैक्टरिंग से विकसित होते हैं। इसका उदाहरण यह होगा कि ऑफिस सूट जैसे एप्लिकेशन पैकेज में यूजर इंटरफेस कैसे सामान्य रूप, अनुभव और डेटा-साझाकरण विशेषताओं और विधियों के लिए बढ़ता है, बार अलग-अलग बंडल किए गए एप्लिकेशनों के रूप में, सूट में एकीकृत हो जाता है जो सख्त है। और छोटा; नया/विकसित सुइट ऐसा उत्पाद हो सकता है जो अभिन्न उपयोगिता पुस्तकालयों और उपयोगकर्ता इंटरफेस को साझा करता है।


विवाद में यह प्रवृत्ति रूपरेखाओं के बारे में एक महत्वपूर्ण मुद्दा उठाती है। एक ऐसा ढाँचा बनाना जो सुरुचिपूर्ण हो, बनाम वह जो केवल एक समस्या का समाधान करता हो, अभी भी एक विज्ञान के बजाय एक शिल्प है। सॉफ्टवेयर [[लालित्य]] का तात्पर्य स्पष्टता, संक्षिप्तता और थोड़ी बर्बादी (अतिरिक्त या बाहरी कार्यक्षमता, जिनमें से अधिकांश उपयोगकर्ता-परिभाषित है) है। उन रूपरेखाओं के लिए जो कोड उत्पन्न करते हैं, उदाहरण के लिए, लालित्य का मतलब कोड का निर्माण होता है जो एक उचित जानकार प्रोग्रामर (और जो आसानी से परिवर्तनीय है) के लिए स्वच्छ और समझने योग्य है, जो केवल सही कोड उत्पन्न करता है। लालित्य का मुद्दा यह है कि अपेक्षाकृत कुछ सॉफ्टवेयर फ्रेमवर्क समय की कसौटी पर खरे उतरे हैं: सबसे अच्छी रूपरेखाएँ अंतर्निहित तकनीक के रूप में विकसित होने में सक्षम हैं, जिस पर वे उन्नत बनाए गए थे। वहां भी, विकसित होने के बाद, ऐसे कई पैकेज अंतिम सॉफ्टवेयर को फुलाते हुए विरासत की क्षमताओं को बनाए रखेंगे क्योंकि अन्यथा बदले गए तरीकों को नए तरीकों के साथ समानांतर में रखा गया है।
विवाद में यह प्रवृत्ति रूपरेखाओं के बारे में महत्वपूर्ण उद्देश्य उठाती है। ऐसा फ्रेमवर्क बनाना जो सुरुचिपूर्ण हो, बनाम वह जो केवल समस्या का समाधान करता हो, अभी भी विज्ञान के अतिरिक्त शिल्प है। सॉफ्टवेयर [[लालित्य]] का तात्पर्य स्पष्टता, संक्षिप्तता और थोड़ी बर्बादी (अतिरिक्त या बाहरी कार्यक्षमता, जिनमें से अधिकांश उपयोगकर्ता-परिभाषित है) है। उन रूपरेखाओं के लिए जो कोड उत्पन्न करते हैं, उदाहरण के लिए, लालित्य का अर्थ कोड का निर्माण होता है जो उचित जानकार प्रोग्रामर (और जो आसानी से परिवर्तनीय है) के लिए स्वच्छ और समझने योग्य है, जो केवल सही कोड उत्पन्न करता है। लालित्य का उद्देश्य यह है कि अपेक्षाकृत कुछ सॉफ्टवेयर फ्रेमवर्क समय की कसौटी पर खरे उतरे हैं: सबसे अच्छी रूपरेखाएँ अंतर्निहित विधि के रूप में विकसित होने में सक्षम हैं, जिस पर वे उन्नत बनाए गए थे। वहां भी, विकसित होने के बाद, ऐसे कई पैकेज अंतिम सॉफ्टवेयर को फुलाते हुए विरासत की क्षमताओं को बनाए रखेंगे क्योंकि अन्यथा बदले गए विधियों को नए विधियों के साथ समानांतर में रखा गया है।


== उदाहरण ==
== उदाहरण ==
[[File:Python Powered.png|thumb]]सॉफ़्टवेयर ढांचे में आम तौर पर बूटस्ट्रैप उपयोगकर्ता अनुप्रयोगों की सहायता के लिए काफी हाउसकीपिंग और उपयोगिता कोड होते हैं, लेकिन आम तौर पर विशिष्ट समस्या डोमेन पर ध्यान केंद्रित करते हैं, जैसे कि:
[[File:Python Powered.png|thumb]]सॉफ़्टवेयर फ्रेमवर्क में सामान्यतः बूटस्ट्रैप उपयोगकर्ता एप्लिकेशनों की सहायता के लिए अधिक हाउसकीपिंग और उपयोगिता कोड होते हैं, किन्तु सामान्यतः विशिष्ट समस्या डोमेन पर ध्यान केंद्रित करते हैं, जैसे कि:


* कलात्मक ड्राइंग, संगीत रचना, और यांत्रिक [[कंप्यूटर एडेड डिजाइन]]<ref>{{citation|doi = 10.1145/98188.98197|last1 = Vlissides|first1 = J M|last2 = Linton|first2 = M A|year = 1990|title = Unidraw: a framework for building domain-specific graphical editors|journal = ACM Transactions on Information Systems|volume = 8|issue = 3|pages =237–268|s2cid = 11248368}}</ref><ref>{{citation|last = Johnson|first = R E|year = 1992|title = Documenting frameworks using patterns|publisher = ACM Press|journal = Proceedings of the Conference on Object Oriented Programming Systems Languages and Applications|pages = 63–76}}</ref>
* कलात्मक ड्राइंग, संगीत रचना, और यांत्रिक [[कंप्यूटर एडेड डिजाइन]]<ref>{{citation|doi = 10.1145/98188.98197|last1 = Vlissides|first1 = J M|last2 = Linton|first2 = M A|year = 1990|title = Unidraw: a framework for building domain-specific graphical editors|journal = ACM Transactions on Information Systems|volume = 8|issue = 3|pages =237–268|s2cid = 11248368}}</ref><ref>{{citation|last = Johnson|first = R E|year = 1992|title = Documenting frameworks using patterns|publisher = ACM Press|journal = Proceedings of the Conference on Object Oriented Programming Systems Languages and Applications|pages = 63–76}}</ref>
Line 38: Line 31:
* [[निर्णय समर्थन प्रणाली]]<ref>{{citation|last = Gachet|first = A|year = 2003|title = Software Frameworks for Developing Decision Support Systems – A New Component in the Classification of DSS Development Tools|journal = Journal of Decision Systems|volume = 12|issue = 3|pages = 271–281|doi = 10.3166/jds.12.271-280|s2cid = 29690836}}</ref>
* [[निर्णय समर्थन प्रणाली]]<ref>{{citation|last = Gachet|first = A|year = 2003|title = Software Frameworks for Developing Decision Support Systems – A New Component in the Classification of DSS Development Tools|journal = Journal of Decision Systems|volume = 12|issue = 3|pages = 271–281|doi = 10.3166/jds.12.271-280|s2cid = 29690836}}</ref>
* मीडिया प्लेबैक और संलेखन
* मीडिया प्लेबैक और संलेखन
* वेब ढांचा
* वेब फ्रेमवर्क
* [[मध्यस्थ]]
* [[मध्यस्थ]]
* [[कैक्टस फ्रेमवर्क]] - उच्च प्रदर्शन वैज्ञानिक कंप्यूटिंग।
* [[कैक्टस फ्रेमवर्क]] - उच्च प्रदर्शन वैज्ञानिक कंप्यूटिंग।
* [[आवेदन ढांचा]] - सामान्य जीयूआई अनुप्रयोग।
* [[आवेदन ढांचा|आवेदन फ्रेमवर्क]] - सामान्य जीयूआई अनुप्रयोग।
* [[एंटरप्राइज आर्किटेक्चर फ्रेमवर्क]]
* [[एंटरप्राइज आर्किटेक्चर फ्रेमवर्क]]
* [[ओरेकल एप्लीकेशन डेवलपमेंट फ्रेमवर्क]]
* [[ओरेकल एप्लीकेशन डेवलपमेंट फ्रेमवर्क]]
* [[laravel]] (PHP फ्रेमवर्क)
* [[laravel|लारावेल]] (पीएचपी फ्रेमवर्क)
* [[मैलवेयर]], उदाहरण के लिए [[पाइपड्रीम (टूलकिट)]]
* [[मैलवेयर]], उदाहरण के लिए [[पाइपड्रीम (टूलकिट)]]


== वास्तु ==
== वास्तु ==
प्री के अनुसार,<ref>{{citation|title = Meta Patterns: A Means for Capturing the Essentials of Reusable Object-Oriented Design |author = Pree, W |journal = Proceedings of the 8th European Conference on Object-Oriented Programming |volume = 821 |pages = 150–162 |year = 1994 |publisher = [[Springer-Verlag]]|doi = 10.1007/BFb0052181 |citeseerx = 10.1.1.74.7935 |series = Lecture Notes in Computer Science |isbn = 978-3-540-58202-1 }}</ref> सॉफ्टवेयर फ्रेमवर्क में फ्रोजन स्पॉट और हॉट स्पॉट होते हैं। जमे हुए धब्बे एक सॉफ्टवेयर सिस्टम की समग्र वास्तुकला को परिभाषित करते हैं, अर्थात इसके मूल घटक और उनके बीच संबंध। ये एप्लिकेशन ढांचे के किसी भी तात्कालिकता में अपरिवर्तित (जमे हुए) रहते हैं। हॉट स्पॉट उन हिस्सों का प्रतिनिधित्व करते हैं जहां फ्रेमवर्क का उपयोग करने वाले प्रोग्रामर अपने स्वयं के प्रोजेक्ट के लिए विशिष्ट कार्यक्षमता जोड़ने के लिए अपना कोड जोड़ते हैं।
प्री के अनुसार,<ref>{{citation|title = Meta Patterns: A Means for Capturing the Essentials of Reusable Object-Oriented Design |author = Pree, W |journal = Proceedings of the 8th European Conference on Object-Oriented Programming |volume = 821 |pages = 150–162 |year = 1994 |publisher = [[Springer-Verlag]]|doi = 10.1007/BFb0052181 |citeseerx = 10.1.1.74.7935 |series = Lecture Notes in Computer Science |isbn = 978-3-540-58202-1 }}</ref> सॉफ्टवेयर फ्रेमवर्क में फ्रोजन स्पॉट और हॉट स्पॉट होते हैं। जमे हुए धब्बे एक सॉफ्टवेयर प्रणाली के समग्र आर्किटेक्चर को परिभाषित करते हैं जो इसके मूल घटकों और उनके बीच संबंधों को कहते हैं।। ये एप्लिकेशन फ्रेमवर्क के किसी भी तात्कालिकता में अपरिवर्तित (जमे हुए) रहते हैं। हॉट स्पॉट उन हिस्सों का प्रतिनिधित्व करते हैं जहां फ्रेमवर्क का उपयोग करने वाले प्रोग्रामर अपने स्वयं के प्रोजेक्ट के लिए विशिष्ट कार्यक्षमता जोड़ने के लिए अपना कोड जोड़ते हैं।


एक वस्तु-उन्मुख प्रोग्रामिंग | वस्तु-उन्मुख वातावरण में, एक रूपरेखा में [[सार वर्ग]] और वर्ग (कंप्यूटर विज्ञान) # कंक्रीट वर्ग वर्ग (कंप्यूटर विज्ञान) होते हैं। इस तरह के ढांचे के [[उदाहरण (कंप्यूटर विज्ञान)]] में मौजूदा वर्ग की [[वस्तु रचना]] और [[उपवर्ग (कंप्यूटर विज्ञान)]] शामिल हैं।<ref>{{citation|last = Buschmann|first = F|year = 1996|title = Pattern-Oriented Software Architecture Volume 1: A System of Patterns. Chichester|publisher = [[John Wiley & Sons|Wiley]]|isbn = 978-0-471-95869-7}}</ref>
वस्तु-उन्मुख वातावरण में, रूपरेखा में [[सार वर्ग|अमूर्त वर्ग]] और वर्ग (कंप्यूटर विज्ञान) कंक्रीट वर्ग (कंप्यूटर विज्ञान) होते हैं। इस प्रकार के फ्रेमवर्क के [[उदाहरण (कंप्यूटर विज्ञान)]] में मौजूदा वर्ग की [[वस्तु रचना]] और [[उपवर्ग (कंप्यूटर विज्ञान)]] सम्मिलित हैं।<ref>{{citation|last = Buschmann|first = F|year = 1996|title = Pattern-Oriented Software Architecture Volume 1: A System of Patterns. Chichester|publisher = [[John Wiley & Sons|Wiley]]|isbn = 978-0-471-95869-7}}</ref>
टेम्पलेट विधि पैटर्न का उपयोग करके आवश्यक कार्यक्षमता को लागू किया जा सकता है जिसमें जमे हुए स्पॉट को अपरिवर्तनीय विधियों के रूप में जाना जाता है और हॉट स्पॉट को वेरिएंट या हुक विधियों के रूप में जाना जाता है। सुपरक्लास में अपरिवर्तनीय विधियाँ डिफ़ॉल्ट व्यवहार प्रदान करती हैं जबकि प्रत्येक उपवर्ग में हुक विधियाँ कस्टम व्यवहार प्रदान करती हैं।


सॉफ़्टवेयर ढांचे के साथ एक ठोस सॉफ़्टवेयर सिस्टम विकसित करते समय, डेवलपर्स सिस्टम की विशिष्ट आवश्यकताओं और आवश्यकताओं के अनुसार हॉट स्पॉट का उपयोग करते हैं। सॉफ्टवेयर फ्रेमवर्क [[हॉलीवुड सिद्धांत]] पर निर्भर करता है: हमें कॉल न करें, हम आपको कॉल करेंगे।<ref>{{citation|last = Larman|first = C|year = 2001|title = Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process|isbn = 978-0-13-092569-5|publisher = [[Prentice Hall]]|edition = 2nd}}</ref><ref>{{cite book|title=Design Patterns|last1=Gamma|first1=Erich|last2=Helm|first2=Richard|last3=Johnson|first3=Ralph|last4=Vlissides|first4=John|publisher=Addison-Wesley|year=1994|isbn=0-201-63361-2|authorlink1=Erich Gamma|authorlink2=Richard Helm|authorlink3=Ralph Johnson (computer scientist)|authorlink4=John Vlissides|title-link=Design Patterns}}</ref> इसका अर्थ है कि उपयोगकर्ता-परिभाषित वर्ग (उदाहरण के लिए, नए उपवर्ग) पूर्वनिर्धारित रूपरेखा वर्गों से संदेश प्राप्त करते हैं। डेवलपर्स आमतौर पर सुपरक्लास (कंप्यूटर साइंस) [[सार विधि]]यों को लागू करके इसे संभालते हैं।
टेम्पलेट विधि पैटर्न का उपयोग करके आवश्यक कार्यक्षमता को प्रायुक्त किया जा सकता है जिसमें जमे हुए स्पॉट को अपरिवर्तनीय विधियों के रूप में जाना जाता है और हॉट स्पॉट को प्रकार या हुक विधियों के रूप में जाना जाता है। अधिवर्ग में अपरिवर्तनीय विधियाँ डिफ़ॉल्ट व्यवहार प्रदान करती हैं चूँकि प्रत्येक उपवर्ग में हुक विधियाँ कस्टम व्यवहार प्रदान करती हैं।
 
सॉफ़्टवेयर फ्रेमवर्क के साथ ठोस सॉफ़्टवेयर प्रणाली विकसित करते समय, डेवलपर्स प्रणाली की विशिष्ट आवश्यकताओं और आवश्यकताओं के अनुसार हॉट स्पॉट का उपयोग करते हैं। सॉफ्टवेयर फ्रेमवर्क [[हॉलीवुड सिद्धांत]] पर निर्भर करता है: हमें कॉल न करें, हम आपको कॉल करेंगे।<ref>{{citation|last = Larman|first = C|year = 2001|title = Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process|isbn = 978-0-13-092569-5|publisher = [[Prentice Hall]]|edition = 2nd}}</ref><ref>{{cite book|title=Design Patterns|last1=Gamma|first1=Erich|last2=Helm|first2=Richard|last3=Johnson|first3=Ralph|last4=Vlissides|first4=John|publisher=Addison-Wesley|year=1994|isbn=0-201-63361-2|authorlink1=Erich Gamma|authorlink2=Richard Helm|authorlink3=Ralph Johnson (computer scientist)|authorlink4=John Vlissides|title-link=Design Patterns}}</ref> इसका अर्थ है कि उपयोगकर्ता-परिभाषित वर्ग (उदाहरण के लिए, नए उपवर्ग) पूर्वनिर्धारित रूपरेखा वर्गों से संदेश प्राप्त करते हैं। डेवलपर्स सामान्यतः अधिवर्ग (कंप्यूटर साइंस) [[सार विधि|अमूर्त विधियों]] को प्रायुक्त करके इसे संभालते हैं।


== यह भी देखें ==
== यह भी देखें ==
Line 71: Line 65:


{{Authority control}}
{{Authority control}}
[[Category: सॉफ्टवेयर फ्रेमवर्क | सॉफ्टवेयर फ्रेमवर्क ]] [[Category: ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग]] [[Category: सॉफ़्टवेयर वास्तुशिल्प]] [[Category: सॉफ्टवेयर डिजाइन पैटर्न]]


[[Category: Machine Translated Page]]
[[Category:All articles with unsourced statements]]
[[Category:Articles with hatnote templates targeting a nonexistent page]]
[[Category:Articles with unsourced statements from April 2011]]
[[Category:Created On 16/02/2023]]
[[Category:Created On 16/02/2023]]
[[Category:Lua-based templates]]
[[Category:Machine Translated Page]]
[[Category:Missing redirects]]
[[Category:Pages with script errors]]
[[Category:Short description with empty Wikidata description]]
[[Category:Templates Vigyan Ready]]
[[Category:Templates that add a tracking category]]
[[Category:Templates that generate short descriptions]]
[[Category:Templates using TemplateData]]
[[Category:ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग]]
[[Category:सॉफ़्टवेयर वास्तुशिल्प]]
[[Category:सॉफ्टवेयर डिजाइन पैटर्न]]
[[Category:सॉफ्टवेयर फ्रेमवर्क| सॉफ्टवेयर फ्रेमवर्क ]]

Latest revision as of 10:59, 7 March 2023

कंप्यूटर प्रोग्रामिंग में, सॉफ्टवेयर फ्रेमवर्क अमूर्त (कंप्यूटर विज्ञान) है जिसमें सॉफ्टवेयर, सामान्य कार्यक्षमता प्रदान करते हुए, अतिरिक्त उपयोगकर्ता-लिखित कोड द्वारा श्रेष्ठ रूप से बदला जा सकता है, इस प्रकार एप्लिकेशन-विशिष्ट सॉफ़्टवेयर प्रदान करता है। यह एप्लिकेशन को बनाने और नियुक्त करने का मानक विधिा प्रदान करता है और सार्वभौमिक, पुन: प्रयोज्य सॉफ़्टवेयर वातावरण (बहुविकल्पी) है जो सॉफ़्टवेयर एप्लिकेशनों, उत्पादों और समाधानों के विकास को सुविधाजनक बनाने के लिए बड़े सॉफ्टवेयर मंच के भाग के रूप में विशेष कार्यक्षमता प्रदान करता है।

सॉफ्टवेयर फ्रेमवर्क में समर्थन प्रोग्राम, संकलनकर्ता, कूट भाषा पुस्तकालय, टूलसेट और एप्लिकेशन प्रोग्रामिंग अंतरफलक (एपीआई) सम्मिलित हो सकते हैं जो सॉफ्टवेयर परियोजना या सॉफ्टवेयर प्रणाली के विकास को सक्षम करने के लिए सभी अलग-अलग सॉफ्टवेयर घटकों को साथ लाते हैं।

फ्रेमवर्क में मुख्य विशिष्ट विशेषताएं होती हैं जो उन्हें सामान्य पुस्तकालय (कम्प्यूटिंग) से अलग करती हैं:

  • नियंत्रण का व्युत्क्रम: फ्रेमवर्क में, पुस्तकालयों या मानक उपयोगकर्ता एप्लिकेशनों के विपरीत, समग्र कार्यक्रम का नियंत्रण प्रवाह कॉलर द्वारा निर्धारित नहीं किया जाता है, किन्तु रूपरेखा द्वारा निर्धारित किया जाता है।[1] यह सामान्यतः टेम्पलेट विधि पैटर्न के साथ प्राप्त किया जाता है।
  • डिफ़ॉल्ट व्यवहार: यह अमूर्त वर्ग में टेम्पलेट विधि पैटर्न के अपरिवर्तनीय विधियों के साथ प्रदान किया जा सकता है जो फ्रेमवर्क द्वारा प्रदान किया जाता है।
  • प्रसारण क्षमता: उपयोगकर्ता फ्रेमवर्क का विस्तार कर सकता है - सामान्यतः चयनात्मक अधिभावी द्वारा - या प्रोग्रामर विशिष्ट कार्यक्षमता प्रदान करने के लिए विशेष उपयोगकर्ता कोड जोड़ सकते हैं। यह सामान्यतः उपवर्ग में हुक विधि द्वारा प्राप्त किया जाता है जो अधिवर्ग में टेम्पलेट विधि को अधिभावी करता है।
  • गैर-संशोधित फ्रेमवर्क कोड: उपयोगकर्ता द्वारा प्रायुक्त किए गए एक्सटेंशन को स्वीकार करते समय फ्रेमवर्क कोड को सामान्य रूप से संशोधित नहीं किया जाना चाहिए। दूसरे शब्दों में, उपयोगकर्ता फ्रेमवर्क का विस्तार कर सकते हैं, किन्तु इसके कोड को संशोधित नहीं कर सकते हैं।

उपपत्ति

सॉफ्टवेयर फ्रेमवर्क के डिजाइनरों का लक्ष्य कार्य प्रणाली प्रदान करने के अधिक मानक निम्न-स्तरीय विवरणों से निपटने के अतिरिक्त डिजाइनरों और प्रोग्रामरों को सॉफ्टवेयर आवश्यकताओं को पूरा करने के लिए अपना समय समर्पित करने की अनुमति देकर सॉफ्टवेयर विकास को सुविधाजनक बनाना है, जिससे समग्र विकास समय कम हो जाता है।[2] उदाहरण के लिए, बैंकिंग वेबसाइट विकसित करने के लिए वेब फ्रेमवर्क का उपयोग करने वाली टीम अनुरोध प्रबंधन और राज्य प्रबंधन के यांत्रिकी के अतिरिक्त विशेष रूप से बैंकिंग के लिए कोड लिखने पर ध्यान केंद्रित कर सकती है।

फ्रेमवर्क अधिकांश कार्यक्रमों के आकार में वृद्धि करते हैं, घटना जिसे कोड ब्लोट कहा जाता है। ग्राहक-मांग-संचालित एप्लिकेशनों की जरूरतों के कारण, प्रतिस्पर्धी और पूरक फ्रेमवर्क दोनों कभी-कभी उत्पाद में समाप्त हो जाते हैं। इसके अतिरिक्त, उनके एपीआई की जटिलता के कारण, फ्रेमवर्क का उपयोग करने के लिए अतिरिक्त समय सीखने की आवश्यकता के कारण समग्र विकास समय में इच्छित कमी प्राप्त नहीं की जा सकती है; यह आलोचना स्पष्ट रूप से मान्य है जब विकास कर्मचारियों द्वारा पहली बार विशेष या नए फ्रेमवर्क का सामना किया जाता है।[citation needed] यदि इस प्रकार के फ्रेमवर्क का उपयोग बाद के कार्य कार्यों में नहीं किया जाता है, तो फ्रेमवर्क को सीखने में लगने वाला समय परियोजना के कर्मचारियों से परिचित उद्देश्य-लिखित कोड से अधिक खर्च हो सकता है; कई प्रोग्रामर आम जरूरतों के लिए उपयोगी बॉयलरप्लेट कोड की प्रतियां रखते हैं।

चूँकि, बार रूपरेखा सीख लेने के बाद, भविष्य की परियोजनाएँ तेज़ और आसानी से पूरी हो सकती हैं; फ्रेमवर्क की अवधारणा आकार-फिट-सभी समाधान सेट बनाना है, और परिचितता के साथ, कोड उत्पादन तार्किक रूप से बढ़ना चाहिए। कोड के आकार के बारे में ऐसा कोई प्रमाणित नहीं किया गया है, जो अंततः आउटपुट उत्पाद के साथ बंडल किया गया है, न ही इसकी सापेक्ष दक्षता और संक्षिप्तता। किसी भी पुस्तकालय समाधान का उपयोग आवश्यक रूप से अतिरिक्त और अप्रयुक्त बाहरी गुणों को खींचता है जब तक कि सॉफ़्टवेयर संकलनकर्ता-ऑब्जेक्ट लिंकर नहीं है जो तंग (छोटा, पूर्ण नियंत्रित और निर्दिष्ट) निष्पादन योग्य मॉड्यूल बनाता है।

उद्देश्य जारी है, किन्तु उद्योग के दशक से अधिक का अनुभव[citation needed] ने दिखाया है कि सबसे प्रभावी फ्रेमवर्क वे होते हैं जो सामान्य उद्देश्यों के लिए तीसरे पक्ष द्वारा विकसित सामान्य आकार-फिट-सभी फ्रेमवर्क का उपयोग करने के अतिरिक्त कोड रीफैक्टरिंग|उद्यम के सामान्य कोड को फिर से फैक्टरिंग से विकसित होते हैं। इसका उदाहरण यह होगा कि ऑफिस सूट जैसे एप्लिकेशन पैकेज में यूजर इंटरफेस कैसे सामान्य रूप, अनुभव और डेटा-साझाकरण विशेषताओं और विधियों के लिए बढ़ता है, बार अलग-अलग बंडल किए गए एप्लिकेशनों के रूप में, सूट में एकीकृत हो जाता है जो सख्त है। और छोटा; नया/विकसित सुइट ऐसा उत्पाद हो सकता है जो अभिन्न उपयोगिता पुस्तकालयों और उपयोगकर्ता इंटरफेस को साझा करता है।

विवाद में यह प्रवृत्ति रूपरेखाओं के बारे में महत्वपूर्ण उद्देश्य उठाती है। ऐसा फ्रेमवर्क बनाना जो सुरुचिपूर्ण हो, बनाम वह जो केवल समस्या का समाधान करता हो, अभी भी विज्ञान के अतिरिक्त शिल्प है। सॉफ्टवेयर लालित्य का तात्पर्य स्पष्टता, संक्षिप्तता और थोड़ी बर्बादी (अतिरिक्त या बाहरी कार्यक्षमता, जिनमें से अधिकांश उपयोगकर्ता-परिभाषित है) है। उन रूपरेखाओं के लिए जो कोड उत्पन्न करते हैं, उदाहरण के लिए, लालित्य का अर्थ कोड का निर्माण होता है जो उचित जानकार प्रोग्रामर (और जो आसानी से परिवर्तनीय है) के लिए स्वच्छ और समझने योग्य है, जो केवल सही कोड उत्पन्न करता है। लालित्य का उद्देश्य यह है कि अपेक्षाकृत कुछ सॉफ्टवेयर फ्रेमवर्क समय की कसौटी पर खरे उतरे हैं: सबसे अच्छी रूपरेखाएँ अंतर्निहित विधि के रूप में विकसित होने में सक्षम हैं, जिस पर वे उन्नत बनाए गए थे। वहां भी, विकसित होने के बाद, ऐसे कई पैकेज अंतिम सॉफ्टवेयर को फुलाते हुए विरासत की क्षमताओं को बनाए रखेंगे क्योंकि अन्यथा बदले गए विधियों को नए विधियों के साथ समानांतर में रखा गया है।

उदाहरण

Python Powered.png

सॉफ़्टवेयर फ्रेमवर्क में सामान्यतः बूटस्ट्रैप उपयोगकर्ता एप्लिकेशनों की सहायता के लिए अधिक हाउसकीपिंग और उपयोगिता कोड होते हैं, किन्तु सामान्यतः विशिष्ट समस्या डोमेन पर ध्यान केंद्रित करते हैं, जैसे कि:

वास्तु

प्री के अनुसार,[8] सॉफ्टवेयर फ्रेमवर्क में फ्रोजन स्पॉट और हॉट स्पॉट होते हैं। जमे हुए धब्बे एक सॉफ्टवेयर प्रणाली के समग्र आर्किटेक्चर को परिभाषित करते हैं जो इसके मूल घटकों और उनके बीच संबंधों को कहते हैं।। ये एप्लिकेशन फ्रेमवर्क के किसी भी तात्कालिकता में अपरिवर्तित (जमे हुए) रहते हैं। हॉट स्पॉट उन हिस्सों का प्रतिनिधित्व करते हैं जहां फ्रेमवर्क का उपयोग करने वाले प्रोग्रामर अपने स्वयं के प्रोजेक्ट के लिए विशिष्ट कार्यक्षमता जोड़ने के लिए अपना कोड जोड़ते हैं।

वस्तु-उन्मुख वातावरण में, रूपरेखा में अमूर्त वर्ग और वर्ग (कंप्यूटर विज्ञान) कंक्रीट वर्ग (कंप्यूटर विज्ञान) होते हैं। इस प्रकार के फ्रेमवर्क के उदाहरण (कंप्यूटर विज्ञान) में मौजूदा वर्ग की वस्तु रचना और उपवर्ग (कंप्यूटर विज्ञान) सम्मिलित हैं।[9]

टेम्पलेट विधि पैटर्न का उपयोग करके आवश्यक कार्यक्षमता को प्रायुक्त किया जा सकता है जिसमें जमे हुए स्पॉट को अपरिवर्तनीय विधियों के रूप में जाना जाता है और हॉट स्पॉट को प्रकार या हुक विधियों के रूप में जाना जाता है। अधिवर्ग में अपरिवर्तनीय विधियाँ डिफ़ॉल्ट व्यवहार प्रदान करती हैं चूँकि प्रत्येक उपवर्ग में हुक विधियाँ कस्टम व्यवहार प्रदान करती हैं।

सॉफ़्टवेयर फ्रेमवर्क के साथ ठोस सॉफ़्टवेयर प्रणाली विकसित करते समय, डेवलपर्स प्रणाली की विशिष्ट आवश्यकताओं और आवश्यकताओं के अनुसार हॉट स्पॉट का उपयोग करते हैं। सॉफ्टवेयर फ्रेमवर्क हॉलीवुड सिद्धांत पर निर्भर करता है: हमें कॉल न करें, हम आपको कॉल करेंगे।[10][11] इसका अर्थ है कि उपयोगकर्ता-परिभाषित वर्ग (उदाहरण के लिए, नए उपवर्ग) पूर्वनिर्धारित रूपरेखा वर्गों से संदेश प्राप्त करते हैं। डेवलपर्स सामान्यतः अधिवर्ग (कंप्यूटर साइंस) अमूर्त विधियों को प्रायुक्त करके इसे संभालते हैं।

यह भी देखें

संदर्भ

  1. Riehle, Dirk (2000), Framework Design: A Role Modeling Approach (PDF), Swiss Federal Institute of Technology
  2. "Framework". DocForge. Archived from the original on 7 October 2018. Retrieved 15 December 2008.
  3. 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
  4. Johnson, R E (1992), "Documenting frameworks using patterns", Proceedings of the Conference on Object Oriented Programming Systems Languages and Applications, ACM Press: 63–76
  5. 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
  6. 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
  7. 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
  8. 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
  9. Buschmann, F (1996), Pattern-Oriented Software Architecture Volume 1: A System of Patterns. Chichester, Wiley, ISBN 978-0-471-95869-7
  10. 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
  11. Gamma, Erich; Helm, Richard; Johnson, Ralph; Vlissides, John (1994). Design Patterns. Addison-Wesley. ISBN 0-201-63361-2.


बाहरी संबंध