सॉफ्टवेर डिज़ाइन: Difference between revisions
No edit summary |
No edit summary |
||
| (5 intermediate revisions by 3 users not shown) | |||
| Line 1: | Line 1: | ||
{{Software development process|Core activities}} | {{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> | ||
सॉफ़्टवेयर डिजाइन में सामान्यतः समस्या-समाधान और सॉफ़्टवेयर समाधान की योजना बनाना सम्मिलित होता है। इसमें निम्न-स्तरीय घटक और [[एल्गोरिथम डिजाइन]] और उच्च-स्तरीय सॉफ़्टवेयर आर्किटेक्चर डिजाइन दोनों सम्मिलित हैं। | सॉफ़्टवेयर डिजाइन में सामान्यतः समस्या-समाधान और सॉफ़्टवेयर समाधान की योजना बनाना सम्मिलित होता है। इसमें निम्न-स्तरीय घटक और [[एल्गोरिथम डिजाइन]] और उच्च-स्तरीय सॉफ़्टवेयर आर्किटेक्चर डिजाइन दोनों सम्मिलित हैं। | ||
| Line 116: | 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> किन्तु अधिक जटिल परियोजनाओं के लिए इसे व्यवहार्य नहीं माना जाएगा। प्रोग्रामिंग से पहले एक अलग डिजाइन बहु-विषयक डिजाइनरों और विषय-विशेषज्ञों (एसएमई) को सॉफ्टवेयर के लिए अत्यधिक कुशल प्रोग्रामर के साथ सहयोग करने की अनुमति प्रदान करता है। जो उपयोगी और तकनीकी रूप से ध्वनि दोनों होते हैं। | ||
== यह भी देखें == | == यह भी देखें == | ||
{{Commons category|Software design}} | {{Commons category|Software design}} | ||
* | * सॉफ्टवेयर डेवलवमेन्ट | ||
* [[सूचना प्रौद्योगिकी में विज्ञान स्नातक]] | * [[सूचना प्रौद्योगिकी में विज्ञान स्नातक]] | ||
* [[डिज़ाइन|डिजाइन]] | * [[डिज़ाइन|डिजाइन]] | ||
* [[डिजाइन तर्क]] | * [[डिजाइन तर्क]] | ||
* [[ग्राफ़िक डिज़ाइन|ग्राफ़िक डिजाइन]] | * [[ग्राफ़िक डिज़ाइन|ग्राफ़िक डिजाइन]] | ||
* [[पारस्परिक प्रभाव वाली डिज़ाइन| | * [[पारस्परिक प्रभाव वाली डिज़ाइन|इन्टरेक्शन डिजाइन]] | ||
* [[चिह्न डिजाइन]] | * [[चिह्न डिजाइन|आइकन डिजाइन]] | ||
* [[सॉफ्टवेयर की रूपरेखा]] | * [[सॉफ्टवेयर की रूपरेखा]] | ||
* [[सॉफ्टवेयर विकास की रूपरेखा]] | * [[सॉफ्टवेयर विकास की रूपरेखा]] | ||
* [[सॉफ्टवेयर इंजीनियरिंग की रूपरेखा]] | * [[सॉफ्टवेयर इंजीनियरिंग की रूपरेखा]] | ||
* | *[[खोज-आधारित सॉफ्टवेयर इंजीनियरिंग]] | ||
* सॉफ्टवेयर डिजाइन विवरण ( | * सॉफ्टवेयर डिजाइन विवरण (आईईईई 1016) | ||
* सॉफ्टवेयर डेवलपमेंट | * सॉफ्टवेयर डेवलपमेंट | ||
* | * यूजर एक्सपीरिएंस | ||
* यूजर इंटरफेस डिजाइन | * यूजर इंटरफेस डिजाइन | ||
* वेब डिजाइन | * वेब डिजाइन | ||
| Line 147: | Line 147: | ||
{{Design}} | {{Design}} | ||
{{DEFAULTSORT:Software Design}} | {{DEFAULTSORT:Software Design}} | ||
[[Category:Collapse templates|Software Design]] | |||
[[Category:Commons category link is locally defined|Software Design]] | |||
[[Category: | [[Category:Created On 13/05/2023|Software Design]] | ||
[[Category:Created On 13/05/2023]] | [[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 |
|---|
सॉफ़्टवेयर डिजाइन वह प्रक्रिया है, जिसके द्वारा एक एजेंट पुराने घटकों के समुच्चय का उपयोग करके और बाधाओं के अधीन लक्ष्यों को पूरा करने के उद्देश्य से कलाकृति (सॉफ़्टवेयर विकास) का एक विनिर्देश का निर्माण करती है।[1] इस शब्द का प्रयोग अधिकांशतः सॉफ्टवेयर की संकल्पना को बनाने, तैयार करने, संचालित करने, प्रारम्भ करने और अंततः संशोधित करने में सम्मिलित सभी गतिविधियों को संदर्भित करने के लिए किया जाता है या अधिक विशेष रूप से सॉफ्टवेयर आवश्यकताओं के विनिर्देश के पश्चात और कंप्यूटर प्रोग्रामिंग से पहले की गतिविधि के रूप में एक शैलीबद्ध सॉफ्टवेयर इंजीनियरिंग प्रक्रिया में इसका प्रयोग किया जाता है।[2]
सॉफ़्टवेयर डिजाइन में सामान्यतः समस्या-समाधान और सॉफ़्टवेयर समाधान की योजना बनाना सम्मिलित होता है। इसमें निम्न-स्तरीय घटक और एल्गोरिथम डिजाइन और उच्च-स्तरीय सॉफ़्टवेयर आर्किटेक्चर डिजाइन दोनों सम्मिलित हैं।
अवलोकन
सॉफ़्टवेयर डिजाइन समस्याओं के एक या अधिक समुच्चयों के लिए सॉफ़्टवेयर समाधानों की कल्पना करने और उन्हें परिभाषित करने की प्रक्रिया होती है। सॉफ़्टवेयर डिजाइन के मुख्य घटकों में से एक सॉफ़्टवेयर आवश्यकता विश्लेषण (एसआरए) है। एसआरए सॉफ्टवेयर डेवलपमेंट प्रोसेस का एक भाग होता है। जो सॉफ्टवेयर इंजीनियरिंग में उपयोग किए जाने वाले विनिर्देशों को सूची के रूप में प्रदर्शित करता है।
यदि सॉफ़्टवेयर अर्ध-स्वचालित या उपयोगकर्ता केंद्रित डिजाइन है। तो सॉफ़्टवेयर डिजाइन में उन विशिष्टताओं को निर्धारित करने में सहायता के लिए स्टोरीबोर्ड प्रदान करने वाले उपयोगकर्ता अनुभव डिजाइन भी सम्मिलित हो सकते हैं। यदि सॉफ़्टवेयर पूर्णतयः स्वचालन (अर्थात् कोई उपयोगकर्ता (कंप्यूटिंग) या उपयोगकर्ता इंटरफ़ेस नहीं है) है। जिससे एक सॉफ़्टवेयर डिजाइन घटनाओं के नियोजित अनुक्रम का वर्णन करने वाले प्रवाह चार्ट या पाठ के समान सरल हो सकता है। यूनिफाइड मॉडलिंग लैंग्वेज और मौलिक मॉडलिंग अवधारणाएँ जैसी अर्ध-मानक विधियाँ भी हैं। किसी भी स्थिति में योजना के कुछ लेख सामान्यतः डिजाइन के उत्पाद होते हैं। इसके अतिरिक्त एक सॉफ्टवेयर डिजाइन प्लेटफ़ॉर्म-स्वतंत्र मॉडल या प्लेटफ़ॉर्म-विशिष्ट हो सकता है। जो डिजाइन के लिए उपयोग की जाने वाली विधि की उपलब्धता पर पूर्णतयः निर्भर करता है।
सॉफ़्टवेयर विश्लेषण और डिजाइन के बीच मुख्य अंतर यह है कि सॉफ़्टवेयर विश्लेषण के आउटपुट में हल करने के लिए छोटी समस्याएं होती हैं। इसके अतिरिक्त, विश्लेषण को अलग-अलग टीम के सदस्यों या समूहों में बहुत अलग तरीके से डिजाइन नहीं किया जाना चाहिए। इसके विपरीत, डिजाइन क्षमताओं पर केंद्रित है, और इस प्रकार एक ही समस्या के लिए कई डिजाइन उपस्थित हो सकते हैं और उपस्थित रहेंगे। पर्यावरण के आधार पर, डिजाइन अक्सर भिन्न होता है, चाहे वह विश्वसनीय सॉफ़्टवेयर ढांचे से बनाया गया हो या उपयुक्त डिजाइन पैटर्न्स के साथ कार्यान्वित किया गया हो। डिजाइन के उदाहरणों में ऑपरेशन सिस्टम, वेबपेज, मोबाइल डिवाइस या यहां तक कि नए क्लाउड कंप्यूटिंग प्रतिमान सम्मिलित हैं।
सॉफ्टवेयर डिजाइन एक प्रक्रिया और मॉडल दोनों है। डिजाइन प्रक्रिया चरणों का एक क्रम है। जो डिजाइनर को निर्माण के लिए सॉफ़्टवेयर के सभी पहलुओं का वर्णन करने में सक्षम बनाती है। रचनात्मक कौशल, पिछला अनुभव, अच्छा सॉफ्टवेयर बनाने की भावना और गुणवत्ता के प्रति समग्र प्रतिबद्धता एक सक्षम डिजाइन के लिए महत्वपूर्ण सफलता के कारकों के उदाहरण हैं। चूंकि यह ध्यान रखना महत्वपूर्ण है कि डिजाइन प्रक्रिया सदैव एक सीधी प्रक्रिया नहीं होती है। डिजाइन मॉडल की तुलना एक घर के लिए आर्किटेक्ट की योजनाओं से की जा सकती है। यह उस वस्तु की समग्रता का प्रतिनिधित्व करने से प्रारम्भ होता है। जिसे बनाया जाना है (उदाहरण के लिए घर का त्रि-आयामी प्रतिपादन); धीरे-धीरे प्रत्येक विवरण के निर्माण के लिए मार्गदर्शन प्रदान करने के लिए वस्तु को परिष्कृत किया जाता है (जैसे प्लंबिंग ले )। इसी प्रकार सॉफ़्टवेयर के लिए बनाया गया डिजाइन मॉडल कंप्यूटर सॉफ़्टवेयर के विभिन्न प्रकार के विभिन्न दृश्य प्रदान करता है। मूल डिजाइन सिद्धांत सॉफ़्टवेयर इंजीनियर को डिजाइन प्रक्रिया को नेविगेट करने में सक्षम बनाती हैं। डेविस[3] सॉफ्टवेयर डिजाइन के लिए सिद्धांतों का एक समुच्चय का निर्माण कर सकता है। जिसे निम्नलिखित सूची में अनुकूलित और विस्तारित किया गया है:
- डिजाइन प्रक्रिया को टनल विजन से पीड़ित नहीं होना चाहिए। एक अच्छे डिजाइनर को वैकल्पिक उपायों पर विचार करना चाहिए, समस्या की आवश्यकताओं के आधार पर प्रत्येक को देखते हुए काम करने के लिए उपलब्ध संसाधनों की व्यवस्था करनी चाहिए।
- डिजाइन विश्लेषण मॉडल के लिए पता लगाने योग्य होना चाहिए क्योंकि डिजाइन मॉडल के एक तत्व को प्रायः कई आवश्यकताओं के लिए वापस खोजा जा सकता है। यह ट्रैक करने के लिए एक साधन होना आवश्यक है कि डिजाइन मॉडल द्वारा आवश्यकताओं को कैसे पूरा किया गया है।
- डिजाइन को पहिया को फिर से नहीं लगाना चाहिए। प्रणाली का निर्माण डिजाइन पैटर्न के एक समुच्चय का उपयोग करके किया जाता है। जिनमें से कई की जानकारी पहले ही प्राप्त की जा चुकी है। इन पैटर्नों को सदैव पुनर्खोज के विकल्प के रूप में चुना जाना चाहिए। समय कम है और संसाधन सीमित हैं। डिजाइन समय को पहले से उपस्थित (जब संचालित हो) पैटर्न को एकीकृत करके (वास्तव में नए) विचारों का प्रतिनिधित्व करने में निवेश किया जाना चाहिए।
- डिजाइन को सॉफ्टवेयर और समस्या के बीच बौद्धिक दूरी को कम करना चाहिए क्योंकि यह वास्तविक विश्व में उपस्थित है। अर्थात्, सॉफ़्टवेयर डिजाइन की संरचना, जब भी संभव हो, समस्या डोमेन की संरचना की कॉपी करनी चाहिए।
- डिजाइन में एकरूपता और एकीकरण प्रदर्शित होना चाहिए। एक डिजाइन एक समान है। यदि यह पूर्णतयः सुसंगत प्रतीत होता है। इस परिणाम को प्राप्त करने के लिए डिजाइन का कार्य प्रारम्भ होने से पहले डिजाइन टीम के लिए शैली और डिजाइन के नियमों को परिभाषित किया जाना चाहिए। यदि डिजाइन घटकों के बीच इंटरफेस को परिभाषित करने में सावधानी की जानी चाहिए। जिससे डिजाइन को एकीकृत किया जाता है।
- परिवर्तन को समायोजित करने के लिए डिजाइन को संरचित किया जाना चाहिए। अगले खंड के विषय में चर्चा की गई डिजाइन अवधारणाएँ इस सिद्धांत को प्राप्त करने के लिए डिजाइन को सक्षम बनाती हैं।
- डिजाइन को धीरे-धीरे निम्न स्तर का प्रदर्शित करने के लिए संरचित किया जाना चाहिए। तथापि असामान्य डेटा, घटनाओं या परिचालन स्थितियों का सामना करना पड़े। अच्छी प्रकार से डिजाइन किए गए सॉफ़्टवेयर को कभी भी बम नहीं बनाना चाहिए। इसे असामान्य परिस्थितियों को समायोजित करने के लिए डिजाइन किया जाना चाहिए और यदि इसे प्रसंस्करण समाप्त करना ही है। जिससे इसे एक उत्तम प्रकार से किया जाना चाहिए।
- डिजाइन कोडिंग नहीं है, कोडिंग डिजाइन नहीं है। यहां तक कि जब प्रोग्राम घटकों के लिए विस्तृत प्रक्रियात्मक डिजाइन बनाए जाते हैं। तब भी डिजाइन मॉडल के अमूर्तन का स्तर स्रोत कोड से अधिक होता है। कोडिंग स्तर पर किए गए एकमात्र डिजाइन निर्णयों को छोटे कार्यान्वयन विवरणों को संबोधित करना चाहिए। जो प्रक्रियात्मक डिजाइन को कोडित करने में सक्षम बनाने का कार्य करता है।
- डिजाइन का मूल्यांकन गुणवत्ता के लिए किया जाना चाहिए क्योंकि यह तथ्य के बाद नहीं बनाया जा रहा है। विकास प्रक्रिया के समय गुणवत्ता का आकलन करने में डिजाइनर की सहायता के लिए विभिन्न प्रकार की डिजाइन अवधारणाएँ और डिजाइन उपाय उपलब्ध होते हैं।
- वैचारिक (सिमेंटिक) त्रुटियों को कम करने के लिए डिजाइन की समीक्षा की जानी चाहिए। जब डिजाइन की समीक्षा की जाती है। तो संभवतः छोटी-छोटी त्रुटियों पर ध्यान केंद्रित करने की प्रवृत्ति होती है, पेड़ों के लिए जंगल विलुप्त हो जाता है। एक डिजाइन टीम को यह सुनिश्चित करना चाहिए कि डिजाइन मॉडल के सिंटैक्स के बारे में चिंता करने से पहले डिजाइन के प्रमुख वैचारिक तत्वों (भ्रम, अस्पष्टता, असंगति) को संबोधित किया गया है।
डिजाइन अवधारणा
डिजाइन अवधारणाएँ सॉफ़्टवेयर डिजाइनर को एक आधार प्रदान करती हैं। जिससे अधिक परिष्कृत उपाय संचालित किए जा सकते हैं। मौलिक डिजाइन अवधारणाओं का एक समुच्चय विकसित हुआ है। वे इस प्रकार हैं:
- अमूर्तता (कंप्यूटर विज्ञान) - अमूर्तन एक अवधारणा की सूचना सामग्री को कम करके सामान्यीकरण की प्रक्रिया या परिणाम है। सामान्यतः केवल उस जानकारी को बनाए रखने के लिए जो किसी विशेष उद्देश्य के लिए प्रासंगिक है। यह पृष्ठभूमि विवरण या स्पष्टीकरण को सम्मिलित किए बिना आवश्यक विशेषताओं का प्रतिनिधित्व करने का एक कार्य होता है।
- कार्यक्रम शोधन - यह विस्तार की प्रक्रिया है। प्रोग्रामिंग लैंग्वेज स्टेटमेंट्स तक पहुंचने तक स्टेप-वाइज फैशन में फलन के मैक्रोस्कोपिक स्टेटमेंट को विघटित करके एक पदानुक्रम विकसित किया जाता है। प्रत्येक चरण में दिए गए प्रोग्राम के एक या कई निर्देश अधिक विस्तृत निर्देशों में विघटित हो जाते हैं। अमूर्तता और शोधन पूरक अवधारणाएँ होती हैं।
- प्रतिरूपकता - सॉफ्टवेयर आर्किटेक्चर को मॉड्यूल नामक घटकों में विभाजित किया गया है।
- सॉफ्टवेयर आर्किटेक्चर - यह सॉफ्टवेयर की समग्र संरचना और उन उपायों को संदर्भित करता है। जिसमें वह संरचना एक प्रणाली के लिए वैचारिक अखंडता प्रदान करती है। अच्छा सॉफ्टवेयर आर्किटेक्चर परियोजना के वांछित परिणाम के संबंध में निवेश पर अच्छा रिटर्न प्रदान करेगा। उदा प्रदर्शन, गुणवत्ता, अनुसूची और व्यय आदि के संदर्भ में।
- नियंत्रण पदानुक्रम - एक कार्यक्रम संरचना जो एक कार्यक्रम घटक के संगठन का प्रतिनिधित्व करती है और नियंत्रण के एक पदानुक्रम का अर्थ है।
- संरचनात्मक विभाजन- कार्यक्रम संरचना को क्षैतिज और लंबवत दोनों में विभाजित किया जा सकता है। क्षैतिज विभाजन प्रत्येक प्रमुख प्रोग्राम फलन के लिए मॉड्यूलर पदानुक्रम की विभिन्न शाखाओं को परिभाषित करता है। लंबवत विभाजन सुझाव प्रदान करता है कि कार्यक्रम संरचना में नियंत्रण और कार्य को ऊपर से नीचे वितरित किया जाना चाहिए।
- डेटा संरचना - यह डेटा के विभिन्न प्रकार के तत्वों के बीच तार्किक संबंध का प्रतिनिधित्व होता है।
- सॉफ्टवेयर प्रक्रिया - यह व्यक्तिगत रूप से प्रत्येक मॉड्यूल के प्रसंस्करण पर केंद्रित है।
- जानकारी छिपाना - मॉड्यूल को निर्दिष्ट और डिजाइन किया जाना चाहिए। जिससे एक मॉड्यूल के अन्दर निहित जानकारी अन्य मॉड्यूल के लिए दुर्गम हो। जिन्हें ऐसी जानकारी की कोई आवश्यकता नहीं है।
अपने ऑब्जेक्ट मॉडल में, ग्रेडी बूच ने मौलिक सॉफ्टवेयर डिजाइन सिद्धांतों के रूप में एब्सट्रैक्शन, एनकैप्सुलेशन, मॉड्यूलराइजेशन और पदानुक्रम का उल्लेख किया है।[4] परिवर्णी शब्द फेम (पदानुक्रम के सिद्धांत, अमूर्तता, मॉड्यूलरीकरण, और एनकैप्सुलेशन) का प्रयोग संभवतः इन चार मूलभूत सिद्धांतों को संदर्भित करने के लिए किया जाता है।[5]
डिजाइन विचार
सॉफ्टवेयर के एक टुकड़े के डिजाइन में विचार करने के लिए कई तथ्य उपस्थित होते हैं। प्रत्येक विचार के महत्व को उन लक्ष्यों और अपेक्षाओं को प्रतिबिंबित करना चाहिए। जिन्हें पूरा करने के लिए सॉफ्टवेयर बनाया जा रहा है। इनमें से कुछ तथ्य निम्नलिखित हैं:
- संगतता - सॉफ़्टवेयर अन्य उत्पादों के साथ काम करने में सक्षम है। जो किसी अन्य उत्पाद के साथ इंटरऑपरेबिलिटी के लिए डिजाइन किए गए हैं। उदाहरण के लिए सॉफ़्टवेयर का एक टुकड़ा अपने पुराने संस्करण के साथ पिछड़ा-संगत हो सकता है।
- तानाना - अंतर्निहित आर्किटेक्चर में बड़े परिवर्तन के बिना सॉफ्टवेयर में नई क्षमताओं को जोड़ा जा सकता है।
- मॉड्यूलरिटी - परिणामी सॉफ़्टवेयर में अच्छी प्रकार से परिभाषित स्वतंत्र घटक सम्मिलित होते हैं। जो उत्तम देखरेख की ओर ले जाते हैं। वांछित सॉफ्टवेयर प्रणाली का निर्माण करने के लिए एकीकृत होने से पहले घटकों को संचालित किया जा सकता है और विच्छेदन में परीक्षण किया जा सकता है। यह एक सॉफ्टवेयर डेवलपमेंट प्रोजेक्ट में कार्य के विभाजन की अनुमति प्रदान करता है।
- दोष-सहिष्णुता - सॉफ्टवेयर प्रतिरोधी है और घटक विफलता से बाहर निकलने में पूर्णतयः सक्षम है।
- रख-रखाव - बग फिक्स या कार्यात्मक संशोधनों को कितनी सरलता से पूरा किया जा सकता है। इसका एक उपाय उच्च रख-रखाव मॉड्यूलरिटी और एक्स्टेंसिबिलिटी का उत्पाद हो सकता है।
- विश्वसनीयता (सॉफ्टवेयर स्थायित्व) - सॉफ्टवेयर निर्दिष्ट नियमों के अनुसार एक निर्दिष्ट अवधि के लिए एक आवश्यक कार्य करने में सक्षम है।
- पुन: प्रयोज्य - अन्य परियोजनाओं में पहले से उपस्थित सॉफ़्टवेयर के कुछ या सभी तथ्यों को बिना किसी संशोधन के उपयोग करने की क्षमता होती है।
- दोष-सहिष्णु प्रणाली - सॉफ्टवेयर तनाव में काम करने या अप्रत्याशित या अमान्य इनपुट को सहन करने में सक्षम है। उदाहरण के लिए इसे कम स्मृति स्थितियों के लचीलेपन के साथ डिजाइन किया जा सकता है।
- कंप्यूटर सुरक्षा - सॉफ्टवेयर शत्रुतापूर्ण कृत्यों और प्रभावों का सामना करने और उनका विरोध करने में सक्षम है।
- उपयोगिता - सॉफ्टवेयर यूजर इंटरफेस अपने लक्षित उपयोगकर्ता/दर्शकों के लिए प्रयोग करने योग्य होना चाहिए। मापदंडों के लिए डिफ़ॉल्ट मान चुना जाना चाहिए। जिससे वे अधिकांश उपयोगकर्ताओं के लिए एक अच्छा विकल्प हों।[6]
- कंप्यूटर का प्रदर्शन - सॉफ्टवेयर एक समय-सीमा के अन्दर अपना कार्य करता है। जो उपयोगकर्ता के लिए स्वीकार्य है और इसके लिए बहुत अधिक मेमोरी की आवश्यकता नहीं होती है।
- सॉफ्टवेयर सुवाह्यता - सॉफ्टवेयर को कई विभिन्न स्थितियों और वातावरणों में प्रयोग करने योग्य होना चाहिए।
- मापनीयता - सॉफ्टवेयर बढ़ते हुए डेटा या अतिरिक्त सुविधाओं या उपयोगकर्ताओं की संख्या के लिए अच्छी प्रकार से अनुकूल है।
मॉडलिंग भाषा
मॉडलिंग भाषा कोई भी कृत्रिम भाषा है। जिसका उपयोग सूचनाओं, ज्ञान या प्रणालियों को एक संरचना में व्यक्त करने के लिए किया जा सकता है। जिसे नियमों के एक सुसंगत समुच्चय द्वारा परिभाषित किया गया है। इन नियमों का उपयोग संरचना के अन्दर घटकों की व्याख्या के लिए किया जाता है। एक मॉडलिंग भाषा चित्रमय या पाठ्य हो सकती है। सॉफ़्टवेयर डिजाइन के लिए ग्राफ़िकल मॉडलिंग भाषाओं के उदाहरण हैं:
- वास्तुकला विवरण भाषा (एडीएल) एक ऐसी भाषा है, जिसका उपयोग सॉफ्टवेयर प्रणाली के सॉफ्टवेयर आर्किटेक्चर का वर्णन और प्रतिनिधित्व करने के लिए किया जाता है।
- बिजनेस प्रोसेस मॉडलिंग नोटेशन (बीपीएमएन) प्रोसेस मॉडलिंग भाषा का एक उदाहरण है।
- एक्सप्रेस (मॉडलिंग की दिनांक भाषा) और एक्सप्रेस-जी (आईएसओ 10303-11) एक अंतरराष्ट्रीय मानक सामान्य प्रयोजन डेटा मॉडलिंग भाषा है।
- विस्तारित विस्तारित उद्यम मॉडलिंग भाषा ईईएमएस) का उपयोग सामान्यतः कई परतों में व्यवसाय प्रक्रिया मॉडलिंग के लिए किया जाता है।
- फ़्लोचार्ट एल्गोरिदम या अन्य चरण-वार प्रक्रियाओं का योजनाबद्ध प्रतिनिधित्व है।
- मौलिक मॉडलिंग अवधारणाएँ (एफएमसी) सॉफ्टवेयर-इंटेंसिव सिस्टम्स के लिए मॉडलिंग भाषा है।
- आईडीईएफ मॉडलिंग भाषाओं की एक फैमली है। जिनमें से सबसे उल्लेखनीय में कार्यात्मक मॉडलिंग के लिए आईडीईएफ0, सूचना मॉडलिंग के लिए आईडीईएफ1एक्स और ओन्टोलॉजी (सूचना विज्ञान) मॉडलिंग के लिए आईडीईएफ5 सम्मिलित हैं।
- जैक्सन संरचित प्रोग्रामिंग (जेएसपी) डेटा स्ट्रीम संरचना और प्रोग्राम संरचना के बीच पत्राचार के आधार पर संरचित प्रोग्रामिंग के लिए एक विधि है।
- लेपस3 एक वस्तु के उन्मुख विज़ुअल डिजाइन डिस्क्रिप्शन लैंग्वेज और एक औपचारिक विनिर्देश भाषा है। जो मुख्य रूप से बड़े ऑब्जेक्ट-ओरिएंटेड (जावा (प्रोग्रामिंग लैंग्वेज), C++, सी सार्प (प्रोग्रामिंग लैंग्वेज),सी#) प्रोग्राम और डिजाइन पैटर्न मॉडलिंग के लिए उपयुक्त है।
- यूनिफाइड मॉडलिंग लैंग्वेज (यूएमएल) एक सामान्य मॉडलिंग भाषा है। जो सॉफ्टवेयर को संरचनात्मक और व्यवहारिक रूप से वर्णित करती है। इसमें ग्राफिकल नोटेशन है और प्रोफाइल (यूएमएल) के साथ विस्तार की अनुमति देता है।
- मिश्र धातु (विनिर्देश भाषा) एक सॉफ्टवेयर प्रणाली में जटिल संरचनात्मक बाधाओं और व्यवहार को व्यक्त करने के लिए एक सामान्य प्रयोजन विनिर्देश भाषा है। यह फर्स्ट-ऑर्डर रिलेशनल लॉजिक पर एक संक्षिप्त भाषा आधार प्रदान करता है।
- सिस्टम्स मॉडलिंग लैंग्वेज (एसएमएल) प्रणाली इंजीनियरिंग के लिए एक नई सामान्य प्रयोजन वाली मॉडलिंग भाषा है।
- सर्विस-ओरिएंटेड मॉडलिंग फ्रेमवर्क (एसओएमएफ)[7]
डिजाइन पैटर्न
सॉफ्टवेयर डिजाइनर या वास्तुकार डिजाइन समस्या की पहचान कर सकता है। जिसे पहले देखा गया है और दूसरों के द्वारा हल भी किया गया है। सामान्य समस्या के समाधान का वर्णन करने वाला एक टेम्पलेट या पैटर्न डिजाइन पैटर्न के रूप में जाना जाता है। ऐसे पैटर्न का पुन: उपयोग सॉफ्टवेयर विकास प्रक्रिया को गति देने में सहायता कर सकता है।[8]
विधि
सॉफ़्टवेयर के संबंध में डिजाइन शब्द का उपयोग करने में कठिनता यह है कि कुछ अर्थों में किसी प्रोग्राम का स्रोत कोड उस प्रोग्राम के लिए डिजाइन होता है। जिसे वह उत्पन्न करता है। इस लिमिट तक कि यह सही है और सॉफ्टवेयर डिजाइन, डिजाइन के डिजाइन को संदर्भित करता है। एडजर डब्ल्यू डिज्कस्ट्रा ने सिमेंटिक स्तरों की इस लेयरिंग को कंप्यूटर प्रोग्रामिंग की मौलिक नवीनता के रूप में संदर्भित किया[9] और डोनाल्ड नुथ ने इसे संचालित करने से पहले एक कार्यक्रम को डिजाइन करने के प्रयास की व्यर्थता का वर्णन करने के लिए TeX लिखने के अपने अनुभव का उपयोग किया।
TEX पूर्णतयः विफल होता। यदि मैंने इसे केवल निर्दिष्ट किया होता और इसके प्रारंभिक कार्यान्वयन में पूर्णतयः भाग नहीं लिया होता। कार्यान्वयन की प्रक्रिया ने मुझे निरंतर अप्रत्याशित प्रश्नों और नई अंतर्दृष्टि के लिए प्रेरित किया कि मूल विनिर्देशों को कैसे सही किया जा सकता है.[10]
उपयोग
कंप्यूटर प्रोग्रामिंग से पहले बाधाओं, विनिर्देशों और यहां तक कि आवश्यकताओं को समायोजित करने की अनुमति देने के लिए सॉफ़्टवेयर डिजाइन प्रलेखन की समीक्षा या प्रस्तुत किया जा सकता है। प्रोग्राम किए गए सिमुलेशन या प्रोटोटाइप की समीक्षा के बाद री-डिजाइन हो सकता है। किसी योजना या आवश्यकता विश्लेषण के बिना प्रोग्रामिंग की प्रक्रिया में सॉफ़्टवेयर डिजाइन करना संभव है।[11] किन्तु अधिक जटिल परियोजनाओं के लिए इसे व्यवहार्य नहीं माना जाएगा। प्रोग्रामिंग से पहले एक अलग डिजाइन बहु-विषयक डिजाइनरों और विषय-विशेषज्ञों (एसएमई) को सॉफ्टवेयर के लिए अत्यधिक कुशल प्रोग्रामर के साथ सहयोग करने की अनुमति प्रदान करता है। जो उपयोगी और तकनीकी रूप से ध्वनि दोनों होते हैं।
यह भी देखें
- सॉफ्टवेयर डेवलवमेन्ट
- सूचना प्रौद्योगिकी में विज्ञान स्नातक
- डिजाइन
- डिजाइन तर्क
- ग्राफ़िक डिजाइन
- इन्टरेक्शन डिजाइन
- आइकन डिजाइन
- सॉफ्टवेयर की रूपरेखा
- सॉफ्टवेयर विकास की रूपरेखा
- सॉफ्टवेयर इंजीनियरिंग की रूपरेखा
- खोज-आधारित सॉफ्टवेयर इंजीनियरिंग
- सॉफ्टवेयर डिजाइन विवरण (आईईईई 1016)
- सॉफ्टवेयर डेवलपमेंट
- यूजर एक्सपीरिएंस
- यूजर इंटरफेस डिजाइन
- वेब डिजाइन
- जीरो वन इन्फिनिटी
संदर्भ
- ↑ 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.
- ↑ Freeman, Peter; David Hart (2004). "सॉफ्टवेयर-गहन प्रणालियों के लिए डिजाइन का विज्ञान". Communications of the ACM. 47 (8): 19–21 [20]. doi:10.1145/1012037.1012054. S2CID 14331332.
- ↑ Davis, A:"201 Principles of Software Development", McGraw Hill, 1995.
- ↑ Booch, Grady; et al. (2004). ऑब्जेक्ट-ओरिएंटेड विश्लेषण और अनुप्रयोगों के साथ डिजाइन (3rd ed.). MA, USA: Addison Wesley. ISBN 0-201-89551-X. Retrieved 30 January 2015.
- ↑ Suryanarayana, Girish (November 2014). सॉफ्टवेयर डिजाइन गंध के लिए रिफैक्टरिंग. Morgan Kaufmann. p. 258. ISBN 978-0128013977.
- ↑ Carroll, John, ed. (1995). Scenario-Based Design: Envisioning Work and Technology in System Development. New York: John Wiley & Sons. ISBN 0471076597.
- ↑ Bell, Michael (2008). "Introduction to Service-Oriented Modeling". Service-Oriented Modeling: Service Analysis, Design, and Architecture. Wiley & Sons. ISBN 978-0-470-14111-3.
- ↑ 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.
- ↑ Dijkstra, E. W. (1988). "On the cruelty of really teaching computing science". Retrieved 2014-01-10.
- ↑ Knuth, Donald E. (1989). "Notes on the Errors of TeX" (PDF).
- ↑ 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.
Note: This template roughly follows the 2012 ACM Computing Classification System. | ||
| हार्डवेयर |  | |
| कंप्यूटर सिस्टम संगठन | ||
| नेटवर्क | ||
| सॉफ्टवेयर संगठन | ||
| सॉफ्टवेयर नोटेशन और टूल्स | ||
| सॉफ्टवेयर डेवलपमेंट | ||
| गणना का सिद्धांत | ||
| कलन विधि | ||
| कंप्यूटिंग का गणित | ||
| सूचना प्रणाली | ||
| सुरक्षा | ||
| मानव-कंप्यूटर संपर्क | ||
| Concurrency | ||
| कृत्रिम बुद्धि | ||
| मशीन लर्निंग | ||
| ग्राफिक्स | ||
| एप्लाइड कंप्यूटिंग |
| |
| Fields | |||||||
|---|---|---|---|---|---|---|---|
| Concepts |
| ||||||
| Orientations | |||||||
| Models |
| ||||||
| Related fields | |||||||
