सॉफ्टवेर डिज़ाइन: Difference between revisions
No edit summary |
No edit summary |
||
| Line 18: | Line 18: | ||
* डिजाइन को पहिया को फिर से नहीं लगाना चाहिए। प्रणाली का निर्माण डिजाइन पैटर्न के एक समुच्चय का उपयोग करके किया जाता है। जिनमें से कई की जानकारी पहले ही प्राप्त की जा चुकी है। इन पैटर्नों को सदैव पुनर्खोज के विकल्प के रूप में चुना जाना चाहिए। समय कम है और संसाधन सीमित हैं। डिजाइन समय को पहले से उपस्थित (जब संचालित हो) पैटर्न को एकीकृत करके (वास्तव में नए) विचारों का प्रतिनिधित्व करने में निवेश किया जाना चाहिए। | * डिजाइन को पहिया को फिर से नहीं लगाना चाहिए। प्रणाली का निर्माण डिजाइन पैटर्न के एक समुच्चय का उपयोग करके किया जाता है। जिनमें से कई की जानकारी पहले ही प्राप्त की जा चुकी है। इन पैटर्नों को सदैव पुनर्खोज के विकल्प के रूप में चुना जाना चाहिए। समय कम है और संसाधन सीमित हैं। डिजाइन समय को पहले से उपस्थित (जब संचालित हो) पैटर्न को एकीकृत करके (वास्तव में नए) विचारों का प्रतिनिधित्व करने में निवेश किया जाना चाहिए। | ||
* डिजाइन को सॉफ्टवेयर और समस्या के बीच बौद्धिक दूरी को कम करना चाहिए क्योंकि यह वास्तविक विश्व में उपस्थित है। अर्थात्, सॉफ़्टवेयर डिजाइन की संरचना, जब भी संभव हो, समस्या डोमेन की संरचना की कॉपी करनी चाहिए। | * डिजाइन को सॉफ्टवेयर और समस्या के बीच बौद्धिक दूरी को कम करना चाहिए क्योंकि यह वास्तविक विश्व में उपस्थित है। अर्थात्, सॉफ़्टवेयर डिजाइन की संरचना, जब भी संभव हो, समस्या डोमेन की संरचना की कॉपी करनी चाहिए। | ||
* डिजाइन में एकरूपता और एकीकरण प्रदर्शित होना चाहिए। एक डिजाइन एक समान है। यदि यह पूर्णतयः सुसंगत | * डिजाइन में एकरूपता और एकीकरण प्रदर्शित होना चाहिए। एक डिजाइन एक समान है। यदि यह पूर्णतयः सुसंगत प्रतीत होता है। इस परिणाम को प्राप्त करने के लिए डिजाइन का कार्य प्रारम्भ होने से पहले डिजाइन टीम के लिए शैली और डिजाइन के नियमों को परिभाषित किया जाना चाहिए। यदि डिजाइन घटकों के बीच इंटरफेस को परिभाषित करने में सावधानी की जानी चाहिए। जिससे डिजाइन को एकीकृत किया जाता है। | ||
* परिवर्तन को समायोजित करने के लिए डिजाइन को संरचित किया जाना चाहिए। अगले खंड में चर्चा की गई डिजाइन अवधारणाएँ इस सिद्धांत को प्राप्त करने के लिए डिजाइन को सक्षम बनाती हैं। | * परिवर्तन को समायोजित करने के लिए डिजाइन को संरचित किया जाना चाहिए। अगले खंड के विषय में चर्चा की गई डिजाइन अवधारणाएँ इस सिद्धांत को प्राप्त करने के लिए डिजाइन को सक्षम बनाती हैं। | ||
* डिजाइन को धीरे-धीरे | * डिजाइन को धीरे-धीरे निम्न स्तर का प्रदर्शित करने के लिए संरचित किया जाना चाहिए। तथापि असामान्य डेटा, घटनाओं या परिचालन स्थितियों का सामना करना पड़े। अच्छी प्रकार से डिजाइन किए गए सॉफ़्टवेयर को कभी भी बम नहीं बनाना चाहिए। इसे असामान्य परिस्थितियों को समायोजित करने के लिए डिजाइन किया जाना चाहिए और यदि इसे प्रसंस्करण समाप्त करना ही है। जिससे इसे एक उत्तम प्रकार से किया जाना चाहिए। | ||
* डिजाइन कोडिंग नहीं है, कोडिंग डिजाइन नहीं है। यहां तक कि जब प्रोग्राम घटकों के लिए विस्तृत प्रक्रियात्मक डिजाइन बनाए जाते | * डिजाइन कोडिंग नहीं है, कोडिंग डिजाइन नहीं है। यहां तक कि जब प्रोग्राम घटकों के लिए विस्तृत प्रक्रियात्मक डिजाइन बनाए जाते हैं। तब भी डिजाइन मॉडल के अमूर्तन का स्तर स्रोत कोड से अधिक होता है। कोडिंग स्तर पर किए गए एकमात्र डिजाइन निर्णयों को छोटे कार्यान्वयन विवरणों को संबोधित करना चाहिए। जो प्रक्रियात्मक डिजाइन को कोडित करने में सक्षम बनाने का कार्य करता है। | ||
* डिजाइन का मूल्यांकन गुणवत्ता के लिए किया जाना चाहिए क्योंकि यह बनाया जा रहा | * डिजाइन का मूल्यांकन गुणवत्ता के लिए किया जाना चाहिए क्योंकि यह तथ्य के बाद नहीं बनाया जा रहा है। विकास प्रक्रिया के समय गुणवत्ता का आकलन करने में डिजाइनर की सहायता के लिए विभिन्न प्रकार की डिजाइन अवधारणाएँ और डिजाइन उपाय उपलब्ध होते हैं। | ||
* वैचारिक (सिमेंटिक) त्रुटियों को कम करने के लिए डिजाइन की समीक्षा की जानी चाहिए। जब डिजाइन की समीक्षा की जाती | * वैचारिक (सिमेंटिक) त्रुटियों को कम करने के लिए डिजाइन की समीक्षा की जानी चाहिए। जब डिजाइन की समीक्षा की जाती है। तो संभवतः छोटी-छोटी त्रुटियों पर ध्यान केंद्रित करने की प्रवृत्ति होती है, पेड़ों के लिए जंगल विलुप्त हो जाता है। एक डिजाइन टीम को यह सुनिश्चित करना चाहिए कि डिजाइन मॉडल के सिंटैक्स के बारे में चिंता करने से पहले डिजाइन के प्रमुख वैचारिक तत्वों (भ्रम, अस्पष्टता, असंगति) को संबोधित किया गया है। | ||
== डिजाइन अवधारणा == | == डिजाइन अवधारणा == | ||
Revision as of 09:52, 19 May 2023
| Part of a series on |
| Software development |
|---|
सॉफ़्टवेयर डिजाइन वह प्रक्रिया है, जिसके द्वारा एक एजेंट पुराने घटकों के समुच्चय का उपयोग करके और बाधाओं के अधीन लक्ष्यों को पूरा करने के उद्देश्य से कलाकृति (सॉफ़्टवेयर विकास) का एक विनिर्देश का निर्माण करती है।[1] इस शब्द का प्रयोग अधिकांशतः सॉफ्टवेयर की संकल्पना को बनाने, तैयार करने, संचालित करने, प्रारम्भ करने और अंततः संशोधित करने में सम्मिलित सभी गतिविधियों को संदर्भित करने के लिए किया जाता है या अधिक विशेष रूप से सॉफ्टवेयर आवश्यकताओं के विनिर्देश के पश्चात और कंप्यूटर प्रोग्रामिंग से पहले की गतिविधि के रूप में एक शैलीबद्ध सॉफ्टवेयर इंजीनियरिंग प्रक्रिया में इसका प्रयोग किया जाता है।[2]
सॉफ़्टवेयर डिजाइन में सामान्यतः समस्या-समाधान और सॉफ़्टवेयर समाधान की योजना बनाना सम्मिलित होता है। इसमें निम्न-स्तरीय घटक और एल्गोरिथम डिजाइन और उच्च-स्तरीय, सॉफ़्टवेयर आर्किटेक्चर डिजाइन दोनों सम्मिलित हैं।
अवलोकन
सॉफ़्टवेयर डिजाइन समस्याओं के एक या अधिक समुच्चयों के लिए सॉफ़्टवेयर समाधानों की कल्पना करने और उन्हें परिभाषित करने की प्रक्रिया होती है। सॉफ़्टवेयर डिजाइन के मुख्य घटकों में से एक सॉफ़्टवेयर आवश्यकता विश्लेषण (एसआरए) है। एसआरए सॉफ्टवेयर डेवलपमेंट प्रोसेस का एक भाग होता है। जो सॉफ्टवेयर इंजीनियरिंग में उपयोग किए जाने वाले विनिर्देशों को सूची के रूप में प्रदर्शित करता है।
यदि सॉफ़्टवेयर अर्ध-स्वचालित या उपयोगकर्ता केंद्रित डिजाइन है। तो सॉफ़्टवेयर डिजाइन में उन विशिष्टताओं को निर्धारित करने में सहायता के लिए स्टोरीबोर्ड प्रदान करने वाले उपयोगकर्ता अनुभव डिजाइन भी सम्मिलित हो सकते हैं। यदि सॉफ़्टवेयर पूर्णतयः स्वचालन (अर्थात् कोई उपयोगकर्ता (कंप्यूटिंग) या उपयोगकर्ता इंटरफ़ेस नहीं है) है। जिससे एक सॉफ़्टवेयर डिजाइन घटनाओं के नियोजित अनुक्रम का वर्णन करने वाले प्रवाह चार्ट या पाठ के समान सरल हो सकता है। यूनिफाइड मॉडलिंग लैंग्वेज और मौलिक मॉडलिंग अवधारणाएँ जैसी अर्ध-मानक विधियाँ भी हैं। किसी भी स्थिति में योजना के कुछ लेख सामान्यतः डिजाइन के उत्पाद होते हैं। इसके अतिरिक्त एक सॉफ्टवेयर डिजाइन प्लेटफ़ॉर्म-स्वतंत्र मॉडल या प्लेटफ़ॉर्म-विशिष्ट हो सकता है। जो डिजाइन के लिए उपयोग की जाने वाली विधि की उपलब्धता पर पूर्णतयः निर्भर करता है।
सॉफ़्टवेयर विश्लेषण और डिजाइन के बीच मुख्य अंतर यह है कि सॉफ़्टवेयर विश्लेषण के आउटपुट में हल करने के लिए छोटी समस्याएं होती हैं। इसके अतिरिक्त, विश्लेषण को अलग-अलग टीम के सदस्यों या समूहों में बहुत अलग तरीके से डिजाइन नहीं किया जाना चाहिए। इसके विपरीत, डिजाइन क्षमताओं पर केंद्रित है, और इस प्रकार एक ही समस्या के लिए कई डिजाइन उपस्थित हो सकते हैं और उपस्थित रहेंगे। पर्यावरण के आधार पर, डिजाइन अक्सर भिन्न होता है, चाहे वह विश्वसनीय सॉफ़्टवेयर ढांचे से बनाया गया हो या उपयुक्त डिजाइन पैटर्न्स के साथ कार्यान्वित किया गया हो। डिजाइन के उदाहरणों में ऑपरेशन सिस्टम, वेबपेज, मोबाइल डिवाइस या यहां तक कि नए क्लाउड कंप्यूटिंग प्रतिमान सम्मिलित हैं।
सॉफ्टवेयर डिजाइन एक प्रक्रिया और मॉडल दोनों है। डिजाइन प्रक्रिया चरणों का एक क्रम है। जो डिजाइनर को निर्माण के लिए सॉफ़्टवेयर के सभी पहलुओं का वर्णन करने में सक्षम बनाती है। रचनात्मक कौशल, पिछला अनुभव, अच्छा सॉफ्टवेयर बनाने की भावना और गुणवत्ता के प्रति समग्र प्रतिबद्धता एक सक्षम डिजाइन के लिए महत्वपूर्ण सफलता के कारकों के उदाहरण हैं। चूंकि यह ध्यान रखना महत्वपूर्ण है कि डिजाइन प्रक्रिया सदैव एक सीधी प्रक्रिया नहीं होती है। डिजाइन मॉडल की तुलना एक घर के लिए आर्किटेक्ट की योजनाओं से की जा सकती है। यह उस वस्तु की समग्रता का प्रतिनिधित्व करने से प्रारम्भ होता है। जिसे बनाया जाना है (उदाहरण के लिए घर का त्रि-आयामी प्रतिपादन); धीरे-धीरे प्रत्येक विवरण के निर्माण के लिए मार्गदर्शन प्रदान करने के लिए वस्तु को परिष्कृत किया जाता है (जैसे प्लंबिंग ले )। इसी प्रकार सॉफ़्टवेयर के लिए बनाया गया डिजाइन मॉडल कंप्यूटर सॉफ़्टवेयर के विभिन्न प्रकार के विभिन्न दृश्य प्रदान करता है। मूल डिजाइन सिद्धांत सॉफ़्टवेयर इंजीनियर को डिजाइन प्रक्रिया को नेविगेट करने में सक्षम बनाती हैं। डेविस[3] सॉफ्टवेयर डिजाइन के लिए सिद्धांतों का एक समुच्चय का निर्माण कर सकता है। जिसे निम्नलिखित सूची में अनुकूलित और विस्तारित किया गया है:
- डिजाइन प्रक्रिया को टनल विजन से पीड़ित नहीं होना चाहिए। एक अच्छे डिजाइनर को वैकल्पिक उपायों पर विचार करना चाहिए, समस्या की आवश्यकताओं के आधार पर प्रत्येक को देखते हुए काम करने के लिए उपलब्ध संसाधनों की व्यवस्था करनी चाहिए।
- डिजाइन विश्लेषण मॉडल के लिए पता लगाने योग्य होना चाहिए क्योंकि डिजाइन मॉडल के एक तत्व को प्रायः कई आवश्यकताओं के लिए वापस खोजा जा सकता है। यह ट्रैक करने के लिए एक साधन होना आवश्यक है कि डिजाइन मॉडल द्वारा आवश्यकताओं को कैसे पूरा किया गया है।
- डिजाइन को पहिया को फिर से नहीं लगाना चाहिए। प्रणाली का निर्माण डिजाइन पैटर्न के एक समुच्चय का उपयोग करके किया जाता है। जिनमें से कई की जानकारी पहले ही प्राप्त की जा चुकी है। इन पैटर्नों को सदैव पुनर्खोज के विकल्प के रूप में चुना जाना चाहिए। समय कम है और संसाधन सीमित हैं। डिजाइन समय को पहले से उपस्थित (जब संचालित हो) पैटर्न को एकीकृत करके (वास्तव में नए) विचारों का प्रतिनिधित्व करने में निवेश किया जाना चाहिए।
- डिजाइन को सॉफ्टवेयर और समस्या के बीच बौद्धिक दूरी को कम करना चाहिए क्योंकि यह वास्तविक विश्व में उपस्थित है। अर्थात्, सॉफ़्टवेयर डिजाइन की संरचना, जब भी संभव हो, समस्या डोमेन की संरचना की कॉपी करनी चाहिए।
- डिजाइन में एकरूपता और एकीकरण प्रदर्शित होना चाहिए। एक डिजाइन एक समान है। यदि यह पूर्णतयः सुसंगत प्रतीत होता है। इस परिणाम को प्राप्त करने के लिए डिजाइन का कार्य प्रारम्भ होने से पहले डिजाइन टीम के लिए शैली और डिजाइन के नियमों को परिभाषित किया जाना चाहिए। यदि डिजाइन घटकों के बीच इंटरफेस को परिभाषित करने में सावधानी की जानी चाहिए। जिससे डिजाइन को एकीकृत किया जाता है।
- परिवर्तन को समायोजित करने के लिए डिजाइन को संरचित किया जाना चाहिए। अगले खंड के विषय में चर्चा की गई डिजाइन अवधारणाएँ इस सिद्धांत को प्राप्त करने के लिए डिजाइन को सक्षम बनाती हैं।
- डिजाइन को धीरे-धीरे निम्न स्तर का प्रदर्शित करने के लिए संरचित किया जाना चाहिए। तथापि असामान्य डेटा, घटनाओं या परिचालन स्थितियों का सामना करना पड़े। अच्छी प्रकार से डिजाइन किए गए सॉफ़्टवेयर को कभी भी बम नहीं बनाना चाहिए। इसे असामान्य परिस्थितियों को समायोजित करने के लिए डिजाइन किया जाना चाहिए और यदि इसे प्रसंस्करण समाप्त करना ही है। जिससे इसे एक उत्तम प्रकार से किया जाना चाहिए।
- डिजाइन कोडिंग नहीं है, कोडिंग डिजाइन नहीं है। यहां तक कि जब प्रोग्राम घटकों के लिए विस्तृत प्रक्रियात्मक डिजाइन बनाए जाते हैं। तब भी डिजाइन मॉडल के अमूर्तन का स्तर स्रोत कोड से अधिक होता है। कोडिंग स्तर पर किए गए एकमात्र डिजाइन निर्णयों को छोटे कार्यान्वयन विवरणों को संबोधित करना चाहिए। जो प्रक्रियात्मक डिजाइन को कोडित करने में सक्षम बनाने का कार्य करता है।
- डिजाइन का मूल्यांकन गुणवत्ता के लिए किया जाना चाहिए क्योंकि यह तथ्य के बाद नहीं बनाया जा रहा है। विकास प्रक्रिया के समय गुणवत्ता का आकलन करने में डिजाइनर की सहायता के लिए विभिन्न प्रकार की डिजाइन अवधारणाएँ और डिजाइन उपाय उपलब्ध होते हैं।
- वैचारिक (सिमेंटिक) त्रुटियों को कम करने के लिए डिजाइन की समीक्षा की जानी चाहिए। जब डिजाइन की समीक्षा की जाती है। तो संभवतः छोटी-छोटी त्रुटियों पर ध्यान केंद्रित करने की प्रवृत्ति होती है, पेड़ों के लिए जंगल विलुप्त हो जाता है। एक डिजाइन टीम को यह सुनिश्चित करना चाहिए कि डिजाइन मॉडल के सिंटैक्स के बारे में चिंता करने से पहले डिजाइन के प्रमुख वैचारिक तत्वों (भ्रम, अस्पष्टता, असंगति) को संबोधित किया गया है।
डिजाइन अवधारणा
डिजाइन अवधारणाएँ सॉफ़्टवेयर डिजाइनर को एक नींव प्रदान करती हैं जिससे अधिक परिष्कृत तरीके लागू किए जा सकते हैं। मौलिक डिजाइन अवधारणाओं का एक सेट विकसित हुआ है। वे इस प्रकार हैं:
- अमूर्तता (कंप्यूटर विज्ञान) - अमूर्तन एक अवधारणा की सूचना सामग्री को कम करके सामान्यीकरण की प्रक्रिया या परिणाम है, सामान्यतः केवल उस जानकारी को बनाए रखने के लिए जो किसी विशेष उद्देश्य के लिए प्रासंगिक है। यह पृष्ठभूमि विवरण या स्पष्टीकरण को सम्मिलित किए बिना आवश्यक विशेषताओं का प्रतिनिधित्व करने का एक कार्य है।
- कार्यक्रम शोधन - यह विस्तार की प्रक्रिया है। प्रोग्रामिंग लैंग्वेज स्टेटमेंट्स तक पहुंचने तक स्टेप-वाइज फैशन में फंक्शन के मैक्रोस्कोपिक स्टेटमेंट को विघटित करके एक पदानुक्रम विकसित किया जाता है। प्रत्येक चरण में, दिए गए प्रोग्राम के एक या कई निर्देश अधिक विस्तृत निर्देशों में विघटित हो जाते हैं। अमूर्तता और शोधन पूरक अवधारणाएँ हैं।
- प्रतिरूपकता - सॉफ्टवेयर आर्किटेक्चर को मॉड्यूल नामक घटकों में बांटा गया है।
- सॉफ्टवेयर आर्किटेक्चर - यह सॉफ्टवेयर की समग्र संरचना और उन तरीकों को संदर्भित करता है जिसमें वह संरचना एक सिस्टम के लिए वैचारिक अखंडता प्रदान करती है। अच्छा सॉफ्टवेयर आर्किटेक्चर परियोजना के वांछित परिणाम के संबंध में निवेश पर अच्छा रिटर्न देगा, उदा। प्रदर्शन, गुणवत्ता, अनुसूची और लागत के संदर्भ में।
- नियंत्रण पदानुक्रम - एक कार्यक्रम संरचना जो एक कार्यक्रम घटक के संगठन का प्रतिनिधित्व करती है और नियंत्रण के एक पदानुक्रम का अर्थ है।
- Structural Partitioning - कार्यक्रम संरचना को क्षैतिज और लंबवत दोनों में विभाजित किया जा सकता है। क्षैतिज विभाजन प्रत्येक प्रमुख प्रोग्राम फ़ंक्शन के लिए मॉड्यूलर पदानुक्रम की अलग-अलग शाखाओं को परिभाषित करता है। लंबवत विभाजन सुझाव देता है कि कार्यक्रम संरचना में नियंत्रण और कार्य को ऊपर से नीचे वितरित किया जाना चाहिए।
- डेटा संरचना - यह डेटा के अलग-अलग तत्वों के बीच तार्किक संबंध का प्रतिनिधित्व है।
- सॉफ्टवेयर प्रक्रिया - यह व्यक्तिगत रूप से प्रत्येक मॉड्यूल के प्रसंस्करण पर केंद्रित है।
- जानकारी छिपाना - मॉड्यूल को निर्दिष्ट और डिजाइन किया जाना चाहिए ताकि एक मॉड्यूल के भीतर निहित जानकारी अन्य मॉड्यूल के लिए दुर्गम हो, जिन्हें ऐसी जानकारी की कोई आवश्यकता नहीं है।
अपने ऑब्जेक्ट मॉडल में, ग्रेडी बूच ने मौलिक सॉफ्टवेयर डिजाइन सिद्धांतों के रूप में एब्सट्रैक्शन, एनकैप्सुलेशन, मॉड्यूलराइजेशन और पदानुक्रम का उल्लेख किया है।[4] परिवर्णी शब्द PHAME (पदानुक्रम के सिद्धांत, अमूर्तता, मॉड्यूलरीकरण, और एनकैप्सुलेशन) का प्रयोग कभी-कभी इन चार मूलभूत सिद्धांतों को संदर्भित करने के लिए किया जाता है।[5]
डिजाइन विचार
सॉफ्टवेयर के एक टुकड़े के डिजाइन में विचार करने के लिए कई पहलू हैं। प्रत्येक विचार के महत्व को उन लक्ष्यों और अपेक्षाओं को प्रतिबिंबित करना चाहिए जिन्हें पूरा करने के लिए सॉफ्टवेयर बनाया जा रहा है। इनमें से कुछ पहलू हैं:
- संगतता - सॉफ़्टवेयर अन्य उत्पादों के साथ काम करने में सक्षम है जो किसी अन्य उत्पाद के साथ इंटरऑपरेबिलिटी के लिए डिजाइन किए गए हैं। उदाहरण के लिए, सॉफ़्टवेयर का एक टुकड़ा अपने पुराने संस्करण के साथ पिछड़ा-संगत हो सकता है।
- तानाना - अंतर्निहित आर्किटेक्चर में बड़े बदलाव के बिना सॉफ्टवेयर में नई क्षमताओं को जोड़ा जा सकता है।
- मॉड्यूलरिटी - परिणामी सॉफ़्टवेयर में अच्छी तरह से परिभाषित, स्वतंत्र घटक सम्मिलित होते हैं जो बेहतर रखरखाव की ओर ले जाते हैं। वांछित सॉफ्टवेयर सिस्टम बनाने के लिए एकीकृत होने से पहले घटकों को लागू किया जा सकता है और अलगाव में परीक्षण किया जा सकता है। यह एक सॉफ्टवेयर डेवलपमेंट प्रोजेक्ट में काम के विभाजन की अनुमति देता है।
- दोष-सहिष्णुता - सॉफ्टवेयर प्रतिरोधी है और घटक विफलता से उबरने में सक्षम है।
- रख-रखाव - बग फिक्स या कार्यात्मक संशोधनों को कितनी आसानी से पूरा किया जा सकता है, इसका एक उपाय। उच्च रख-रखाव मॉड्यूलरिटी और एक्स्टेंसिबिलिटी का उत्पाद हो सकता है।
- विश्वसनीयता (सॉफ्टवेयर स्थायित्व) - सॉफ्टवेयर निर्दिष्ट शर्तों के तहत एक निर्दिष्ट अवधि के लिए एक आवश्यक कार्य करने में सक्षम है।
- पुन: प्रयोज्य - अन्य परियोजनाओं में पहले से उपस्थित सॉफ़्टवेयर के कुछ या सभी पहलुओं को बिना किसी संशोधन के उपयोग करने की क्षमता।
- दोष-सहिष्णु प्रणाली - सॉफ्टवेयर तनाव में काम करने या अप्रत्याशित या अमान्य इनपुट को सहन करने में सक्षम है। उदाहरण के लिए, इसे कम स्मृति स्थितियों के लचीलेपन के साथ डिजाइन किया जा सकता है।
- कंप्यूटर सुरक्षा - सॉफ्टवेयर शत्रुतापूर्ण कृत्यों और प्रभावों का सामना करने और उनका विरोध करने में सक्षम है।
- उपयोगिता - सॉफ्टवेयर यूजर इंटरफेस अपने लक्षित उपयोगकर्ता/दर्शकों के लिए प्रयोग करने योग्य होना चाहिए। मापदंडों के लिए डिफ़ॉल्ट मान चुना जाना चाहिए ताकि वे अधिकांश उपयोगकर्ताओं के लिए एक अच्छा विकल्प हों।[6]
- कंप्यूटर का प्रदर्शन - सॉफ्टवेयर एक समय-सीमा के भीतर अपना कार्य करता है जो उपयोगकर्ता के लिए स्वीकार्य है, और इसके लिए बहुत अधिक मेमोरी की आवश्यकता नहीं होती है।
- सॉफ्टवेयर सुवाह्यता - सॉफ्टवेयर को कई अलग-अलग स्थितियों और वातावरणों में प्रयोग करने योग्य होना चाहिए।
- मापनीयता - सॉफ्टवेयर बढ़ते हुए डेटा या अतिरिक्त सुविधाओं या उपयोगकर्ताओं की संख्या के लिए अच्छी तरह से अनुकूल है।
मॉडलिंग भाषा
एक मॉडलिंग भाषा कोई भी कृत्रिम भाषा है जिसका उपयोग सूचनाओं, ज्ञान या प्रणालियों को एक संरचना में व्यक्त करने के लिए किया जा सकता है जिसे नियमों के एक सुसंगत सेट द्वारा परिभाषित किया गया है। इन नियमों का उपयोग संरचना के भीतर घटकों की व्याख्या के लिए किया जाता है। एक मॉडलिंग भाषा चित्रमय या पाठ्य हो सकती है। सॉफ़्टवेयर डिजाइन के लिए ग्राफ़िकल मॉडलिंग भाषाओं के उदाहरण हैं:
- वास्तुकला विवरण भाषा (एडीएल) एक ऐसी भाषा है जिसका उपयोग सॉफ्टवेयर सिस्टम के सॉफ्टवेयर आर्किटेक्चर का वर्णन और प्रतिनिधित्व करने के लिए किया जाता है।
- बिजनेस प्रोसेस मॉडलिंग नोटेशन (बीपीएमएन) प्रोसेस मॉडलिंग भाषा का एक उदाहरण है।
- [[एक्सप्रेस (मॉडलिंग की दिनांक भाषा)]] और एक्सप्रेस-जी (आईएसओ 10303-11) एक अंतरराष्ट्रीय मानक सामान्य प्रयोजन डेटा मॉडलिंग भाषा है।
- विस्तारित विस्तारित उद्यम मॉडलिंग भाषाEEML) का उपयोग सामान्यतः कई परतों में व्यवसाय प्रक्रिया मॉडलिंग के लिए किया जाता है।
- फ़्लोचार्ट एल्गोरिदम या अन्य चरण-वार प्रक्रियाओं का योजनाबद्ध प्रतिनिधित्व है।
- मौलिक मॉडलिंग अवधारणाएँ (FMC) सॉफ्टवेयर-इंटेंसिव सिस्टम्स के लिए मॉडलिंग लैंग्वेज है।
- IDEF मॉडलिंग भाषाओं का एक परिवार है, जिनमें से सबसे उल्लेखनीय में कार्यात्मक मॉडलिंग के लिए IDEF0, सूचना मॉडलिंग के लिए IDEF1X और ओन्टोलॉजी (सूचना विज्ञान) मॉडलिंग के लिए IDEF5 सम्मिलित हैं।
- जैक्सन संरचित प्रोग्रामिंग (जेएसपी) डेटा स्ट्रीम संरचना और प्रोग्राम संरचना के बीच पत्राचार के आधार पर संरचित प्रोग्रामिंग के लिए एक विधि है।
- Lepus3 एक वस्तु के उन्मुख विज़ुअल डिजाइन डिस्क्रिप्शन लैंग्वेज और एक औपचारिक विनिर्देश भाषा है जो मुख्य रूप से बड़े ऑब्जेक्ट-ओरिएंटेड (Java (प्रोग्रामिंग लैंग्वेज), C++, C Sharp (प्रोग्रामिंग लैंग्वेज)|C#) प्रोग्राम और डिजाइन पैटर्न मॉडलिंग के लिए उपयुक्त है।
- यूनिफाइड मॉडलिंग लैंग्वेज (यूएमएल) एक सामान्य मॉडलिंग भाषा है जो सॉफ्टवेयर को संरचनात्मक और व्यवहारिक रूप से वर्णित करती है। इसमें ग्राफिकल नोटेशन है और प्रोफाइल (यूएमएल) के साथ विस्तार की अनुमति देता है।
- मिश्र धातु (विनिर्देश भाषा) एक सॉफ्टवेयर सिस्टम में जटिल संरचनात्मक बाधाओं और व्यवहार को व्यक्त करने के लिए एक सामान्य प्रयोजन विनिर्देश भाषा है। यह फर्स्ट-ऑर्डर रिलेशनल लॉजिक पर एक संक्षिप्त भाषा आधार प्रदान करता है।
- सिस्टम्स मॉडलिंग लैंग्वेज (SysML) सिस्टम इंजीनियरिंग के लिए एक नई सामान्य प्रयोजन वाली मॉडलिंग भाषा है।
- सर्विस-ओरिएंटेड मॉडलिंग#सर्विस-ओरिएंटेड मॉडलिंग फ्रेमवर्क|सर्विस-ओरिएंटेड मॉडलिंग फ्रेमवर्क (SOMF)[7]
डिजाइन पैटर्न
एक सॉफ्टवेयर डिजाइनर या वास्तुकार एक डिजाइन समस्या की पहचान कर सकता है जिसे पहले देखा गया है और शायद दूसरों द्वारा हल भी किया गया है। एक सामान्य समस्या के समाधान का वर्णन करने वाला एक टेम्पलेट या पैटर्न डिजाइन पैटर्न (कंप्यूटर विज्ञान) के रूप में जाना जाता है। ऐसे पैटर्न का पुन: उपयोग सॉफ्टवेयर विकास प्रक्रिया को गति देने में मदद कर सकता है।[8]
तकनीक
सॉफ़्टवेयर के संबंध में डिजाइन शब्द का उपयोग करने में कठिनाई यह है कि कुछ अर्थों में, किसी प्रोग्राम का स्रोत कोड उस प्रोग्राम के लिए डिजाइन होता है जिसे वह उत्पन्न करता है। इस हद तक कि यह सच है, सॉफ्टवेयर डिजाइन डिजाइन के डिजाइन को संदर्भित करता है। Edsger W. Dijkstra ने सिमेंटिक स्तरों की इस लेयरिंग को कंप्यूटर प्रोग्रामिंग की मौलिक नवीनता के रूप में संदर्भित किया,[9] और डोनाल्ड नुथ ने इसे लागू करने से पहले एक कार्यक्रम को डिजाइन करने के प्रयास की व्यर्थता का वर्णन करने के लिए TeX लिखने के अपने अनुभव का उपयोग किया:
TEX 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.[10]
उपयोग
कंप्यूटर प्रोग्रामिंग से पहले बाधाओं, विनिर्देशों और यहां तक कि आवश्यकताओं को समायोजित करने की अनुमति देने के लिए सॉफ़्टवेयर डिजाइन प्रलेखन की समीक्षा या प्रस्तुत किया जा सकता है। प्रोग्राम किए गए सिमुलेशन या प्रोटोटाइप की समीक्षा के बाद रीडिजाइन हो सकता है। किसी योजना या आवश्यकता विश्लेषण के बिना, प्रोग्रामिंग की प्रक्रिया में सॉफ़्टवेयर डिजाइन करना संभव है,[11] लेकिन अधिक जटिल परियोजनाओं के लिए इसे व्यवहार्य नहीं माना जाएगा। प्रोग्रामिंग से पहले एक अलग डिजाइन बहु-विषयक डिजाइनरों और विषय-विशेषज्ञों (एसएमई) को सॉफ्टवेयर के लिए अत्यधिक कुशल प्रोग्रामर के साथ सहयोग करने की अनुमति देता है जो उपयोगी और तकनीकी रूप से ध्वनि दोनों है।
यह भी देखें
- पहलू-उन्मुख सॉफ्टवेयर विकास
- सूचना प्रौद्योगिकी में विज्ञान स्नातक
- डिजाइन
- डिजाइन तर्क
- ग्राफ़िक डिजाइन
- पारस्परिक प्रभाव वाली डिजाइन
- चिह्न डिजाइन
- सॉफ्टवेयर की रूपरेखा
- सॉफ्टवेयर विकास की रूपरेखा
- सॉफ्टवेयर इंजीनियरिंग की रूपरेखा
- खोज खोज-आधारित सॉफ्टवेयर इंजीनियरिंग
- सॉफ्टवेयर डिजाइन विवरण (IEEE 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 | |||||||
