सॉफ्टवेयर संरचना

From Vigyanwiki
Revision as of 09:58, 20 February 2023 by alpha>Sweta (→‎स्कोप)
Part of a series on
Software development
Core activities
Paradigms and models
Methodologies and frameworks
Supporting disciplines
Practices
Tools
Standards and Bodies of Knowledge
Glossaries
Outlines

सॉफ्टवेयर आर्किटेक्चर एक सॉफ्टवेयर सिस्टम और ऐसी संरचनाओं और प्रणालियों को बनाने के अनुशासन के बारे में तर्क करने के लिए आवश्यक संरचनाओं का समूह है। प्रत्येक संरचना में सॉफ्टवेयर तत्व, उनके बीच संबंध और दोनों तत्वों और संबंधों के गुण शामिल हैं।[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]

विश्लेषण गतिविधि के आउटपुट वे आवश्यकताएं हैं जिनका सॉफ्टवेयर सिस्टम के आर्किटेक्चर पर मापन योग्य प्रभाव पड़ता है, जिसे वास्तुशिल्पीय रूप से महत्वपूर्ण आवश्यकताएं कहा जाता है।Cite error: Closing </ref> missing for <ref> tag तकनीकों की तुलना करने के लिए रूपरेखाओं पर सारा रिपोर्ट जैसे ढांचे में चर्चा की गई है[16]और वास्तुकला समीक्षा: अभ्यास और अनुभव।[27]

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

आर्किटेक्चर को महत्वपूर्ण सहायक गतिविधियों की आवश्यकता होती है। ये सहायक गतिविधियाँ कोर सॉफ़्टवेयर आर्किटेक्चर प्रक्रिया के दौरान होती हैं। वे ज्ञान प्रबंधन और संचार, डिजाइन तर्क और निर्णय लेने और प्रलेखन शामिल हैं।

आर्किटेक्चर सहायक गतिविधियाँ

