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

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

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

सॉफ्टवेयर आर्किटेक्चर मौलिक संरचनात्मक विकल्प बनाने के बारे में है जो एक बार लागू होने के बाद बदलने के लिए महंगा है। सॉफ़्टवेयर आर्किटेक्चर विकल्पों में सॉफ्टवेर के डिज़ाइन में संभावनाओं से विशिष्ट संरचनात्मक विकल्प शामिल होते हैं।

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

दस्तावेज़ीकरण सॉफ्टवेयर आर्किटेक्चर हितधारकों के बीच संचार की सुविधा देता है, उच्च-स्तरीय डिज़ाइन के बारे में शुरुआती निर्णय लेता है, और परियोजनाओं के बीच डिज़ाइन घटकों के पुन: उपयोग की अनुमति देता है।



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

विशेषताएं
सॉफ्टवेयर आर्किटेक्चर निम्नलिखित प्रदर्शित करता है:

हितधारकों की बहुलता: सॉफ्टवेयर सिस्टम को विभिन्न प्रकार के हितधारकों जैसे व्यवसाय प्रबंधकों, मालिकों, उपयोगकर्ताओं और ऑपरेटरों को पूरा करना होता है। सिस्टम के संबंध में इन सभी हितधारकों की अपनी चिंताएं हैं। इन चिंताओं को संतुलित करना और प्रदर्शित करना कि उन्हें संबोधित किया गया है, सिस्टम को डिजाइन करने का हिस्सा है। इसका तात्पर्य है कि वास्तुकला में विभिन्न प्रकार की चिंताओं और हितधारकों से निपटना शामिल है, और इसकी प्रकृति बहु-विषयक है।

चिंताओं को अलग करना: वास्तुकारों के लिए जटिलता को कम करने का स्थापित तरीका उन चिंताओं को अलग करना है जो डिजाइन को संचालित करती हैं। आर्किटेक्चर प्रलेखन से पता चलता है कि सभी हितधारक चिंताओं को मॉडलिंग और विभिन्न हितधारक चिंताओं से जुड़े अलग-अलग दृष्टिकोणों से आर्किटेक्चर का वर्णन करके संबोधित किया जाता है। इन अलग-अलग विवरणों को आर्किटेक्चरल व्यू कहा जाता है (उदाहरण के लिए 4+1 आर्किटेक्चरल व्यू मॉडल देखें)।

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

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

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

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

IEEE 1471-2000, सॉफ़्टवेयर-गहन प्रणालियों के आर्किटेक्चर विवरण के लिए अनुशंसित अभ्यास, सॉफ़्टवेयर आर्किटेक्चर के क्षेत्र में पहला औपचारिक मानक था। इसे 2007 में ISO द्वारा IEEE 1471|ISO/IEC 42010:2007 के रूप में अपनाया गया था। नवंबर 2011 में, IEEE 1471-2000 को ISO/IEC 42010|ISO/IEC/IEEE 42010:2011, सिस्टम और सॉफ्टवेयर इंजीनियरिंग - आर्किटेक्चर विवरण (संयुक्त रूप से IEEE और ISO द्वारा प्रकाशित) द्वारा अधिक्रमित किया गया था। जबकि IEEE 1471 में, सॉफ़्टवेयर आर्किटेक्चर सॉफ़्टवेयर-गहन प्रणालियों के आर्किटेक्चर के बारे में था, जिसे किसी भी सिस्टम के रूप में परिभाषित किया गया है, जहाँ सॉफ़्टवेयर समग्र रूप से सिस्टम के डिज़ाइन, निर्माण, परिनियोजन और विकास में आवश्यक प्रभाव डालता है, 2011 संस्करण एक कदम आगे जाता है किसी सिस्टम की ISO/IEC 15288 और ISO/IEC 12207 परिभाषाओं को शामिल करके, जो न केवल हार्डवेयर और सॉफ़्टवेयर, बल्कि मनुष्यों, प्रक्रियाओं, प्रक्रियाओं, सुविधाओं, सामग्री और स्वाभाविक रूप से होने वाली संस्थाओं को भी समाहित करता है। यह सॉफ्टवेयर आर्किटेक्चर, उद्यम स्थापत्य और समाधान वास्तुकला के बीच संबंध को दर्शाता है।

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

