सॉफ्टवेर डिज़ाइन: Difference between revisions

From Vigyanwiki
(Created page with "{{Short description|Process of planning software solutions}} {{more citations needed|date=January 2013}} {{Software development process|Core activities}} सॉफ़्ट...")
 
No edit summary
 
(20 intermediate revisions by 3 users not shown)
Line 1: Line 1:
{{Short description|Process of planning software solutions}}
{{Software development process|Core activities}}
{{more citations needed|date=January 2013}}


{{Software development process|Core activities}}
'''सॉफ़्टवेयर डिजाइन''' वह प्रक्रिया है, जिसके द्वारा एक [[एजेंसी (दर्शन)|एजेंट]] पुराने घटकों के समुच्चय का उपयोग करके और बाधाओं के अधीन [[लक्ष्य|लक्ष्यों]] को पूरा करने के उद्देश्य से कलाकृति (सॉफ़्टवेयर विकास) का एक विनिर्देश का निर्माण करती है।<ref>Ralph, P. and Wand, Y. (2009). A proposal for a formal definition of the design concept. In Lyytinen, K., Loucopoulos, P., [[John Mylopoulos|Mylopoulos, J.]], and Robinson, W., editors, Design Requirements Workshop (LNBIP 14), pp. 103–136. Springer-Verlag, p. 109 {{doi|10.1007/978-3-540-92966-6_6}}.</ref> इस शब्द का प्रयोग अधिकांशतः सॉफ्टवेयर की संकल्पना को बनाने, तैयार करने, संचालित करने, प्रारम्भ करने और अंततः संशोधित करने में सम्मिलित सभी गतिविधियों को संदर्भित करने के लिए किया जाता है या अधिक विशेष रूप से सॉफ्टवेयर आवश्यकताओं के विनिर्देश के पश्चात और [[कंप्यूटर प्रोग्रामिंग]] से पहले की गतिविधि के रूप में एक शैलीबद्ध सॉफ्टवेयर इंजीनियरिंग प्रक्रिया में इसका प्रयोग किया जाता है।<ref>{{cite journal|last=Freeman|first=Peter|author2=David Hart |s2cid=14331332|title=सॉफ्टवेयर-गहन प्रणालियों के लिए डिजाइन का विज्ञान|journal=Communications of the ACM|year=2004|volume=47|issue=8|pages=19–21 [20]|doi=10.1145/1012037.1012054 }}</ref>


सॉफ़्टवेयर डिज़ाइन वह प्रक्रिया है जिसके द्वारा एक [[एजेंसी (दर्शन)]] आदिम घटकों के एक सेट का उपयोग करके और बाधाओं (गणित) के अधीन [[लक्ष्य]]ों को पूरा करने के उद्देश्य से एक कलाकृति (सॉफ़्टवेयर विकास) का एक विनिर्देश बनाती है।<ref>Ralph, P. and Wand, Y. (2009). A proposal for a formal definition of the design concept. In Lyytinen, K., Loucopoulos, P., [[John Mylopoulos|Mylopoulos, J.]], and Robinson, W., editors, Design Requirements Workshop (LNBIP 14), pp. 103–136. Springer-Verlag, p. 109 {{doi|10.1007/978-3-540-92966-6_6}}.</ref> इस शब्द का प्रयोग कभी-कभी मोटे तौर पर सॉफ्टवेयर की संकल्पना बनाने, तैयार करने, लागू करने, चालू करने और अंततः संशोधित करने में शामिल सभी गतिविधियों को संदर्भित करने के लिए किया जाता है, या अधिक विशेष रूप से सॉफ्टवेयर आवश्यकताओं के विनिर्देश के बाद और [[कंप्यूटर प्रोग्रामिंग]] से पहले की गतिविधि के रूप में ... [में] एक शैलीबद्ध सॉफ्टवेयर इंजीनियरिंग प्रक्रिया।<ref>{{cite journal|last=Freeman|first=Peter|author2=David Hart |s2cid=14331332|title=सॉफ्टवेयर-गहन प्रणालियों के लिए डिजाइन का विज्ञान|journal=Communications of the ACM|year=2004|volume=47|issue=8|pages=19–21 [20]|doi=10.1145/1012037.1012054 }}</ref>
सॉफ़्टवेयर डिजाइन में सामान्यतः समस्या-समाधान और सॉफ़्टवेयर समाधान की योजना बनाना सम्मिलित होता है। इसमें निम्न-स्तरीय घटक और [[एल्गोरिथम डिजाइन]] और उच्च-स्तरीय सॉफ़्टवेयर आर्किटेक्चर डिजाइन दोनों सम्मिलित हैं।
सॉफ़्टवेयर डिज़ाइन में आमतौर पर समस्या-समाधान और सॉफ़्टवेयर समाधान की योजना बनाना शामिल होता है। इसमें निम्न-स्तरीय घटक और [[एल्गोरिथम डिजाइन]] और उच्च-स्तरीय, सॉफ़्टवेयर आर्किटेक्चर डिज़ाइन दोनों शामिल हैं।


== सिंहावलोकन ==
== अवलोकन ==


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


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


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