सॉफ्टवेयर आर्किटेक्चर सहायक गतिविधियाँ कोर सॉफ्टवेयर आर्किटेक्चर गतिविधियों के दौरान की जाती हैं। ये सहायक गतिविधियाँ सॉफ़्टवेयर आर्किटेक्ट को विश्लेषण, संश्लेषण, मूल्यांकन और विकास करने में सहायता करती हैं। उदाहरण के लिए, एक वास्तुकार को विश्लेषण चरण के दौरान ज्ञान इकट्ठा करना, निर्णय लेना और दस्तावेज़ बनाना होता है।

  • ज्ञान प्रबंधन और संचार ज्ञान की खोज और प्रबंधन का कार्य है जो एक सॉफ्टवेयर आर्किटेक्चर को डिजाइन करने के लिए आवश्यक है। एक सॉफ्टवेयर आर्किटेक्ट अलगाव में काम नहीं करता है। वे विभिन्न हितधारकों से इनपुट, कार्यात्मक और गैर-कार्यात्मक आवश्यकताएं और डिजाइन संदर्भ प्राप्त करते हैं; और हितधारकों को आउटपुट प्रदान करता है। सॉफ्टवेयर आर्किटेक्चर का ज्ञान अक्सर मौन होता है और हितधारकों के दिमाग में बना रहता है। सॉफ्टवेयर आर्किटेक्चर नॉलेज मैनेजमेंट एक्टिविटी ज्ञान को खोजने, संचार करने और बनाए रखने के बारे में है। चूंकि सॉफ़्टवेयर आर्किटेक्चर डिज़ाइन के मुद्दे जटिल और अन्योन्याश्रित हैं, डिज़ाइन तर्क में ज्ञान अंतर गलत सॉफ़्टवेयर आर्किटेक्चर डिज़ाइन का कारण बन सकता है।[23][28] ज्ञान प्रबंधन और संचार गतिविधियों के उदाहरणों में डिजाइन पैटर्न की खोज, प्रोटोटाइपिंग, अनुभवी डेवलपर्स और आर्किटेक्ट्स से पूछना, समान प्रणालियों के डिजाइनों का मूल्यांकन करना, अन्य डिजाइनरों और हितधारकों के साथ ज्ञान साझा करना और विकी पेज में अनुभव का दस्तावेजीकरण करना शामिल है।
  • डिजाइन तर्क और निर्णय लेना डिजाइन निर्णयों के मूल्यांकन की गतिविधि है। यह गतिविधि सभी तीन मुख्य सॉफ्टवेयर आर्किटेक्चर गतिविधियों के लिए मौलिक है।[9][29] इसमें निर्णय संदर्भों को इकट्ठा करना और संबद्ध करना, डिजाइन निर्णय समस्याओं को तैयार करना, समाधान विकल्प खोजना और निर्णय लेने से पहले ट्रेडऑफ़ का मूल्यांकन करना शामिल है। यह प्रक्रिया महत्वपूर्ण वास्तु आवश्यकताओं और सॉफ़्टवेयर आर्किटेक्चर निर्णयों और सॉफ़्टवेयर आर्किटेक्चर विश्लेषण, संश्लेषण और मूल्यांकन का मूल्यांकन करते समय निर्णय ग्रैन्युलैरिटी के विभिन्न स्तरों पर होती है। तार्किक गतिविधियों के उदाहरणों में गुणवत्ता विशेषताओं पर किसी आवश्यकता या डिज़ाइन के प्रभाव को समझना, किसी डिज़ाइन के कारण होने वाली समस्याओं पर सवाल उठाना, संभावित समाधान विकल्पों का आकलन करना और समाधानों के बीच ट्रेडऑफ़ का मूल्यांकन करना शामिल है।
  • दस्तावेज़ीकरण सॉफ़्टवेयर आर्किटेक्चर प्रक्रिया के दौरान उत्पन्न डिज़ाइन को रिकॉर्ड करने का कार्य है। सॉफ़्टवेयर डिज़ाइन को कई दृश्यों का उपयोग करके वर्णित किया गया है जिसमें अक्सर एक स्थिर दृश्य शामिल होता है जो सिस्टम की कोड संरचना दिखाता है, एक गतिशील दृश्य जो निष्पादन के दौरान सिस्टम की क्रियाओं को दिखाता है, और एक परिनियोजन दृश्य दिखाता है कि निष्पादन के लिए हार्डवेयर पर सिस्टम कैसे रखा जाता है। क्रुचटेन का 4+1 दृश्य सॉफ्टवेयर आर्किटेक्चर के दस्तावेजीकरण के लिए आमतौर पर उपयोग किए जाने वाले दृश्यों के विवरण का सुझाव देता है;[30] दस्तावेज़ीकरण सॉफ़्टवेयर आर्किटेक्चर: व्यूज़ और बियॉन्ड में उन प्रकार के नोटेशन का वर्णन है जिनका उपयोग दृश्य विवरण के भीतर किया जा सकता है।[1] दस्तावेज़ीकरण गतिविधियों के उदाहरण एक विनिर्देश लिखना, एक सिस्टम डिज़ाइन मॉडल रिकॉर्ड करना, एक डिज़ाइन तर्काधार का दस्तावेज़ीकरण करना, एक दृष्टिकोण विकसित करना, विचारों का दस्तावेज़ीकरण करना है।

सॉफ्टवेयर आर्किटेक्चर विषय

सॉफ्टवेयर आर्किटेक्चर विवरण

Main article: सॉफ्टवेयर वास्तुकला विवरण

सॉफ़्टवेयर आर्किटेक्चर विवरण में आर्किटेक्चर विवरण भाषाओं, आर्किटेक्चर दृष्टिकोण और आर्किटेक्चर फ्रेमवर्क जैसे तंत्र का उपयोग करके मॉडलिंग और आर्किटेक्चर का प्रतिनिधित्व करने के सिद्धांतों और प्रथाओं को शामिल किया गया है।

आर्किटेक्चर विवरण भाषाएं

Main article: वास्तुकला विवरण भाषा

