सॉफ्टवेर डिज़ाइन

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

सिंहावलोकन

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

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

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

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

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

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

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

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

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

डिजाइन विचार

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

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

मॉडलिंग भाषा

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

• वास्तुकला विवरण भाषा (एडीएल) एक ऐसी भाषा है जिसका उपयोग सॉफ्टवेयर सिस्टम के सॉफ्टवेयर आर्किटेक्चर का वर्णन और प्रतिनिधित्व करने के लिए किया जाता है।
• बिजनेस प्रोसेस मॉडलिंग नोटेशन (बीपीएमएन) प्रोसेस मॉडलिंग भाषा का एक उदाहरण है।
• [[एक्सप्रेस (मॉडलिंग की दिनांक भाषा)]] और एक्सप्रेस-जी (आईएसओ 10303-11) एक अंतरराष्ट्रीय मानक सामान्य प्रयोजन डेटा मॉडलिंग भाषा है।
• विस्तारित विस्तारित उद्यम मॉडलिंग भाषाEEML) का उपयोग आमतौर पर कई परतों में व्यवसाय प्रक्रिया मॉडलिंग के लिए किया जाता है।
• फ़्लोचार्ट एल्गोरिदम या अन्य चरण-वार प्रक्रियाओं का योजनाबद्ध प्रतिनिधित्व है।
• मौलिक मॉडलिंग अवधारणाएँ (FMC) सॉफ्टवेयर-इंटेंसिव सिस्टम्स के लिए मॉडलिंग लैंग्वेज है।
• IDEF मॉडलिंग भाषाओं का एक परिवार है, जिनमें से सबसे उल्लेखनीय में कार्यात्मक मॉडलिंग के लिए IDEF0, सूचना मॉडलिंग के लिए IDEF1X और ओन्टोलॉजी (सूचना विज्ञान) मॉडलिंग के लिए IDEF5 शामिल हैं।
• जैक्सन संरचित प्रोग्रामिंग (जेएसपी) डेटा स्ट्रीम संरचना और प्रोग्राम संरचना के बीच पत्राचार के आधार पर संरचित प्रोग्रामिंग के लिए एक विधि है।
• Lepus3 एक वस्तु के उन्मुख विज़ुअल डिज़ाइन डिस्क्रिप्शन लैंग्वेज और एक औपचारिक विनिर्देश भाषा है जो मुख्य रूप से बड़े ऑब्जेक्ट-ओरिएंटेड (Java (प्रोग्रामिंग लैंग्वेज), C++, C Sharp (प्रोग्रामिंग लैंग्वेज)|C#) प्रोग्राम और डिज़ाइन पैटर्न मॉडलिंग के लिए उपयुक्त है।
• यूनिफाइड मॉडलिंग लैंग्वेज (यूएमएल) एक सामान्य मॉडलिंग भाषा है जो सॉफ्टवेयर को संरचनात्मक और व्यवहारिक रूप से वर्णित करती है। इसमें ग्राफिकल नोटेशन है और प्रोफाइल (यूएमएल) के साथ विस्तार की अनुमति देता है।
• मिश्र धातु (विनिर्देश भाषा) एक सॉफ्टवेयर सिस्टम में जटिल संरचनात्मक बाधाओं और व्यवहार को व्यक्त करने के लिए एक सामान्य प्रयोजन विनिर्देश भाषा है। यह फर्स्ट-ऑर्डर रिलेशनल लॉजिक पर एक संक्षिप्त भाषा आधार प्रदान करता है।
• सिस्टम्स मॉडलिंग लैंग्वेज (SysML) सिस्टम इंजीनियरिंग के लिए एक नई सामान्य प्रयोजन वाली मॉडलिंग भाषा है।
• सर्विस-ओरिएंटेड मॉडलिंग#सर्विस-ओरिएंटेड मॉडलिंग फ्रेमवर्क|सर्विस-ओरिएंटेड मॉडलिंग फ्रेमवर्क (SOMF)

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

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

तकनीक

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

T_EX 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.

उपयोग

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

यह भी देखें

• पहलू-उन्मुख सॉफ्टवेयर विकास
• सूचना प्रौद्योगिकी में विज्ञान स्नातक
• डिज़ाइन
• डिजाइन तर्क
• ग्राफ़िक डिज़ाइन
• पारस्परिक प्रभाव वाली डिज़ाइन
• चिह्न डिजाइन
• सॉफ्टवेयर की रूपरेखा
• सॉफ्टवेयर विकास की रूपरेखा
• सॉफ्टवेयर इंजीनियरिंग की रूपरेखा
• खोज खोज-आधारित सॉफ्टवेयर इंजीनियरिंग
• सॉफ्टवेयर डिजाइन विवरण (IEEE 1016)
• सॉफ्टवेयर डेवलपमेंट
• प्रयोगकर्ता का अनुभव
• यूजर इंटरफेस डिजाइन
• वेब डिजाइन
• जीरो वन इन्फिनिटी

संदर्भ

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