सॉफ्टवेयर डिजाइन एक प्रक्रिया और एक मॉडल दोनों है। डिज़ाइन प्रक्रिया चरणों का एक क्रम है जो डिज़ाइनर को निर्माण के लिए सॉफ़्टवेयर के सभी पहलुओं का वर्णन करने में सक्षम बनाती है। रचनात्मक कौशल, पिछला अनुभव, अच्छा सॉफ्टवेयर बनाने की भावना, और गुणवत्ता के प्रति समग्र प्रतिबद्धता एक सक्षम डिजाइन के लिए महत्वपूर्ण सफलता कारकों के उदाहरण हैं। हालांकि, यह ध्यान रखना महत्वपूर्ण है कि डिजाइन प्रक्रिया हमेशा एक सीधी प्रक्रिया नहीं होती है; डिजाइन मॉडल की तुलना एक घर के लिए आर्किटेक्ट की योजनाओं से की जा सकती है। यह उस चीज़ की समग्रता का प्रतिनिधित्व करने से शुरू होता है जिसे बनाया जाना है (उदाहरण के लिए, घर का त्रि-आयामी प्रतिपादन); धीरे-धीरे, प्रत्येक विवरण के निर्माण के लिए मार्गदर्शन प्रदान करने के लिए चीज़ को परिष्कृत किया जाता है (जैसे, नलसाजी बिछाना)। इसी प्रकार, सॉफ़्टवेयर के लिए बनाया गया डिज़ाइन मॉडल कंप्यूटर सॉफ़्टवेयर के विभिन्न प्रकार के विभिन्न दृश्य प्रदान करता है। मूल डिज़ाइन सिद्धांत सॉफ़्टवेयर इंजीनियर को डिज़ाइन प्रक्रिया को नेविगेट करने में सक्षम बनाते हैं। डेविस<ref>Davis, A:"201 Principles of Software Development", McGraw Hill, 1995.</ref> सॉफ्टवेयर डिजाइन के लिए सिद्धांतों का एक सेट सुझाता है, जिसे निम्नलिखित सूची में अनुकूलित और विस्तारित किया गया है:
सॉफ्टवेयर डिजाइन एक प्रक्रिया और मॉडल दोनों है। डिजाइन प्रक्रिया चरणों का एक क्रम है। जो डिजाइनर को निर्माण के लिए सॉफ़्टवेयर के सभी पहलुओं का वर्णन करने में सक्षम बनाती है। रचनात्मक कौशल, पिछला अनुभव, अच्छा सॉफ्टवेयर बनाने की भावना और गुणवत्ता के प्रति समग्र प्रतिबद्धता एक सक्षम डिजाइन के लिए महत्वपूर्ण सफलता के कारकों के उदाहरण हैं। चूंकि यह ध्यान रखना महत्वपूर्ण है कि डिजाइन प्रक्रिया सदैव एक सीधी प्रक्रिया नहीं होती है। डिजाइन मॉडल की तुलना एक घर के लिए आर्किटेक्ट की योजनाओं से की जा सकती है। यह उस वस्तु की समग्रता का प्रतिनिधित्व करने से प्रारम्भ होता है। जिसे बनाया जाना है (उदाहरण के लिए घर का त्रि-आयामी प्रतिपादन); धीरे-धीरे प्रत्येक विवरण के निर्माण के लिए मार्गदर्शन प्रदान करने के लिए वस्तु को परिष्कृत किया जाता है (जैसे प्लंबिंग ले )। इसी प्रकार सॉफ़्टवेयर के लिए बनाया गया डिजाइन मॉडल कंप्यूटर सॉफ़्टवेयर के विभिन्न प्रकार के विभिन्न दृश्य प्रदान करता है। मूल डिजाइन सिद्धांत सॉफ़्टवेयर इंजीनियर को डिजाइन प्रक्रिया को नेविगेट करने में सक्षम बनाती हैं। डेविस<ref>Davis, A:"201 Principles of Software Development", McGraw Hill, 1995.</ref> सॉफ्टवेयर डिजाइन के लिए सिद्धांतों का एक समुच्चय का निर्माण कर सकता है। जिसे निम्नलिखित सूची में अनुकूलित और विस्तारित किया गया है:
* डिजाइन प्रक्रिया को टनल विजन से पीड़ित नहीं होना चाहिए। एक अच्छे डिजाइनर को वैकल्पिक तरीकों पर विचार करना चाहिए, समस्या की आवश्यकताओं के आधार पर प्रत्येक को देखते हुए, काम करने के लिए उपलब्ध संसाधन।
* डिजाइन प्रक्रिया को टनल विजन से पीड़ित नहीं होना चाहिए। एक अच्छे डिजाइनर को वैकल्पिक उपायों पर विचार करना चाहिए, समस्या की आवश्यकताओं के आधार पर प्रत्येक को देखते हुए काम करने के लिए उपलब्ध संसाधनों की व्यवस्था करनी चाहिए।
* डिजाइन विश्लेषण मॉडल के लिए पता लगाने योग्य होना चाहिए। क्योंकि डिज़ाइन मॉडल के एक तत्व को अक्सर कई आवश्यकताओं के लिए वापस खोजा जा सकता है, यह ट्रैक करने के लिए एक साधन होना आवश्यक है कि डिज़ाइन मॉडल द्वारा आवश्यकताओं को कैसे पूरा किया गया है।
* डिजाइन विश्लेषण मॉडल के लिए पता लगाने योग्य होना चाहिए क्योंकि डिजाइन मॉडल के एक तत्व को प्रायः कई आवश्यकताओं के लिए वापस खोजा जा सकता है। यह ट्रैक करने के लिए एक साधन होना आवश्यक है कि डिजाइन मॉडल द्वारा आवश्यकताओं को कैसे पूरा किया गया है।
* डिजाइन को पहिया को फिर से नहीं लगाना चाहिए। सिस्टम का निर्माण डिज़ाइन पैटर्न के एक सेट का उपयोग करके किया जाता है, जिनमें से कई का पहले सामना किया जा चुका है। इन पैटर्नों को हमेशा पुनर्खोज के विकल्प के रूप में चुना जाना चाहिए। समय कम है और संसाधन सीमित हैं; डिजाइन समय को पहले से मौजूद (जब लागू हो) पैटर्न को एकीकृत करके (वास्तव में नए) विचारों का प्रतिनिधित्व करने में निवेश किया जाना चाहिए।
* डिजाइन को पहिया को फिर से नहीं लगाना चाहिए। प्रणाली का निर्माण डिजाइन पैटर्न के एक समुच्चय का उपयोग करके किया जाता है। जिनमें से कई की जानकारी पहले ही प्राप्त की जा चुकी है। इन पैटर्नों को सदैव पुनर्खोज के विकल्प के रूप में चुना जाना चाहिए। समय कम है और संसाधन सीमित हैं। डिजाइन समय को पहले से उपस्थित (जब संचालित हो) पैटर्न को एकीकृत करके (वास्तव में नए) विचारों का प्रतिनिधित्व करने में निवेश किया जाना चाहिए।
* डिजाइन को सॉफ्टवेयर और समस्या के बीच बौद्धिक दूरी को कम करना चाहिए क्योंकि यह वास्तविक दुनिया में मौजूद है। अर्थात्, सॉफ़्टवेयर डिज़ाइन की संरचना, जब भी संभव हो, समस्या डोमेन की संरचना की नकल करनी चाहिए।
* डिजाइन को सॉफ्टवेयर और समस्या के बीच बौद्धिक दूरी को कम करना चाहिए क्योंकि यह वास्तविक विश्व में उपस्थित है। अर्थात्, सॉफ़्टवेयर डिजाइन की संरचना, जब भी संभव हो, समस्या डोमेन की संरचना की कॉपी करनी चाहिए।
* डिजाइन में एकरूपता और एकीकरण प्रदर्शित होना चाहिए। एक डिजाइन एक समान है अगर यह पूरी तरह सुसंगत दिखाई देता है। इस परिणाम को प्राप्त करने के लिए, डिजाइन का काम शुरू होने से पहले डिजाइन टीम के लिए शैली और प्रारूप के नियमों को परिभाषित किया जाना चाहिए। यदि डिजाइन घटकों के बीच इंटरफेस को परिभाषित करने में सावधानी बरती जाती है तो एक डिजाइन को एकीकृत किया जाता है।
* डिजाइन में एकरूपता और एकीकरण प्रदर्शित होना चाहिए। एक डिजाइन एक समान है। यदि यह पूर्णतयः सुसंगत प्रतीत होता है। इस परिणाम को प्राप्त करने के लिए डिजाइन का कार्य प्रारम्भ होने से पहले डिजाइन टीम के लिए शैली और डिजाइन के नियमों को परिभाषित किया जाना चाहिए। यदि डिजाइन घटकों के बीच इंटरफेस को परिभाषित करने में सावधानी की जानी चाहिए। जिससे डिजाइन को एकीकृत किया जाता है।
* परिवर्तन को समायोजित करने के लिए डिजाइन को संरचित किया जाना चाहिए। अगले खंड में चर्चा की गई डिज़ाइन अवधारणाएँ इस सिद्धांत को प्राप्त करने के लिए डिज़ाइन को सक्षम बनाती हैं।
* परिवर्तन को समायोजित करने के लिए डिजाइन को संरचित किया जाना चाहिए। अगले खंड के विषय में चर्चा की गई डिजाइन अवधारणाएँ इस सिद्धांत को प्राप्त करने के लिए डिजाइन को सक्षम बनाती हैं।
* डिजाइन को धीरे-धीरे नीचा दिखाने के लिए संरचित किया जाना चाहिए, भले ही असामान्य डेटा, घटनाओं या परिचालन स्थितियों का सामना करना पड़े। अच्छी तरह से डिज़ाइन किए गए सॉफ़्टवेयर को कभी भी बम नहीं बनाना चाहिए; इसे असामान्य परिस्थितियों को समायोजित करने के लिए डिज़ाइन किया जाना चाहिए, और यदि इसे प्रसंस्करण समाप्त करना ही है, तो इसे एक शालीन तरीके से करना चाहिए।
* डिजाइन को धीरे-धीरे निम्न स्तर का प्रदर्शित करने के लिए संरचित किया जाना चाहिए। तथापि असामान्य डेटा, घटनाओं या परिचालन स्थितियों का सामना करना पड़े। अच्छी प्रकार से डिजाइन किए गए सॉफ़्टवेयर को कभी भी बम नहीं बनाना चाहिए। इसे असामान्य परिस्थितियों को समायोजित करने के लिए डिजाइन किया जाना चाहिए और यदि इसे प्रसंस्करण समाप्त करना ही है। जिससे इसे एक उत्तम प्रकार से किया जाना चाहिए।
* डिज़ाइन कोडिंग नहीं है, कोडिंग डिज़ाइन नहीं है। यहां तक ​​कि जब प्रोग्राम घटकों के लिए विस्तृत प्रक्रियात्मक डिजाइन बनाए जाते हैं, तब भी डिजाइन मॉडल के अमूर्तन का स्तर स्रोत कोड से अधिक होता है। कोडिंग स्तर पर किए गए एकमात्र डिज़ाइन निर्णयों को छोटे कार्यान्वयन विवरणों को संबोधित करना चाहिए जो प्रक्रियात्मक डिज़ाइन को कोडित करने में सक्षम बनाता है।
* डिजाइन कोडिंग नहीं है, कोडिंग डिजाइन नहीं है। यहां तक ​​कि जब प्रोग्राम घटकों के लिए विस्तृत प्रक्रियात्मक डिजाइन बनाए जाते हैं। तब भी डिजाइन मॉडल के अमूर्तन का स्तर स्रोत कोड से अधिक होता है। कोडिंग स्तर पर किए गए एकमात्र डिजाइन निर्णयों को छोटे कार्यान्वयन विवरणों को संबोधित करना चाहिए। जो प्रक्रियात्मक डिजाइन को कोडित करने में सक्षम बनाने का कार्य करता है।
* डिजाइन का मूल्यांकन गुणवत्ता के लिए किया जाना चाहिए क्योंकि यह बनाया जा रहा है, तथ्य के बाद नहीं। विकास प्रक्रिया के दौरान गुणवत्ता का आकलन करने में डिज़ाइनर की सहायता के लिए विभिन्न प्रकार की डिज़ाइन अवधारणाएँ और डिज़ाइन उपाय उपलब्ध हैं।
* डिजाइन का मूल्यांकन गुणवत्ता के लिए किया जाना चाहिए क्योंकि यह तथ्य के बाद नहीं बनाया जा रहा है। विकास प्रक्रिया के समय गुणवत्ता का आकलन करने में डिजाइनर की सहायता के लिए विभिन्न प्रकार की डिजाइन अवधारणाएँ और डिजाइन उपाय उपलब्ध होते हैं।
* वैचारिक (सिमेंटिक) त्रुटियों को कम करने के लिए डिजाइन की समीक्षा की जानी चाहिए। जब डिजाइन की समीक्षा की जाती है तो कभी-कभी बारीकियों पर ध्यान केंद्रित करने की प्रवृत्ति होती है, पेड़ों के लिए जंगल गायब हो जाता है। एक डिज़ाइन टीम को यह सुनिश्चित करना चाहिए कि डिज़ाइन मॉडल के सिंटैक्स के बारे में चिंता करने से पहले डिज़ाइन के प्रमुख वैचारिक तत्वों (चूक, अस्पष्टता, असंगति) को संबोधित किया गया है।
* वैचारिक (सिमेंटिक) त्रुटियों को कम करने के लिए डिजाइन की समीक्षा की जानी चाहिए। जब डिजाइन की समीक्षा की जाती है। तो संभवतः छोटी-छोटी त्रुटियों पर ध्यान केंद्रित करने की प्रवृत्ति होती है, पेड़ों के लिए जंगल विलुप्त हो जाता है। एक डिजाइन टीम को यह सुनिश्चित करना चाहिए कि डिजाइन मॉडल के सिंटैक्स के बारे में चिंता करने से पहले डिजाइन के प्रमुख वैचारिक तत्वों (भ्रम, अस्पष्टता, असंगति) को संबोधित किया गया है।


