सॉफ्टवेयर संरचना: Difference between revisions
From Vigyanwiki
(→स्कोप) |
No edit summary |
||
| (7 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
{{short description|High level structures of a software system}} | {{short description|High level structures of a software system}} | ||
सॉफ्टवेयर आर्किटेक्चर एक [[सॉफ्टवेयर सिस्टम]] और ऐसी संरचनाओं और प्रणालियों को बनाने के अनुशासन के बारे में तर्क करने के लिए आवश्यक संरचनाओं का समूह है। प्रत्येक संरचना में सॉफ्टवेयर तत्व, उनके बीच संबंध और दोनों तत्वों और संबंधों के गुण सम्मिलित हैं।<ref name="DSA2">{{cite book|last=Clements|first=Paul|author2=Felix Bachmann |author3-link=Len Bass|author3=Len Bass |author4=David Garlan |author5=James Ivers |author6=Reed Little |author7=Paulo Merson |author8=Robert Nord |author9=Judith Stafford |title=Documenting Software Architectures: Views and Beyond, Second Edition|publisher = Addison-Wesley|year=2010|location=Boston|isbn=978-0-321-55268-6}}</ref><ref>{{Cite web |title=Software Architecture |url=https://www.sei.cmu.edu/research-capabilities/all-work/display.cfm?customel_datapageid_4050=21328 |access-date=2018-07-23 |website=www.sei.cmu.edu |language=en}}</ref> | |||
सॉफ्टवेयर आर्किटेक्चर एक [[सॉफ्टवेयर सिस्टम]] और ऐसी संरचनाओं और प्रणालियों को बनाने के अनुशासन के बारे में तर्क करने के लिए आवश्यक संरचनाओं का समूह है। प्रत्येक संरचना में सॉफ्टवेयर तत्व, उनके बीच संबंध और दोनों तत्वों और संबंधों के गुण | |||
सॉफ्टवेयर सिस्टम का आर्किटेक्चर एक रूपक है, जो इमारत के आर्किटेक्चर के अनुरूप है।<ref name="PERRY1992">{{Cite journal | last1 = Perry | first1 = D. E. | last2 = Wolf | first2 = A. L. | author-link2 = Alexander L. Wolf| doi = 10.1145/141874.141884 | title = Foundations for the study of software architecture | journal = [[ACM SIGSOFT Software Engineering Notes]]| volume = 17 | issue = 4 | pages = 40 | year = 1992 | url = http://users.ece.utexas.edu/~perry/work/papers/swa-sen.pdf| citeseerx = 10.1.1.40.5174 | s2cid = 628695 }}</ref> यह प्रणाली और विकास परियोजना के लिए खाका के रूप में कार्य करता है, जिसे [[परियोजना प्रबंधन]] बाद में टीमों और सम्मिलित लोगों द्वारा निष्पादित किए जाने वाले आवश्यक कार्यों को वाग्विस्तार करने के लिए उपयोग कर सकता है। | |||
सॉफ्टवेयर आर्किटेक्चर मौलिक संरचनात्मक विकल्प बनाने के बारे में है जो एक बार लागू होने के बाद बदलने के लिए महंगा है। सॉफ़्टवेयर आर्किटेक्चर विकल्पों में [[सॉफ्टवेर डिज़ाइन|सॉफ्टवेर]] के डिज़ाइन में संभावनाओं से विशिष्ट संरचनात्मक विकल्प | सॉफ्टवेयर आर्किटेक्चर मौलिक संरचनात्मक विकल्प बनाने के बारे में है जो एक बार लागू होने के बाद बदलने के लिए महंगा है। सॉफ़्टवेयर आर्किटेक्चर विकल्पों में [[सॉफ्टवेर डिज़ाइन|सॉफ्टवेर]] के डिज़ाइन में संभावनाओं से विशिष्ट संरचनात्मक विकल्प सम्मिलित होते हैं। | ||
उदाहरण के लिए, स्पेस शटल लॉन्च वाहन को नियंत्रित करने वाली प्रणालियों को बहुत तेज और बहुत विश्वसनीय होने की आवश्यकता थी। इसलिए, | उदाहरण के लिए, स्पेस शटल लॉन्च वाहन को नियंत्रित करने वाली प्रणालियों को बहुत तेज और बहुत विश्वसनीय होने की आवश्यकता थी। इसलिए, उपयुक्त [[रीयल-टाइम कंप्यूटिंग]] भाषा को चुनने की जरूरत होगी। इसके अतिरिक्त, विश्वसनीयता की आवश्यकता को पूरा करने के लिए प्रोग्राम की कई निरर्थक और स्वतंत्र रूप से निर्मित प्रतियों को चुनने और परिणामों की क्रॉस-चेकिंग करते समय इन प्रतियों को स्वतंत्र हार्डवेयर पर चलाने के लिए विकल्प बनाया जा सकता है। | ||
दस्तावेज़ीकरण [[सॉफ्टवेयर दस्तावेज|सॉफ्टवेयर]] आर्किटेक्चर हितधारकों के बीच संचार की सुविधा देता है, उच्च-स्तरीय डिज़ाइन के बारे में | दस्तावेज़ीकरण [[सॉफ्टवेयर दस्तावेज|सॉफ्टवेयर]] आर्किटेक्चर हितधारकों के बीच संचार की सुविधा देता है, उच्च-स्तरीय डिज़ाइन के बारे में प्रारम्भ निर्णय लेता है, और परियोजनाओं के बीच डिज़ाइन घटकों के पुन: उपयोग की अनुमति देता है।<ref name="SAP2">{{cite book|last=Bass|first=Len|author2=Paul Clements |author3=Rick Kazman |title=Software Architecture in Practice, Third Edition|publisher = Addison-Wesley|year=2012|location=Boston|isbn=978-0-321-81573-6}}</ref>{{rp|29–35}} | ||
[[File:Software Architecture Activities.jpg|thumb|सॉफ्टवेयर_आर्किटेक्चर_एक्टिविटीज]] | [[File:Software Architecture Activities.jpg|thumb|सॉफ्टवेयर_आर्किटेक्चर_एक्टिविटीज]] | ||
| Line 15: | Line 14: | ||
== स्कोप == | == स्कोप == | ||
सॉफ़्टवेयर आर्किटेक्चर के दायरे के अनुसार राय भिन्न होती है:<ref>{{cite web|author=SEI|title= How do you define Software Architecture?|url= http://www.sei.cmu.edu/architecture/start/glossary/definition-form.cfm |year=2006|access-date=2012-09-12}}</ref> | सॉफ़्टवेयर आर्किटेक्चर के दायरे के अनुसार राय भिन्न होती है:<ref>{{cite web|author=SEI|title= How do you define Software Architecture?|url= http://www.sei.cmu.edu/architecture/start/glossary/definition-form.cfm |year=2006|access-date=2012-09-12}}</ref> | ||
* '''मैक्रोस्कोपिक सिस्टम संरचना:''' यह आर्किटेक्चर को | * '''मैक्रोस्कोपिक सिस्टम संरचना:''' यह आर्किटेक्चर को सॉफ्टवेयर सिस्टम के उच्च-स्तरीय एब्स्ट्रक्शन (कंप्यूटर साइंस) के रूप में संदर्भित करता है जिसमें कम्प्यूटेशनल ''घटकों'' का एक साथ ''कनेक्टर्स'' का संग्रह होता है जो इन घटकों के बीच की बातचीत का वर्णन करता है।<ref>{{cite web|author=Garlan & Shaw |title= An Introduction to Software Architecture |url= https://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf |year=1994|access-date=2012-09-13}}</ref> | ||
* '''महत्वपूर्ण सामग्री- जो कुछ भी है:''' इस तथ्य को संदर्भित करता है कि सॉफ्टवेयर आर्किटेक्ट्स को उन निर्णयों से खुद को जोड़ना चाहिए जो सिस्टम और उसके हितधारकों पर उच्च प्रभाव डालते हैं।<ref name="FOWL2003">{{Cite journal | last1 = Fowler | first1 = Martin | title = Design – Who needs an architect? | doi = 10.1109/MS.2003.1231144 | journal = IEEE Software | volume = 20 | issue = 5 | pages = 11–44 | year = 2003 | s2cid = 356506 }}</ref> | * '''महत्वपूर्ण सामग्री- जो कुछ भी है:''' इस तथ्य को संदर्भित करता है कि सॉफ्टवेयर आर्किटेक्ट्स को उन निर्णयों से खुद को जोड़ना चाहिए जो सिस्टम और उसके हितधारकों पर उच्च प्रभाव डालते हैं।<ref name="FOWL2003">{{Cite journal | last1 = Fowler | first1 = Martin | title = Design – Who needs an architect? | doi = 10.1109/MS.2003.1231144 | journal = IEEE Software | volume = 20 | issue = 5 | pages = 11–44 | year = 2003 | s2cid = 356506 }}</ref> | ||
* वह जो किसी प्रणाली को उसके वातावरण में समझने के लिए मूलभूत है।<ref>[http://www.iso-architecture.org/42010/defining-architecture.html ISO/IEC/IEEE 42010: Defining "architecture"]. Iso-architecture.org. Retrieved on 2013-07-21.</ref> | * वह जो किसी प्रणाली को उसके वातावरण में समझने के लिए मूलभूत है।<ref>[http://www.iso-architecture.org/42010/defining-architecture.html ISO/IEC/IEEE 42010: Defining "architecture"]. Iso-architecture.org. Retrieved on 2013-07-21.</ref> | ||
* '''चीजें जिन्हें लोग बदलना मुश्किल समझते हैं:''' चूंकि आर्किटेक्चर डिजाइन करना सॉफ्टवेयर सिस्टम के जीवनचक्र की | * '''चीजें जिन्हें लोग बदलना मुश्किल समझते हैं:''' चूंकि आर्किटेक्चर डिजाइन करना सॉफ्टवेयर सिस्टम के जीवनचक्र की प्रारम्भ में होता है, आर्किटेक्ट को उन फैसलों पर ध्यान देना चाहिए जो पहली बार सही होने चाहिए। विचार की इस पंक्ति के बाद, उनकी अपरिवर्तनीयता को दूर करने के बाद आर्किटेक्चरल डिज़ाइन के मुद्दे गैर-आर्किटेक्चरल बन सकते हैं।<ref name="FOWL2003"/> | ||
*'''आर्किटेक्चरल डिज़ाइन निर्णयों का एक सेट:''' सॉफ़्टवेयर आर्किटेक्चर को केवल मॉडल या संरचनाओं का एक सेट नहीं माना जाना चाहिए, बल्कि उन निर्णयों को | *'''आर्किटेक्चरल डिज़ाइन निर्णयों का एक सेट:''' सॉफ़्टवेयर आर्किटेक्चर को केवल मॉडल या संरचनाओं का एक सेट नहीं माना जाना चाहिए, बल्कि उन निर्णयों को सम्मिलित करना चाहिए जो इन विशेष संरचनाओं की ओर ले जाते हैं, और उनके पीछे तर्क।<ref name="jansen05" /> इस अंतर्दृष्टि ने सॉफ्टवेयर आर्किटेक्चर [[ज्ञान प्रबंधन]] में पर्याप्त शोध किया है।<ref name="AKM">{{cite book |title=Software Architecture Knowledge Management |last1=Ali Babar |first1=Muhammad|last2=Dingsoyr|first2=Torgeir|last3=Lago|first3=Patricia|last4=van Vliet|first4=Hans|year=2009 |publisher=Springer|location=Dordrecht Heidelberg London New York |isbn=978-3-642-02373-6}}</ref> | ||
सॉफ़्टवेयर आर्किटेक्चर बनाम डिज़ाइन और आवश्यकता इंजीनियरिंग के बीच कोई स्पष्ट अंतर नहीं है (नीचे संबंधित फ़ील्ड देखें)। वे उच्च-स्तरीय इरादों से लेकर निम्न-स्तर के विवरण तक "सकर्मकत्व श्रृंखला" का हिस्सा हैं।<ref name="FAIRBANKS2010">{{cite book|author=George Fairbanks|title=Just Enough Software Architecture|year=2010|publisher=Marshall & Brainerd}}</ref>{{rp|18}} | सॉफ़्टवेयर आर्किटेक्चर बनाम डिज़ाइन और आवश्यकता इंजीनियरिंग के बीच कोई स्पष्ट अंतर नहीं है (नीचे संबंधित फ़ील्ड देखें)। वे उच्च-स्तरीय इरादों से लेकर निम्न-स्तर के विवरण तक "सकर्मकत्व श्रृंखला" का हिस्सा हैं।<ref name="FAIRBANKS2010">{{cite book|author=George Fairbanks|title=Just Enough Software Architecture|year=2010|publisher=Marshall & Brainerd}}</ref>{{rp|18}} | ||
== विशेषताएं == | == विशेषताएं == | ||
सॉफ्टवेयर आर्किटेक्चर निम्नलिखित प्रदर्शित करता है: | सॉफ्टवेयर आर्किटेक्चर निम्नलिखित प्रदर्शित करता है: | ||
'''हितधारकों की बहुलता:''' सॉफ्टवेयर सिस्टम को विभिन्न प्रकार के हितधारकों जैसे व्यवसाय प्रबंधकों, मालिकों, उपयोगकर्ताओं और ऑपरेटरों को पूरा करना होता है। सिस्टम के संबंध में इन सभी हितधारकों की अपनी चिंताएं हैं। इन चिंताओं को संतुलित करना और प्रदर्शित करना कि उन्हें संबोधित किया गया है, सिस्टम को डिजाइन करने का हिस्सा है।<ref name="SAP2" />{{rp|29–31}} इसका तात्पर्य है कि वास्तुकला में विभिन्न प्रकार की चिंताओं और हितधारकों से निपटना | '''हितधारकों की बहुलता:''' सॉफ्टवेयर सिस्टम को विभिन्न प्रकार के हितधारकों जैसे व्यवसाय प्रबंधकों, मालिकों, उपयोगकर्ताओं और ऑपरेटरों को पूरा करना होता है। सिस्टम के संबंध में इन सभी हितधारकों की अपनी चिंताएं हैं। इन चिंताओं को संतुलित करना और प्रदर्शित करना कि उन्हें संबोधित किया गया है, सिस्टम को डिजाइन करने का हिस्सा है।<ref name="SAP2" />{{rp|29–31}} इसका तात्पर्य है कि वास्तुकला में विभिन्न प्रकार की चिंताओं और हितधारकों से निपटना सम्मिलित है, और इसकी प्रकृति बहु-विषयक है। | ||
'''प्रयोजन का विभाजन:''' वास्तुकारों के लिए जटिलता को कम करने का स्थापित तरीका उन चिंताओं को अलग करना है जो डिजाइन को संचालित करती हैं। आर्किटेक्चर प्रलेखन से पता चलता है कि सभी हितधारक चिंताओं को मॉडलिंग और विभिन्न हितधारक चिंताओं से जुड़े अलग-अलग दृष्टिकोणों से आर्किटेक्चर का वर्णन करके संबोधित किया जाता है।<ref name="ISO42010"/> इन अलग-अलग विवरणों को आर्किटेक्चरल व्यू कहा जाता है (उदाहरण के लिए [[4+1 आर्किटेक्चरल व्यू मॉडल]] देखें)। | '''प्रयोजन का विभाजन:''' वास्तुकारों के लिए जटिलता को कम करने का स्थापित तरीका उन चिंताओं को अलग करना है जो डिजाइन को संचालित करती हैं। आर्किटेक्चर प्रलेखन से पता चलता है कि सभी हितधारक चिंताओं को मॉडलिंग और विभिन्न हितधारक चिंताओं से जुड़े अलग-अलग दृष्टिकोणों से आर्किटेक्चर का वर्णन करके संबोधित किया जाता है।<ref name="ISO42010"/> इन अलग-अलग विवरणों को आर्किटेक्चरल व्यू कहा जाता है (उदाहरण के लिए [[4+1 आर्किटेक्चरल व्यू मॉडल]] देखें)। | ||
'''गुणवत्ता-संचालित:''' क्लासिक सॉफ़्टवेयर डिज़ाइन दृष्टिकोण (जैसे [[जैक्सन संरचित प्रोग्रामिंग]]) आवश्यक कार्यक्षमता और सिस्टम के माध्यम से डेटा के प्रवाह द्वारा संचालित थे, लेकिन वर्तमान अंतर्दृष्टि<ref name="SAP2"/>{{rp|26–28}} यह है कि एक सॉफ्टवेयर सिस्टम का आर्किटेक्चर इसकी गुणवत्ता विशेषताओं जैसे दोष-सहिष्णुता, पिछड़े संगतता, विस्तारशीलता, विश्वसनीयता (इंजीनियरिंग), रखरखाव, [[उपलब्धता]], सुरक्षा, उपयोगिता, और अन्य ऐसी-क्षमताओं से अधिक निकटता से संबंधित है। हितधारक चिंताएं | '''गुणवत्ता-संचालित:''' क्लासिक सॉफ़्टवेयर डिज़ाइन दृष्टिकोण (जैसे [[जैक्सन संरचित प्रोग्रामिंग]]) आवश्यक कार्यक्षमता और सिस्टम के माध्यम से डेटा के प्रवाह द्वारा संचालित थे, लेकिन वर्तमान अंतर्दृष्टि<ref name="SAP2"/>{{rp|26–28}} यह है कि एक सॉफ्टवेयर सिस्टम का आर्किटेक्चर इसकी गुणवत्ता विशेषताओं जैसे दोष-सहिष्णुता, पिछड़े संगतता, विस्तारशीलता, विश्वसनीयता (इंजीनियरिंग), रखरखाव, [[उपलब्धता]], सुरक्षा, उपयोगिता, और अन्य ऐसी-क्षमताओं से अधिक निकटता से संबंधित है। हितधारक चिंताएं प्रायः इन गुणवत्ता विशेषताओं पर आवश्यकताओं में अनुवाद करती हैं, जिन्हें विभिन्न प्रकार से [[गैर-कार्यात्मक [[आवश्यकताएं]]]], अतिरिक्त-कार्यात्मक आवश्यकताएं, व्यवहार संबंधी आवश्यकताएं या गुणवत्ता विशेषता आवश्यकताएं कहा जाता है। | ||
'''आवर्ती शैलियाँ:''' बिल्डिंग आर्किटेक्चर की तरह, सॉफ्टवेयर आर्किटेक्चर अनुशासन ने आवर्ती चिंताओं को दूर करने के लिए मानक तरीके विकसित किए हैं। अमूर्तता के विभिन्न स्तरों पर इन मानक तरीकों को विभिन्न नामों से पुकारा जाता है। पुनरावर्ती समाधानों के लिए सामान्य शब्द वास्तु शैली हैं,<ref name="FAIRBANKS2010"/>{{rp|273–277}} युक्ति,<ref name="SAP2"/>{{rp|70–72}} [[संदर्भ वास्तुकला]]<ref name="REFARCHPRIMER">{{cite web |url=http://www.gaudisite.nl/ReferenceArchitecturePrimerPaper.pdf |archive-url=https://web.archive.org/web/20111219235909/http://www.gaudisite.nl/ReferenceArchitecturePrimerPaper.pdf |archive-date=2011-12-19 |url-status=live |title=A Reference Architecture Primer |last1=Muller |first1=Gerrit |date=August 20, 2007 |website=Gaudi site |access-date=November 13, 2015}}</ref><ref name="REFARCHCLASS">{{cite journal |last1=Angelov |first1=Samuil |last2=Grefen |first2=Paul |last3=Greefhorst |first3=Danny |title=A Classification of Software Reference Architectures: Analyzing Their Success and Effectiveness |journal=Proc. Of WICSA/ECSA 2009 |pages=141–150 |doi=10.1109/WICSA.2009.5290800 |year=2009 |isbn=978-1-4244-4984-2 |citeseerx=10.1.1.525.7208 |s2cid=10417628 }}</ref> और [[वास्तु पैटर्न]]।<ref name="SAP2"/>{{rp|203–205}} | '''आवर्ती शैलियाँ:''' बिल्डिंग आर्किटेक्चर की तरह, सॉफ्टवेयर आर्किटेक्चर अनुशासन ने आवर्ती चिंताओं को दूर करने के लिए मानक तरीके विकसित किए हैं। अमूर्तता के विभिन्न स्तरों पर इन मानक तरीकों को विभिन्न नामों से पुकारा जाता है। पुनरावर्ती समाधानों के लिए सामान्य शब्द वास्तु शैली हैं,<ref name="FAIRBANKS2010"/>{{rp|273–277}} युक्ति,<ref name="SAP2"/>{{rp|70–72}} [[संदर्भ वास्तुकला]]<ref name="REFARCHPRIMER">{{cite web |url=http://www.gaudisite.nl/ReferenceArchitecturePrimerPaper.pdf |archive-url=https://web.archive.org/web/20111219235909/http://www.gaudisite.nl/ReferenceArchitecturePrimerPaper.pdf |archive-date=2011-12-19 |url-status=live |title=A Reference Architecture Primer |last1=Muller |first1=Gerrit |date=August 20, 2007 |website=Gaudi site |access-date=November 13, 2015}}</ref><ref name="REFARCHCLASS">{{cite journal |last1=Angelov |first1=Samuil |last2=Grefen |first2=Paul |last3=Greefhorst |first3=Danny |title=A Classification of Software Reference Architectures: Analyzing Their Success and Effectiveness |journal=Proc. Of WICSA/ECSA 2009 |pages=141–150 |doi=10.1109/WICSA.2009.5290800 |year=2009 |isbn=978-1-4244-4984-2 |citeseerx=10.1.1.525.7208 |s2cid=10417628 }}</ref> और [[वास्तु पैटर्न]]।<ref name="SAP2"/>{{rp|203–205}} | ||
'''वैचारिक अखंडता:''' [[फ्रेड ब्रूक्स]] द्वारा अपनी 1975 की पुस्तक ''[[द मिथिकल मैन-मंथ]] '' में इस विचार को निरूपित करने के लिए पेश किया गया एक शब्द है कि | '''वैचारिक अखंडता:''' [[फ्रेड ब्रूक्स]] द्वारा अपनी 1975 की पुस्तक ''[[द मिथिकल मैन-मंथ]]'' में इस विचार को निरूपित करने के लिए पेश किया गया एक शब्द है कि सॉफ्टवेयर सिस्टम की वास्तुकला समग्र दृष्टि का प्रतिनिधित्व करती है कि इसे क्या करना चाहिए और इसे कैसे करना चाहिए। इस दृष्टि को इसके कार्यान्वयन से अलग किया जाना चाहिए। आर्किटेक्ट दृष्टि के रक्षक की भूमिका ग्रहण करता है, यह सुनिश्चित करता है कि सिस्टम में जोड़ वास्तुकला के अनुरूप हैं, इसलिए द मिथिकल मैन-महीने # वैचारिक अखंडता को संरक्षित करते हैं।<ref name="BROOKS">{{cite book | last=Brooks | first=Frederick P. Jr. |date=1975|title=The Mythical Man-Month – Essays on Software Engineering |publisher=Addison-Wesley |isbn=978-0-201-00650-6|title-link=The Mythical Man-Month }}</ref>{{rp|41–50}} | ||
'''संज्ञानात्मक बाधाएँ:''' कॉनवे का नियम पहली बार 1967 में कंप्यूटर प्रोग्रामर [[मेल्विन कॉनवे]] द्वारा बनाया गया था कि जो संगठन सिस्टम डिजाइन करते हैं, वे ऐसे डिजाइन तैयार करने के लिए विवश हैं जो इन संगठनों की संचार संरचनाओं की प्रतियां हैं। वैचारिक अखंडता के साथ, यह फ्रेड ब्रूक्स थे जिन्होंने इसे व्यापक दर्शकों के लिए पेश किया जब उन्होंने अपने सुरुचिपूर्ण क्लासिक 'द मिथिकल मैन-मंथ' में कागज और विचार का हवाला दिया, इसे कॉनवे का नियम कहा जाता है। | '''संज्ञानात्मक बाधाएँ:''' कॉनवे का नियम पहली बार 1967 में कंप्यूटर प्रोग्रामर [[मेल्विन कॉनवे]] द्वारा बनाया गया था कि जो संगठन सिस्टम डिजाइन करते हैं, वे ऐसे डिजाइन तैयार करने के लिए विवश हैं जो इन संगठनों की संचार संरचनाओं की प्रतियां हैं। वैचारिक अखंडता के साथ, यह फ्रेड ब्रूक्स थे जिन्होंने इसे व्यापक दर्शकों के लिए पेश किया जब उन्होंने अपने सुरुचिपूर्ण क्लासिक 'द मिथिकल मैन-मंथ' में कागज और विचार का हवाला दिया, इसे कॉनवे का नियम कहा जाता है। | ||
| Line 53: | Line 52: | ||
| access-date = November 1, 2015}}</ref> इस तरह के विश्लेषण करने के लिए कई तकनीकों का विकास किया गया है, जैसे [[ATAM|एटीएएम]] या सॉफ्टवेयर सिस्टम का एक दृश्य प्रतिनिधित्व बनाकर। | | access-date = November 1, 2015}}</ref> इस तरह के विश्लेषण करने के लिए कई तकनीकों का विकास किया गया है, जैसे [[ATAM|एटीएएम]] या सॉफ्टवेयर सिस्टम का एक दृश्य प्रतिनिधित्व बनाकर। | ||
* यह तत्वों और निर्णयों के पुन: उपयोग के लिए एक आधार प्रदान करता है।<ref name="PERRY1992"/><ref name="SAP2"/>{{rp|35}} एक संपूर्ण सॉफ़्टवेयर आर्किटेक्चर या उसके कुछ हिस्सों, जैसे कि अलग-अलग आर्किटेक्चरल रणनीतियों और निर्णयों का कई प्रणालियों में पुन: उपयोग किया जा सकता है, जिनके हितधारकों को समान गुणवत्ता विशेषताओं या कार्यक्षमता की आवश्यकता होती है, जिससे डिज़ाइन की लागत बचती है और डिज़ाइन की गलतियों के जोखिम को कम किया जा सकता है। | * यह तत्वों और निर्णयों के पुन: उपयोग के लिए एक आधार प्रदान करता है।<ref name="PERRY1992"/><ref name="SAP2"/>{{rp|35}} एक संपूर्ण सॉफ़्टवेयर आर्किटेक्चर या उसके कुछ हिस्सों, जैसे कि अलग-अलग आर्किटेक्चरल रणनीतियों और निर्णयों का कई प्रणालियों में पुन: उपयोग किया जा सकता है, जिनके हितधारकों को समान गुणवत्ता विशेषताओं या कार्यक्षमता की आवश्यकता होती है, जिससे डिज़ाइन की लागत बचती है और डिज़ाइन की गलतियों के जोखिम को कम किया जा सकता है। | ||
* यह | * यह प्रारम्भ डिजाइन निर्णयों का समर्थन करता है जो सिस्टम के विकास, परिनियोजन और रखरखाव जीवन को प्रभावित करते हैं।<ref name="SAP2"/>{{rp|31}} शेड्यूल और लागत में वृद्धि को रोकने के लिए जल्दी, उच्च प्रभाव वाले निर्णय लेना महत्वपूर्ण है। | ||
* यह हितधारकों के साथ संचार की सुविधा प्रदान करता है, एक ऐसी प्रणाली में योगदान देता है जो उनकी आवश्यकताओं को बेहतर ढंग से पूरा करता है।<ref name="SAP2"/>{{rp|29–31}} हितधारकों के दृष्टिकोण से जटिल प्रणालियों के बारे में संवाद करने से उन्हें उनकी घोषित आवश्यकताओं और उनके आधार पर डिजाइन निर्णयों के परिणामों को समझने में मदद मिलती है। आर्किटेक्चर सिस्टम के लागू होने से पहले डिजाइन निर्णयों के बारे में संवाद करने की क्षमता देता है, जब वे अनुकूलन के लिए अपेक्षाकृत आसान होते हैं। | * यह हितधारकों के साथ संचार की सुविधा प्रदान करता है, एक ऐसी प्रणाली में योगदान देता है जो उनकी आवश्यकताओं को बेहतर ढंग से पूरा करता है।<ref name="SAP2"/>{{rp|29–31}} हितधारकों के दृष्टिकोण से जटिल प्रणालियों के बारे में संवाद करने से उन्हें उनकी घोषित आवश्यकताओं और उनके आधार पर डिजाइन निर्णयों के परिणामों को समझने में मदद मिलती है। आर्किटेक्चर सिस्टम के लागू होने से पहले डिजाइन निर्णयों के बारे में संवाद करने की क्षमता देता है, जब वे अनुकूलन के लिए अपेक्षाकृत आसान होते हैं। | ||
* यह जोखिम प्रबंधन में मदद करता है। सॉफ्टवेयर आर्किटेक्चर जोखिम और विफलता की संभावना को कम करने में मदद करता है।<ref name="FAIRBANKS2010"/>{{rp|18}} | * यह जोखिम प्रबंधन में मदद करता है। सॉफ्टवेयर आर्किटेक्चर जोखिम और विफलता की संभावना को कम करने में मदद करता है।<ref name="FAIRBANKS2010"/>{{rp|18}} | ||
* यह [[लागत में कमी]] को सक्षम बनाता है। सॉफ्टवेयर आर्किटेक्चर जटिल आईटी परियोजनाओं में जोखिम और लागत का प्रबंधन करने का एक साधन है।<ref name="RCDA">{{cite journal |last1=Poort |first1=Eltjo |last2=van Vliet |first2=Hans |date=September 2012 |title=RCDA: Architecting as a risk- and cost management discipline |journal=Journal of Systems and Software |volume=85 |issue=9 |pages=1995–2013 |doi=10.1016/j.jss.2012.03.071 |url=https://zenodo.org/record/896159 }}</ref> | * यह [[लागत में कमी]] को सक्षम बनाता है। सॉफ्टवेयर आर्किटेक्चर जटिल आईटी परियोजनाओं में जोखिम और लागत का प्रबंधन करने का एक साधन है।<ref name="RCDA">{{cite journal |last1=Poort |first1=Eltjo |last2=van Vliet |first2=Hans |date=September 2012 |title=RCDA: Architecting as a risk- and cost management discipline |journal=Journal of Systems and Software |volume=85 |issue=9 |pages=1995–2013 |doi=10.1016/j.jss.2012.03.071 |url=https://zenodo.org/record/896159 }}</ref> | ||
== इतिहास == | == इतिहास == | ||
सॉफ्टवेयर डिजाइन और (सिविल) आर्किटेक्चर के बीच तुलना पहली बार 1960 के दशक के अंत में की गई थी,<ref>{{cite web |editor1=P. Naur |editor2=B. Randell |title=Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968 |publisher=NATO, Scientific Affairs Division |location=Brussels |year=1969 |url=http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF |archive-url=https://web.archive.org/web/20030607182458/http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF |archive-date=2003-06-07 |url-status=live |access-date=2012-11-16}}</ref> लेकिन "सॉफ्टवेयर आर्किटेक्चर" शब्द का 1990 के दशक तक व्यापक उपयोग नहीं देखा गया था।<ref>{{Cite journal|author1=P. Kruchten |author2=H. Obbink |author3=J. Stafford |title=The past, present and future of software architecture|journal=IEEE Software |volume=23 |issue=2 |pages=22 |year=2006|doi=10.1109/MS.2006.59 |s2cid=2082927 }}</ref> [[कंप्यूटर विज्ञान]] के क्षेत्र ने अपने गठन के समय से ही जटिलता से जुड़ी समस्याओं का सामना किया है। <ref>{{cite web|author=University of Waterloo|title= A Very Brief History of Computer Science |url=http://www.cs.uwaterloo.ca/~shallit/Courses/134/history.html |year=2006|access-date=2006-09-23}}</ref> पहले जटिलता की समस्याओं को डेवलपर्स द्वारा सही [[डेटा संरचना|डेटा]] संरचनाओं का चयन करके, एल्गोरिदम ([[कलन विधि]]) विकसित करके और चिंताओं को अलग करने की अवधारणा को लागू करके हल किया गया था। यद्यपि शब्द "सॉफ्टवेयर आर्किटेक्चर" उद्योग के लिए अपेक्षाकृत नया है, 1980 के दशक के मध्य से [[सॉफ्टवेयर इंजीनियरिंग]] अग्रदूतों द्वारा क्षेत्र के मौलिक सिद्धांतों को छिटपुट रूप से लागू किया गया है। सिस्टम के सॉफ़्टवेयर आर्किटेक्चर को पकड़ने और समझाने के | सॉफ्टवेयर डिजाइन और (सिविल) आर्किटेक्चर के बीच तुलना पहली बार 1960 के दशक के अंत में की गई थी,<ref>{{cite web |editor1=P. Naur |editor2=B. Randell |title=Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968 |publisher=NATO, Scientific Affairs Division |location=Brussels |year=1969 |url=http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF |archive-url=https://web.archive.org/web/20030607182458/http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1968.PDF |archive-date=2003-06-07 |url-status=live |access-date=2012-11-16}}</ref> लेकिन "सॉफ्टवेयर आर्किटेक्चर" शब्द का 1990 के दशक तक व्यापक उपयोग नहीं देखा गया था।<ref>{{Cite journal|author1=P. Kruchten |author2=H. Obbink |author3=J. Stafford |title=The past, present and future of software architecture|journal=IEEE Software |volume=23 |issue=2 |pages=22 |year=2006|doi=10.1109/MS.2006.59 |s2cid=2082927 }}</ref> [[कंप्यूटर विज्ञान]] के क्षेत्र ने अपने गठन के समय से ही जटिलता से जुड़ी समस्याओं का सामना किया है। <ref>{{cite web|author=University of Waterloo|title= A Very Brief History of Computer Science |url=http://www.cs.uwaterloo.ca/~shallit/Courses/134/history.html |year=2006|access-date=2006-09-23}}</ref> पहले जटिलता की समस्याओं को डेवलपर्स द्वारा सही [[डेटा संरचना|डेटा]] संरचनाओं का चयन करके, एल्गोरिदम ([[कलन विधि]]) विकसित करके और चिंताओं को अलग करने की अवधारणा को लागू करके हल किया गया था। यद्यपि शब्द "सॉफ्टवेयर आर्किटेक्चर" उद्योग के लिए अपेक्षाकृत नया है, 1980 के दशक के मध्य से [[सॉफ्टवेयर इंजीनियरिंग]] अग्रदूतों द्वारा क्षेत्र के मौलिक सिद्धांतों को छिटपुट रूप से लागू किया गया है। सिस्टम के सॉफ़्टवेयर आर्किटेक्चर को पकड़ने और समझाने के प्रारम्भ प्रयास सटीक और असंगठित थे, जो प्रायः बॉक्स-एंड-लाइन आरेखों के एक सेट की विशेषता थी।<ref>{{Cite journal|journal=IEEE.org|title= Introduction to the Special Issue on Software Architecture |year=2006|doi= 10.1109/TSE.1995.10003 }}</ref> | ||
अवधारणा के रूप में सॉफ्टवेयर आर्किटेक्चर की उत्पत्ति 1968 में [[एडवर्ड डिजस्ट्रा]] के शोध और 1970 के दशक की प्रारम्भ में [[डेविड पारनास]] में हुई थी। इन वैज्ञानिकों ने जोर देकर कहा कि सॉफ्टवेयर सिस्टम की संरचना मायने रखती है और संरचना को ठीक करना महत्वपूर्ण है। 1990 के दशक के दौरान वास्तुकला शैलियों ([[पैटर्न]]), [[वास्तुकला विवरण भाषा]]ओं, सॉफ्टवेयर प्रलेखन, वास्तुकला डिजाइन प्रलेखन, और औपचारिक तरीकों पर ध्यान केंद्रित करने वाले अनुसंधान कार्य के साथ अनुशासन के मौलिक पहलुओं को परिभाषित और संहिताबद्ध करने के लिए ठोस प्रयास किया गया था।<ref>{{cite web|author=Garlan & Shaw |title= An Introduction to Software Architecture |url= https://www.cs.cmu.edu/afs/cs/project/able/ftp/intro_softarch/intro_softarch.pdf |year=1994|access-date=2006-09-25}}</ref> | |||
अनुशासन के रूप में सॉफ्टवेयर आर्किटेक्चर को आगे बढ़ाने में अनुसंधान संस्थानों ने प्रमुख भूमिका निभाई है। [[मैरी शॉ (कंप्यूटर वैज्ञानिक)]] और [[कार्नेगी मेलॉन]] के [[डेविड गारलन]] ने 1996 में सॉफ्टवेयर आर्किटेक्चर: पर्सपेक्टिव्स ऑन एन इमर्जिंग डिसिप्लिन नामक पुस्तक लिखी, जिसने [[सॉफ्टवेयर घटक]], कनेक्टर्स और शैलियों जैसे सॉफ्टवेयर आर्किटेक्चर अवधारणाओं को बढ़ावा दिया। कैलिफ़ोर्निया विश्वविद्यालय, इरविन के सॉफ़्टवेयर अनुसंधान संस्थान के सॉफ़्टवेयर आर्किटेक्चर अनुसंधान में प्रयास मुख्य रूप से वास्तुशिल्प शैलियों, आर्किटेक्चर विवरण भाषाओं और गतिशील आर्किटेक्चर में निर्देशित हैं। | |||
आईईईई 1471-2000, "सॉफ्टवेयर-गहन प्रणालियों के वास्तुकला विवरण के लिए अनुशंसित अभ्यास", सॉफ्टवेयर वास्तुकला के क्षेत्र में पहला औपचारिक मानक था। इसे आईएसओ/आईईसी 42010:2007 के रूप में आईएसओ द्वारा 2007 में अपनाया गया था। नवंबर 2011 में, आईईईई 1471–2000 को आईएसओ/आईईसी/आईईईई 42010:2011, "सिस्टम्स एंड सॉफ्टवेयर इंजीनियरिंग - आर्किटेक्चर डिस्क्रिप्शन" (संयुक्त रूप से | आईईईई 1471-2000, "सॉफ्टवेयर-गहन प्रणालियों के वास्तुकला विवरण के लिए अनुशंसित अभ्यास", सॉफ्टवेयर वास्तुकला के क्षेत्र में पहला औपचारिक मानक था। इसे आईएसओ/आईईसी 42010:2007 के रूप में आईएसओ द्वारा 2007 में अपनाया गया था। नवंबर 2011 में, आईईईई 1471–2000 को आईएसओ/आईईसी/आईईईई 42010:2011, "सिस्टम्स एंड सॉफ्टवेयर इंजीनियरिंग - आर्किटेक्चर डिस्क्रिप्शन" (संयुक्त रूप से आईईईई और आईएसओ द्वारा प्रकाशित) द्वारा अधिक्रमित किया गया था।<ref name="ISO42010">{{cite web|author=ISO/IEC/IEEE|title=ISO/IEC/IEEE 42010:2011 Systems and software engineering – Architecture description|url=http://www.iso.org/iso/catalogue_detail.htm?csnumber=50508|year=2011|access-date=2012-09-12}}</ref> | ||
जबकि आईईईई 1471 में, सॉफ़्टवेयर आर्किटेक्चर सॉफ़्टवेयर-गहन प्रणालियों के आर्किटेक्चर के बारे में था, जिसे किसी भी सिस्टम के रूप में परिभाषित किया गया है, जहाँ सॉफ़्टवेयर समग्र रूप से सिस्टम के डिज़ाइन, निर्माण, परिनियोजन और विकास में आवश्यक प्रभाव डालता है, 2011 संस्करण एक कदम आगे जाता है किसी सिस्टम की आईएसओ/आईईसी 15288 और आईएसओ/आईईसी 12207 परिभाषाओं को | जबकि आईईईई 1471 में, सॉफ़्टवेयर आर्किटेक्चर सॉफ़्टवेयर-गहन प्रणालियों के आर्किटेक्चर के बारे में था, जिसे किसी भी सिस्टम के रूप में परिभाषित किया गया है, जहाँ सॉफ़्टवेयर समग्र रूप से सिस्टम के डिज़ाइन, निर्माण, परिनियोजन और विकास में आवश्यक प्रभाव डालता है, 2011 संस्करण एक कदम आगे जाता है किसी सिस्टम की आईएसओ/आईईसी 15288 और आईएसओ/आईईसी 12207 परिभाषाओं को सम्मिलित करके, जो न केवल हार्डवेयर और सॉफ़्टवेयर, बल्कि मनुष्यों, प्रक्रियाओं, प्रक्रियाओं, सुविधाओं, सामग्री और स्वाभाविक रूप से होने वाली संस्थाओं को भी समाहित करता है। यह सॉफ्टवेयर आर्किटेक्चर, [[उद्यम स्थापत्य]] और [[समाधान वास्तुकला]] के बीच संबंध को दर्शाता है। | ||
== आर्किटेक्चर गतिविधियां == | == आर्किटेक्चर गतिविधियां == | ||
ऐसी कई गतिविधियाँ हैं जो | ऐसी कई गतिविधियाँ हैं जो [[सॉफ़्टवेयर शिल्पकार]] करता है। सॉफ्टवेयर आर्किटेक्ट सामान्यतः परियोजना प्रबंधकों के साथ काम करता है, हितधारकों के साथ आर्किटेक्चरल रूप से महत्वपूर्ण आवश्यकताओं पर चर्चा करता है, सॉफ्टवेयर आर्किटेक्चर डिजाइन करता है, डिजाइन का मूल्यांकन करता है, डिजाइनरों और हितधारकों के साथ संचार करता है, वास्तुशिल्प डिजाइन का दस्तावेजीकरण करता है और बहुत कुछ।<ref name="Kruchten 2008">{{Cite journal | last1 = Kruchten | first1 = P. | title = What do software architects really do? | doi = 10.1016/j.jss.2008.08.025 | journal = Journal of Systems and Software | volume = 81 | issue = 12 | pages = 2413–2416 | year = 2008 }}</ref> सॉफ़्टवेयर आर्किटेक्चर डिज़ाइन में चार मुख्य गतिविधियाँ हैं।<ref name="hofmeister07"/> ये मूल वास्तुकला गतिविधियाँ पुनरावृत्त रूप से और प्रारंभिक सॉफ़्टवेयर विकास जीवन-चक्र के विभिन्न चरणों में, साथ ही साथ प्रणाली के विकास पर की जाती हैं। | ||
वास्तुकला विश्लेषण पर्यावरण को समझने की प्रक्रिया है जिसमें | वास्तुकला विश्लेषण पर्यावरण को समझने की प्रक्रिया है जिसमें प्रस्तावित प्रणाली प्रणाली के लिए आवश्यकताओं को संचालित और निर्धारित करेगी। विश्लेषण गतिविधि के लिए इनपुट या आवश्यकताएं किसी भी संख्या में हितधारकों से आ सकती हैं और इसमें निम्न आइटम सम्मिलित हैं: | ||
* चालू होने पर सिस्टम क्या करेगा (कार्यात्मक आवश्यकताएं) | * चालू होने पर सिस्टम क्या करेगा (कार्यात्मक आवश्यकताएं) | ||
* आईएसओ / आईईसी 25010: 2011 मानक में परिभाषित विश्वसनीयता, संचालन क्षमता, प्रदर्शन दक्षता, सुरक्षा, संगतता जैसी गैर-कार्यात्मक आवश्यकताओं को सिस्टम कितनी अच्छी तरह से निष्पादित करेगा।<ref name="ISO25010">{{cite web|author=ISO/IEC|title=ISO/IEC 25010:2011 Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models|url=http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=35733|year=2011|access-date=2012-10-08}}</ref> | * आईएसओ / आईईसी 25010: 2011 मानक में परिभाषित विश्वसनीयता, संचालन क्षमता, प्रदर्शन दक्षता, सुरक्षा, संगतता जैसी गैर-कार्यात्मक आवश्यकताओं को सिस्टम कितनी अच्छी तरह से निष्पादित करेगा।<ref name="ISO25010">{{cite web|author=ISO/IEC|title=ISO/IEC 25010:2011 Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models|url=http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=35733|year=2011|access-date=2012-10-08}}</ref> | ||
*आईएसओ 25010:2011 मानक में परिभाषित रखरखाव और हस्तांतरणीयता जैसी गैर-कार्यात्मक आवश्यकताओं का विकास-समय है।<ref name="ISO25010" /> | *आईएसओ 25010:2011 मानक में परिभाषित रखरखाव और हस्तांतरणीयता जैसी गैर-कार्यात्मक आवश्यकताओं का विकास-समय है।<ref name="ISO25010" /> | ||
* व्यावसायिक आवश्यकताएं और | * व्यावसायिक आवश्यकताएं और प्रणाली के पर्यावरणीय संदर्भ जो समय के साथ बदल सकते हैं, जैसे कि कानूनी, सामाजिक, वित्तीय, प्रतिस्पर्धी और तकनीकी चिंताएं<ref>{{cite book|author=Osterwalder and Pigneur| title = Value Creation from E-Business Models| chapter = An Ontology for e-Business Models|pages=65–97|year=2004| doi = 10.1016/B978-075066140-9/50006-0| isbn = 9780750661409|chapter-url=https://pdfs.semanticscholar.org/8513/9070e23b0b3278d73ea51b873acd99352e9c.pdf|citeseerx=10.1.1.9.6922| s2cid = 14177438| archive-url = https://web.archive.org/web/20181117063152/https://pdfs.semanticscholar.org/8513/9070e23b0b3278d73ea51b873acd99352e9c.pdf| archive-date = 2018-11-17}}</ref> | ||
विश्लेषण गतिविधि के आउटपुट वे आवश्यकताएं हैं जिनका सॉफ्टवेयर सिस्टम के आर्किटेक्चर पर मापन योग्य प्रभाव पड़ता है, जिसे वास्तुशिल्पीय रूप से महत्वपूर्ण आवश्यकताएं कहा जाता है।<ref name="ASR_Chen">{{Cite journal |doi = 10.1109/MS.2012.174|title = वास्तुकला की दृष्टि से महत्वपूर्ण आवश्यकताओं की विशेषता|journal = IEEE Software|volume = 30|issue = 2|pages = 38–45|year = 2013|last1 = Chen|first1 = Lianping|last2 = Ali Babar|first2 = Muhammad|last3 = Nuseibeh|first3 = Bashar|hdl = 10344/3061|s2cid = 17399565|hdl-access = free}}</ | विश्लेषण गतिविधि के आउटपुट वे आवश्यकताएं हैं जिनका सॉफ्टवेयर सिस्टम के आर्किटेक्चर पर मापन योग्य प्रभाव पड़ता है, जिसे वास्तुशिल्पीय रूप से महत्वपूर्ण आवश्यकताएं कहा जाता है।<ref name="ASR_Chen">{{Cite journal |doi = 10.1109/MS.2012.174|title = वास्तुकला की दृष्टि से महत्वपूर्ण आवश्यकताओं की विशेषता|journal = IEEE Software|volume = 30|issue = 2|pages = 38–45|year = 2013|last1 = Chen|first1 = Lianping|last2 = Ali Babar|first2 = Muhammad|last3 = Nuseibeh|first3 = Bashar|hdl = 10344/3061|s2cid = 17399565|hdl-access = free}}</ref> | ||
वास्तु संश्लेषण या डिजाइन एक वास्तुकला बनाने की प्रक्रिया है। विश्लेषण द्वारा निर्धारित वास्तुकला की दृष्टि से महत्वपूर्ण आवश्यकताओं, डिजाइन की वर्तमान स्थिति और किसी भी मूल्यांकन गतिविधियों के परिणामों को देखते हुए, डिजाइन बनाया और सुधार किया जाता है।<ref name="hofmeister07"/><ref name="SAP2"/>{{rp|311–326}} | वास्तु संश्लेषण या डिजाइन एक वास्तुकला बनाने की प्रक्रिया है। विश्लेषण द्वारा निर्धारित वास्तुकला की दृष्टि से महत्वपूर्ण आवश्यकताओं, डिजाइन की वर्तमान स्थिति और किसी भी मूल्यांकन गतिविधियों के परिणामों को देखते हुए, डिजाइन बनाया और सुधार किया जाता है।<ref name="hofmeister07"/><ref name="SAP2"/>{{rp|311–326}} | ||
| Line 85: | Line 84: | ||
आर्किटेक्चर इवोल्यूशन आवश्यकताओं और पर्यावरण में परिवर्तन को पूरा करने के लिए मौजूदा सॉफ़्टवेयर आर्किटेक्चर को बनाए रखने और अपनाने की प्रक्रिया है। जैसा कि सॉफ्टवेयर आर्किटेक्चर एक सॉफ्टवेयर सिस्टम की मूलभूत संरचना प्रदान करता है, इसका विकास और रखरखाव अनिवार्य रूप से इसकी मौलिक संरचना को प्रभावित करेगा। इस प्रकार, आर्किटेक्चर विकास नई कार्यक्षमता जोड़ने के साथ-साथ मौजूदा कार्यक्षमता और सिस्टम व्यवहार को बनाए रखने से संबंधित है। | आर्किटेक्चर इवोल्यूशन आवश्यकताओं और पर्यावरण में परिवर्तन को पूरा करने के लिए मौजूदा सॉफ़्टवेयर आर्किटेक्चर को बनाए रखने और अपनाने की प्रक्रिया है। जैसा कि सॉफ्टवेयर आर्किटेक्चर एक सॉफ्टवेयर सिस्टम की मूलभूत संरचना प्रदान करता है, इसका विकास और रखरखाव अनिवार्य रूप से इसकी मौलिक संरचना को प्रभावित करेगा। इस प्रकार, आर्किटेक्चर विकास नई कार्यक्षमता जोड़ने के साथ-साथ मौजूदा कार्यक्षमता और सिस्टम व्यवहार को बनाए रखने से संबंधित है। | ||
आर्किटेक्चर को महत्वपूर्ण सहायक गतिविधियों की आवश्यकता होती है। ये सहायक गतिविधियाँ कोर सॉफ़्टवेयर आर्किटेक्चर प्रक्रिया के दौरान होती हैं। वे ज्ञान प्रबंधन और संचार, डिजाइन तर्क और निर्णय लेने और प्रलेखन | आर्किटेक्चर को महत्वपूर्ण सहायक गतिविधियों की आवश्यकता होती है। ये सहायक गतिविधियाँ कोर सॉफ़्टवेयर आर्किटेक्चर प्रक्रिया के दौरान होती हैं। वे ज्ञान प्रबंधन और संचार, डिजाइन तर्क और निर्णय लेने और प्रलेखन सम्मिलित हैं। | ||
=== आर्किटेक्चर सहायक गतिविधियाँ === | === आर्किटेक्चर सहायक गतिविधियाँ === | ||
सॉफ्टवेयर आर्किटेक्चर सहायक गतिविधियाँ कोर सॉफ्टवेयर आर्किटेक्चर गतिविधियों के दौरान की जाती हैं। ये सहायक गतिविधियाँ सॉफ़्टवेयर आर्किटेक्ट को विश्लेषण, संश्लेषण, मूल्यांकन और विकास करने में सहायता करती हैं। उदाहरण के लिए, एक वास्तुकार को विश्लेषण चरण के दौरान ज्ञान इकट्ठा करना, निर्णय लेना और दस्तावेज़ बनाना होता है। | सॉफ्टवेयर आर्किटेक्चर सहायक गतिविधियाँ कोर सॉफ्टवेयर आर्किटेक्चर गतिविधियों के दौरान की जाती हैं। ये सहायक गतिविधियाँ सॉफ़्टवेयर आर्किटेक्ट को विश्लेषण, संश्लेषण, मूल्यांकन और विकास करने में सहायता करती हैं। उदाहरण के लिए, एक वास्तुकार को विश्लेषण चरण के दौरान ज्ञान इकट्ठा करना, निर्णय लेना और दस्तावेज़ बनाना होता है। | ||
* ज्ञान प्रबंधन और संचार ज्ञान की खोज और प्रबंधन का कार्य है जो | * ज्ञान प्रबंधन और संचार ज्ञान की खोज और प्रबंधन का कार्य है जो सॉफ्टवेयर आर्किटेक्चर को डिजाइन करने के लिए आवश्यक है। सॉफ्टवेयर आर्किटेक्ट अलगाव में काम नहीं करता है। वे विभिन्न हितधारकों से इनपुट, कार्यात्मक और गैर-कार्यात्मक आवश्यकताएं और डिजाइन संदर्भ प्राप्त करते हैं; और हितधारकों को आउटपुट प्रदान करता है। सॉफ्टवेयर आर्किटेक्चर का ज्ञान प्रायः मौन होता है और हितधारकों के दिमाग में बना रहता है। सॉफ्टवेयर आर्किटेक्चर नॉलेज मैनेजमेंट एक्टिविटी ज्ञान को खोजने, संचार करने और बनाए रखने के बारे में है। चूंकि सॉफ़्टवेयर आर्किटेक्चर डिज़ाइन के मुद्दे जटिल और अन्योन्याश्रित हैं, डिज़ाइन तर्क में ज्ञान अंतर गलत सॉफ़्टवेयर आर्किटेक्चर डिज़ाइन का कारण बन सकता है।<ref name="Kruchten 2008" /><ref name="SAKM">{{cite book|last1=Babar|first1=M.A.|last2=Dingsøyr|first2=T.|last3=Lago|first3=P.|last4=Vliet|first4=H. van|title=Software Architecture Knowledge Management:Theory and Practice (eds.), First Edition|publisher = Springer|year=2009|isbn=978-3-642-02373-6}}</ref> ज्ञान प्रबंधन और संचार गतिविधियों के उदाहरणों में डिजाइन पैटर्न की खोज, प्रोटोटाइपिंग, अनुभवी डेवलपर्स और आर्किटेक्ट्स से पूछना, समान प्रणालियों के डिजाइनों का मूल्यांकन करना, अन्य डिजाइनरों और हितधारकों के साथ ज्ञान साझा करना और विकी पेज में अनुभव का दस्तावेजीकरण करना सम्मिलित है। | ||
* डिजाइन तर्क और निर्णय लेना डिजाइन निर्णयों के मूल्यांकन की गतिविधि है। यह गतिविधि सभी तीन मुख्य सॉफ्टवेयर आर्किटेक्चर गतिविधियों के लिए मौलिक है।<ref name="jansen05">{{Cite book | last1 = Jansen | first1 = A. | last2 = Bosch | first2 = J. | doi = 10.1109/WICSA.2005.61 | chapter = Software Architecture as a Set of Architectural Design Decisions | title = 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05) | pages = 109 | year = 2005 | isbn = 978-0-7695-2548-8 | citeseerx = 10.1.1.60.8680 | s2cid = 13492610 }}</ref><ref name="tang09">{{Cite journal | last1 = Tang | first1 = A. | last2 = Han | first2 = J. | last3 = Vasa | first3 = R. | doi = 10.1109/MS.2009.46 | title = Software Architecture Design Reasoning: A Case for Improved Methodology Support | journal = IEEE Software | volume = 26 | issue = 2 | pages = 43 | year = 2009 | hdl = 1959.3/51601 | s2cid = 12230032 }}</ref> इसमें निर्णय संदर्भों को इकट्ठा करना और संबद्ध करना, डिजाइन निर्णय समस्याओं को तैयार करना, समाधान विकल्प खोजना और निर्णय लेने से पहले ट्रेडऑफ़ का मूल्यांकन करना | * डिजाइन तर्क और निर्णय लेना डिजाइन निर्णयों के मूल्यांकन की गतिविधि है। यह गतिविधि सभी तीन मुख्य सॉफ्टवेयर आर्किटेक्चर गतिविधियों के लिए मौलिक है।<ref name="jansen05">{{Cite book | last1 = Jansen | first1 = A. | last2 = Bosch | first2 = J. | doi = 10.1109/WICSA.2005.61 | chapter = Software Architecture as a Set of Architectural Design Decisions | title = 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05) | pages = 109 | year = 2005 | isbn = 978-0-7695-2548-8 | citeseerx = 10.1.1.60.8680 | s2cid = 13492610 }}</ref><ref name="tang09">{{Cite journal | last1 = Tang | first1 = A. | last2 = Han | first2 = J. | last3 = Vasa | first3 = R. | doi = 10.1109/MS.2009.46 | title = Software Architecture Design Reasoning: A Case for Improved Methodology Support | journal = IEEE Software | volume = 26 | issue = 2 | pages = 43 | year = 2009 | hdl = 1959.3/51601 | s2cid = 12230032 }}</ref> इसमें निर्णय संदर्भों को इकट्ठा करना और संबद्ध करना, डिजाइन निर्णय समस्याओं को तैयार करना, समाधान विकल्प खोजना और निर्णय लेने से पहले ट्रेडऑफ़ का मूल्यांकन करना सम्मिलित है। यह प्रक्रिया महत्वपूर्ण वास्तु आवश्यकताओं और सॉफ़्टवेयर आर्किटेक्चर निर्णयों और सॉफ़्टवेयर आर्किटेक्चर विश्लेषण, संश्लेषण और मूल्यांकन का मूल्यांकन करते समय निर्णय ग्रैन्युलैरिटी के विभिन्न स्तरों पर होती है। तार्किक गतिविधियों के उदाहरणों में गुणवत्ता विशेषताओं पर किसी आवश्यकता या डिज़ाइन के प्रभाव को समझना, किसी डिज़ाइन के कारण होने वाली समस्याओं पर सवाल उठाना, संभावित समाधान विकल्पों का आकलन करना और समाधानों के बीच ट्रेडऑफ़ का मूल्यांकन करना सम्मिलित है। | ||
* दस्तावेज़ीकरण सॉफ़्टवेयर आर्किटेक्चर प्रक्रिया के दौरान उत्पन्न डिज़ाइन को रिकॉर्ड करने का कार्य है। सॉफ़्टवेयर डिज़ाइन को कई दृश्यों का उपयोग करके वर्णित किया गया है जिसमें | * दस्तावेज़ीकरण सॉफ़्टवेयर आर्किटेक्चर प्रक्रिया के दौरान उत्पन्न डिज़ाइन को रिकॉर्ड करने का कार्य है। सॉफ़्टवेयर डिज़ाइन को कई दृश्यों का उपयोग करके वर्णित किया गया है जिसमें प्रायः स्थिर दृश्य सम्मिलित होता है जो सिस्टम की कोड संरचना दिखाता है, गतिशील दृश्य जो निष्पादन के दौरान सिस्टम की क्रियाओं को दिखाता है, और एक परिनियोजन दृश्य दिखाता है कि निष्पादन के लिए हार्डवेयर पर सिस्टम कैसे रखा जाता है। क्रुचटेन का 4+1 दृश्य सॉफ्टवेयर आर्किटेक्चर के दस्तावेजीकरण के लिए सामान्यतः उपयोग किए जाने वाले दृश्यों के विवरण का सुझाव देता है;<ref name="Kru95">{{cite journal |last=Kruchten |first=Philippe |year=1995 |url=http://www.cs.ubc.ca/~gregor/teaching/papers/4+1view-architecture.pdf |title=Architectural Blueprints – The '4+1' View Model of Software Architecture |journal=IEEE Software |volume=12 |issue=6 |pages=42–50 |doi=10.1109/52.469759|arxiv=2006.04975 |s2cid=219558624 }}</ref> दस्तावेज़ीकरण सॉफ़्टवेयर आर्किटेक्चर: व्यूज़ और बियॉन्ड में उन प्रकार के नोटेशन का वर्णन है जिनका उपयोग दृश्य विवरण के भीतर किया जा सकता है।<ref name="DSA2" /> दस्तावेज़ीकरण गतिविधियों के उदाहरण एक विनिर्देश लिखना, सिस्टम डिज़ाइन मॉडल रिकॉर्ड करना, डिज़ाइन तर्काधार का दस्तावेज़ीकरण करना, दृष्टिकोण विकसित करना, विचारों का दस्तावेज़ीकरण करना है। | ||
== सॉफ्टवेयर आर्किटेक्चर विषय == | == सॉफ्टवेयर आर्किटेक्चर विषय == | ||
| Line 98: | Line 108: | ||
=== सॉफ्टवेयर आर्किटेक्चर विवरण === | === सॉफ्टवेयर आर्किटेक्चर विवरण === | ||
{{main|सॉफ्टवेयर वास्तुकला विवरण}} | {{main|सॉफ्टवेयर वास्तुकला विवरण}} | ||
सॉफ़्टवेयर आर्किटेक्चर विवरण में आर्किटेक्चर विवरण भाषाओं, आर्किटेक्चर दृष्टिकोण और आर्किटेक्चर फ्रेमवर्क जैसे तंत्र का उपयोग करके मॉडलिंग और आर्किटेक्चर का प्रतिनिधित्व करने के सिद्धांतों और प्रथाओं को | सॉफ़्टवेयर आर्किटेक्चर विवरण में आर्किटेक्चर विवरण भाषाओं, आर्किटेक्चर दृष्टिकोण और आर्किटेक्चर फ्रेमवर्क जैसे तंत्र का उपयोग करके मॉडलिंग और आर्किटेक्चर का प्रतिनिधित्व करने के सिद्धांतों और प्रथाओं को सम्मिलित किया गया है। | ||
=== आर्किटेक्चर विवरण भाषाएं === | === आर्किटेक्चर विवरण भाषाएं === | ||
{{main|वास्तुकला विवरण भाषा}} | {{main|वास्तुकला विवरण भाषा}} | ||
आर्किटेक्चर डिस्क्रिप्शन लैंग्वेज (एडीएल) | आर्किटेक्चर डिस्क्रिप्शन लैंग्वेज (एडीएल) सॉफ्टवेयर आर्किटेक्चर (आईएसओ/आईईसी 42010|आईएसओ/आईईसी/आईईईई 42010) का वर्णन करने के लिए उपयोग की जाने वाली अभिव्यक्ति का कोई साधन है। | ||
1990 के दशक के बाद से कई विशेष उद्देश्य एडीएल विकसित किए गए हैं, जिनमें आर्किटेक्चर विश्लेषण और डिजाइन भाषा (एसएई मानक), [[राइट (एडीएल)]] (कार्नेगी मेलन द्वारा विकसित), [[एक्मे (एडीएल)]] (कार्नेगी मेलॉन द्वारा विकसित), एक्सएडीएल (यूसीआई द्वारा विकसित) | 1990 के दशक के बाद से कई विशेष उद्देश्य एडीएल विकसित किए गए हैं, जिनमें आर्किटेक्चर विश्लेषण और डिजाइन भाषा (एसएई मानक), [[राइट (एडीएल)]] (कार्नेगी मेलन द्वारा विकसित), [[एक्मे (एडीएल)]] (कार्नेगी मेलॉन द्वारा विकसित), एक्सएडीएल (यूसीआई द्वारा विकसित) सम्मिलित हैं। ), [[डार्विन (संपादित करें)]] एडीएल) ([[इंपीरियल कॉलेज लंदन]] द्वारा विकसित), डीएओपी-एडीएल (मैलागा विश्वविद्यालय द्वारा विकसित), एसबीसी-एडीएल ([[राष्ट्रीय सूर्य यात-सेन विश्वविद्यालय]] द्वारा विकसित), और एडीएल (ल'अक्विला विश्वविद्यालय, इटली) द्वारा। | ||
=== वास्तुकला दृष्टिकोण === | === वास्तुकला दृष्टिकोण === | ||
{{main|मॉडल देखें}} | {{main|मॉडल देखें}} | ||
[[File:4+1 Architectural View Model.svg|thumb|264px|4+1 आर्किटेक्चरल व्यू मॉडल।]]सॉफ़्टवेयर आर्किटेक्चर विवरण | [[File:4+1 Architectural View Model.svg|thumb|264px|4+1 आर्किटेक्चरल व्यू मॉडल।]]सॉफ़्टवेयर आर्किटेक्चर विवरण सामान्यतः [[मॉडल देखें]] में व्यवस्थित होते हैं, जो बिल्डिंग आर्किटेक्चर में बने विभिन्न प्रकार के [[खाका]] के अनुरूप होते हैं। प्रत्येक दृश्य अपने दृष्टिकोण के सम्मेलनों के बाद सिस्टम चिंताओं के एक सेट को संबोधित करता है, जहां एक दृष्टिकोण एक विनिर्देश है जो किसी दिए गए सेट के परिप्रेक्ष्य से आर्किटेक्चर को व्यक्त करने वाले दृश्य में उपयोग करने के लिए नोटेशन, मॉडलिंग और विश्लेषण तकनीकों का वर्णन करता है। हितधारकों और उनकी चिंताओं के बारे में (आईएसओ/आईईसी 42010|आईएसओ/आईईसी/आईईईई 42010)। दृष्टिकोण न केवल तैयार की गई चिंताओं को निर्दिष्ट करता है (अर्थात, संबोधित किया जाना) लेकिन प्रस्तुति, मॉडल प्रकार का उपयोग किया जाता है, किसी दृश्य को अन्य दृष्टिकोणों के अनुरूप रखने के लिए फंक्शन्स और किसी भी संगति (पत्राचार) नियमों का उपयोग किया जाता है। | ||
=== आर्किटेक्चर फ्रेमवर्क === | === आर्किटेक्चर फ्रेमवर्क === | ||
{{main|आर्किटेक्चर फ्रेमवर्क}} | {{main|आर्किटेक्चर फ्रेमवर्क}} | ||
आर्किटेक्चर फ्रेमवर्क अनुप्रयोग के एक विशिष्ट डोमेन और/या हितधारकों के समुदाय (आईएसओ/आईईसी 42010|आईएसओ/आईईसी/आईईईई 42010) के भीतर स्थापित आर्किटेक्चर के विवरण के लिए सम्मेलनों, सिद्धांतों और प्रथाओं को कैप्चर करता है। एक ढांचा सामान्यतः एक या अधिक दृष्टिकोण या एडीएल के संदर्भ में लागू किया जाता है। | |||
=== स्थापत्य शैली और पैटर्न === | === स्थापत्य शैली और पैटर्न === | ||
वास्तुशिल्प पैटर्न एक दिए गए संदर्भ में सॉफ़्टवेयर आर्किटेक्चर में सामान्य रूप से होने वाली समस्या का सामान्य, पुन: प्रयोज्य समाधान है। | |||
आर्किटेक्चरल पैटर्न को | आर्किटेक्चरल पैटर्न को प्रायः सॉफ्टवेयर [[सॉफ्टवेयर डिजाइन पैटर्न]] के रूप में प्रलेखित किया जाता है। | ||
पारंपरिक भवन वास्तुकला के बाद, | पारंपरिक भवन वास्तुकला के बाद, 'सॉफ्टवेयर वास्तुकला शैली' निर्माण की एक विशिष्ट विधि है, जो इसे उल्लेखनीय (वास्तुकला शैली) बनाने वाली विशेषताओं की विशेषता है। | ||
{{cquote|'' | {{cquote|''एक स्थापत्य शैली परिभाषित करती है: संरचनात्मक संगठन के एक पैटर्न के संदर्भ में प्रणालियों का एक परिवार; घटकों और कनेक्टर्स की एक शब्दावली, इस पर बाधाओं के साथ उन्हें कैसे जोड़ा जा सकता है।''<ref name=SG>{{cite book |last1=Shaw |first1=Mary |last2=Garlan |first2=David |date=1996 |title=Software architecture: perspectives on an emerging discipline |publisher=Prentice Hall |isbn=978-0-13-182957-2}}</ref>}} | ||
{{cquote|'' | {{cquote|"आर्किटेक्चरल शैलियाँ डिज़ाइन निर्णयों और बाधाओं के पुन: प्रयोज्य 'पैकेज' हैं जो चुने हुए वांछनीय गुणों को प्रेरित करने के लिए एक आर्किटेक्चर पर लागू होते हैं।"<ref>[http://www.isr.uci.edu/architecture/styles.html UCI Software Architecture Research – UCI Software Architecture Research: Architectural Styles]. Isr.uci.edu. Retrieved on 2013-07-21.</ref>}} | ||
उनमें से कई मान्यता प्राप्त वास्तुशिल्प पैटर्न और शैलियाँ हैं: | उनमें से कई मान्यता प्राप्त वास्तुशिल्प पैटर्न और शैलियाँ हैं: | ||
* [[ब्लैकबोर्ड (कंप्यूटिंग)]] | * [[ब्लैकबोर्ड (कंप्यूटिंग)]] | ||
* क्लाइंट-सर्वर मॉडल | * क्लाइंट-सर्वर मॉडल | ||
* [[सॉफ्टवेयर घटक]] | * [[सॉफ्टवेयर घटक]] | ||
* [[डेटाबेस-केंद्रित वास्तुकला | * [[डेटाबेस-केंद्रित वास्तुकला|डेटा-केंद्रित]] | ||
* | * इवेंट-ड्रिवन (या [[निहित आह्वान]]) | ||
* | * स्तरित वास्तुकला (या [[बहुस्तरीय वास्तुकला]]) | ||
* [[माइक्रोसर्विसेज]] | * [[माइक्रोसर्विसेज]] | ||
* [[अखंड आवेदन]] | * [[अखंड आवेदन]] | ||
* [[पीयर टू पीयर]] ( | * [[पीयर टू पीयर]] (पी2पी) | ||
* [[पाइप और फिल्टर]] | * [[पाइप और फिल्टर]] | ||
* [[प्लग-इन (कंप्यूटिंग)]] | * [[प्लग-इन (कंप्यूटिंग)]] | ||
* [[प्रतिक्रियाशील वास्तुकला]] | * [[प्रतिक्रियाशील वास्तुकला]] | ||
* प्रतिनिधित्वात्मक राज्य स्थानांतरण ( | * प्रतिनिधित्वात्मक राज्य स्थानांतरण (रेस्ट) | ||
* | * नियम-आधारित | ||
* | * सेवा-उन्मुख | ||
* साझा कुछ भी नहीं वास्तुकला | * साझा कुछ भी नहीं वास्तुकला | ||
* [[अंतरिक्ष आधारित वास्तुकला]] | * [[अंतरिक्ष आधारित वास्तुकला]] | ||
कुछ स्थापत्य पैटर्न और स्थापत्य शैली को समान मानते हैं,<ref name=MSDN>[http://msdn.microsoft.com/en-us/library/ee658117.aspx Chapter 3: Architectural Patterns and Styles]. Msdn.microsoft.com. Retrieved on 2013-07-21.</ref> कुछ शैलियों को पैटर्न की विशेषज्ञता के रूप में मानते हैं। उनके पास | कुछ स्थापत्य पैटर्न और स्थापत्य शैली को समान मानते हैं,<ref name=MSDN>[http://msdn.microsoft.com/en-us/library/ee658117.aspx Chapter 3: Architectural Patterns and Styles]. Msdn.microsoft.com. Retrieved on 2013-07-21.</ref> कुछ शैलियों को पैटर्न की विशेषज्ञता के रूप में मानते हैं। उनके पास साधारण बात यह है कि आर्किटेक्ट्स के उपयोग के लिए पैटर्न और शैलियों दोनों वाक्यांश हैं, वे एक साधारण भाषा प्रदान करते हैं<ref name=MSDN/> या शब्दावली<ref name=SG/> जिसके साथ सिस्टम की कक्षाओं का वर्णन करना है। | ||
=== सॉफ्टवेयर वास्तुकला और फुर्तीली विकास === | === सॉफ्टवेयर वास्तुकला और फुर्तीली विकास === | ||
{{main| | {{main|तीव्र विकास}} | ||
ऐसी | |||
ऐसी सरोकार भी हैं कि सॉफ़्टवेयर आर्किटेक्चर बहुत [[बड़ा डिज़ाइन अप फ्रंट]] की ओर ले जाता है, विशेष रूप से फुर्तीले सॉफ़्टवेयर विकास के समर्थकों के बीच। अप-फ्रंट डिज़ाइन और चपलता के व्यापार-नापसंद को संतुलित करने के लिए कई तरीके विकसित किए गए हैं,<ref name="Boehm2004">{{cite book |title=Balancing Agility and Discipline |last1=Boehm|first1=Barry|last2=Turner|first2=Richard|year=2004|publisher=Addison-Wesley|isbn=978-0-321-18612-6}}</ref> तीव्र विधि [[गतिशील प्रणाली विकास पद्धति]] सहित, जो एक फाउंडेशन चरण को अनिवार्य करता है, जिसके दौरान पर्याप्त वास्तु नींव रखी जाती है। [[आईईईई सॉफ्टवेयर]] निपुणता और वास्तुकला के बीच बातचीत के लिए एक विशेष मुद्दा समर्पित करता है। | |||
=== सॉफ्टवेयर आर्किटेक्चर क्षरण === | === सॉफ्टवेयर आर्किटेक्चर क्षरण === | ||
सॉफ्टवेयर आर्किटेक्चर कटाव (या क्षय) | सॉफ्टवेयर आर्किटेक्चर कटाव (या क्षय) सॉफ्टवेयर सिस्टम के नियोजित और वास्तविक आर्किटेक्चर के बीच देखे गए अंतर को संदर्भित करता है जैसा कि इसके कार्यान्वयन में महसूस किया गया है।<ref>Terra, R., M.T. Valente, K. Czarnecki, and R.S. Bigonha, "Recommending Refactorings to Reverse Software Architecture Erosion", | ||
16th European Conference on Software Maintenance and Reengineering, 2012. | 16th European Conference on Software Maintenance and Reengineering, 2012. | ||
http://gsd.uwaterloo.ca/sites/default/files/Full%20Text.pdf</ref> सॉफ़्टवेयर आर्किटेक्चर का क्षरण तब होता है जब कार्यान्वयन निर्णय या तो पूरी तरह से आर्किटेक्चर-जैसी योजना को प्राप्त नहीं करते हैं या अन्यथा उस आर्किटेक्चर की बाधाओं या सिद्धांतों का उल्लंघन करते हैं।<ref name="PERRY1992"/> | http://gsd.uwaterloo.ca/sites/default/files/Full%20Text.pdf</ref> सॉफ़्टवेयर आर्किटेक्चर का क्षरण तब होता है जब कार्यान्वयन निर्णय या तो पूरी तरह से आर्किटेक्चर-जैसी योजना को प्राप्त नहीं करते हैं या अन्यथा उस आर्किटेक्चर की बाधाओं या सिद्धांतों का उल्लंघन करते हैं।<ref name="PERRY1992"/> | ||
उदाहरण के रूप में, सख्ती से अमूर्तता (कंप्यूटर विज्ञान) स्तरित वास्तुकला प्रणाली पर विचार करें, जहां प्रत्येक परत केवल उसके ठीक नीचे की परत द्वारा प्रदान की जाने वाली सेवाओं का उपयोग कर सकती है। कोई भी स्रोत कोड घटक जो इस बाधा का पालन नहीं करता है, एक आर्किटेक्चर उल्लंघन का प्रतिनिधित्व करता है। यदि सही नहीं किया जाता है, तो इस तरह के उल्लंघन आर्किटेक्चर को मोनोलिथिक ब्लॉक में बदल सकते हैं, जिसमें समझ, रखरखाव और विकास पर प्रतिकूल प्रभाव पड़ता है। | |||
कटाव को संबोधित करने के लिए विभिन्न दृष्टिकोण प्रस्तावित किए गए हैं। | कटाव को संबोधित करने के लिए विभिन्न दृष्टिकोण प्रस्तावित किए गए हैं। | ||
इन दृष्टिकोणों, जिनमें उपकरण, तकनीक और प्रक्रियाएं सम्मिलित हैं, को मुख्य रूप से तीन सामान्य श्रेणियों में वर्गीकृत किया गया है जो वास्तुकला क्षरण को कम करने, रोकने और मरम्मत करने का प्रयास करते हैं। इन व्यापक श्रेणियों के भीतर, कटाव से निपटने के लिए अपनाई गई उच्च-स्तरीय रणनीतियों को दर्शाते हुए प्रत्येक दृष्टिकोण को और विभाजित किया गया है। ये प्रक्रिया-उन्मुख वास्तुकला अनुरूपता, वास्तुकला विकास प्रबंधन, वास्तुकला डिजाइन प्रवर्तन, कार्यान्वयन लिंकेज के लिए वास्तुकला, स्व-अनुकूलन और पुनर्प्राप्ति, खोज और सामंजस्य से युक्त वास्तुकला बहाली तकनीकें हैं।<ref>{{cite journal |last1=de Silva |first1=L. |first2=D. |last2=Balasubramaniam |title=Controlling software architecture erosion: A survey |journal=Journal of Systems and Software |year=2012 |volume=85 |issue=1 |pages=132–151 |doi=10.1016/j.jss.2011.07.036}}</ref> | |||
वास्तुकला संबंधी उल्लंघनों का पता लगाने के लिए दो प्रमुख तकनीकें हैं: प्रतिबिंब मॉडल और [[डोमेन-विशिष्ट भाषा]]एं। रिफ्लेक्सियन मॉडल (आरएम) तकनीक सिस्टम के आर्किटेक्ट द्वारा प्रदान किए गए उच्च-स्तरीय मॉडल की तुलना स्रोत कोड कार्यान्वयन से करती है। आर्किटेक्चरल बाधाओं को निर्दिष्ट करने और जांचने पर ध्यान देने के साथ डोमेन-विशिष्ट भाषाएं भी हैं। | वास्तुकला संबंधी उल्लंघनों का पता लगाने के लिए दो प्रमुख तकनीकें हैं: प्रतिबिंब मॉडल और [[डोमेन-विशिष्ट भाषा]]एं। रिफ्लेक्सियन मॉडल (आरएम) तकनीक सिस्टम के आर्किटेक्ट द्वारा प्रदान किए गए उच्च-स्तरीय मॉडल की तुलना स्रोत कोड कार्यान्वयन से करती है। आर्किटेक्चरल बाधाओं को निर्दिष्ट करने और जांचने पर ध्यान देने के साथ डोमेन-विशिष्ट भाषाएं भी हैं। | ||
=== सॉफ्टवेयर आर्किटेक्चर रिकवरी === | === सॉफ्टवेयर आर्किटेक्चर रिकवरी === | ||
{{main| | {{main|सॉफ्टवेयर आर्किटेक्चर रिकवरी}} | ||
सॉफ़्टवेयर आर्किटेक्चर रिकवरी (या पुनर्निर्माण, या [[रिवर्स इंजीनियरिंग]]) में इसके कार्यान्वयन और दस्तावेज़ीकरण सहित उपलब्ध जानकारी से सॉफ़्टवेयर सिस्टम के आर्किटेक्चर को उजागर करने के तरीके, तकनीक और प्रक्रियाएं | सॉफ़्टवेयर आर्किटेक्चर रिकवरी (या पुनर्निर्माण, या [[रिवर्स इंजीनियरिंग]]) में इसके कार्यान्वयन और दस्तावेज़ीकरण सहित उपलब्ध जानकारी से सॉफ़्टवेयर सिस्टम के आर्किटेक्चर को उजागर करने के तरीके, तकनीक और प्रक्रियाएं सम्मिलित हैं। अप्रचलित या पुराने दस्तावेजों और के सामने सूचित निर्णय लेने के लिए आर्किटेक्चर रिकवरी प्रायः आवश्यक होती है। | ||
सॉफ्टवेयर आर्किटेक्चर | |||
सॉफ्टवेयर आर्किटेक्चर सॉफ्टवेयर आर्किटेक्चर डिग्रेडेशन कार्यान्वयन और रखरखाव के फैसले कल्पना की गई वास्तुकला से दूर हैं।<ref> | |||
Lungu, M. "Software architecture recovery", University of Lugano, 2008. | Lungu, M. "Software architecture recovery", University of Lugano, 2008. | ||
http://www.slideshare.net/mircea.lungu/software-architecture-recovery-in-five-questions-presentation | http://www.slideshare.net/mircea.lungu/software-architecture-recovery-in-five-questions-presentation | ||
| Line 173: | Line 187: | ||
=== डिजाइन === | === डिजाइन === | ||
{{main| | {{main|सॉफ्टवेर डिज़ाइन}} | ||
आर्किटेक्चर सॉफ्टवेयर डिज़ाइन है लेकिन सभी डिज़ाइन आर्किटेक्चरल नहीं हैं।<ref name="DSA2"/>व्यवहार में, आर्किटेक्ट वह है जो सॉफ्टवेयर आर्किटेक्चर (आर्किटेक्चरल डिजाइन) और विस्तृत डिजाइन (गैर-आर्किटेक्चरल डिजाइन) के बीच रेखा खींचता है। ऐसे कोई नियम या दिशानिर्देश नहीं हैं जो सभी मामलों में फिट हों, हालांकि इस अंतर को औपचारिक रूप देने के प्रयास किए गए हैं। | आर्किटेक्चर सॉफ्टवेयर डिज़ाइन है लेकिन सभी डिज़ाइन आर्किटेक्चरल नहीं हैं।<ref name="DSA2"/>व्यवहार में, आर्किटेक्ट वह है जो सॉफ्टवेयर आर्किटेक्चर (आर्किटेक्चरल डिजाइन) और विस्तृत डिजाइन (गैर-आर्किटेक्चरल डिजाइन) के बीच रेखा खींचता है। ऐसे कोई नियम या दिशानिर्देश नहीं हैं जो सभी मामलों में फिट हों, हालांकि इस अंतर को औपचारिक रूप देने के प्रयास किए गए हैं। | ||
तीव्रता/स्थानीय परिकल्पना के अनुसार,<ref name="edenkazman">{{cite web |author1=Amnon H. Eden |author2=Rick Kazman |title=Architecture Design Implementation |url=http://www.eden-study.org/articles/2003/icse03.pdf |year=2003 |url-status=dead |archive-url=https://web.archive.org/web/20070928035606/http://eden-study.org/articles/2003/icse03.pdf |archive-date=2007-09-28 }}</ref> वास्तुकला और विस्तृत डिजाइन के बीच भेद स्थानीयता मानदंड द्वारा परिभाषित किया गया है,<ref name="edenkazman"/>जिसके अनुसार सॉफ्टवेयर डिजाइन के बारे में एक बयान गैर-स्थानीय (आर्किटेक्चरल) है यदि और केवल अगर कोई प्रोग्राम जो इसे संतुष्ट करता है उसे एक ऐसे प्रोग्राम में विस्तारित किया जा सकता है जो नहीं करता है। उदाहरण के लिए, क्लाइंट-सर्वर शैली आर्किटेक्चरल (रणनीतिक) है क्योंकि इस सिद्धांत पर बनाए गए प्रोग्राम को ऐसे प्रोग्राम में विस्तारित किया जा सकता है जो क्लाइंट-सर्वर नहीं है- उदाहरण के लिए, पीयर-टू-पीयर नोड्स जोड़कर। | तीव्रता/स्थानीय परिकल्पना के अनुसार,<ref name="edenkazman">{{cite web |author1=Amnon H. Eden |author2=Rick Kazman |title=Architecture Design Implementation |url=http://www.eden-study.org/articles/2003/icse03.pdf |year=2003 |url-status=dead |archive-url=https://web.archive.org/web/20070928035606/http://eden-study.org/articles/2003/icse03.pdf |archive-date=2007-09-28 }}</ref> वास्तुकला और विस्तृत डिजाइन के बीच भेद स्थानीयता मानदंड द्वारा परिभाषित किया गया है,<ref name="edenkazman"/>जिसके अनुसार सॉफ्टवेयर डिजाइन के बारे में एक बयान गैर-स्थानीय (आर्किटेक्चरल) है यदि और केवल अगर कोई प्रोग्राम जो इसे संतुष्ट करता है उसे एक ऐसे प्रोग्राम में विस्तारित किया जा सकता है जो नहीं करता है। उदाहरण के लिए, क्लाइंट-सर्वर शैली आर्किटेक्चरल (रणनीतिक) है क्योंकि इस सिद्धांत पर बनाए गए प्रोग्राम को ऐसे प्रोग्राम में विस्तारित किया जा सकता है जो क्लाइंट-सर्वर नहीं है- उदाहरण के लिए, पीयर-टू-पीयर नोड्स जोड़कर। | ||
=== आवश्यकताएँ इंजीनियरिंग === | === आवश्यकताएँ इंजीनियरिंग === | ||
{{main| | {{main|आवश्यकताएँ अभियांत्रिकी}} | ||
आवश्यकताएँ इंजीनियरिंग और सॉफ़्टवेयर आर्किटेक्चर को पूरक दृष्टिकोण के रूप में देखा जा सकता है: जबकि सॉफ़्टवेयर आर्किटेक्चर '[[समाधान स्थान]]' या 'कैसे' को लक्षित करता है, आवश्यकताएँ इंजीनियरिंग '[[कम्प्यूटेशनल समस्या]]' या 'क्या' को संबोधित करती हैं।<ref name="shekaran94">{{Cite journal|author1=C. Shekaran |journal=Proceedings of IEEE International Conference on Requirements Engineering |pages=239–245 |author2=D. Garlan |author3=M. Jackson |author4=N.R. Mead |author5=C. Potts |author6=H.B. Reubenstein |year=1994|doi=10.1109/ICRE.1994.292379 |title=The role of software architecture in requirements engineering |isbn=978-0-8186-5480-0 |s2cid=3129363 }}</ref> आवश्यकताएँ इंजीनियरिंग आवश्यकताओं को पूरा करने, आवश्यकताएँ विश्लेषण, सॉफ़्टवेयर आवश्यकताएँ विशिष्टता, डेटा सत्यापन, [[आवश्यकताएँ पता लगाने की क्षमता]] और आवश्यकताओं के प्रबंधन की आवश्यकताओं को पूरा करती है। दोनों आवश्यकताएं इंजीनियरिंग और सॉफ्टवेयर आर्किटेक्चर [[हितधारक (कॉर्पोरेट)]] की | आवश्यकताएँ इंजीनियरिंग और सॉफ़्टवेयर आर्किटेक्चर को पूरक दृष्टिकोण के रूप में देखा जा सकता है: जबकि सॉफ़्टवेयर आर्किटेक्चर '[[समाधान स्थान]]' या 'कैसे' को लक्षित करता है, आवश्यकताएँ इंजीनियरिंग '[[कम्प्यूटेशनल समस्या]]' या 'क्या' को संबोधित करती हैं।<ref name="shekaran94">{{Cite journal|author1=C. Shekaran |journal=Proceedings of IEEE International Conference on Requirements Engineering |pages=239–245 |author2=D. Garlan |author3=M. Jackson |author4=N.R. Mead |author5=C. Potts |author6=H.B. Reubenstein |year=1994|doi=10.1109/ICRE.1994.292379 |title=The role of software architecture in requirements engineering |isbn=978-0-8186-5480-0 |s2cid=3129363 }}</ref> आवश्यकताएँ इंजीनियरिंग आवश्यकताओं को पूरा करने, आवश्यकताएँ विश्लेषण, सॉफ़्टवेयर आवश्यकताएँ विशिष्टता, डेटा सत्यापन, [[आवश्यकताएँ पता लगाने की क्षमता]] और आवश्यकताओं के प्रबंधन की आवश्यकताओं को पूरा करती है। दोनों आवश्यकताएं इंजीनियरिंग और सॉफ्टवेयर आर्किटेक्चर [[हितधारक (कॉर्पोरेट)]] की सरोकार, जरूरतों और इच्छाओं के इर्द-गिर्द घूमती हैं। | ||
आवश्यकताओं इंजीनियरिंग और सॉफ़्टवेयर आर्किटेक्चर के बीच काफी | आवश्यकताओं इंजीनियरिंग और सॉफ़्टवेयर आर्किटेक्चर के बीच काफी अधिव्यापन है, जैसा उदाहरण के लिए पांच औद्योगिक सॉफ़्टवेयर आर्किटेक्चर विधियों में एक अध्ययन से प्रमाणित है, जो निष्कर्ष निकाला है कि इनपुट (लक्ष्य, बाधाएं, आदि) सामान्यतः खराब परिभाषित होते हैं, और केवल खोजे जाते हैं या बेहतर समझे जाते हैं। जैसे-जैसे वास्तुकला उभरना प्रारम्भ होती है और जबकि अधिकांश वास्तु संबंधी चिंताओं को सिस्टम पर आवश्यकताओं के रूप में व्यक्त किया जाता है, वे अनिवार्य डिजाइन निर्णयों को भी सम्मिलित कर सकते हैं।<ref name="hofmeister07">{{cite journal|author1=Christine Hofmeister |author2=Philippe Kruchten |author3=Robert L. Nord |author4=Henk Obbink |author5=Alexander Ran |author6=Pierre America |title=A general model of software architecture design derived from five industrial approaches|year=2007|doi=10.1016/j.jss.2006.05.024|journal=Journal of Systems and Software |volume=80 |issue=1 |pages=106–126}}</ref> संक्षेप में, आवश्यक व्यवहार समाधान संरचना को प्रभावित करता है, जो बदले में नई आवश्यकताओं को प्रस्तुत कर सकता है।<ref name="boer09">{{Cite journal|author=Remco C. de Boer, [[Hans van Vliet]]|title=On the similarity between requirements and architecture|journal=Journal of Systems and Software|volume=82|issue=3|pages=544–550|year=2009|doi=10.1016/j.jss.2008.11.185|citeseerx=10.1.1.415.6023}}</ref> ट्विन पीक्स मॉडल जैसे दृष्टिकोण<ref name="twinpeaks">{{Cite journal|author=Bashar Nuseibeh|title=Weaving together requirements and architectures|journal=Computer|volume=34|issue=3|pages=115–119|year=2001|doi=10.1109/2.910904|url=http://oro.open.ac.uk/2213/1/00910904.pdf |archive-url=https://web.archive.org/web/20120907054241/http://oro.open.ac.uk/2213/1/00910904.pdf |archive-date=2012-09-07 |url-status=live}}</ref> आवश्यकताओं और वास्तुकला के बीच [[तालमेल]] संबंध का फायदा उठाना है। | ||
=== 'आर्किटेक्चर' के अन्य प्रकार === | === 'आर्किटेक्चर' के अन्य प्रकार === | ||
{{main| | {{main|कंप्यूटर आर्किटेक्चर|सिस्टम आर्किटेक्चर|एंटरप्राइज़ आर्किटेक्चर}} | ||
;[[कंप्यूटर आर्किटेक्चर]] | ;[[कंप्यूटर आर्किटेक्चर]] | ||
: कंप्यूटर आर्किटेक्चर केंद्रीय प्रसंस्करण इकाई - या प्रोसेसर - [[बस (कंप्यूटिंग)]] और [[स्मृति]] जैसे हार्डवेयर घटकों के सहयोग के संदर्भ में कंप्यूटर सिस्टम की आंतरिक संरचना को लक्षित करता है। | : कंप्यूटर आर्किटेक्चर केंद्रीय प्रसंस्करण इकाई - या प्रोसेसर - [[बस (कंप्यूटिंग)]] और [[स्मृति]] जैसे हार्डवेयर घटकों के सहयोग के संदर्भ में कंप्यूटर सिस्टम की आंतरिक संरचना को लक्षित करता है। | ||
[[सिस्टम आर्किटेक्चर]] | [[सिस्टम आर्किटेक्चर]] | ||
: सिस्टम आर्किटेक्चर शब्द मूल रूप से सिस्टम के आर्किटेक्चर पर लागू किया गया है जिसमें हार्डवेयर और सॉफ्टवेयर दोनों | : सिस्टम आर्किटेक्चर शब्द मूल रूप से सिस्टम के आर्किटेक्चर पर लागू किया गया है जिसमें हार्डवेयर और सॉफ्टवेयर दोनों सम्मिलित हैं। सिस्टम आर्किटेक्चर द्वारा संबोधित मुख्य चिंता तब एक पूर्ण, सही ढंग से काम करने वाले डिवाइस में सॉफ्टवेयर और हार्डवेयर का एकीकरण है। एक अन्य सामान्य - बहुत व्यापक - अर्थ में, यह शब्द किसी भी जटिल [[प्रणाली]] की वास्तुकला पर लागू होता है जो [[तकनीकी]], सामाजिक-तकनीकी प्रणाली या सामाजिक प्रकृति का हो सकता है। | ||
;उद्यम स्थापत्य | ;उद्यम स्थापत्य (एंटरप्राइज़ आर्किटेक्चर) | ||
: उद्यम वास्तुकला का लक्ष्य व्यावसायिक दृष्टि और रणनीति को प्रभावी उद्यम में बदलना है। एंटरप्राइज आर्किटेक्चर [[आर्किटेक्चर फ्रेमवर्क]], जैसे [[TOGAF]] और | : उद्यम वास्तुकला का लक्ष्य व्यावसायिक दृष्टि और रणनीति को प्रभावी उद्यम में बदलना है। एंटरप्राइज आर्किटेक्चर [[आर्किटेक्चर फ्रेमवर्क]], जैसे [[TOGAF|टोगाफ]] और ज़चमन फ्रेमवर्क, सामान्यतः विभिन्न एंटरप्राइज़ आर्किटेक्चर परतों के बीच अंतर करते हैं। हालांकि शब्दावली फ्रेमवर्क से फ्रेमवर्क में भिन्न होती है, कई में कम से कम व्यावसायिक परत, एप्लिकेशन [[सॉफ़्टवेयर]] (या सूचना) परत और एक तकनीकी परत के बीच अंतर सम्मिलित होता है। एंटरप्राइज़ आर्किटेक्चर दूसरों के बीच इन परतों के बीच संरेखण को संबोधित करता है, सामान्यतः टॉप-डाउन दृष्टिकोण में है। | ||
== यह भी देखें == | == यह भी देखें == | ||
{{cmn|colwidth=30em| | {{cmn|colwidth=30em|*[[आर्कीमेट|आर्कीमेट]] | ||
*[[ | *[[आर्किटेक्चरल पैटर्न (कंप्यूटर साइंस)]] | ||
*[[ | *[[एंटी-पैटर्न]] | ||
*[[ | *[[विशेषता-संचालित डिज़ाइन]] | ||
*[[ | *[[सी4 मॉडल (सॉफ्टवेयर)|सी4 मॉडल]] | ||
*[[ | *[[कंप्यूटर आर्किटेक्चर]] | ||
*[[ | *[[वितरित डेटा प्रबंधन आर्किटेक्चर]] | ||
*[[ | *[[डीआरडीए|वितरित संबंधपरक डेटाबेस संरचना]] | ||
*[[ | *[[सिस्टम आर्किटेक्चर]] | ||
*[[ | *[[सिस्टम डिजाइन]] | ||
*[[ | *[[सॉफ्टवेयर आर्किटेक्चर विश्लेषण विधि]] | ||
*[[ | *[[टाइम-ट्रिगर सिस्टम]]}} | ||
*[[ | |||
}} | |||
==संदर्भ== | ==संदर्भ== | ||
{{Reflist}} | {{Reflist}} | ||
== अग्रिम पठन == | == अग्रिम पठन == | ||
*{{Cite book|last=Richards|first=Mark|title=Fundamentals of Software Architecture: An Engineering Approach|publisher=[[O'Reilly Media]]|year=2020|isbn=9781492043454}} | *{{Cite book|last=Richards|first=Mark|title=Fundamentals of Software Architecture: An Engineering Approach|publisher=[[O'Reilly Media]]|year=2020|isbn=9781492043454}} | ||
| Line 226: | Line 234: | ||
*{{cite journal |last=Kruchten |first=Philippe |year=1995 |url=http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf |archive-url=https://web.archive.org/web/20060613222204/http://www.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf |archive-date=2006-06-13 |url-status=live |title=Architectural Blueprints – The '4+1' View Model of Software Architecture |journal=IEEE Software |volume=12 |issue=6 |pages=42–50 |doi=10.1109/52.469759|arxiv=2006.04975 |s2cid=219558624 }} | *{{cite journal |last=Kruchten |first=Philippe |year=1995 |url=http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf |archive-url=https://web.archive.org/web/20060613222204/http://www.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf |archive-date=2006-06-13 |url-status=live |title=Architectural Blueprints – The '4+1' View Model of Software Architecture |journal=IEEE Software |volume=12 |issue=6 |pages=42–50 |doi=10.1109/52.469759|arxiv=2006.04975 |s2cid=219558624 }} | ||
*{{Cite book|last=Pautasso|first=Cesare|title=Software Architecture: visual lecture notes|publisher=LeanPub|year=2020|url=https://leanpub.com/software-architecture/|pages=689}} | *{{Cite book|last=Pautasso|first=Cesare|title=Software Architecture: visual lecture notes|publisher=LeanPub|year=2020|url=https://leanpub.com/software-architecture/|pages=689}} | ||
==बाहरी संबंध== | ==बाहरी संबंध== | ||
* [http://www.ibm.com/developerworks/rational/library/feb06/eeles/ Explanation on IBM Developerworks] | * [http://www.ibm.com/developerworks/rational/library/feb06/eeles/ Explanation on IBM Developerworks] | ||
* Collection of [http://www.sei.cmu.edu/architecture/start/definitions.cfm software architecture definitions] at [[Software Engineering Institute]] (SEI), [[Carnegie Mellon University]] (CMU) | * Collection of [http://www.sei.cmu.edu/architecture/start/definitions.cfm software architecture definitions] at [[Software Engineering Institute]] (SEI), [[Carnegie Mellon University]] (CMU) | ||
| Line 240: | Line 244: | ||
* [https://github.com/bp4you/sadd The Spiral Architecture Driven Development] – the [[Systems Development Life Cycle|SDLC]] based on the [[Spiral model]] aims to reduce the risks of ineffective architecture | * [https://github.com/bp4you/sadd The Spiral Architecture Driven Development] – the [[Systems Development Life Cycle|SDLC]] based on the [[Spiral model]] aims to reduce the risks of ineffective architecture | ||
* [https://www.infoq.com/architecture Software Architecture Real Life Case Studies] | * [https://www.infoq.com/architecture Software Architecture Real Life Case Studies] | ||
{{Authority control}} | {{Authority control}} | ||
{{DEFAULTSORT:Software Architecture}} | {{DEFAULTSORT:Software Architecture}} | ||
[[Category: | [[Category:Articles with hatnote templates targeting a nonexistent page|Software Architecture]] | ||
[[Category:Created On 16/02/2023]] | [[Category:CS1 English-language sources (en)]] | ||
[[Category:Collapse templates|Software Architecture]] | |||
[[Category:Commons category link is the pagename|Software Architecture]] | |||
[[Category:Created On 16/02/2023|Software Architecture]] | |||
[[Category:Lua-based templates|Software Architecture]] | |||
[[Category:Machine Translated Page|Software Architecture]] | |||
[[Category:Multi-column templates|Software Architecture]] | |||
[[Category:Navigational boxes| ]] | |||
[[Category:Navigational boxes without horizontal lists|Software Architecture]] | |||
[[Category:Pages using div col with small parameter|Software Architecture]] | |||
[[Category:Pages with reference errors|Software Architecture]] | |||
[[Category:Pages with script errors|Software Architecture]] | |||
[[Category:Short description with empty Wikidata description|Software Architecture]] | |||
[[Category:Templates Vigyan Ready|Software Architecture]] | |||
[[Category:Templates that add a tracking category|Software Architecture]] | |||
[[Category:Templates that generate short descriptions|Software Architecture]] | |||
[[Category:Templates using TemplateData|Software Architecture]] | |||
[[Category:Templates using under-protected Lua modules|Software Architecture]] | |||
[[Category:Wikipedia fully protected templates|Div col]] | |||
[[Category:सॉफ्टवेयर आर्किटेक्चर| सॉफ्टवेयर आर्किटेक्चर ]] | |||
Latest revision as of 11:02, 10 March 2023
सॉफ्टवेयर आर्किटेक्चर एक सॉफ्टवेयर सिस्टम और ऐसी संरचनाओं और प्रणालियों को बनाने के अनुशासन के बारे में तर्क करने के लिए आवश्यक संरचनाओं का समूह है। प्रत्येक संरचना में सॉफ्टवेयर तत्व, उनके बीच संबंध और दोनों तत्वों और संबंधों के गुण सम्मिलित हैं।[1][2]
सॉफ्टवेयर सिस्टम का आर्किटेक्चर एक रूपक है, जो इमारत के आर्किटेक्चर के अनुरूप है।[3] यह प्रणाली और विकास परियोजना के लिए खाका के रूप में कार्य करता है, जिसे परियोजना प्रबंधन बाद में टीमों और सम्मिलित लोगों द्वारा निष्पादित किए जाने वाले आवश्यक कार्यों को वाग्विस्तार करने के लिए उपयोग कर सकता है।
सॉफ्टवेयर आर्किटेक्चर मौलिक संरचनात्मक विकल्प बनाने के बारे में है जो एक बार लागू होने के बाद बदलने के लिए महंगा है। सॉफ़्टवेयर आर्किटेक्चर विकल्पों में सॉफ्टवेर के डिज़ाइन में संभावनाओं से विशिष्ट संरचनात्मक विकल्प सम्मिलित होते हैं।
उदाहरण के लिए, स्पेस शटल लॉन्च वाहन को नियंत्रित करने वाली प्रणालियों को बहुत तेज और बहुत विश्वसनीय होने की आवश्यकता थी। इसलिए, उपयुक्त रीयल-टाइम कंप्यूटिंग भाषा को चुनने की जरूरत होगी। इसके अतिरिक्त, विश्वसनीयता की आवश्यकता को पूरा करने के लिए प्रोग्राम की कई निरर्थक और स्वतंत्र रूप से निर्मित प्रतियों को चुनने और परिणामों की क्रॉस-चेकिंग करते समय इन प्रतियों को स्वतंत्र हार्डवेयर पर चलाने के लिए विकल्प बनाया जा सकता है।
दस्तावेज़ीकरण सॉफ्टवेयर आर्किटेक्चर हितधारकों के बीच संचार की सुविधा देता है, उच्च-स्तरीय डिज़ाइन के बारे में प्रारम्भ निर्णय लेता है, और परियोजनाओं के बीच डिज़ाइन घटकों के पुन: उपयोग की अनुमति देता है।[4]: 29–35
स्कोप
सॉफ़्टवेयर आर्किटेक्चर के दायरे के अनुसार राय भिन्न होती है:[5]
- मैक्रोस्कोपिक सिस्टम संरचना: यह आर्किटेक्चर को सॉफ्टवेयर सिस्टम के उच्च-स्तरीय एब्स्ट्रक्शन (कंप्यूटर साइंस) के रूप में संदर्भित करता है जिसमें कम्प्यूटेशनल घटकों का एक साथ कनेक्टर्स का संग्रह होता है जो इन घटकों के बीच की बातचीत का वर्णन करता है।[6]
- महत्वपूर्ण सामग्री- जो कुछ भी है: इस तथ्य को संदर्भित करता है कि सॉफ्टवेयर आर्किटेक्ट्स को उन निर्णयों से खुद को जोड़ना चाहिए जो सिस्टम और उसके हितधारकों पर उच्च प्रभाव डालते हैं।[7]
- वह जो किसी प्रणाली को उसके वातावरण में समझने के लिए मूलभूत है।[8]
- चीजें जिन्हें लोग बदलना मुश्किल समझते हैं: चूंकि आर्किटेक्चर डिजाइन करना सॉफ्टवेयर सिस्टम के जीवनचक्र की प्रारम्भ में होता है, आर्किटेक्ट को उन फैसलों पर ध्यान देना चाहिए जो पहली बार सही होने चाहिए। विचार की इस पंक्ति के बाद, उनकी अपरिवर्तनीयता को दूर करने के बाद आर्किटेक्चरल डिज़ाइन के मुद्दे गैर-आर्किटेक्चरल बन सकते हैं।[7]
- आर्किटेक्चरल डिज़ाइन निर्णयों का एक सेट: सॉफ़्टवेयर आर्किटेक्चर को केवल मॉडल या संरचनाओं का एक सेट नहीं माना जाना चाहिए, बल्कि उन निर्णयों को सम्मिलित करना चाहिए जो इन विशेष संरचनाओं की ओर ले जाते हैं, और उनके पीछे तर्क।[9] इस अंतर्दृष्टि ने सॉफ्टवेयर आर्किटेक्चर ज्ञान प्रबंधन में पर्याप्त शोध किया है।[10]
सॉफ़्टवेयर आर्किटेक्चर बनाम डिज़ाइन और आवश्यकता इंजीनियरिंग के बीच कोई स्पष्ट अंतर नहीं है (नीचे संबंधित फ़ील्ड देखें)। वे उच्च-स्तरीय इरादों से लेकर निम्न-स्तर के विवरण तक "सकर्मकत्व श्रृंखला" का हिस्सा हैं।[11]: 18
विशेषताएं
सॉफ्टवेयर आर्किटेक्चर निम्नलिखित प्रदर्शित करता है:
हितधारकों की बहुलता: सॉफ्टवेयर सिस्टम को विभिन्न प्रकार के हितधारकों जैसे व्यवसाय प्रबंधकों, मालिकों, उपयोगकर्ताओं और ऑपरेटरों को पूरा करना होता है। सिस्टम के संबंध में इन सभी हितधारकों की अपनी चिंताएं हैं। इन चिंताओं को संतुलित करना और प्रदर्शित करना कि उन्हें संबोधित किया गया है, सिस्टम को डिजाइन करने का हिस्सा है।[4]: 29–31 इसका तात्पर्य है कि वास्तुकला में विभिन्न प्रकार की चिंताओं और हितधारकों से निपटना सम्मिलित है, और इसकी प्रकृति बहु-विषयक है।
प्रयोजन का विभाजन: वास्तुकारों के लिए जटिलता को कम करने का स्थापित तरीका उन चिंताओं को अलग करना है जो डिजाइन को संचालित करती हैं। आर्किटेक्चर प्रलेखन से पता चलता है कि सभी हितधारक चिंताओं को मॉडलिंग और विभिन्न हितधारक चिंताओं से जुड़े अलग-अलग दृष्टिकोणों से आर्किटेक्चर का वर्णन करके संबोधित किया जाता है।[12] इन अलग-अलग विवरणों को आर्किटेक्चरल व्यू कहा जाता है (उदाहरण के लिए 4+1 आर्किटेक्चरल व्यू मॉडल देखें)।
गुणवत्ता-संचालित: क्लासिक सॉफ़्टवेयर डिज़ाइन दृष्टिकोण (जैसे जैक्सन संरचित प्रोग्रामिंग) आवश्यक कार्यक्षमता और सिस्टम के माध्यम से डेटा के प्रवाह द्वारा संचालित थे, लेकिन वर्तमान अंतर्दृष्टि[4]: 26–28 यह है कि एक सॉफ्टवेयर सिस्टम का आर्किटेक्चर इसकी गुणवत्ता विशेषताओं जैसे दोष-सहिष्णुता, पिछड़े संगतता, विस्तारशीलता, विश्वसनीयता (इंजीनियरिंग), रखरखाव, उपलब्धता, सुरक्षा, उपयोगिता, और अन्य ऐसी-क्षमताओं से अधिक निकटता से संबंधित है। हितधारक चिंताएं प्रायः इन गुणवत्ता विशेषताओं पर आवश्यकताओं में अनुवाद करती हैं, जिन्हें विभिन्न प्रकार से [[गैर-कार्यात्मक आवश्यकताएं]], अतिरिक्त-कार्यात्मक आवश्यकताएं, व्यवहार संबंधी आवश्यकताएं या गुणवत्ता विशेषता आवश्यकताएं कहा जाता है।
आवर्ती शैलियाँ: बिल्डिंग आर्किटेक्चर की तरह, सॉफ्टवेयर आर्किटेक्चर अनुशासन ने आवर्ती चिंताओं को दूर करने के लिए मानक तरीके विकसित किए हैं। अमूर्तता के विभिन्न स्तरों पर इन मानक तरीकों को विभिन्न नामों से पुकारा जाता है। पुनरावर्ती समाधानों के लिए सामान्य शब्द वास्तु शैली हैं,[11]: 273–277 युक्ति,[4]: 70–72 संदर्भ वास्तुकला[13][14] और वास्तु पैटर्न।[4]: 203–205
वैचारिक अखंडता: फ्रेड ब्रूक्स द्वारा अपनी 1975 की पुस्तक द मिथिकल मैन-मंथ में इस विचार को निरूपित करने के लिए पेश किया गया एक शब्द है कि सॉफ्टवेयर सिस्टम की वास्तुकला समग्र दृष्टि का प्रतिनिधित्व करती है कि इसे क्या करना चाहिए और इसे कैसे करना चाहिए। इस दृष्टि को इसके कार्यान्वयन से अलग किया जाना चाहिए। आर्किटेक्ट दृष्टि के रक्षक की भूमिका ग्रहण करता है, यह सुनिश्चित करता है कि सिस्टम में जोड़ वास्तुकला के अनुरूप हैं, इसलिए द मिथिकल मैन-महीने # वैचारिक अखंडता को संरक्षित करते हैं।[15]: 41–50
संज्ञानात्मक बाधाएँ: कॉनवे का नियम पहली बार 1967 में कंप्यूटर प्रोग्रामर मेल्विन कॉनवे द्वारा बनाया गया था कि जो संगठन सिस्टम डिजाइन करते हैं, वे ऐसे डिजाइन तैयार करने के लिए विवश हैं जो इन संगठनों की संचार संरचनाओं की प्रतियां हैं। वैचारिक अखंडता के साथ, यह फ्रेड ब्रूक्स थे जिन्होंने इसे व्यापक दर्शकों के लिए पेश किया जब उन्होंने अपने सुरुचिपूर्ण क्लासिक 'द मिथिकल मैन-मंथ' में कागज और विचार का हवाला दिया, इसे कॉनवे का नियम कहा जाता है।
प्रेरणा
सॉफ्टवेयर आर्किटेक्चर एक जटिल प्रणाली का बौद्धिक रूप से समझने योग्य सार है।[4]: 5–6 यह अमूर्तता कई लाभ प्रदान करती है:
- यह सिस्टम के निर्माण से पहले सॉफ्टवेयर सिस्टम के व्यवहार के विश्लेषण का आधार देता है।[3] यह सत्यापित करने की क्षमता कि भविष्य की सॉफ़्टवेयर प्रणाली अपने हितधारकों की ज़रूरतों को वास्तव में बनाए बिना पूरा करती है, पर्याप्त लागत-बचत और जोखिम-शमन का प्रतिनिधित्व करती है।[16] इस तरह के विश्लेषण करने के लिए कई तकनीकों का विकास किया गया है, जैसे एटीएएम या सॉफ्टवेयर सिस्टम का एक दृश्य प्रतिनिधित्व बनाकर।
- यह तत्वों और निर्णयों के पुन: उपयोग के लिए एक आधार प्रदान करता है।[3][4]: 35 एक संपूर्ण सॉफ़्टवेयर आर्किटेक्चर या उसके कुछ हिस्सों, जैसे कि अलग-अलग आर्किटेक्चरल रणनीतियों और निर्णयों का कई प्रणालियों में पुन: उपयोग किया जा सकता है, जिनके हितधारकों को समान गुणवत्ता विशेषताओं या कार्यक्षमता की आवश्यकता होती है, जिससे डिज़ाइन की लागत बचती है और डिज़ाइन की गलतियों के जोखिम को कम किया जा सकता है।
- यह प्रारम्भ डिजाइन निर्णयों का समर्थन करता है जो सिस्टम के विकास, परिनियोजन और रखरखाव जीवन को प्रभावित करते हैं।[4]: 31 शेड्यूल और लागत में वृद्धि को रोकने के लिए जल्दी, उच्च प्रभाव वाले निर्णय लेना महत्वपूर्ण है।
- यह हितधारकों के साथ संचार की सुविधा प्रदान करता है, एक ऐसी प्रणाली में योगदान देता है जो उनकी आवश्यकताओं को बेहतर ढंग से पूरा करता है।[4]: 29–31 हितधारकों के दृष्टिकोण से जटिल प्रणालियों के बारे में संवाद करने से उन्हें उनकी घोषित आवश्यकताओं और उनके आधार पर डिजाइन निर्णयों के परिणामों को समझने में मदद मिलती है। आर्किटेक्चर सिस्टम के लागू होने से पहले डिजाइन निर्णयों के बारे में संवाद करने की क्षमता देता है, जब वे अनुकूलन के लिए अपेक्षाकृत आसान होते हैं।
- यह जोखिम प्रबंधन में मदद करता है। सॉफ्टवेयर आर्किटेक्चर जोखिम और विफलता की संभावना को कम करने में मदद करता है।[11]: 18
- यह लागत में कमी को सक्षम बनाता है। सॉफ्टवेयर आर्किटेक्चर जटिल आईटी परियोजनाओं में जोखिम और लागत का प्रबंधन करने का एक साधन है।[17]
इतिहास
सॉफ्टवेयर डिजाइन और (सिविल) आर्किटेक्चर के बीच तुलना पहली बार 1960 के दशक के अंत में की गई थी,[18] लेकिन "सॉफ्टवेयर आर्किटेक्चर" शब्द का 1990 के दशक तक व्यापक उपयोग नहीं देखा गया था।[19] कंप्यूटर विज्ञान के क्षेत्र ने अपने गठन के समय से ही जटिलता से जुड़ी समस्याओं का सामना किया है। [20] पहले जटिलता की समस्याओं को डेवलपर्स द्वारा सही डेटा संरचनाओं का चयन करके, एल्गोरिदम (कलन विधि) विकसित करके और चिंताओं को अलग करने की अवधारणा को लागू करके हल किया गया था। यद्यपि शब्द "सॉफ्टवेयर आर्किटेक्चर" उद्योग के लिए अपेक्षाकृत नया है, 1980 के दशक के मध्य से सॉफ्टवेयर इंजीनियरिंग अग्रदूतों द्वारा क्षेत्र के मौलिक सिद्धांतों को छिटपुट रूप से लागू किया गया है। सिस्टम के सॉफ़्टवेयर आर्किटेक्चर को पकड़ने और समझाने के प्रारम्भ प्रयास सटीक और असंगठित थे, जो प्रायः बॉक्स-एंड-लाइन आरेखों के एक सेट की विशेषता थी।[21]
अवधारणा के रूप में सॉफ्टवेयर आर्किटेक्चर की उत्पत्ति 1968 में एडवर्ड डिजस्ट्रा के शोध और 1970 के दशक की प्रारम्भ में डेविड पारनास में हुई थी। इन वैज्ञानिकों ने जोर देकर कहा कि सॉफ्टवेयर सिस्टम की संरचना मायने रखती है और संरचना को ठीक करना महत्वपूर्ण है। 1990 के दशक के दौरान वास्तुकला शैलियों (पैटर्न), वास्तुकला विवरण भाषाओं, सॉफ्टवेयर प्रलेखन, वास्तुकला डिजाइन प्रलेखन, और औपचारिक तरीकों पर ध्यान केंद्रित करने वाले अनुसंधान कार्य के साथ अनुशासन के मौलिक पहलुओं को परिभाषित और संहिताबद्ध करने के लिए ठोस प्रयास किया गया था।[22]
अनुशासन के रूप में सॉफ्टवेयर आर्किटेक्चर को आगे बढ़ाने में अनुसंधान संस्थानों ने प्रमुख भूमिका निभाई है। मैरी शॉ (कंप्यूटर वैज्ञानिक) और कार्नेगी मेलॉन के डेविड गारलन ने 1996 में सॉफ्टवेयर आर्किटेक्चर: पर्सपेक्टिव्स ऑन एन इमर्जिंग डिसिप्लिन नामक पुस्तक लिखी, जिसने सॉफ्टवेयर घटक, कनेक्टर्स और शैलियों जैसे सॉफ्टवेयर आर्किटेक्चर अवधारणाओं को बढ़ावा दिया। कैलिफ़ोर्निया विश्वविद्यालय, इरविन के सॉफ़्टवेयर अनुसंधान संस्थान के सॉफ़्टवेयर आर्किटेक्चर अनुसंधान में प्रयास मुख्य रूप से वास्तुशिल्प शैलियों, आर्किटेक्चर विवरण भाषाओं और गतिशील आर्किटेक्चर में निर्देशित हैं।
आईईईई 1471-2000, "सॉफ्टवेयर-गहन प्रणालियों के वास्तुकला विवरण के लिए अनुशंसित अभ्यास", सॉफ्टवेयर वास्तुकला के क्षेत्र में पहला औपचारिक मानक था। इसे आईएसओ/आईईसी 42010:2007 के रूप में आईएसओ द्वारा 2007 में अपनाया गया था। नवंबर 2011 में, आईईईई 1471–2000 को आईएसओ/आईईसी/आईईईई 42010:2011, "सिस्टम्स एंड सॉफ्टवेयर इंजीनियरिंग - आर्किटेक्चर डिस्क्रिप्शन" (संयुक्त रूप से आईईईई और आईएसओ द्वारा प्रकाशित) द्वारा अधिक्रमित किया गया था।[12]
जबकि आईईईई 1471 में, सॉफ़्टवेयर आर्किटेक्चर सॉफ़्टवेयर-गहन प्रणालियों के आर्किटेक्चर के बारे में था, जिसे किसी भी सिस्टम के रूप में परिभाषित किया गया है, जहाँ सॉफ़्टवेयर समग्र रूप से सिस्टम के डिज़ाइन, निर्माण, परिनियोजन और विकास में आवश्यक प्रभाव डालता है, 2011 संस्करण एक कदम आगे जाता है किसी सिस्टम की आईएसओ/आईईसी 15288 और आईएसओ/आईईसी 12207 परिभाषाओं को सम्मिलित करके, जो न केवल हार्डवेयर और सॉफ़्टवेयर, बल्कि मनुष्यों, प्रक्रियाओं, प्रक्रियाओं, सुविधाओं, सामग्री और स्वाभाविक रूप से होने वाली संस्थाओं को भी समाहित करता है। यह सॉफ्टवेयर आर्किटेक्चर, उद्यम स्थापत्य और समाधान वास्तुकला के बीच संबंध को दर्शाता है।
आर्किटेक्चर गतिविधियां
ऐसी कई गतिविधियाँ हैं जो सॉफ़्टवेयर शिल्पकार करता है। सॉफ्टवेयर आर्किटेक्ट सामान्यतः परियोजना प्रबंधकों के साथ काम करता है, हितधारकों के साथ आर्किटेक्चरल रूप से महत्वपूर्ण आवश्यकताओं पर चर्चा करता है, सॉफ्टवेयर आर्किटेक्चर डिजाइन करता है, डिजाइन का मूल्यांकन करता है, डिजाइनरों और हितधारकों के साथ संचार करता है, वास्तुशिल्प डिजाइन का दस्तावेजीकरण करता है और बहुत कुछ।[23] सॉफ़्टवेयर आर्किटेक्चर डिज़ाइन में चार मुख्य गतिविधियाँ हैं।[24] ये मूल वास्तुकला गतिविधियाँ पुनरावृत्त रूप से और प्रारंभिक सॉफ़्टवेयर विकास जीवन-चक्र के विभिन्न चरणों में, साथ ही साथ प्रणाली के विकास पर की जाती हैं।
वास्तुकला विश्लेषण पर्यावरण को समझने की प्रक्रिया है जिसमें प्रस्तावित प्रणाली प्रणाली के लिए आवश्यकताओं को संचालित और निर्धारित करेगी। विश्लेषण गतिविधि के लिए इनपुट या आवश्यकताएं किसी भी संख्या में हितधारकों से आ सकती हैं और इसमें निम्न आइटम सम्मिलित हैं:
- चालू होने पर सिस्टम क्या करेगा (कार्यात्मक आवश्यकताएं)
- आईएसओ / आईईसी 25010: 2011 मानक में परिभाषित विश्वसनीयता, संचालन क्षमता, प्रदर्शन दक्षता, सुरक्षा, संगतता जैसी गैर-कार्यात्मक आवश्यकताओं को सिस्टम कितनी अच्छी तरह से निष्पादित करेगा।[25]
- आईएसओ 25010:2011 मानक में परिभाषित रखरखाव और हस्तांतरणीयता जैसी गैर-कार्यात्मक आवश्यकताओं का विकास-समय है।[25]
- व्यावसायिक आवश्यकताएं और प्रणाली के पर्यावरणीय संदर्भ जो समय के साथ बदल सकते हैं, जैसे कि कानूनी, सामाजिक, वित्तीय, प्रतिस्पर्धी और तकनीकी चिंताएं[26]
विश्लेषण गतिविधि के आउटपुट वे आवश्यकताएं हैं जिनका सॉफ्टवेयर सिस्टम के आर्किटेक्चर पर मापन योग्य प्रभाव पड़ता है, जिसे वास्तुशिल्पीय रूप से महत्वपूर्ण आवश्यकताएं कहा जाता है।[27]
वास्तु संश्लेषण या डिजाइन एक वास्तुकला बनाने की प्रक्रिया है। विश्लेषण द्वारा निर्धारित वास्तुकला की दृष्टि से महत्वपूर्ण आवश्यकताओं, डिजाइन की वर्तमान स्थिति और किसी भी मूल्यांकन गतिविधियों के परिणामों को देखते हुए, डिजाइन बनाया और सुधार किया जाता है।[24][4]: 311–326 आर्किटेक्चर मूल्यांकन यह निर्धारित करने की प्रक्रिया है कि वर्तमान डिज़ाइन या इसका एक भाग विश्लेषण के दौरान प्राप्त आवश्यकताओं को कितनी अच्छी तरह से संतुष्ट करता है। एक मूल्यांकन तब हो सकता है जब एक वास्तुकार एक डिजाइन निर्णय पर विचार कर रहा हो, यह डिजाइन के कुछ हिस्से के पूरा होने के बाद हो सकता है, यह अंतिम डिजाइन के पूरा होने के बाद हो सकता है या यह सिस्टम के निर्माण के बाद हो सकता है। कुछ उपलब्ध सॉफ्टवेयर आर्किटेक्चर मूल्यांकन तकनीकों में आर्किटेक्चर ट्रेडऑफ़ विश्लेषण पद्धति | आर्किटेक्चर ट्रेडऑफ़ विश्लेषण विधि (एटीएएम) और तारा शामिल हैं।[28] तकनीकों की तुलना करने के लिए रूपरेखाओं पर सारा रिपोर्ट जैसे ढांचे में चर्चा की गई है[16]और वास्तुकला समीक्षा: अभ्यास और अनुभव।[29]
आर्किटेक्चर इवोल्यूशन आवश्यकताओं और पर्यावरण में परिवर्तन को पूरा करने के लिए मौजूदा सॉफ़्टवेयर आर्किटेक्चर को बनाए रखने और अपनाने की प्रक्रिया है। जैसा कि सॉफ्टवेयर आर्किटेक्चर एक सॉफ्टवेयर सिस्टम की मूलभूत संरचना प्रदान करता है, इसका विकास और रखरखाव अनिवार्य रूप से इसकी मौलिक संरचना को प्रभावित करेगा। इस प्रकार, आर्किटेक्चर विकास नई कार्यक्षमता जोड़ने के साथ-साथ मौजूदा कार्यक्षमता और सिस्टम व्यवहार को बनाए रखने से संबंधित है।
आर्किटेक्चर को महत्वपूर्ण सहायक गतिविधियों की आवश्यकता होती है। ये सहायक गतिविधियाँ कोर सॉफ़्टवेयर आर्किटेक्चर प्रक्रिया के दौरान होती हैं। वे ज्ञान प्रबंधन और संचार, डिजाइन तर्क और निर्णय लेने और प्रलेखन सम्मिलित हैं।
आर्किटेक्चर सहायक गतिविधियाँ
सॉफ्टवेयर आर्किटेक्चर सहायक गतिविधियाँ कोर सॉफ्टवेयर आर्किटेक्चर गतिविधियों के दौरान की जाती हैं। ये सहायक गतिविधियाँ सॉफ़्टवेयर आर्किटेक्ट को विश्लेषण, संश्लेषण, मूल्यांकन और विकास करने में सहायता करती हैं। उदाहरण के लिए, एक वास्तुकार को विश्लेषण चरण के दौरान ज्ञान इकट्ठा करना, निर्णय लेना और दस्तावेज़ बनाना होता है।
- ज्ञान प्रबंधन और संचार ज्ञान की खोज और प्रबंधन का कार्य है जो सॉफ्टवेयर आर्किटेक्चर को डिजाइन करने के लिए आवश्यक है। सॉफ्टवेयर आर्किटेक्ट अलगाव में काम नहीं करता है। वे विभिन्न हितधारकों से इनपुट, कार्यात्मक और गैर-कार्यात्मक आवश्यकताएं और डिजाइन संदर्भ प्राप्त करते हैं; और हितधारकों को आउटपुट प्रदान करता है। सॉफ्टवेयर आर्किटेक्चर का ज्ञान प्रायः मौन होता है और हितधारकों के दिमाग में बना रहता है। सॉफ्टवेयर आर्किटेक्चर नॉलेज मैनेजमेंट एक्टिविटी ज्ञान को खोजने, संचार करने और बनाए रखने के बारे में है। चूंकि सॉफ़्टवेयर आर्किटेक्चर डिज़ाइन के मुद्दे जटिल और अन्योन्याश्रित हैं, डिज़ाइन तर्क में ज्ञान अंतर गलत सॉफ़्टवेयर आर्किटेक्चर डिज़ाइन का कारण बन सकता है।[23][30] ज्ञान प्रबंधन और संचार गतिविधियों के उदाहरणों में डिजाइन पैटर्न की खोज, प्रोटोटाइपिंग, अनुभवी डेवलपर्स और आर्किटेक्ट्स से पूछना, समान प्रणालियों के डिजाइनों का मूल्यांकन करना, अन्य डिजाइनरों और हितधारकों के साथ ज्ञान साझा करना और विकी पेज में अनुभव का दस्तावेजीकरण करना सम्मिलित है।
- डिजाइन तर्क और निर्णय लेना डिजाइन निर्णयों के मूल्यांकन की गतिविधि है। यह गतिविधि सभी तीन मुख्य सॉफ्टवेयर आर्किटेक्चर गतिविधियों के लिए मौलिक है।[9][31] इसमें निर्णय संदर्भों को इकट्ठा करना और संबद्ध करना, डिजाइन निर्णय समस्याओं को तैयार करना, समाधान विकल्प खोजना और निर्णय लेने से पहले ट्रेडऑफ़ का मूल्यांकन करना सम्मिलित है। यह प्रक्रिया महत्वपूर्ण वास्तु आवश्यकताओं और सॉफ़्टवेयर आर्किटेक्चर निर्णयों और सॉफ़्टवेयर आर्किटेक्चर विश्लेषण, संश्लेषण और मूल्यांकन का मूल्यांकन करते समय निर्णय ग्रैन्युलैरिटी के विभिन्न स्तरों पर होती है। तार्किक गतिविधियों के उदाहरणों में गुणवत्ता विशेषताओं पर किसी आवश्यकता या डिज़ाइन के प्रभाव को समझना, किसी डिज़ाइन के कारण होने वाली समस्याओं पर सवाल उठाना, संभावित समाधान विकल्पों का आकलन करना और समाधानों के बीच ट्रेडऑफ़ का मूल्यांकन करना सम्मिलित है।
- दस्तावेज़ीकरण सॉफ़्टवेयर आर्किटेक्चर प्रक्रिया के दौरान उत्पन्न डिज़ाइन को रिकॉर्ड करने का कार्य है। सॉफ़्टवेयर डिज़ाइन को कई दृश्यों का उपयोग करके वर्णित किया गया है जिसमें प्रायः स्थिर दृश्य सम्मिलित होता है जो सिस्टम की कोड संरचना दिखाता है, गतिशील दृश्य जो निष्पादन के दौरान सिस्टम की क्रियाओं को दिखाता है, और एक परिनियोजन दृश्य दिखाता है कि निष्पादन के लिए हार्डवेयर पर सिस्टम कैसे रखा जाता है। क्रुचटेन का 4+1 दृश्य सॉफ्टवेयर आर्किटेक्चर के दस्तावेजीकरण के लिए सामान्यतः उपयोग किए जाने वाले दृश्यों के विवरण का सुझाव देता है;[32] दस्तावेज़ीकरण सॉफ़्टवेयर आर्किटेक्चर: व्यूज़ और बियॉन्ड में उन प्रकार के नोटेशन का वर्णन है जिनका उपयोग दृश्य विवरण के भीतर किया जा सकता है।[1] दस्तावेज़ीकरण गतिविधियों के उदाहरण एक विनिर्देश लिखना, सिस्टम डिज़ाइन मॉडल रिकॉर्ड करना, डिज़ाइन तर्काधार का दस्तावेज़ीकरण करना, दृष्टिकोण विकसित करना, विचारों का दस्तावेज़ीकरण करना है।
सॉफ्टवेयर आर्किटेक्चर विषय
सॉफ्टवेयर आर्किटेक्चर विवरण
सॉफ़्टवेयर आर्किटेक्चर विवरण में आर्किटेक्चर विवरण भाषाओं, आर्किटेक्चर दृष्टिकोण और आर्किटेक्चर फ्रेमवर्क जैसे तंत्र का उपयोग करके मॉडलिंग और आर्किटेक्चर का प्रतिनिधित्व करने के सिद्धांतों और प्रथाओं को सम्मिलित किया गया है।
आर्किटेक्चर विवरण भाषाएं
आर्किटेक्चर डिस्क्रिप्शन लैंग्वेज (एडीएल) सॉफ्टवेयर आर्किटेक्चर (आईएसओ/आईईसी 42010|आईएसओ/आईईसी/आईईईई 42010) का वर्णन करने के लिए उपयोग की जाने वाली अभिव्यक्ति का कोई साधन है।
1990 के दशक के बाद से कई विशेष उद्देश्य एडीएल विकसित किए गए हैं, जिनमें आर्किटेक्चर विश्लेषण और डिजाइन भाषा (एसएई मानक), राइट (एडीएल) (कार्नेगी मेलन द्वारा विकसित), एक्मे (एडीएल) (कार्नेगी मेलॉन द्वारा विकसित), एक्सएडीएल (यूसीआई द्वारा विकसित) सम्मिलित हैं। ), डार्विन (संपादित करें) एडीएल) (इंपीरियल कॉलेज लंदन द्वारा विकसित), डीएओपी-एडीएल (मैलागा विश्वविद्यालय द्वारा विकसित), एसबीसी-एडीएल (राष्ट्रीय सूर्य यात-सेन विश्वविद्यालय द्वारा विकसित), और एडीएल (ल'अक्विला विश्वविद्यालय, इटली) द्वारा।
वास्तुकला दृष्टिकोण
सॉफ़्टवेयर आर्किटेक्चर विवरण सामान्यतः मॉडल देखें में व्यवस्थित होते हैं, जो बिल्डिंग आर्किटेक्चर में बने विभिन्न प्रकार के खाका के अनुरूप होते हैं। प्रत्येक दृश्य अपने दृष्टिकोण के सम्मेलनों के बाद सिस्टम चिंताओं के एक सेट को संबोधित करता है, जहां एक दृष्टिकोण एक विनिर्देश है जो किसी दिए गए सेट के परिप्रेक्ष्य से आर्किटेक्चर को व्यक्त करने वाले दृश्य में उपयोग करने के लिए नोटेशन, मॉडलिंग और विश्लेषण तकनीकों का वर्णन करता है। हितधारकों और उनकी चिंताओं के बारे में (आईएसओ/आईईसी 42010|आईएसओ/आईईसी/आईईईई 42010)। दृष्टिकोण न केवल तैयार की गई चिंताओं को निर्दिष्ट करता है (अर्थात, संबोधित किया जाना) लेकिन प्रस्तुति, मॉडल प्रकार का उपयोग किया जाता है, किसी दृश्य को अन्य दृष्टिकोणों के अनुरूप रखने के लिए फंक्शन्स और किसी भी संगति (पत्राचार) नियमों का उपयोग किया जाता है।
आर्किटेक्चर फ्रेमवर्क
आर्किटेक्चर फ्रेमवर्क अनुप्रयोग के एक विशिष्ट डोमेन और/या हितधारकों के समुदाय (आईएसओ/आईईसी 42010|आईएसओ/आईईसी/आईईईई 42010) के भीतर स्थापित आर्किटेक्चर के विवरण के लिए सम्मेलनों, सिद्धांतों और प्रथाओं को कैप्चर करता है। एक ढांचा सामान्यतः एक या अधिक दृष्टिकोण या एडीएल के संदर्भ में लागू किया जाता है।
स्थापत्य शैली और पैटर्न
वास्तुशिल्प पैटर्न एक दिए गए संदर्भ में सॉफ़्टवेयर आर्किटेक्चर में सामान्य रूप से होने वाली समस्या का सामान्य, पुन: प्रयोज्य समाधान है।
आर्किटेक्चरल पैटर्न को प्रायः सॉफ्टवेयर सॉफ्टवेयर डिजाइन पैटर्न के रूप में प्रलेखित किया जाता है।
पारंपरिक भवन वास्तुकला के बाद, 'सॉफ्टवेयर वास्तुकला शैली' निर्माण की एक विशिष्ट विधि है, जो इसे उल्लेखनीय (वास्तुकला शैली) बनाने वाली विशेषताओं की विशेषता है।
एक स्थापत्य शैली परिभाषित करती है: संरचनात्मक संगठन के एक पैटर्न के संदर्भ में प्रणालियों का एक परिवार; घटकों और कनेक्टर्स की एक शब्दावली, इस पर बाधाओं के साथ उन्हें कैसे जोड़ा जा सकता है।[33]
"आर्किटेक्चरल शैलियाँ डिज़ाइन निर्णयों और बाधाओं के पुन: प्रयोज्य 'पैकेज' हैं जो चुने हुए वांछनीय गुणों को प्रेरित करने के लिए एक आर्किटेक्चर पर लागू होते हैं।"[34]
उनमें से कई मान्यता प्राप्त वास्तुशिल्प पैटर्न और शैलियाँ हैं:
- ब्लैकबोर्ड (कंप्यूटिंग)
- क्लाइंट-सर्वर मॉडल
- सॉफ्टवेयर घटक
- डेटा-केंद्रित
- इवेंट-ड्रिवन (या निहित आह्वान)
- स्तरित वास्तुकला (या बहुस्तरीय वास्तुकला)
- माइक्रोसर्विसेज
- अखंड आवेदन
- पीयर टू पीयर (पी2पी)
- पाइप और फिल्टर
- प्लग-इन (कंप्यूटिंग)
- प्रतिक्रियाशील वास्तुकला
- प्रतिनिधित्वात्मक राज्य स्थानांतरण (रेस्ट)
- नियम-आधारित
- सेवा-उन्मुख
- साझा कुछ भी नहीं वास्तुकला
- अंतरिक्ष आधारित वास्तुकला
कुछ स्थापत्य पैटर्न और स्थापत्य शैली को समान मानते हैं,[35] कुछ शैलियों को पैटर्न की विशेषज्ञता के रूप में मानते हैं। उनके पास साधारण बात यह है कि आर्किटेक्ट्स के उपयोग के लिए पैटर्न और शैलियों दोनों वाक्यांश हैं, वे एक साधारण भाषा प्रदान करते हैं[35] या शब्दावली[33] जिसके साथ सिस्टम की कक्षाओं का वर्णन करना है।
सॉफ्टवेयर वास्तुकला और फुर्तीली विकास
ऐसी सरोकार भी हैं कि सॉफ़्टवेयर आर्किटेक्चर बहुत बड़ा डिज़ाइन अप फ्रंट की ओर ले जाता है, विशेष रूप से फुर्तीले सॉफ़्टवेयर विकास के समर्थकों के बीच। अप-फ्रंट डिज़ाइन और चपलता के व्यापार-नापसंद को संतुलित करने के लिए कई तरीके विकसित किए गए हैं,[36] तीव्र विधि गतिशील प्रणाली विकास पद्धति सहित, जो एक फाउंडेशन चरण को अनिवार्य करता है, जिसके दौरान पर्याप्त वास्तु नींव रखी जाती है। आईईईई सॉफ्टवेयर निपुणता और वास्तुकला के बीच बातचीत के लिए एक विशेष मुद्दा समर्पित करता है।
सॉफ्टवेयर आर्किटेक्चर क्षरण
सॉफ्टवेयर आर्किटेक्चर कटाव (या क्षय) सॉफ्टवेयर सिस्टम के नियोजित और वास्तविक आर्किटेक्चर के बीच देखे गए अंतर को संदर्भित करता है जैसा कि इसके कार्यान्वयन में महसूस किया गया है।[37] सॉफ़्टवेयर आर्किटेक्चर का क्षरण तब होता है जब कार्यान्वयन निर्णय या तो पूरी तरह से आर्किटेक्चर-जैसी योजना को प्राप्त नहीं करते हैं या अन्यथा उस आर्किटेक्चर की बाधाओं या सिद्धांतों का उल्लंघन करते हैं।[3]
उदाहरण के रूप में, सख्ती से अमूर्तता (कंप्यूटर विज्ञान) स्तरित वास्तुकला प्रणाली पर विचार करें, जहां प्रत्येक परत केवल उसके ठीक नीचे की परत द्वारा प्रदान की जाने वाली सेवाओं का उपयोग कर सकती है। कोई भी स्रोत कोड घटक जो इस बाधा का पालन नहीं करता है, एक आर्किटेक्चर उल्लंघन का प्रतिनिधित्व करता है। यदि सही नहीं किया जाता है, तो इस तरह के उल्लंघन आर्किटेक्चर को मोनोलिथिक ब्लॉक में बदल सकते हैं, जिसमें समझ, रखरखाव और विकास पर प्रतिकूल प्रभाव पड़ता है।
कटाव को संबोधित करने के लिए विभिन्न दृष्टिकोण प्रस्तावित किए गए हैं।
इन दृष्टिकोणों, जिनमें उपकरण, तकनीक और प्रक्रियाएं सम्मिलित हैं, को मुख्य रूप से तीन सामान्य श्रेणियों में वर्गीकृत किया गया है जो वास्तुकला क्षरण को कम करने, रोकने और मरम्मत करने का प्रयास करते हैं। इन व्यापक श्रेणियों के भीतर, कटाव से निपटने के लिए अपनाई गई उच्च-स्तरीय रणनीतियों को दर्शाते हुए प्रत्येक दृष्टिकोण को और विभाजित किया गया है। ये प्रक्रिया-उन्मुख वास्तुकला अनुरूपता, वास्तुकला विकास प्रबंधन, वास्तुकला डिजाइन प्रवर्तन, कार्यान्वयन लिंकेज के लिए वास्तुकला, स्व-अनुकूलन और पुनर्प्राप्ति, खोज और सामंजस्य से युक्त वास्तुकला बहाली तकनीकें हैं।[38]
वास्तुकला संबंधी उल्लंघनों का पता लगाने के लिए दो प्रमुख तकनीकें हैं: प्रतिबिंब मॉडल और डोमेन-विशिष्ट भाषाएं। रिफ्लेक्सियन मॉडल (आरएम) तकनीक सिस्टम के आर्किटेक्ट द्वारा प्रदान किए गए उच्च-स्तरीय मॉडल की तुलना स्रोत कोड कार्यान्वयन से करती है। आर्किटेक्चरल बाधाओं को निर्दिष्ट करने और जांचने पर ध्यान देने के साथ डोमेन-विशिष्ट भाषाएं भी हैं।
सॉफ्टवेयर आर्किटेक्चर रिकवरी
सॉफ़्टवेयर आर्किटेक्चर रिकवरी (या पुनर्निर्माण, या रिवर्स इंजीनियरिंग) में इसके कार्यान्वयन और दस्तावेज़ीकरण सहित उपलब्ध जानकारी से सॉफ़्टवेयर सिस्टम के आर्किटेक्चर को उजागर करने के तरीके, तकनीक और प्रक्रियाएं सम्मिलित हैं। अप्रचलित या पुराने दस्तावेजों और के सामने सूचित निर्णय लेने के लिए आर्किटेक्चर रिकवरी प्रायः आवश्यक होती है।
सॉफ्टवेयर आर्किटेक्चर सॉफ्टवेयर आर्किटेक्चर डिग्रेडेशन कार्यान्वयन और रखरखाव के फैसले कल्पना की गई वास्तुकला से दूर हैं।[39] स्थिर प्रोग्राम विश्लेषण के रूप में सॉफ़्टवेयर आर्किटेक्चर को पुनर्प्राप्त करने के लिए अभ्यास मौजूद हैं। यह सॉफ्टवेयर बुद्धि अभ्यास द्वारा कवर किए गए विषयों का एक हिस्सा है।
संबंधित क्षेत्र
डिजाइन
आर्किटेक्चर सॉफ्टवेयर डिज़ाइन है लेकिन सभी डिज़ाइन आर्किटेक्चरल नहीं हैं।[1]व्यवहार में, आर्किटेक्ट वह है जो सॉफ्टवेयर आर्किटेक्चर (आर्किटेक्चरल डिजाइन) और विस्तृत डिजाइन (गैर-आर्किटेक्चरल डिजाइन) के बीच रेखा खींचता है। ऐसे कोई नियम या दिशानिर्देश नहीं हैं जो सभी मामलों में फिट हों, हालांकि इस अंतर को औपचारिक रूप देने के प्रयास किए गए हैं। तीव्रता/स्थानीय परिकल्पना के अनुसार,[40] वास्तुकला और विस्तृत डिजाइन के बीच भेद स्थानीयता मानदंड द्वारा परिभाषित किया गया है,[40]जिसके अनुसार सॉफ्टवेयर डिजाइन के बारे में एक बयान गैर-स्थानीय (आर्किटेक्चरल) है यदि और केवल अगर कोई प्रोग्राम जो इसे संतुष्ट करता है उसे एक ऐसे प्रोग्राम में विस्तारित किया जा सकता है जो नहीं करता है। उदाहरण के लिए, क्लाइंट-सर्वर शैली आर्किटेक्चरल (रणनीतिक) है क्योंकि इस सिद्धांत पर बनाए गए प्रोग्राम को ऐसे प्रोग्राम में विस्तारित किया जा सकता है जो क्लाइंट-सर्वर नहीं है- उदाहरण के लिए, पीयर-टू-पीयर नोड्स जोड़कर।
आवश्यकताएँ इंजीनियरिंग
आवश्यकताएँ इंजीनियरिंग और सॉफ़्टवेयर आर्किटेक्चर को पूरक दृष्टिकोण के रूप में देखा जा सकता है: जबकि सॉफ़्टवेयर आर्किटेक्चर 'समाधान स्थान' या 'कैसे' को लक्षित करता है, आवश्यकताएँ इंजीनियरिंग 'कम्प्यूटेशनल समस्या' या 'क्या' को संबोधित करती हैं।[41] आवश्यकताएँ इंजीनियरिंग आवश्यकताओं को पूरा करने, आवश्यकताएँ विश्लेषण, सॉफ़्टवेयर आवश्यकताएँ विशिष्टता, डेटा सत्यापन, आवश्यकताएँ पता लगाने की क्षमता और आवश्यकताओं के प्रबंधन की आवश्यकताओं को पूरा करती है। दोनों आवश्यकताएं इंजीनियरिंग और सॉफ्टवेयर आर्किटेक्चर हितधारक (कॉर्पोरेट) की सरोकार, जरूरतों और इच्छाओं के इर्द-गिर्द घूमती हैं।
आवश्यकताओं इंजीनियरिंग और सॉफ़्टवेयर आर्किटेक्चर के बीच काफी अधिव्यापन है, जैसा उदाहरण के लिए पांच औद्योगिक सॉफ़्टवेयर आर्किटेक्चर विधियों में एक अध्ययन से प्रमाणित है, जो निष्कर्ष निकाला है कि इनपुट (लक्ष्य, बाधाएं, आदि) सामान्यतः खराब परिभाषित होते हैं, और केवल खोजे जाते हैं या बेहतर समझे जाते हैं। जैसे-जैसे वास्तुकला उभरना प्रारम्भ होती है और जबकि अधिकांश वास्तु संबंधी चिंताओं को सिस्टम पर आवश्यकताओं के रूप में व्यक्त किया जाता है, वे अनिवार्य डिजाइन निर्णयों को भी सम्मिलित कर सकते हैं।[24] संक्षेप में, आवश्यक व्यवहार समाधान संरचना को प्रभावित करता है, जो बदले में नई आवश्यकताओं को प्रस्तुत कर सकता है।[42] ट्विन पीक्स मॉडल जैसे दृष्टिकोण[43] आवश्यकताओं और वास्तुकला के बीच तालमेल संबंध का फायदा उठाना है।
'आर्किटेक्चर' के अन्य प्रकार
- कंप्यूटर आर्किटेक्चर
- कंप्यूटर आर्किटेक्चर केंद्रीय प्रसंस्करण इकाई - या प्रोसेसर - बस (कंप्यूटिंग) और स्मृति जैसे हार्डवेयर घटकों के सहयोग के संदर्भ में कंप्यूटर सिस्टम की आंतरिक संरचना को लक्षित करता है।
- सिस्टम आर्किटेक्चर शब्द मूल रूप से सिस्टम के आर्किटेक्चर पर लागू किया गया है जिसमें हार्डवेयर और सॉफ्टवेयर दोनों सम्मिलित हैं। सिस्टम आर्किटेक्चर द्वारा संबोधित मुख्य चिंता तब एक पूर्ण, सही ढंग से काम करने वाले डिवाइस में सॉफ्टवेयर और हार्डवेयर का एकीकरण है। एक अन्य सामान्य - बहुत व्यापक - अर्थ में, यह शब्द किसी भी जटिल प्रणाली की वास्तुकला पर लागू होता है जो तकनीकी, सामाजिक-तकनीकी प्रणाली या सामाजिक प्रकृति का हो सकता है।
- उद्यम स्थापत्य (एंटरप्राइज़ आर्किटेक्चर)
- उद्यम वास्तुकला का लक्ष्य व्यावसायिक दृष्टि और रणनीति को प्रभावी उद्यम में बदलना है। एंटरप्राइज आर्किटेक्चर आर्किटेक्चर फ्रेमवर्क, जैसे टोगाफ और ज़चमन फ्रेमवर्क, सामान्यतः विभिन्न एंटरप्राइज़ आर्किटेक्चर परतों के बीच अंतर करते हैं। हालांकि शब्दावली फ्रेमवर्क से फ्रेमवर्क में भिन्न होती है, कई में कम से कम व्यावसायिक परत, एप्लिकेशन सॉफ़्टवेयर (या सूचना) परत और एक तकनीकी परत के बीच अंतर सम्मिलित होता है। एंटरप्राइज़ आर्किटेक्चर दूसरों के बीच इन परतों के बीच संरेखण को संबोधित करता है, सामान्यतः टॉप-डाउन दृष्टिकोण में है।
यह भी देखें
संदर्भ
- ↑ 1.0 1.1 1.2 Clements, Paul; Felix Bachmann; Len Bass; David Garlan; James Ivers; Reed Little; Paulo Merson; Robert Nord; Judith Stafford (2010). Documenting Software Architectures: Views and Beyond, Second Edition. Boston: Addison-Wesley. ISBN 978-0-321-55268-6.
- ↑ "Software Architecture". www.sei.cmu.edu (in English). Retrieved 2018-07-23.
- ↑ 3.0 3.1 3.2 3.3 Perry, D. E.; Wolf, A. L. (1992). "Foundations for the study of software architecture" (PDF). ACM SIGSOFT Software Engineering Notes. 17 (4): 40. CiteSeerX 10.1.1.40.5174. doi:10.1145/141874.141884. S2CID 628695.
- ↑ 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 4.9 Bass, Len; Paul Clements; Rick Kazman (2012). Software Architecture in Practice, Third Edition. Boston: Addison-Wesley. ISBN 978-0-321-81573-6.
- ↑ SEI (2006). "How do you define Software Architecture?". Retrieved 2012-09-12.
- ↑ Garlan & Shaw (1994). "An Introduction to Software Architecture" (PDF). Retrieved 2012-09-13.
- ↑ 7.0 7.1 Fowler, Martin (2003). "Design – Who needs an architect?". IEEE Software. 20 (5): 11–44. doi:10.1109/MS.2003.1231144. S2CID 356506.
- ↑ ISO/IEC/IEEE 42010: Defining "architecture". Iso-architecture.org. Retrieved on 2013-07-21.
- ↑ 9.0 9.1 Jansen, A.; Bosch, J. (2005). "Software Architecture as a Set of Architectural Design Decisions". 5th Working IEEE/IFIP Conference on Software Architecture (WICSA'05). p. 109. CiteSeerX 10.1.1.60.8680. doi:10.1109/WICSA.2005.61. ISBN 978-0-7695-2548-8. S2CID 13492610.
- ↑ Ali Babar, Muhammad; Dingsoyr, Torgeir; Lago, Patricia; van Vliet, Hans (2009). Software Architecture Knowledge Management. Dordrecht Heidelberg London New York: Springer. ISBN 978-3-642-02373-6.
- ↑ 11.0 11.1 11.2 George Fairbanks (2010). Just Enough Software Architecture. Marshall & Brainerd.
- ↑ 12.0 12.1 ISO/IEC/IEEE (2011). "ISO/IEC/IEEE 42010:2011 Systems and software engineering – Architecture description". Retrieved 2012-09-12.
- ↑ Muller, Gerrit (August 20, 2007). "A Reference Architecture Primer" (PDF). Gaudi site. Archived (PDF) from the original on 2011-12-19. Retrieved November 13, 2015.
- ↑ Angelov, Samuil; Grefen, Paul; Greefhorst, Danny (2009). "A Classification of Software Reference Architectures: Analyzing Their Success and Effectiveness". Proc. Of WICSA/ECSA 2009: 141–150. CiteSeerX 10.1.1.525.7208. doi:10.1109/WICSA.2009.5290800. ISBN 978-1-4244-4984-2. S2CID 10417628.
- ↑ Brooks, Frederick P. Jr. (1975). The Mythical Man-Month – Essays on Software Engineering. Addison-Wesley. ISBN 978-0-201-00650-6.
- ↑ 16.0 16.1 Obbink, H.; Kruchten, P.; Kozaczynski, W.; Postema, H.; Ran, A.; Dominick, L.; Kazman, R.; Hilliard, R.; Tracz, W.; Kahane, E. (Feb 6, 2002). "Software Architecture Review and Assessment (SARA) Report" (PDF). Retrieved November 1, 2015.
- ↑ Poort, Eltjo; van Vliet, Hans (September 2012). "RCDA: Architecting as a risk- and cost management discipline". Journal of Systems and Software. 85 (9): 1995–2013. doi:10.1016/j.jss.2012.03.071.
- ↑ P. Naur; B. Randell, eds. (1969). "Software Engineering: Report of a conference sponsored by the NATO Science Committee, Garmisch, Germany, 7–11 Oct. 1968" (PDF). Brussels: NATO, Scientific Affairs Division. Archived (PDF) from the original on 2003-06-07. Retrieved 2012-11-16.
- ↑ P. Kruchten; H. Obbink; J. Stafford (2006). "The past, present and future of software architecture". IEEE Software. 23 (2): 22. doi:10.1109/MS.2006.59. S2CID 2082927.
- ↑ University of Waterloo (2006). "A Very Brief History of Computer Science". Retrieved 2006-09-23.
- ↑ "Introduction to the Special Issue on Software Architecture". IEEE.org. 2006. doi:10.1109/TSE.1995.10003.
- ↑ Garlan & Shaw (1994). "An Introduction to Software Architecture" (PDF). Retrieved 2006-09-25.
- ↑ 23.0 23.1 Kruchten, P. (2008). "What do software architects really do?". Journal of Systems and Software. 81 (12): 2413–2416. doi:10.1016/j.jss.2008.08.025.
- ↑ 24.0 24.1 24.2 Christine Hofmeister; Philippe Kruchten; Robert L. Nord; Henk Obbink; Alexander Ran; Pierre America (2007). "A general model of software architecture design derived from five industrial approaches". Journal of Systems and Software. 80 (1): 106–126. doi:10.1016/j.jss.2006.05.024.
- ↑ 25.0 25.1 ISO/IEC (2011). "ISO/IEC 25010:2011 Systems and software engineering – Systems and software Quality Requirements and Evaluation (SQuaRE) – System and software quality models". Retrieved 2012-10-08.
- ↑ Osterwalder and Pigneur (2004). "An Ontology for e-Business Models" (PDF). Value Creation from E-Business Models. pp. 65–97. CiteSeerX 10.1.1.9.6922. doi:10.1016/B978-075066140-9/50006-0. ISBN 9780750661409. S2CID 14177438. Archived from the original (PDF) on 2018-11-17.
- ↑ Chen, Lianping; Ali Babar, Muhammad; Nuseibeh, Bashar (2013). "वास्तुकला की दृष्टि से महत्वपूर्ण आवश्यकताओं की विशेषता". IEEE Software. 30 (2): 38–45. doi:10.1109/MS.2012.174. hdl:10344/3061. S2CID 17399565.
- ↑ Woods, E. (2012). "Industrial architectural assessment using TARA". Journal of Systems and Software. 85 (9): 2034–2047. doi:10.1016/j.jss.2012.04.055. S2CID 179244.
- ↑ Maranzano, J. F.; Rozsypal, S. A.; Zimmerman, G. H.; Warnken, G. W.; Wirth, P. E.; Weiss, D. M. (2005). "Architecture Reviews: Practice and Experience". IEEE Software. 22 (2): 34. doi:10.1109/MS.2005.28. S2CID 11697335.
- ↑ Babar, M.A.; Dingsøyr, T.; Lago, P.; Vliet, H. van (2009). Software Architecture Knowledge Management:Theory and Practice (eds.), First Edition. Springer. ISBN 978-3-642-02373-6.
- ↑ Tang, A.; Han, J.; Vasa, R. (2009). "Software Architecture Design Reasoning: A Case for Improved Methodology Support". IEEE Software. 26 (2): 43. doi:10.1109/MS.2009.46. hdl:1959.3/51601. S2CID 12230032.
- ↑ Kruchten, Philippe (1995). "Architectural Blueprints – The '4+1' View Model of Software Architecture" (PDF). IEEE Software. 12 (6): 42–50. arXiv:2006.04975. doi:10.1109/52.469759. S2CID 219558624.
- ↑ 33.0 33.1 Shaw, Mary; Garlan, David (1996). Software architecture: perspectives on an emerging discipline. Prentice Hall. ISBN 978-0-13-182957-2.
- ↑ UCI Software Architecture Research – UCI Software Architecture Research: Architectural Styles. Isr.uci.edu. Retrieved on 2013-07-21.
- ↑ 35.0 35.1 Chapter 3: Architectural Patterns and Styles. Msdn.microsoft.com. Retrieved on 2013-07-21.
- ↑ Boehm, Barry; Turner, Richard (2004). Balancing Agility and Discipline. Addison-Wesley. ISBN 978-0-321-18612-6.
- ↑ Terra, R., M.T. Valente, K. Czarnecki, and R.S. Bigonha, "Recommending Refactorings to Reverse Software Architecture Erosion", 16th European Conference on Software Maintenance and Reengineering, 2012. http://gsd.uwaterloo.ca/sites/default/files/Full%20Text.pdf
- ↑ de Silva, L.; Balasubramaniam, D. (2012). "Controlling software architecture erosion: A survey". Journal of Systems and Software. 85 (1): 132–151. doi:10.1016/j.jss.2011.07.036.
- ↑ Lungu, M. "Software architecture recovery", University of Lugano, 2008. http://www.slideshare.net/mircea.lungu/software-architecture-recovery-in-five-questions-presentation
- ↑ 40.0 40.1 Amnon H. Eden; Rick Kazman (2003). "Architecture Design Implementation" (PDF). Archived from the original (PDF) on 2007-09-28.
- ↑ C. Shekaran; D. Garlan; M. Jackson; N.R. Mead; C. Potts; H.B. Reubenstein (1994). "The role of software architecture in requirements engineering". Proceedings of IEEE International Conference on Requirements Engineering: 239–245. doi:10.1109/ICRE.1994.292379. ISBN 978-0-8186-5480-0. S2CID 3129363.
- ↑ Remco C. de Boer, Hans van Vliet (2009). "On the similarity between requirements and architecture". Journal of Systems and Software. 82 (3): 544–550. CiteSeerX 10.1.1.415.6023. doi:10.1016/j.jss.2008.11.185.
- ↑ Bashar Nuseibeh (2001). "Weaving together requirements and architectures" (PDF). Computer. 34 (3): 115–119. doi:10.1109/2.910904. Archived (PDF) from the original on 2012-09-07.
अग्रिम पठन
- Richards, Mark (2020). Fundamentals of Software Architecture: An Engineering Approach. O'Reilly Media. ISBN 9781492043454.
- Len, Bass (2012). Software Architecture in Practice (3rd ed.). Addison-Wesley Professional. ISBN 9780321815736. - This book covers the fundamental concepts of the discipline. The theme is centered on achieving quality attributes of a system.
- Clements, Paul (2010). Documenting Software Architectures: Views and Beyond (2nd ed.). Addison-Wesley Professional. ISBN 9780321552686. - This book describes what software architecture is and shows how to document it in multiple views, using UML and other notations. It also explains how to complement the architecture views with behavior, software interface, and rationale documentation. Accompanying the book is a wiki that contains an example of software architecture documentation.
- Bell, Michael (2008). Bell, Michael (ed.). Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley. doi:10.1002/9781119198864. ISBN 9780470255704.
- Shan, Tony; Hua, Winnie (October 2006). "Solution Architecting Mechanism". Proceedings of the 10th IEEE International EDOC Enterprise Computing Conference: 23–32. doi:10.1109/EDOC.2006.54. ISBN 978-0-7695-2558-7. S2CID 8361936.
- Garzás, Javier; Piattini, Mario (2005). "An ontology for micro-architectural design knowledge". IEEE Software. 22 (2): 28–33. doi:10.1109/MS.2005.26. S2CID 17639072.
- Fowler, Martin (September 2003). "Who Needs an Architect?" (PDF). IEEE Software. 20 (5). doi:10.1109/MS.2003.1231144. S2CID 356506.
- Kazman, Rick (May 2003). "Architecture, Design, Implementation" (PDF). Software Engineering Institute. Archived (PDF) from the original on 2015-09-21. - On the distinction between architectural design and detailed design.
- Kruchten, Philippe (1995). "Architectural Blueprints – The '4+1' View Model of Software Architecture" (PDF). IEEE Software. 12 (6): 42–50. arXiv:2006.04975. doi:10.1109/52.469759. S2CID 219558624. Archived (PDF) from the original on 2006-06-13.
- Pautasso, Cesare (2020). Software Architecture: visual lecture notes. LeanPub. p. 689.
बाहरी संबंध
- Explanation on IBM Developerworks
- Collection of software architecture definitions at Software Engineering Institute (SEI), Carnegie Mellon University (CMU)
- International Association of IT Architects (IASA Global), formerly known as the International Association for Software Architects (IASA)
- SoftwareArchitecturePortal.org – website of IFIP Working Group 2.10 on Software Architecture
- SoftwareArchitectures.com – an independent resource of information on the discipline
- Software Architecture, chapter 1 of Roy Fielding's REST dissertation
- When Good Architecture Goes Bad
- The Spiral Architecture Driven Development – the SDLC based on the Spiral model aims to reduce the risks of ineffective architecture
- Software Architecture Real Life Case Studies