वास्तुकला विश्लेषण पर्यावरण को समझने की प्रक्रिया है जिसमें एक प्रस्तावित प्रणाली प्रणाली के लिए आवश्यकताओं को संचालित और निर्धारित करेगी। विश्लेषण गतिविधि के लिए इनपुट या आवश्यकताएं किसी भी संख्या में हितधारकों से आ सकती हैं और इसमें निम्न आइटम शामिल हैं:

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

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

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


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

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

आर्किटेक्चर विवरण भाषाएं
एक आर्किटेक्चर डिस्क्रिप्शन लैंग्वेज (ADL) एक सॉफ्टवेयर आर्किटेक्चर (ISO/IEC 42010|ISO/IEC/IEEE 42010) का वर्णन करने के लिए उपयोग की जाने वाली अभिव्यक्ति का कोई साधन है। 1990 के दशक के बाद से कई विशेष उद्देश्य एडीएल विकसित किए गए हैं, जिनमें आर्किटेक्चर विश्लेषण और डिजाइन भाषा (एसएई मानक), राइट (एडीएल) (कार्नेगी मेलन द्वारा विकसित), एक्मे (एडीएल) (कार्नेगी मेलॉन द्वारा विकसित), एक्सएडीएल (यूसीआई द्वारा विकसित) शामिल हैं। ), डार्विन (संपादित करें)ADL) (इंपीरियल कॉलेज लंदन द्वारा विकसित), DAOP-ADL (मैलागा विश्वविद्यालय द्वारा विकसित), SBC-ADL (राष्ट्रीय सूर्य यात-सेन विश्वविद्यालय द्वारा विकसित), और ByADL (ADL) (L'Aquila विश्वविद्यालय), इटली)।

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

आर्किटेक्चर फ्रेमवर्क
एक आर्किटेक्चर फ्रेमवर्क अनुप्रयोग के एक विशिष्ट डोमेन और/या हितधारकों के समुदाय (ISO/IEC 42010|ISO/IEC/IEEE 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.

Architectural styles are reusable 'packages' of design decisions and constraints that are applied to an architecture to induce chosen desirable qualities. उनमें से कई मान्यता प्राप्त वास्तुशिल्प पैटर्न और शैलियाँ हैं:
 * ब्लैकबोर्ड (कंप्यूटिंग)
 * क्लाइंट-सर्वर मॉडल | क्लाइंट-सर्वर (2-टियर, त्रि-स्तरीय (कंप्यूटिंग)|3-टियर, एन-टियर|एन-टियर, क्लाउड कम्प्यूटिंग इस शैली को प्रदर्शित करता है)
 * सॉफ्टवेयर घटक | घटक-आधारित
 * डेटाबेस-केंद्रित वास्तुकला|डेटा-केंद्रित
 * घटना-संचालित वास्तुकला| इवेंट-ड्रिवन (या निहित आह्वान)
 * अमूर्तता (कंप्यूटर विज्ञान) # स्तरित वास्तुकला (या बहुस्तरीय वास्तुकला)
 * माइक्रोसर्विसेज
 * अखंड आवेदन
 * पीयर टू पीयर (P2P)
 * पाइप और फिल्टर
 * प्लग-इन (कंप्यूटिंग) | प्लग-इन
 * प्रतिक्रियाशील वास्तुकला
 * प्रतिनिधित्वात्मक राज्य स्थानांतरण (REST)
 * नियम-आधारित व्यवस्था|नियम-आधारित
 * सेवा-उन्मुख वास्तुकला | सेवा-उन्मुख
 * साझा कुछ भी नहीं वास्तुकला
 * अंतरिक्ष आधारित वास्तुकला

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

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

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

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

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

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

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

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

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

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

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

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


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

यह भी देखें
• Archimate

• Architectural pattern (computer science)

• Anti-pattern

• Attribute-driven design

• C4 model

• Computer architecture

• Distributed Data Management Architecture

• Distributed Relational Database Architecture

• Systems architecture

• Systems design

• Software Architecture Analysis Method

• Time-triggered system

अग्रिम पठन

 * - This book covers the fundamental concepts of the discipline. The theme is centered on achieving quality attributes of a system.
 * - 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.
 * - On the distinction between architectural design and detailed design.
 * - On the distinction between architectural design and detailed design.
 * - On the distinction between architectural design and detailed design.
 * - On the distinction between architectural design and detailed design.
 * - On the distinction between architectural design and detailed design.
 * - On the distinction between architectural design and detailed design.

बाहरी संबंध

 * 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