== डिजाइन अवधारणा ==
== डिजाइन अवधारणा ==


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


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


अपने ऑब्जेक्ट मॉडल में, [[ग्रेडी बूच]] ने मौलिक सॉफ्टवेयर डिजाइन सिद्धांतों के रूप में एब्सट्रैक्शन, एनकैप्सुलेशन, मॉड्यूलराइजेशन और पदानुक्रम का उल्लेख किया है।<ref>{{cite book|last1=Booch|first1=Grady|title=ऑब्जेक्ट-ओरिएंटेड विश्लेषण और अनुप्रयोगों के साथ डिजाइन|date=2004|publisher=Addison Wesley|location=MA, USA|isbn=0-201-89551-X|edition=3rd|url=http://dl.acm.org/citation.cfm?id=975416|access-date=30 January 2015|display-authors=etal}}</ref> परिवर्णी शब्द PHAME (पदानुक्रम के सिद्धांत, अमूर्तता, मॉड्यूलरीकरण, और एनकैप्सुलेशन) का प्रयोग कभी-कभी इन चार मूलभूत सिद्धांतों को संदर्भित करने के लिए किया जाता है।<ref>{{cite book|last1=Suryanarayana|first1=Girish|title=सॉफ्टवेयर डिजाइन गंध के लिए रिफैक्टरिंग|date=November 2014|publisher=Morgan Kaufmann|isbn=978-0128013977|pages=258}}</ref>
अपने ऑब्जेक्ट मॉडल में, [[ग्रेडी बूच]] ने मौलिक सॉफ्टवेयर डिजाइन सिद्धांतों के रूप में एब्सट्रैक्शन, एनकैप्सुलेशन, मॉड्यूलराइजेशन और पदानुक्रम का उल्लेख किया है।<ref>{{cite book|last1=Booch|first1=Grady|title=ऑब्जेक्ट-ओरिएंटेड विश्लेषण और अनुप्रयोगों के साथ डिजाइन|date=2004|publisher=Addison Wesley|location=MA, USA|isbn=0-201-89551-X|edition=3rd|url=http://dl.acm.org/citation.cfm?id=975416|access-date=30 January 2015|display-authors=etal}}</ref> परिवर्णी शब्द फेम (पदानुक्रम के सिद्धांत, अमूर्तता, मॉड्यूलरीकरण, और एनकैप्सुलेशन) का प्रयोग संभवतः इन चार मूलभूत सिद्धांतों को संदर्भित करने के लिए किया जाता है।<ref>{{cite book|last1=Suryanarayana|first1=Girish|title=सॉफ्टवेयर डिजाइन गंध के लिए रिफैक्टरिंग|date=November 2014|publisher=Morgan Kaufmann|isbn=978-0128013977|pages=258}}</ref>




== डिजाइन विचार ==
== डिजाइन विचार ==


सॉफ्टवेयर के एक टुकड़े के डिजाइन में विचार करने के लिए कई पहलू हैं। प्रत्येक विचार के महत्व को उन लक्ष्यों और अपेक्षाओं को प्रतिबिंबित करना चाहिए जिन्हें पूरा करने के लिए सॉफ्टवेयर बनाया जा रहा है। इनमें से कुछ पहलू हैं:
सॉफ्टवेयर के एक टुकड़े के डिजाइन में विचार करने के लिए कई तथ्य उपस्थित होते हैं। प्रत्येक विचार के महत्व को उन लक्ष्यों और अपेक्षाओं को प्रतिबिंबित करना चाहिए। जिन्हें पूरा करने के लिए सॉफ्टवेयर बनाया जा रहा है। इनमें से कुछ तथ्य निम्नलिखित हैं:


* संगतता - सॉफ़्टवेयर अन्य उत्पादों के साथ काम करने में सक्षम है जो किसी अन्य उत्पाद के साथ इंटरऑपरेबिलिटी के लिए डिज़ाइन किए गए हैं। उदाहरण के लिए, सॉफ़्टवेयर का एक टुकड़ा अपने पुराने संस्करण के साथ पिछड़ा-संगत हो सकता है।
* संगतता - सॉफ़्टवेयर अन्य उत्पादों के साथ काम करने में सक्षम है। जो किसी अन्य उत्पाद के साथ इंटरऑपरेबिलिटी के लिए डिजाइन किए गए हैं। उदाहरण के लिए सॉफ़्टवेयर का एक टुकड़ा अपने पुराने संस्करण के साथ पिछड़ा-संगत हो सकता है।
* [[तानाना]] - अंतर्निहित आर्किटेक्चर में बड़े बदलाव के बिना सॉफ्टवेयर में नई क्षमताओं को जोड़ा जा सकता है।
* [[तानाना]] - अंतर्निहित आर्किटेक्चर में बड़े परिवर्तन के बिना सॉफ्टवेयर में नई क्षमताओं को जोड़ा जा सकता है।
* मॉड्यूलरिटी - परिणामी सॉफ़्टवेयर में अच्छी तरह से परिभाषित, स्वतंत्र घटक शामिल होते हैं जो बेहतर रखरखाव की ओर ले जाते हैं। वांछित सॉफ्टवेयर सिस्टम बनाने के लिए एकीकृत होने से पहले घटकों को लागू किया जा सकता है और अलगाव में परीक्षण किया जा सकता है। यह एक सॉफ्टवेयर डेवलपमेंट प्रोजेक्ट में काम के विभाजन की अनुमति देता है।
* मॉड्यूलरिटी - परिणामी सॉफ़्टवेयर में अच्छी प्रकार से परिभाषित स्वतंत्र घटक सम्मिलित होते हैं। जो उत्तम देखरेख की ओर ले जाते हैं। वांछित सॉफ्टवेयर प्रणाली का निर्माण करने के लिए एकीकृत होने से पहले घटकों को संचालित किया जा सकता है और विच्छेदन में परीक्षण किया जा सकता है। यह एक सॉफ्टवेयर डेवलपमेंट प्रोजेक्ट में कार्य के विभाजन की अनुमति प्रदान करता है।
* दोष-सहिष्णुता - सॉफ्टवेयर प्रतिरोधी है और घटक विफलता से उबरने में सक्षम है।
* दोष-सहिष्णुता - सॉफ्टवेयर प्रतिरोधी है और घटक विफलता से बाहर निकलने में पूर्णतयः सक्षम है।
* [[रख-रखाव]] - बग फिक्स या कार्यात्मक संशोधनों को कितनी आसानी से पूरा किया जा सकता है, इसका एक उपाय। उच्च रख-रखाव मॉड्यूलरिटी और एक्स्टेंसिबिलिटी का उत्पाद हो सकता है।
* [[रख-रखाव]] - बग फिक्स या कार्यात्मक संशोधनों को कितनी सरलता से पूरा किया जा सकता है। इसका एक उपाय उच्च रख-रखाव मॉड्यूलरिटी और एक्स्टेंसिबिलिटी का उत्पाद हो सकता है।
* विश्वसनीयता (सॉफ्टवेयर स्थायित्व) - सॉफ्टवेयर निर्दिष्ट शर्तों के तहत एक निर्दिष्ट अवधि के लिए एक आवश्यक कार्य करने में सक्षम है।
* विश्वसनीयता (सॉफ्टवेयर स्थायित्व) - सॉफ्टवेयर निर्दिष्ट नियमों के अनुसार एक निर्दिष्ट अवधि के लिए एक आवश्यक कार्य करने में सक्षम है।
* पुन: प्रयोज्य - अन्य परियोजनाओं में पहले से मौजूद सॉफ़्टवेयर के कुछ या सभी पहलुओं को बिना किसी संशोधन के उपयोग करने की क्षमता।
* पुन: प्रयोज्य - अन्य परियोजनाओं में पहले से उपस्थित सॉफ़्टवेयर के कुछ या सभी तथ्यों को बिना किसी संशोधन के उपयोग करने की क्षमता होती है।
* [[दोष-सहिष्णु प्रणाली]] - सॉफ्टवेयर तनाव में काम करने या अप्रत्याशित या अमान्य इनपुट को सहन करने में सक्षम है। उदाहरण के लिए, इसे कम स्मृति स्थितियों के लचीलेपन के साथ डिजाइन किया जा सकता है।
* [[दोष-सहिष्णु प्रणाली]] - सॉफ्टवेयर तनाव में काम करने या अप्रत्याशित या अमान्य इनपुट को सहन करने में सक्षम है। उदाहरण के लिए इसे कम स्मृति स्थितियों के लचीलेपन के साथ डिजाइन किया जा सकता है।
* [[कंप्यूटर सुरक्षा]] - सॉफ्टवेयर शत्रुतापूर्ण कृत्यों और प्रभावों का सामना करने और उनका विरोध करने में सक्षम है।
* [[कंप्यूटर सुरक्षा]] - सॉफ्टवेयर शत्रुतापूर्ण कृत्यों और प्रभावों का सामना करने और उनका विरोध करने में सक्षम है।
* उपयोगिता - सॉफ्टवेयर यूजर इंटरफेस अपने लक्षित उपयोगकर्ता/दर्शकों के लिए प्रयोग करने योग्य होना चाहिए। मापदंडों के लिए डिफ़ॉल्ट मान चुना जाना चाहिए ताकि वे अधिकांश उपयोगकर्ताओं के लिए एक अच्छा विकल्प हों।<ref>{{cite book|editor-last=Carroll|editor-first=John|title=Scenario-Based Design: Envisioning Work and Technology in System Development|year=1995|publisher=John Wiley & Sons|location=New York|isbn=0471076597}}</ref>
* उपयोगिता - सॉफ्टवेयर यूजर इंटरफेस अपने लक्षित उपयोगकर्ता/दर्शकों के लिए प्रयोग करने योग्य होना चाहिए। मापदंडों के लिए डिफ़ॉल्ट मान चुना जाना चाहिए। जिससे वे अधिकांश उपयोगकर्ताओं के लिए एक अच्छा विकल्प हों।<ref>{{cite book|editor-last=Carroll|editor-first=John|title=Scenario-Based Design: Envisioning Work and Technology in System Development|year=1995|publisher=John Wiley & Sons|location=New York|isbn=0471076597}}</ref>
* [[कंप्यूटर का प्रदर्शन]] - सॉफ्टवेयर एक समय-सीमा के भीतर अपना कार्य करता है जो उपयोगकर्ता के लिए स्वीकार्य है, और इसके लिए बहुत अधिक मेमोरी की आवश्यकता नहीं होती है।
* [[कंप्यूटर का प्रदर्शन]] - सॉफ्टवेयर एक समय-सीमा के अन्दर अपना कार्य करता है। जो उपयोगकर्ता के लिए स्वीकार्य है और इसके लिए बहुत अधिक मेमोरी की आवश्यकता नहीं होती है।
* सॉफ्टवेयर सुवाह्यता - सॉफ्टवेयर को कई अलग-अलग स्थितियों और वातावरणों में प्रयोग करने योग्य होना चाहिए।
* सॉफ्टवेयर सुवाह्यता - सॉफ्टवेयर को कई विभिन्न स्थितियों और वातावरणों में प्रयोग करने योग्य होना चाहिए।
* मापनीयता - सॉफ्टवेयर बढ़ते हुए डेटा या अतिरिक्त सुविधाओं या उपयोगकर्ताओं की संख्या के लिए अच्छी तरह से अनुकूल है।
* मापनीयता - सॉफ्टवेयर बढ़ते हुए डेटा या अतिरिक्त सुविधाओं या उपयोगकर्ताओं की संख्या के लिए अच्छी प्रकार से अनुकूल है।


== [[मॉडलिंग भाषा]] ==
== [[मॉडलिंग भाषा]] ==


एक मॉडलिंग भाषा कोई भी कृत्रिम भाषा है जिसका उपयोग सूचनाओं, ज्ञान या प्रणालियों को एक संरचना में व्यक्त करने के लिए किया जा सकता है जिसे नियमों के एक सुसंगत सेट द्वारा परिभाषित किया गया है। इन नियमों का उपयोग संरचना के भीतर घटकों की व्याख्या के लिए किया जाता है। एक मॉडलिंग भाषा चित्रमय या पाठ्य हो सकती है। सॉफ़्टवेयर डिज़ाइन के लिए ग्राफ़िकल मॉडलिंग भाषाओं के उदाहरण हैं:
मॉडलिंग भाषा कोई भी कृत्रिम भाषा है। जिसका उपयोग सूचनाओं, ज्ञान या प्रणालियों को एक संरचना में व्यक्त करने के लिए किया जा सकता है। जिसे नियमों के एक सुसंगत समुच्चय द्वारा परिभाषित किया गया है। इन नियमों का उपयोग संरचना के अन्दर घटकों की व्याख्या के लिए किया जाता है। एक मॉडलिंग भाषा चित्रमय या पाठ्य हो सकती है। सॉफ़्टवेयर डिजाइन के लिए ग्राफ़िकल मॉडलिंग भाषाओं के उदाहरण हैं:
*[[ वास्तुकला विवरण भाषा ]] (एडीएल) एक ऐसी भाषा है जिसका उपयोग सॉफ्टवेयर सिस्टम के सॉफ्टवेयर आर्किटेक्चर का वर्णन और प्रतिनिधित्व करने के लिए किया जाता है।
*[[ वास्तुकला विवरण भाषा ]] (एडीएल) एक ऐसी भाषा है, जिसका उपयोग सॉफ्टवेयर प्रणाली के सॉफ्टवेयर आर्किटेक्चर का वर्णन और प्रतिनिधित्व करने के लिए किया जाता है।
* [[बिजनेस प्रोसेस मॉडलिंग नोटेशन]] (बीपीएमएन) प्रोसेस मॉडलिंग भाषा का एक उदाहरण है।
* [[बिजनेस प्रोसेस मॉडलिंग नोटेशन]] (बीपीएमएन) प्रोसेस मॉडलिंग भाषा का एक उदाहरण है।
* [[एक्सप्रेस ([[मॉडलिंग की दिनांक]] भाषा)]] और एक्सप्रेस-जी (आईएसओ 10303-11) एक अंतरराष्ट्रीय मानक सामान्य प्रयोजन डेटा मॉडलिंग भाषा है।
* एक्सप्रेस ([[मॉडलिंग की दिनांक]] भाषा) और एक्सप्रेस-जी (आईएसओ 10303-11) एक अंतरराष्ट्रीय मानक सामान्य प्रयोजन डेटा मॉडलिंग भाषा है।
* विस्तारित [[विस्तारित उद्यम मॉडलिंग भाषा]]EEML) का उपयोग आमतौर पर कई परतों में व्यवसाय [[प्रक्रिया मॉडलिंग]] के लिए किया जाता है।
* विस्तारित [[विस्तारित उद्यम मॉडलिंग भाषा]] ईईएमएस) का उपयोग सामान्यतः कई परतों में व्यवसाय [[प्रक्रिया मॉडलिंग]] के लिए किया जाता है।
* [[फ़्लोचार्ट]] एल्गोरिदम या अन्य चरण-वार प्रक्रियाओं का योजनाबद्ध प्रतिनिधित्व है।
* [[फ़्लोचार्ट]] एल्गोरिदम या अन्य चरण-वार प्रक्रियाओं का योजनाबद्ध प्रतिनिधित्व है।
* [[मौलिक मॉडलिंग अवधारणाएँ]] (FMC) सॉफ्टवेयर-इंटेंसिव सिस्टम्स के लिए मॉडलिंग लैंग्वेज है।
* [[मौलिक मॉडलिंग अवधारणाएँ]] (एफएमसी) सॉफ्टवेयर-इंटेंसिव सिस्टम्स के लिए मॉडलिंग भाषा है।
* [[IDEF]] मॉडलिंग भाषाओं का एक परिवार है, जिनमें से सबसे उल्लेखनीय में कार्यात्मक मॉडलिंग के लिए [[IDEF0]], सूचना मॉडलिंग के लिए [[IDEF1X]] और ओन्टोलॉजी (सूचना विज्ञान) मॉडलिंग के लिए [[IDEF5]] शामिल हैं।
* [[IDEF|आईडीईएफ]] मॉडलिंग भाषाओं की एक फैमली है। जिनमें से सबसे उल्लेखनीय में कार्यात्मक मॉडलिंग के लिए [[IDEF0|आईडीईएफ0]], सूचना मॉडलिंग के लिए [[IDEF1X|आईडीईएफ]][[IDEF1X|1एक्स]] और ओन्टोलॉजी (सूचना विज्ञान) मॉडलिंग के लिए [[IDEF5|आईडीईएफ]][[IDEF5|5]] सम्मिलित हैं।
* [[ जैक्सन संरचित प्रोग्रामिंग ]] (जेएसपी) डेटा स्ट्रीम संरचना और प्रोग्राम संरचना के बीच पत्राचार के आधार पर संरचित प्रोग्रामिंग के लिए एक विधि है।
* [[ जैक्सन संरचित प्रोग्रामिंग ]] (जेएसपी) डेटा स्ट्रीम संरचना और प्रोग्राम संरचना के बीच पत्राचार के आधार पर संरचित प्रोग्रामिंग के लिए एक विधि है।
* [[Lepus3]] एक [[ वस्तु के उन्मुख ]] विज़ुअल डिज़ाइन डिस्क्रिप्शन लैंग्वेज और एक [[औपचारिक विनिर्देश]] भाषा है जो मुख्य रूप से बड़े ऑब्जेक्ट-ओरिएंटेड (Java (प्रोग्रामिंग लैंग्वेज), [[C++]], C Sharp (प्रोग्रामिंग लैंग्वेज)|C#) प्रोग्राम और डिज़ाइन पैटर्न मॉडलिंग के लिए उपयुक्त है।
* [[Lepus3|लेपस3]] एक [[ वस्तु के उन्मुख ]] विज़ुअल डिजाइन डिस्क्रिप्शन लैंग्वेज और एक [[औपचारिक विनिर्देश]] भाषा है। जो मुख्य रूप से बड़े ऑब्जेक्ट-ओरिएंटेड (जावा (प्रोग्रामिंग लैंग्वेज), [[C++]], सी सार्प (प्रोग्रामिंग लैंग्वेज),सी#) प्रोग्राम और डिजाइन पैटर्न मॉडलिंग के लिए उपयुक्त है।
* यूनिफाइड मॉडलिंग लैंग्वेज (यूएमएल) एक सामान्य मॉडलिंग भाषा है जो सॉफ्टवेयर को संरचनात्मक और व्यवहारिक रूप से वर्णित करती है। इसमें ग्राफिकल नोटेशन है और [[प्रोफाइल (यूएमएल)]] के साथ विस्तार की अनुमति देता है।
* यूनिफाइड मॉडलिंग लैंग्वेज (यूएमएल) एक सामान्य मॉडलिंग भाषा है। जो सॉफ्टवेयर को संरचनात्मक और व्यवहारिक रूप से वर्णित करती है। इसमें ग्राफिकल नोटेशन है और [[प्रोफाइल (यूएमएल)]] के साथ विस्तार की अनुमति देता है।
* मिश्र धातु (विनिर्देश भाषा) एक सॉफ्टवेयर सिस्टम में जटिल संरचनात्मक बाधाओं और व्यवहार को व्यक्त करने के लिए एक सामान्य प्रयोजन विनिर्देश भाषा है। यह फर्स्ट-ऑर्डर रिलेशनल लॉजिक पर एक संक्षिप्त भाषा आधार प्रदान करता है।
* मिश्र धातु (विनिर्देश भाषा) एक सॉफ्टवेयर प्रणाली में जटिल संरचनात्मक बाधाओं और व्यवहार को व्यक्त करने के लिए एक सामान्य प्रयोजन विनिर्देश भाषा है। यह फर्स्ट-ऑर्डर रिलेशनल लॉजिक पर एक संक्षिप्त भाषा आधार प्रदान करता है।
* सिस्टम्स मॉडलिंग लैंग्वेज (SysML) सिस्टम इंजीनियरिंग के लिए एक नई सामान्य प्रयोजन वाली मॉडलिंग भाषा है।
* सिस्टम्स मॉडलिंग लैंग्वेज (एसएमएल) प्रणाली इंजीनियरिंग के लिए एक नई सामान्य प्रयोजन वाली मॉडलिंग भाषा है।
* सर्विस-ओरिएंटेड मॉडलिंग#सर्विस-ओरिएंटेड मॉडलिंग फ्रेमवर्क|सर्विस-ओरिएंटेड मॉडलिंग फ्रेमवर्क (SOMF)<ref name="Bell">{{cite book |last=Bell |first=Michael|title=Service-Oriented Modeling: Service Analysis, Design, and Architecture|year= 2008 |publisher=Wiley & Sons|isbn=978-0-470-14111-3 |chapter=Introduction to Service-Oriented Modeling}}</ref>
* सर्विस-ओरिएंटेड मॉडलिंग फ्रेमवर्क (एसओएमएफ)<ref name="Bell">{{cite book |last=Bell |first=Michael|title=Service-Oriented Modeling: Service Analysis, Design, and Architecture|year= 2008 |publisher=Wiley & Sons|isbn=978-0-470-14111-3 |chapter=Introduction to Service-Oriented Modeling}}</ref>




== डिजाइन पैटर्न ==
== डिजाइन पैटर्न ==


एक सॉफ्टवेयर डिजाइनर या वास्तुकार एक डिजाइन समस्या की पहचान कर सकता है जिसे पहले देखा गया है और शायद दूसरों द्वारा हल भी किया गया है। एक सामान्य समस्या के समाधान का वर्णन करने वाला एक टेम्पलेट या पैटर्न डिज़ाइन पैटर्न (कंप्यूटर विज्ञान) के रूप में जाना जाता है। ऐसे पैटर्न का पुन: उपयोग सॉफ्टवेयर विकास प्रक्रिया को गति देने में मदद कर सकता है।<ref>{{cite web
सॉफ्टवेयर डिजाइनर या वास्तुकार डिजाइन समस्या की पहचान कर सकता है। जिसे पहले देखा गया है और दूसरों के द्वारा हल भी किया गया है। सामान्य समस्या के समाधान का वर्णन करने वाला एक टेम्पलेट या पैटर्न डिजाइन पैटर्न के रूप में जाना जाता है। ऐसे पैटर्न का पुन: उपयोग सॉफ्टवेयर विकास प्रक्रिया को गति देने में सहायता कर सकता है।<ref>{{cite web
  | url        = http://msdn.microsoft.com/en-us/vstudio/ff729657
  | url        = http://msdn.microsoft.com/en-us/vstudio/ff729657
  | author    = Judith Bishop
  | author    = Judith Bishop
Line 92: Line 90:




== तकनीक ==
== विधि ==


सॉफ़्टवेयर के संबंध में डिज़ाइन शब्द का उपयोग करने में कठिनाई यह है कि कुछ अर्थों में, किसी प्रोग्राम का स्रोत कोड उस प्रोग्राम के लिए डिज़ाइन होता है जिसे वह उत्पन्न करता है। इस हद तक कि यह सच है, सॉफ्टवेयर डिजाइन डिजाइन के डिजाइन को संदर्भित करता है। Edsger W. Dijkstra ने सिमेंटिक स्तरों की इस लेयरिंग को कंप्यूटर प्रोग्रामिंग की मौलिक नवीनता के रूप में संदर्भित किया,<ref>{{cite web
सॉफ़्टवेयर के संबंध में डिजाइन शब्द का उपयोग करने में कठिनता यह है कि कुछ अर्थों में किसी प्रोग्राम का स्रोत कोड उस प्रोग्राम के लिए डिजाइन होता है। जिसे वह उत्पन्न करता है। इस लिमिट तक कि यह सही है और सॉफ्टवेयर डिजाइन, डिजाइन के डिजाइन को संदर्भित करता है। एडजर डब्ल्यू डिज्कस्ट्रा ने सिमेंटिक स्तरों की इस लेयरिंग को कंप्यूटर प्रोग्रामिंग की मौलिक नवीनता के रूप में संदर्भित किया<ref>{{cite web
| url=http://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html
| url=http://www.cs.utexas.edu/~EWD/transcriptions/EWD10xx/EWD1036.html
| title=On the cruelty of really teaching computing science
| title=On the cruelty of really teaching computing science
Line 102: Line 100:
| year=1988
| year=1988
| access-date=2014-01-10
| access-date=2014-01-10
}}</ref> और [[डोनाल्ड नुथ]] ने इसे लागू करने से पहले एक कार्यक्रम को डिजाइन करने के प्रयास की व्यर्थता का वर्णन करने के लिए TeX लिखने के अपने अनुभव का उपयोग किया:
}}</ref> और [[डोनाल्ड नुथ]] ने इसे संचालित करने से पहले एक कार्यक्रम को डिजाइन करने के प्रयास की व्यर्थता का वर्णन करने के लिए TeX लिखने के अपने अनुभव का उपयोग किया।


{{quotation |
{{quotation |
T<sub>E</sub>X would have been a complete failure if I had merely specified it and not participated fully in its initial implementation. The process of implementation constantly led me to unanticipated questions and to new insights about how the original specifications could be improved.<ref>{{cite web
T<sub>E</sub>X पूर्णतयः विफल होता। यदि मैंने इसे केवल निर्दिष्ट किया होता और इसके प्रारंभिक कार्यान्वयन में पूर्णतयः भाग नहीं लिया होता। कार्यान्वयन की प्रक्रिया ने मुझे निरंतर अप्रत्याशित प्रश्नों और नई अंतर्दृष्टि के लिए प्रेरित किया कि मूल विनिर्देशों को कैसे सही किया जा सकता है.<ref>{{cite web
| url = http://www.tug.org/TUGboat/tb10-4/tb26knut.pdf
| url = http://www.tug.org/TUGboat/tb10-4/tb26knut.pdf
| title = Notes on the Errors of TeX
| title = Notes on the Errors of TeX
Line 118: Line 116:
== उपयोग ==
== उपयोग ==


कंप्यूटर प्रोग्रामिंग से पहले बाधाओं, विनिर्देशों और यहां तक ​​कि आवश्यकताओं को समायोजित करने की अनुमति देने के लिए सॉफ़्टवेयर डिज़ाइन प्रलेखन की समीक्षा या प्रस्तुत किया जा सकता है। प्रोग्राम किए गए सिमुलेशन या [[प्रोटोटाइप]] की समीक्षा के बाद रीडिज़ाइन हो सकता है। किसी योजना या आवश्यकता विश्लेषण के बिना, प्रोग्रामिंग की प्रक्रिया में सॉफ़्टवेयर डिज़ाइन करना संभव है,<ref>Ralph, P., and Wand, Y. A Proposal for a Formal Definition of the Design Concept. In, Lyytinen, K., Loucopoulos, P., Mylopoulos, J., and Robinson, W., (eds.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, pp. 103-136</ref> लेकिन अधिक जटिल परियोजनाओं के लिए इसे व्यवहार्य नहीं माना जाएगा। प्रोग्रामिंग से पहले एक अलग डिजाइन बहु-विषयक डिजाइनरों और विषय-विशेषज्ञों (एसएमई) को सॉफ्टवेयर के लिए अत्यधिक कुशल प्रोग्रामर के साथ सहयोग करने की अनुमति देता है जो उपयोगी और तकनीकी रूप से ध्वनि दोनों है।
कंप्यूटर प्रोग्रामिंग से पहले बाधाओं, विनिर्देशों और यहां तक ​​कि आवश्यकताओं को समायोजित करने की अनुमति देने के लिए सॉफ़्टवेयर डिजाइन प्रलेखन की समीक्षा या प्रस्तुत किया जा सकता है। प्रोग्राम किए गए सिमुलेशन या [[प्रोटोटाइप]] की समीक्षा के बाद री-डिजाइन हो सकता है। किसी योजना या आवश्यकता विश्लेषण के बिना प्रोग्रामिंग की प्रक्रिया में सॉफ़्टवेयर डिजाइन करना संभव है।<ref>Ralph, P., and Wand, Y. A Proposal for a Formal Definition of the Design Concept. In, Lyytinen, K., Loucopoulos, P., Mylopoulos, J., and Robinson, W., (eds.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, pp. 103-136</ref> किन्तु अधिक जटिल परियोजनाओं के लिए इसे व्यवहार्य नहीं माना जाएगा। प्रोग्रामिंग से पहले एक अलग डिजाइन बहु-विषयक डिजाइनरों और विषय-विशेषज्ञों (एसएमई) को सॉफ्टवेयर के लिए अत्यधिक कुशल प्रोग्रामर के साथ सहयोग करने की अनुमति प्रदान करता है। जो उपयोगी और तकनीकी रूप से ध्वनि दोनों होते हैं।


== यह भी देखें ==
== यह भी देखें ==
{{Commons category|Software design}}
{{Commons category|Software design}}
* पहलू-उन्मुख सॉफ्टवेयर विकास
* सॉफ्टवेयर डेवलवमेन्ट
* [[सूचना प्रौद्योगिकी में विज्ञान स्नातक]]
* [[सूचना प्रौद्योगिकी में विज्ञान स्नातक]]
* [[डिज़ाइन]]
* [[डिज़ाइन|डिजाइन]]
* [[डिजाइन तर्क]]
* [[डिजाइन तर्क]]
* [[ग्राफ़िक डिज़ाइन]]
* [[ग्राफ़िक डिज़ाइन|ग्राफ़िक डिजाइन]]
* [[पारस्परिक प्रभाव वाली डिज़ाइन]]
* [[पारस्परिक प्रभाव वाली डिज़ाइन|इन्टरेक्शन डिजाइन]]
* [[चिह्न डिजाइन]]
* [[चिह्न डिजाइन|आइकन डिजाइन]]
* [[सॉफ्टवेयर की रूपरेखा]]
* [[सॉफ्टवेयर की रूपरेखा]]
* [[सॉफ्टवेयर विकास की रूपरेखा]]
* [[सॉफ्टवेयर विकास की रूपरेखा]]
* [[सॉफ्टवेयर इंजीनियरिंग की रूपरेखा]]
* [[सॉफ्टवेयर इंजीनियरिंग की रूपरेखा]]
* खोज [[खोज-आधारित सॉफ्टवेयर इंजीनियरिंग]]
*[[खोज-आधारित सॉफ्टवेयर इंजीनियरिंग]]
* सॉफ्टवेयर डिजाइन विवरण (IEEE 1016)
* सॉफ्टवेयर डिजाइन विवरण (आईईईई 1016)
* सॉफ्टवेयर डेवलपमेंट
* सॉफ्टवेयर डेवलपमेंट
* प्रयोगकर्ता का अनुभव
* यूजर एक्सपीरिएंस
* यूजर इंटरफेस डिजाइन
* यूजर इंटरफेस डिजाइन
* वेब डिजाइन
* वेब डिजाइन
Line 149: Line 147:
{{Design}}
{{Design}}


{{DEFAULTSORT:Software Design}}[[Category: सॉफ्टवेयर इंजीनियरिंग]] [[Category: सॉफ्टवेयर डिजाइन | सॉफ्टवेयर डिजाइन ]] [[Category: कंप्यूटर पेशा]]
{{DEFAULTSORT:Software Design}}
 
 


[[Category: Machine Translated Page]]
[[Category:Collapse templates|Software Design]]
[[Category:Created On 13/05/2023]]
[[Category:Commons category link is locally defined|Software Design]]
[[Category:Created On 13/05/2023|Software Design]]
[[Category:Machine Translated Page|Software Design]]
[[Category:Navigational boxes| ]]
[[Category:Navigational boxes without horizontal lists|Software Design]]
[[Category:Pages with script errors|Software Design]]
[[Category:Sidebars with styles needing conversion|Software Design]]
[[Category:Template documentation pages|Documentation/doc]]
[[Category:Templates Translated in Hindi|Software Design]]
[[Category:Templates Vigyan Ready|Software Design]]
[[Category:Templates generating microformats|Software Design]]
[[Category:Templates that are not mobile friendly|Software Design]]
[[Category:Templates using TemplateData|Software Design]]
[[Category:Wikipedia metatemplates|Software Design]]
[[Category:कंप्यूटर पेशा|Software Design]]
[[Category:सॉफ्टवेयर इंजीनियरिंग|Software Design]]
[[Category:सॉफ्टवेयर डिजाइन| सॉफ्टवेयर डिजाइन ]]

Latest revision as of 17:00, 25 May 2023

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] सॉफ्टवेयर डिजाइन के लिए सिद्धांतों का एक समुच्चय का निर्माण कर सकता है। जिसे निम्नलिखित सूची में अनुकूलित और विस्तारित किया गया है:

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

डिजाइन अवधारणा

डिजाइन अवधारणाएँ सॉफ़्टवेयर डिजाइनर को एक आधार प्रदान करती हैं। जिससे अधिक परिष्कृत उपाय संचालित किए जा सकते हैं। मौलिक डिजाइन अवधारणाओं का एक समुच्चय विकसित हुआ है। वे इस प्रकार हैं:

  1. अमूर्तता (कंप्यूटर विज्ञान) - अमूर्तन एक अवधारणा की सूचना सामग्री को कम करके सामान्यीकरण की प्रक्रिया या परिणाम है। सामान्यतः केवल उस जानकारी को बनाए रखने के लिए जो किसी विशेष उद्देश्य के लिए प्रासंगिक है। यह पृष्ठभूमि विवरण या स्पष्टीकरण को सम्मिलित किए बिना आवश्यक विशेषताओं का प्रतिनिधित्व करने का एक कार्य होता है।
  2. कार्यक्रम शोधन - यह विस्तार की प्रक्रिया है। प्रोग्रामिंग लैंग्वेज स्टेटमेंट्स तक पहुंचने तक स्टेप-वाइज फैशन में फलन के मैक्रोस्कोपिक स्टेटमेंट को विघटित करके एक पदानुक्रम विकसित किया जाता है। प्रत्येक चरण में दिए गए प्रोग्राम के एक या कई निर्देश अधिक विस्तृत निर्देशों में विघटित हो जाते हैं। अमूर्तता और शोधन पूरक अवधारणाएँ होती हैं।
  3. प्रतिरूपकता - सॉफ्टवेयर आर्किटेक्चर को मॉड्यूल नामक घटकों में विभाजित किया गया है।
  4. सॉफ्टवेयर आर्किटेक्चर - यह सॉफ्टवेयर की समग्र संरचना और उन उपायों को संदर्भित करता है। जिसमें वह संरचना एक प्रणाली के लिए वैचारिक अखंडता प्रदान करती है। अच्छा सॉफ्टवेयर आर्किटेक्चर परियोजना के वांछित परिणाम के संबंध में निवेश पर अच्छा रिटर्न प्रदान करेगा। उदा प्रदर्शन, गुणवत्ता, अनुसूची और व्यय आदि के संदर्भ में।
  5. नियंत्रण पदानुक्रम - एक कार्यक्रम संरचना जो एक कार्यक्रम घटक के संगठन का प्रतिनिधित्व करती है और नियंत्रण के एक पदानुक्रम का अर्थ है।
  6. संरचनात्मक विभाजन- कार्यक्रम संरचना को क्षैतिज और लंबवत दोनों में विभाजित किया जा सकता है। क्षैतिज विभाजन प्रत्येक प्रमुख प्रोग्राम फलन के लिए मॉड्यूलर पदानुक्रम की विभिन्न शाखाओं को परिभाषित करता है। लंबवत विभाजन सुझाव प्रदान करता है कि कार्यक्रम संरचना में नियंत्रण और कार्य को ऊपर से नीचे वितरित किया जाना चाहिए।
  7. डेटा संरचना - यह डेटा के विभिन्न प्रकार के तत्वों के बीच तार्किक संबंध का प्रतिनिधित्व होता है।
  8. सॉफ्टवेयर प्रक्रिया - यह व्यक्तिगत रूप से प्रत्येक मॉड्यूल के प्रसंस्करण पर केंद्रित है।
  9. जानकारी छिपाना - मॉड्यूल को निर्दिष्ट और डिजाइन किया जाना चाहिए। जिससे एक मॉड्यूल के अन्दर निहित जानकारी अन्य मॉड्यूल के लिए दुर्गम हो। जिन्हें ऐसी जानकारी की कोई आवश्यकता नहीं है।

अपने ऑब्जेक्ट मॉडल में, ग्रेडी बूच ने मौलिक सॉफ्टवेयर डिजाइन सिद्धांतों के रूप में एब्सट्रैक्शन, एनकैप्सुलेशन, मॉड्यूलराइजेशन और पदानुक्रम का उल्लेख किया है।[4] परिवर्णी शब्द फेम (पदानुक्रम के सिद्धांत, अमूर्तता, मॉड्यूलरीकरण, और एनकैप्सुलेशन) का प्रयोग संभवतः इन चार मूलभूत सिद्धांतों को संदर्भित करने के लिए किया जाता है।[5]


डिजाइन विचार

सॉफ्टवेयर के एक टुकड़े के डिजाइन में विचार करने के लिए कई तथ्य उपस्थित होते हैं। प्रत्येक विचार के महत्व को उन लक्ष्यों और अपेक्षाओं को प्रतिबिंबित करना चाहिए। जिन्हें पूरा करने के लिए सॉफ्टवेयर बनाया जा रहा है। इनमें से कुछ तथ्य निम्नलिखित हैं:

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

मॉडलिंग भाषा

मॉडलिंग भाषा कोई भी कृत्रिम भाषा है। जिसका उपयोग सूचनाओं, ज्ञान या प्रणालियों को एक संरचना में व्यक्त करने के लिए किया जा सकता है। जिसे नियमों के एक सुसंगत समुच्चय द्वारा परिभाषित किया गया है। इन नियमों का उपयोग संरचना के अन्दर घटकों की व्याख्या के लिए किया जाता है। एक मॉडलिंग भाषा चित्रमय या पाठ्य हो सकती है। सॉफ़्टवेयर डिजाइन के लिए ग्राफ़िकल मॉडलिंग भाषाओं के उदाहरण हैं:

  • वास्तुकला विवरण भाषा (एडीएल) एक ऐसी भाषा है, जिसका उपयोग सॉफ्टवेयर प्रणाली के सॉफ्टवेयर आर्किटेक्चर का वर्णन और प्रतिनिधित्व करने के लिए किया जाता है।
  • बिजनेस प्रोसेस मॉडलिंग नोटेशन (बीपीएमएन) प्रोसेस मॉडलिंग भाषा का एक उदाहरण है।
  • एक्सप्रेस (मॉडलिंग की दिनांक भाषा) और एक्सप्रेस-जी (आईएसओ 10303-11) एक अंतरराष्ट्रीय मानक सामान्य प्रयोजन डेटा मॉडलिंग भाषा है।
  • विस्तारित विस्तारित उद्यम मॉडलिंग भाषा ईईएमएस) का उपयोग सामान्यतः कई परतों में व्यवसाय प्रक्रिया मॉडलिंग के लिए किया जाता है।
  • फ़्लोचार्ट एल्गोरिदम या अन्य चरण-वार प्रक्रियाओं का योजनाबद्ध प्रतिनिधित्व है।
  • मौलिक मॉडलिंग अवधारणाएँ (एफएमसी) सॉफ्टवेयर-इंटेंसिव सिस्टम्स के लिए मॉडलिंग भाषा है।
  • आईडीईएफ मॉडलिंग भाषाओं की एक फैमली है। जिनमें से सबसे उल्लेखनीय में कार्यात्मक मॉडलिंग के लिए आईडीईएफ0, सूचना मॉडलिंग के लिए आईडीईएफ1एक्स और ओन्टोलॉजी (सूचना विज्ञान) मॉडलिंग के लिए आईडीईएफ5 सम्मिलित हैं।
  • जैक्सन संरचित प्रोग्रामिंग (जेएसपी) डेटा स्ट्रीम संरचना और प्रोग्राम संरचना के बीच पत्राचार के आधार पर संरचित प्रोग्रामिंग के लिए एक विधि है।
  • लेपस3 एक वस्तु के उन्मुख विज़ुअल डिजाइन डिस्क्रिप्शन लैंग्वेज और एक औपचारिक विनिर्देश भाषा है। जो मुख्य रूप से बड़े ऑब्जेक्ट-ओरिएंटेड (जावा (प्रोग्रामिंग लैंग्वेज), C++, सी सार्प (प्रोग्रामिंग लैंग्वेज),सी#) प्रोग्राम और डिजाइन पैटर्न मॉडलिंग के लिए उपयुक्त है।
  • यूनिफाइड मॉडलिंग लैंग्वेज (यूएमएल) एक सामान्य मॉडलिंग भाषा है। जो सॉफ्टवेयर को संरचनात्मक और व्यवहारिक रूप से वर्णित करती है। इसमें ग्राफिकल नोटेशन है और प्रोफाइल (यूएमएल) के साथ विस्तार की अनुमति देता है।
  • मिश्र धातु (विनिर्देश भाषा) एक सॉफ्टवेयर प्रणाली में जटिल संरचनात्मक बाधाओं और व्यवहार को व्यक्त करने के लिए एक सामान्य प्रयोजन विनिर्देश भाषा है। यह फर्स्ट-ऑर्डर रिलेशनल लॉजिक पर एक संक्षिप्त भाषा आधार प्रदान करता है।
  • सिस्टम्स मॉडलिंग लैंग्वेज (एसएमएल) प्रणाली इंजीनियरिंग के लिए एक नई सामान्य प्रयोजन वाली मॉडलिंग भाषा है।
  • सर्विस-ओरिएंटेड मॉडलिंग फ्रेमवर्क (एसओएमएफ)[7]


डिजाइन पैटर्न

सॉफ्टवेयर डिजाइनर या वास्तुकार डिजाइन समस्या की पहचान कर सकता है। जिसे पहले देखा गया है और दूसरों के द्वारा हल भी किया गया है। सामान्य समस्या के समाधान का वर्णन करने वाला एक टेम्पलेट या पैटर्न डिजाइन पैटर्न के रूप में जाना जाता है। ऐसे पैटर्न का पुन: उपयोग सॉफ्टवेयर विकास प्रक्रिया को गति देने में सहायता कर सकता है।[8]


विधि

सॉफ़्टवेयर के संबंध में डिजाइन शब्द का उपयोग करने में कठिनता यह है कि कुछ अर्थों में किसी प्रोग्राम का स्रोत कोड उस प्रोग्राम के लिए डिजाइन होता है। जिसे वह उत्पन्न करता है। इस लिमिट तक कि यह सही है और सॉफ्टवेयर डिजाइन, डिजाइन के डिजाइन को संदर्भित करता है। एडजर डब्ल्यू डिज्कस्ट्रा ने सिमेंटिक स्तरों की इस लेयरिंग को कंप्यूटर प्रोग्रामिंग की मौलिक नवीनता के रूप में संदर्भित किया[9] और डोनाल्ड नुथ ने इसे संचालित करने से पहले एक कार्यक्रम को डिजाइन करने के प्रयास की व्यर्थता का वर्णन करने के लिए TeX लिखने के अपने अनुभव का उपयोग किया।

TEX पूर्णतयः विफल होता। यदि मैंने इसे केवल निर्दिष्ट किया होता और इसके प्रारंभिक कार्यान्वयन में पूर्णतयः भाग नहीं लिया होता। कार्यान्वयन की प्रक्रिया ने मुझे निरंतर अप्रत्याशित प्रश्नों और नई अंतर्दृष्टि के लिए प्रेरित किया कि मूल विनिर्देशों को कैसे सही किया जा सकता है.[10]

उपयोग

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

यह भी देखें

Wikimedia Commons has media related to Software design.

संदर्भ

  1. ↑ Ralph, P. and Wand, Y. (2009). A proposal for a formal definition of the design concept. In Lyytinen, K., Loucopoulos, P., Mylopoulos, J., and Robinson, W., editors, Design Requirements Workshop (LNBIP 14), pp. 103–136. Springer-Verlag, p. 109 doi:10.1007/978-3-540-92966-6_6.
  2. ↑ Freeman, Peter; David Hart (2004). "सॉफ्टवेयर-गहन प्रणालियों के लिए डिजाइन का विज्ञान". Communications of the ACM. 47 (8): 19–21 [20]. doi:10.1145/1012037.1012054. S2CID 14331332.
  3. ↑ Davis, A:"201 Principles of Software Development", McGraw Hill, 1995.
  4. ↑ Booch, Grady; et al. (2004). ऑब्जेक्ट-ओरिएंटेड विश्लेषण और अनुप्रयोगों के साथ डिजाइन (3rd ed.). MA, USA: Addison Wesley. ISBN 0-201-89551-X. Retrieved 30 January 2015.
  5. ↑ Suryanarayana, Girish (November 2014). सॉफ्टवेयर डिजाइन गंध के लिए रिफैक्टरिंग. Morgan Kaufmann. p. 258. ISBN 978-0128013977.
  6. ↑ Carroll, John, ed. (1995). Scenario-Based Design: Envisioning Work and Technology in System Development. New York: John Wiley & Sons. ISBN 0471076597.
  7. ↑ Bell, Michael (2008). "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. ISBN 978-0-470-14111-3.
  8. ↑ Judith Bishop. "C# 3.0 Design Patterns: Use the Power of C# 3.0 to Solve Real-World Problems". C# Books from O'Reilly Media. Retrieved 2012-05-15. If you want to speed up the development of your .NET applications, you're ready for C# design patterns -- elegant, accepted and proven ways to tackle common programming problems.
  9. ↑ Dijkstra, E. W. (1988). "On the cruelty of really teaching computing science". Retrieved 2014-01-10.
  10. ↑ Knuth, Donald E. (1989). "Notes on the Errors of TeX" (PDF).
  11. ↑ Ralph, P., and Wand, Y. A Proposal for a Formal Definition of the Design Concept. In, Lyytinen, K., Loucopoulos, P., Mylopoulos, J., and Robinson, W., (eds.), Design Requirements Engineering: A Ten-Year Perspective: Springer-Verlag, 2009, pp. 103-136

^Roger S. Pressman (2001). Software engineering: a practitioner's approach. McGraw-Hill. ISBN 0-07-365578-3.

Retrieved from ‘https://www.vigyanwiki.in/index.php?title=सॉफ्टवेर_डिज़ाइन&oldid=170042’