आर्किटेक्चर डिस्क्रिप्शन लैंग्वेज (एडीएल) एक सॉफ्टवेयर आर्किटेक्चर (आईएसओ/आईईसी 42010|आईएसओ/आईईसी/आईईईई 42010) का वर्णन करने के लिए उपयोग की जाने वाली अभिव्यक्ति का कोई साधन है।

1990 के दशक के बाद से कई विशेष उद्देश्य एडीएल विकसित किए गए हैं, जिनमें आर्किटेक्चर विश्लेषण और डिजाइन भाषा (एसएई मानक), राइट (एडीएल) (कार्नेगी मेलन द्वारा विकसित), एक्मे (एडीएल) (कार्नेगी मेलॉन द्वारा विकसित), एक्सएडीएल (यूसीआई द्वारा विकसित) शामिल हैं। ), डार्विन (संपादित करें) एडीएल) (इंपीरियल कॉलेज लंदन द्वारा विकसित), डीएओपी-एडीएल (मैलागा विश्वविद्यालय द्वारा विकसित), एसबीसी-एडीएल (राष्ट्रीय सूर्य यात-सेन विश्वविद्यालय द्वारा विकसित), और एडीएल (ल'अक्विला विश्वविद्यालय, इटली) द्वारा।

वास्तुकला दृष्टिकोण

Main article: मॉडल देखें
4+1 आर्किटेक्चरल व्यू मॉडल।

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

आर्किटेक्चर फ्रेमवर्क

Main article: आर्किटेक्चर फ्रेमवर्क

एक आर्किटेक्चर फ्रेमवर्क अनुप्रयोग के एक विशिष्ट डोमेन और/या हितधारकों के समुदाय (आईएसओ/आईईसी 42010|आईएसओ/आईईसी/आईईईई 42010) के भीतर स्थापित आर्किटेक्चर के विवरण के लिए सम्मेलनों, सिद्धांतों और प्रथाओं को कैप्चर करता है। एक ढांचा आमतौर पर एक या अधिक दृष्टिकोण या एडीएल के संदर्भ में लागू किया जाता है।

स्थापत्य शैली और पैटर्न

एक वास्तुशिल्प पैटर्न एक दिए गए संदर्भ में सॉफ़्टवेयर आर्किटेक्चर में सामान्य रूप से होने वाली समस्या का एक सामान्य, पुन: प्रयोज्य समाधान है।

आर्किटेक्चरल पैटर्न को अक्सर सॉफ्टवेयर सॉफ्टवेयर डिजाइन पैटर्न के रूप में प्रलेखित किया जाता है।

पारंपरिक भवन वास्तुकला के बाद, एक 'सॉफ्टवेयर वास्तुकला शैली' निर्माण की एक विशिष्ट विधि है, जो इसे उल्लेखनीय (वास्तुकला शैली) बनाने वाली विशेषताओं की विशेषता है।

An architectural style defines: a family of systems in terms of a pattern of structural organization; a vocabulary of components and connectors, with constraints on how they can be combined.[31]

Architectural styles are reusable 'packages' of design decisions and constraints that are applied to an architecture to induce chosen desirable qualities.[32]

उनमें से कई मान्यता प्राप्त वास्तुशिल्प पैटर्न और शैलियाँ हैं:

कुछ स्थापत्य पैटर्न और स्थापत्य शैली को समान मानते हैं,[33] कुछ शैलियों को पैटर्न की विशेषज्ञता के रूप में मानते हैं। उनके पास आम बात यह है कि आर्किटेक्ट्स के उपयोग के लिए पैटर्न और शैलियों दोनों मुहावरे हैं, वे एक आम भाषा प्रदान करते हैं[33]या शब्दावली[31]जिसके साथ सिस्टम की कक्षाओं का वर्णन करना है।

सॉफ्टवेयर वास्तुकला और फुर्तीली विकास

Main article: Agile development

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

सॉफ्टवेयर आर्किटेक्चर क्षरण

सॉफ्टवेयर आर्किटेक्चर कटाव (या क्षय) एक सॉफ्टवेयर सिस्टम के नियोजित और वास्तविक आर्किटेक्चर के बीच देखे गए अंतर को संदर्भित करता है जैसा कि इसके कार्यान्वयन में महसूस किया गया है।[35] सॉफ़्टवेयर आर्किटेक्चर का क्षरण तब होता है जब कार्यान्वयन निर्णय या तो पूरी तरह से आर्किटेक्चर-जैसी योजना को प्राप्त नहीं करते हैं या अन्यथा उस आर्किटेक्चर की बाधाओं या सिद्धांतों का उल्लंघन करते हैं।[3]

एक उदाहरण के रूप में, एक सख्ती से अमूर्तता (कंप्यूटर विज्ञान) # स्तरित वास्तुकला प्रणाली पर विचार करें, जहां प्रत्येक परत केवल उसके ठीक नीचे की परत द्वारा प्रदान की जाने वाली सेवाओं का उपयोग कर सकती है। कोई भी स्रोत कोड घटक जो इस बाधा का पालन नहीं करता है, एक आर्किटेक्चर उल्लंघन का प्रतिनिधित्व करता है। यदि सही नहीं किया जाता है, तो इस तरह के उल्लंघन आर्किटेक्चर को एक मोनोलिथिक ब्लॉक में बदल सकते हैं, जिसमें समझ, रखरखाव और विकास पर प्रतिकूल प्रभाव पड़ता है।

कटाव को संबोधित करने के लिए विभिन्न दृष्टिकोण प्रस्तावित किए गए हैं। 

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

वास्तुकला संबंधी उल्लंघनों का पता लगाने के लिए दो प्रमुख तकनीकें हैं: प्रतिबिंब मॉडल और डोमेन-विशिष्ट भाषाएं। रिफ्लेक्सियन मॉडल (आरएम) तकनीक सिस्टम के आर्किटेक्ट द्वारा प्रदान किए गए उच्च-स्तरीय मॉडल की तुलना स्रोत कोड कार्यान्वयन से करती है। आर्किटेक्चरल बाधाओं को निर्दिष्ट करने और जांचने पर ध्यान देने के साथ डोमेन-विशिष्ट भाषाएं भी हैं।

सॉफ्टवेयर आर्किटेक्चर रिकवरी

Main article: Software architecture recovery

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

संबंधित क्षेत्र

डिजाइन

Main article: Software design

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

आवश्यकताएँ इंजीनियरिंग

Main article: Requirements engineering

आवश्यकताएँ इंजीनियरिंग और सॉफ़्टवेयर आर्किटेक्चर को पूरक दृष्टिकोण के रूप में देखा जा सकता है: जबकि सॉफ़्टवेयर आर्किटेक्चर 'समाधान स्थान' या 'कैसे' को लक्षित करता है, आवश्यकताएँ इंजीनियरिंग 'कम्प्यूटेशनल समस्या' या 'क्या' को संबोधित करती हैं।[39] आवश्यकताएँ इंजीनियरिंग आवश्यकताओं को पूरा करने, आवश्यकताएँ विश्लेषण, सॉफ़्टवेयर आवश्यकताएँ विशिष्टता, डेटा सत्यापन, आवश्यकताएँ पता लगाने की क्षमता और आवश्यकताओं के प्रबंधन की आवश्यकताओं को पूरा करती है। दोनों आवश्यकताएं इंजीनियरिंग और सॉफ्टवेयर आर्किटेक्चर हितधारक (कॉर्पोरेट) की चिंताओं, जरूरतों और इच्छाओं के इर्द-गिर्द घूमती हैं।

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

'आर्किटेक्चर' के अन्य प्रकार

Main articles: Computer architecture, Systems architecture, and Enterprise architecture
कंप्यूटर आर्किटेक्चर
कंप्यूटर आर्किटेक्चर केंद्रीय प्रसंस्करण इकाई - या प्रोसेसर - बस (कंप्यूटिंग) और स्मृति जैसे हार्डवेयर घटकों के सहयोग के संदर्भ में कंप्यूटर सिस्टम की आंतरिक संरचना को लक्षित करता है।

सिस्टम आर्किटेक्चर

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

यह भी देखें


संदर्भ

  1. ↑ 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.
  2. ↑ "Software Architecture". www.sei.cmu.edu (in English). Retrieved 2018-07-23.
  3. ↑ 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. ↑ 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 Bass, Len; Paul Clements; Rick Kazman (2012). Software Architecture in Practice, Third Edition. Boston: Addison-Wesley. ISBN 978-0-321-81573-6.
  5. ↑ SEI (2006). "How do you define Software Architecture?". Retrieved 2012-09-12.
  6. ↑ Garlan & Shaw (1994). "An Introduction to Software Architecture" (PDF). Retrieved 2012-09-13.
  7. ↑ 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.
  8. ↑ ISO/IEC/IEEE 42010: Defining "architecture". Iso-architecture.org. Retrieved on 2013-07-21.
  9. ↑ 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.
  10. ↑ 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. ↑ 11.0 11.1 11.2 George Fairbanks (2010). Just Enough Software Architecture. Marshall & Brainerd.
  12. ↑ 12.0 12.1 ISO/IEC/IEEE (2011). "ISO/IEC/IEEE 42010:2011 Systems and software engineering – Architecture description". Retrieved 2012-09-12.
  13. ↑ 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.
  14. ↑ 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.
  15. ↑ Brooks, Frederick P. Jr. (1975). The Mythical Man-Month – Essays on Software Engineering. Addison-Wesley. ISBN 978-0-201-00650-6.
  16. ↑ 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.
  17. ↑ 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.
  18. ↑ 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.
  19. ↑ 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.
  20. ↑ University of Waterloo (2006). "A Very Brief History of Computer Science". Retrieved 2006-09-23.
  21. ↑ "Introduction to the Special Issue on Software Architecture". IEEE.org. 2006. doi:10.1109/TSE.1995.10003.
  22. ↑ Garlan & Shaw (1994). "An Introduction to Software Architecture" (PDF). Retrieved 2006-09-25.
  23. ↑ 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. ↑ 24.0 24.1 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. ↑ 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.
  26. ↑ 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.
  27. ↑ 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.
  28. ↑ 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.
  29. ↑ 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.
  30. ↑ 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.
  31. ↑ 31.0 31.1 Shaw, Mary; Garlan, David (1996). Software architecture: perspectives on an emerging discipline. Prentice Hall. ISBN 978-0-13-182957-2.
  32. ↑ UCI Software Architecture Research – UCI Software Architecture Research: Architectural Styles. Isr.uci.edu. Retrieved on 2013-07-21.
  33. ↑ 33.0 33.1 Chapter 3: Architectural Patterns and Styles. Msdn.microsoft.com. Retrieved on 2013-07-21.
  34. ↑ Boehm, Barry; Turner, Richard (2004). Balancing Agility and Discipline. Addison-Wesley. ISBN 978-0-321-18612-6.
  35. ↑ 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
  36. ↑ 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.
  37. ↑ Lungu, M. "Software architecture recovery", University of Lugano, 2008. http://www.slideshare.net/mircea.lungu/software-architecture-recovery-in-five-questions-presentation
  38. ↑ 38.0 38.1 Amnon H. Eden; Rick Kazman (2003). "Architecture Design Implementation" (PDF). Archived from the original (PDF) on 2007-09-28.
  39. ↑ 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.
  40. ↑ 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.
  41. ↑ 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.


अग्रिम पठन


बाहरी संबंध

Wikimedia Commons has media related to [[commons:Category:सॉफ्टवेयर संरचना|सॉफ्टवेयर संरचना]].
Wikiquote has quotations related to सॉफ्टवेयर संरचना.
Retrieved from ‘https://www.vigyanwiki.in/index.php?title=सॉफ्टवेयर_संरचना&oldid=102057’