सॉफ्टवेर डिज़ाइन: Difference between revisions
From Vigyanwiki
No edit summary |
No edit summary |
||
| Line 5: | Line 5: | ||
सॉफ़्टवेयर प्रारूप में सामान्यतः समस्या-समाधान और सॉफ़्टवेयर समाधान की योजना बनाना सम्मिलित होता है। इसमें निम्न-स्तरीय घटक और [[एल्गोरिथम डिजाइन|एल्गोरिथम प्रारूप]] और उच्च-स्तरीय, सॉफ़्टवेयर आर्किटेक्चर प्रारूप दोनों सम्मिलित हैं। | सॉफ़्टवेयर प्रारूप में सामान्यतः समस्या-समाधान और सॉफ़्टवेयर समाधान की योजना बनाना सम्मिलित होता है। इसमें निम्न-स्तरीय घटक और [[एल्गोरिथम डिजाइन|एल्गोरिथम प्रारूप]] और उच्च-स्तरीय, सॉफ़्टवेयर आर्किटेक्चर प्रारूप दोनों सम्मिलित हैं। | ||
== | == वलोकन == | ||
सॉफ़्टवेयर | सॉफ़्टवेयर प्रारूप समस्याओं के एक या अधिक सेटों के लिए सॉफ़्टवेयर समाधानों की कल्पना करने और उन्हें परिभाषित करने की प्रक्रिया है। सॉफ़्टवेयर प्रारूप के मुख्य घटकों में से एक सॉफ़्टवेयर आवश्यकता विश्लेषण (SRA) है। एसआरए सॉफ्टवेयर डेवलपमेंट प्रोसेस का एक हिस्सा है जो सॉफ्टवेयर इंजीनियरिंग में उपयोग किए जाने वाले विनिर्देशों को सूचीबद्ध करता है। | ||
यदि सॉफ़्टवेयर अर्ध-स्वचालित या उपयोगकर्ता केंद्रित | यदि सॉफ़्टवेयर अर्ध-स्वचालित या उपयोगकर्ता केंद्रित प्रारूप है, तो सॉफ़्टवेयर प्रारूप में उन विशिष्टताओं को निर्धारित करने में सहायता के लिए स्टोरीबोर्ड प्रदान करने वाले उपयोगकर्ता अनुभव प्रारूप सम्मिलित हो सकते हैं। यदि सॉफ़्टवेयर पूरी तरह से [[स्वचालन]] (अर्थात् कोई उपयोगकर्ता (कंप्यूटिंग) या उपयोगकर्ता इंटरफ़ेस नहीं है) है, तो एक सॉफ़्टवेयर प्रारूप घटनाओं के नियोजित अनुक्रम का वर्णन करने वाले [[प्रवाह चार्ट]] या पाठ के समान सरल हो सकता है। यूनिफाइड मॉडलिंग लैंग्वेज और [[मौलिक मॉडलिंग अवधारणाएँ]] जैसी अर्ध-मानक विधियाँ भी हैं। किसी भी मामले में, योजना के कुछ दस्तावेज आमतौर पर डिजाइन के उत्पाद होते हैं। इसके अलावा, एक सॉफ्टवेयर प्रारूप प्लेटफ़ॉर्म-स्वतंत्र मॉडल | प्लेटफ़ॉर्म-स्वतंत्र या प्लेटफ़ॉर्म-विशिष्ट मॉडल | प्लेटफ़ॉर्म-विशिष्ट हो सकता है, जो प्रारूप के लिए उपयोग की जाने वाली तकनीक की उपलब्धता पर निर्भर करता है। | ||
सॉफ़्टवेयर विश्लेषण और | सॉफ़्टवेयर विश्लेषण और प्रारूप के बीच मुख्य अंतर यह है कि सॉफ़्टवेयर विश्लेषण के आउटपुट में हल करने के लिए छोटी समस्याएं होती हैं। इसके अतिरिक्त, विश्लेषण को अलग-अलग टीम के सदस्यों या समूहों में बहुत अलग तरीके से प्रारूप नहीं किया जाना चाहिए। इसके विपरीत, प्रारूप क्षमताओं पर केंद्रित है, और इस प्रकार एक ही समस्या के लिए कई प्रारूप मौजूद हो सकते हैं और मौजूद रहेंगे। पर्यावरण के आधार पर, प्रारूप अक्सर भिन्न होता है, चाहे वह विश्वसनीय सॉफ़्टवेयर ढांचे से बनाया गया हो या उपयुक्त [[डिजाइन पैटर्न्स]] के साथ कार्यान्वित किया गया हो। डिजाइन के उदाहरणों में ऑपरेशन सिस्टम, वेबपेज, मोबाइल डिवाइस या यहां तक कि नए क्लाउड कंप्यूटिंग प्रतिमान सम्मिलित हैं। | ||
सॉफ्टवेयर डिजाइन एक प्रक्रिया और एक मॉडल दोनों है। | सॉफ्टवेयर डिजाइन एक प्रक्रिया और एक मॉडल दोनों है। प्रारूप प्रक्रिया चरणों का एक क्रम है जो प्रारूपर को निर्माण के लिए सॉफ़्टवेयर के सभी पहलुओं का वर्णन करने में सक्षम बनाती है। रचनात्मक कौशल, पिछला अनुभव, अच्छा सॉफ्टवेयर बनाने की भावना, और गुणवत्ता के प्रति समग्र प्रतिबद्धता एक सक्षम डिजाइन के लिए महत्वपूर्ण सफलता कारकों के उदाहरण हैं। हालांकि, यह ध्यान रखना महत्वपूर्ण है कि डिजाइन प्रक्रिया हमेशा एक सीधी प्रक्रिया नहीं होती है; डिजाइन मॉडल की तुलना एक घर के लिए आर्किटेक्ट की योजनाओं से की जा सकती है। यह उस चीज़ की समग्रता का प्रतिनिधित्व करने से शुरू होता है जिसे बनाया जाना है (उदाहरण के लिए, घर का त्रि-आयामी प्रतिपादन); धीरे-धीरे, प्रत्येक विवरण के निर्माण के लिए मार्गदर्शन प्रदान करने के लिए चीज़ को परिष्कृत किया जाता है (जैसे, नलसाजी बिछाना)। इसी प्रकार, सॉफ़्टवेयर के लिए बनाया गया प्रारूप मॉडल कंप्यूटर सॉफ़्टवेयर के विभिन्न प्रकार के विभिन्न दृश्य प्रदान करता है। मूल प्रारूप सिद्धांत सॉफ़्टवेयर इंजीनियर को प्रारूप प्रक्रिया को नेविगेट करने में सक्षम बनाते हैं। डेविस<ref>Davis, A:"201 Principles of Software Development", McGraw Hill, 1995.</ref> सॉफ्टवेयर डिजाइन के लिए सिद्धांतों का एक सेट सुझाता है, जिसे निम्नलिखित सूची में अनुकूलित और विस्तारित किया गया है: | ||
* डिजाइन प्रक्रिया को टनल विजन से पीड़ित नहीं होना चाहिए। एक अच्छे डिजाइनर को वैकल्पिक तरीकों पर विचार करना चाहिए, समस्या की आवश्यकताओं के आधार पर प्रत्येक को देखते हुए, काम करने के लिए उपलब्ध संसाधन। | * डिजाइन प्रक्रिया को टनल विजन से पीड़ित नहीं होना चाहिए। एक अच्छे डिजाइनर को वैकल्पिक तरीकों पर विचार करना चाहिए, समस्या की आवश्यकताओं के आधार पर प्रत्येक को देखते हुए, काम करने के लिए उपलब्ध संसाधन। | ||
* डिजाइन विश्लेषण मॉडल के लिए पता लगाने योग्य होना चाहिए। क्योंकि | * डिजाइन विश्लेषण मॉडल के लिए पता लगाने योग्य होना चाहिए। क्योंकि प्रारूप मॉडल के एक तत्व को अक्सर कई आवश्यकताओं के लिए वापस खोजा जा सकता है, यह ट्रैक करने के लिए एक साधन होना आवश्यक है कि प्रारूप मॉडल द्वारा आवश्यकताओं को कैसे पूरा किया गया है। | ||
* डिजाइन को पहिया को फिर से नहीं लगाना चाहिए। सिस्टम का निर्माण | * डिजाइन को पहिया को फिर से नहीं लगाना चाहिए। सिस्टम का निर्माण प्रारूप पैटर्न के एक सेट का उपयोग करके किया जाता है, जिनमें से कई का पहले सामना किया जा चुका है। इन पैटर्नों को हमेशा पुनर्खोज के विकल्प के रूप में चुना जाना चाहिए। समय कम है और संसाधन सीमित हैं; डिजाइन समय को पहले से मौजूद (जब लागू हो) पैटर्न को एकीकृत करके (वास्तव में नए) विचारों का प्रतिनिधित्व करने में निवेश किया जाना चाहिए। | ||
* डिजाइन को सॉफ्टवेयर और समस्या के बीच बौद्धिक दूरी को कम करना चाहिए क्योंकि यह वास्तविक दुनिया में मौजूद है। अर्थात्, सॉफ़्टवेयर | * डिजाइन को सॉफ्टवेयर और समस्या के बीच बौद्धिक दूरी को कम करना चाहिए क्योंकि यह वास्तविक दुनिया में मौजूद है। अर्थात्, सॉफ़्टवेयर प्रारूप की संरचना, जब भी संभव हो, समस्या डोमेन की संरचना की नकल करनी चाहिए। | ||
* डिजाइन में एकरूपता और एकीकरण प्रदर्शित होना चाहिए। एक डिजाइन एक समान है अगर यह पूरी तरह सुसंगत दिखाई देता है। इस परिणाम को प्राप्त करने के लिए, डिजाइन का काम शुरू होने से पहले डिजाइन टीम के लिए शैली और प्रारूप के नियमों को परिभाषित किया जाना चाहिए। यदि डिजाइन घटकों के बीच इंटरफेस को परिभाषित करने में सावधानी बरती जाती है तो एक डिजाइन को एकीकृत किया जाता है। | * डिजाइन में एकरूपता और एकीकरण प्रदर्शित होना चाहिए। एक डिजाइन एक समान है अगर यह पूरी तरह सुसंगत दिखाई देता है। इस परिणाम को प्राप्त करने के लिए, डिजाइन का काम शुरू होने से पहले डिजाइन टीम के लिए शैली और प्रारूप के नियमों को परिभाषित किया जाना चाहिए। यदि डिजाइन घटकों के बीच इंटरफेस को परिभाषित करने में सावधानी बरती जाती है तो एक डिजाइन को एकीकृत किया जाता है। | ||
* परिवर्तन को समायोजित करने के लिए डिजाइन को संरचित किया जाना चाहिए। अगले खंड में चर्चा की गई | * परिवर्तन को समायोजित करने के लिए डिजाइन को संरचित किया जाना चाहिए। अगले खंड में चर्चा की गई प्रारूप अवधारणाएँ इस सिद्धांत को प्राप्त करने के लिए प्रारूप को सक्षम बनाती हैं। | ||
* डिजाइन को धीरे-धीरे नीचा दिखाने के लिए संरचित किया जाना चाहिए, भले ही असामान्य डेटा, घटनाओं या परिचालन स्थितियों का सामना करना पड़े। अच्छी तरह से | * डिजाइन को धीरे-धीरे नीचा दिखाने के लिए संरचित किया जाना चाहिए, भले ही असामान्य डेटा, घटनाओं या परिचालन स्थितियों का सामना करना पड़े। अच्छी तरह से प्रारूप किए गए सॉफ़्टवेयर को कभी भी बम नहीं बनाना चाहिए; इसे असामान्य परिस्थितियों को समायोजित करने के लिए प्रारूप किया जाना चाहिए, और यदि इसे प्रसंस्करण समाप्त करना ही है, तो इसे एक शालीन तरीके से करना चाहिए। | ||
* | * प्रारूप कोडिंग नहीं है, कोडिंग प्रारूप नहीं है। यहां तक कि जब प्रोग्राम घटकों के लिए विस्तृत प्रक्रियात्मक डिजाइन बनाए जाते हैं, तब भी डिजाइन मॉडल के अमूर्तन का स्तर स्रोत कोड से अधिक होता है। कोडिंग स्तर पर किए गए एकमात्र प्रारूप निर्णयों को छोटे कार्यान्वयन विवरणों को संबोधित करना चाहिए जो प्रक्रियात्मक प्रारूप को कोडित करने में सक्षम बनाता है। | ||
* डिजाइन का मूल्यांकन गुणवत्ता के लिए किया जाना चाहिए क्योंकि यह बनाया जा रहा है, तथ्य के बाद नहीं। विकास प्रक्रिया के दौरान गुणवत्ता का आकलन करने में | * डिजाइन का मूल्यांकन गुणवत्ता के लिए किया जाना चाहिए क्योंकि यह बनाया जा रहा है, तथ्य के बाद नहीं। विकास प्रक्रिया के दौरान गुणवत्ता का आकलन करने में प्रारूपर की सहायता के लिए विभिन्न प्रकार की प्रारूप अवधारणाएँ और प्रारूप उपाय उपलब्ध हैं। | ||
* वैचारिक (सिमेंटिक) त्रुटियों को कम करने के लिए डिजाइन की समीक्षा की जानी चाहिए। जब डिजाइन की समीक्षा की जाती है तो कभी-कभी बारीकियों पर ध्यान केंद्रित करने की प्रवृत्ति होती है, पेड़ों के लिए जंगल गायब हो जाता है। एक | * वैचारिक (सिमेंटिक) त्रुटियों को कम करने के लिए डिजाइन की समीक्षा की जानी चाहिए। जब डिजाइन की समीक्षा की जाती है तो कभी-कभी बारीकियों पर ध्यान केंद्रित करने की प्रवृत्ति होती है, पेड़ों के लिए जंगल गायब हो जाता है। एक प्रारूप टीम को यह सुनिश्चित करना चाहिए कि प्रारूप मॉडल के सिंटैक्स के बारे में चिंता करने से पहले प्रारूप के प्रमुख वैचारिक तत्वों (चूक, अस्पष्टता, असंगति) को संबोधित किया गया है। | ||
== डिजाइन अवधारणा == | == डिजाइन अवधारणा == | ||
प्रारूप अवधारणाएँ सॉफ़्टवेयर प्रारूपर को एक नींव प्रदान करती हैं जिससे अधिक परिष्कृत तरीके लागू किए जा सकते हैं। मौलिक डिजाइन अवधारणाओं का एक सेट विकसित हुआ है। वे इस प्रकार हैं: | |||
#अमूर्तता (कंप्यूटर विज्ञान) - अमूर्तन एक अवधारणा की सूचना सामग्री को कम करके सामान्यीकरण की प्रक्रिया या परिणाम है, आमतौर पर केवल उस जानकारी को बनाए रखने के लिए जो किसी विशेष उद्देश्य के लिए प्रासंगिक है। यह पृष्ठभूमि विवरण या स्पष्टीकरण को सम्मिलित किए बिना आवश्यक विशेषताओं का प्रतिनिधित्व करने का एक कार्य है। | #अमूर्तता (कंप्यूटर विज्ञान) - अमूर्तन एक अवधारणा की सूचना सामग्री को कम करके सामान्यीकरण की प्रक्रिया या परिणाम है, आमतौर पर केवल उस जानकारी को बनाए रखने के लिए जो किसी विशेष उद्देश्य के लिए प्रासंगिक है। यह पृष्ठभूमि विवरण या स्पष्टीकरण को सम्मिलित किए बिना आवश्यक विशेषताओं का प्रतिनिधित्व करने का एक कार्य है। | ||
| Line 37: | Line 37: | ||
#[[डेटा संरचना]] - यह डेटा के अलग-अलग तत्वों के बीच तार्किक संबंध का प्रतिनिधित्व है। | #[[डेटा संरचना]] - यह डेटा के अलग-अलग तत्वों के बीच तार्किक संबंध का प्रतिनिधित्व है। | ||
#सॉफ्टवेयर प्रक्रिया - यह व्यक्तिगत रूप से प्रत्येक मॉड्यूल के प्रसंस्करण पर केंद्रित है। | #सॉफ्टवेयर प्रक्रिया - यह व्यक्तिगत रूप से प्रत्येक मॉड्यूल के प्रसंस्करण पर केंद्रित है। | ||
#जानकारी छिपाना - मॉड्यूल को निर्दिष्ट और | #जानकारी छिपाना - मॉड्यूल को निर्दिष्ट और प्रारूप किया जाना चाहिए ताकि एक मॉड्यूल के भीतर निहित जानकारी अन्य मॉड्यूल के लिए दुर्गम हो, जिन्हें ऐसी जानकारी की कोई आवश्यकता नहीं है। | ||
अपने ऑब्जेक्ट मॉडल में, [[ग्रेडी बूच]] ने मौलिक सॉफ्टवेयर डिजाइन सिद्धांतों के रूप में एब्सट्रैक्शन, एनकैप्सुलेशन, मॉड्यूलराइजेशन और पदानुक्रम का उल्लेख किया है।<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> परिवर्णी शब्द PHAME (पदानुक्रम के सिद्धांत, अमूर्तता, मॉड्यूलरीकरण, और एनकैप्सुलेशन) का प्रयोग कभी-कभी इन चार मूलभूत सिद्धांतों को संदर्भित करने के लिए किया जाता है।<ref>{{cite book|last1=Suryanarayana|first1=Girish|title=सॉफ्टवेयर डिजाइन गंध के लिए रिफैक्टरिंग|date=November 2014|publisher=Morgan Kaufmann|isbn=978-0128013977|pages=258}}</ref> | ||
| Line 46: | Line 46: | ||
सॉफ्टवेयर के एक टुकड़े के डिजाइन में विचार करने के लिए कई पहलू हैं। प्रत्येक विचार के महत्व को उन लक्ष्यों और अपेक्षाओं को प्रतिबिंबित करना चाहिए जिन्हें पूरा करने के लिए सॉफ्टवेयर बनाया जा रहा है। इनमें से कुछ पहलू हैं: | सॉफ्टवेयर के एक टुकड़े के डिजाइन में विचार करने के लिए कई पहलू हैं। प्रत्येक विचार के महत्व को उन लक्ष्यों और अपेक्षाओं को प्रतिबिंबित करना चाहिए जिन्हें पूरा करने के लिए सॉफ्टवेयर बनाया जा रहा है। इनमें से कुछ पहलू हैं: | ||
* संगतता - सॉफ़्टवेयर अन्य उत्पादों के साथ काम करने में सक्षम है जो किसी अन्य उत्पाद के साथ इंटरऑपरेबिलिटी के लिए | * संगतता - सॉफ़्टवेयर अन्य उत्पादों के साथ काम करने में सक्षम है जो किसी अन्य उत्पाद के साथ इंटरऑपरेबिलिटी के लिए प्रारूप किए गए हैं। उदाहरण के लिए, सॉफ़्टवेयर का एक टुकड़ा अपने पुराने संस्करण के साथ पिछड़ा-संगत हो सकता है। | ||
* [[तानाना]] - अंतर्निहित आर्किटेक्चर में बड़े बदलाव के बिना सॉफ्टवेयर में नई क्षमताओं को जोड़ा जा सकता है। | * [[तानाना]] - अंतर्निहित आर्किटेक्चर में बड़े बदलाव के बिना सॉफ्टवेयर में नई क्षमताओं को जोड़ा जा सकता है। | ||
* मॉड्यूलरिटी - परिणामी सॉफ़्टवेयर में अच्छी तरह से परिभाषित, स्वतंत्र घटक सम्मिलित होते हैं जो बेहतर रखरखाव की ओर ले जाते हैं। वांछित सॉफ्टवेयर सिस्टम बनाने के लिए एकीकृत होने से पहले घटकों को लागू किया जा सकता है और अलगाव में परीक्षण किया जा सकता है। यह एक सॉफ्टवेयर डेवलपमेंट प्रोजेक्ट में काम के विभाजन की अनुमति देता है। | * मॉड्यूलरिटी - परिणामी सॉफ़्टवेयर में अच्छी तरह से परिभाषित, स्वतंत्र घटक सम्मिलित होते हैं जो बेहतर रखरखाव की ओर ले जाते हैं। वांछित सॉफ्टवेयर सिस्टम बनाने के लिए एकीकृत होने से पहले घटकों को लागू किया जा सकता है और अलगाव में परीक्षण किया जा सकता है। यह एक सॉफ्टवेयर डेवलपमेंट प्रोजेक्ट में काम के विभाजन की अनुमति देता है। | ||
| Line 62: | Line 62: | ||
== [[मॉडलिंग भाषा]] == | == [[मॉडलिंग भाषा]] == | ||
एक मॉडलिंग भाषा कोई भी कृत्रिम भाषा है जिसका उपयोग सूचनाओं, ज्ञान या प्रणालियों को एक संरचना में व्यक्त करने के लिए किया जा सकता है जिसे नियमों के एक सुसंगत सेट द्वारा परिभाषित किया गया है। इन नियमों का उपयोग संरचना के भीतर घटकों की व्याख्या के लिए किया जाता है। एक मॉडलिंग भाषा चित्रमय या पाठ्य हो सकती है। सॉफ़्टवेयर | एक मॉडलिंग भाषा कोई भी कृत्रिम भाषा है जिसका उपयोग सूचनाओं, ज्ञान या प्रणालियों को एक संरचना में व्यक्त करने के लिए किया जा सकता है जिसे नियमों के एक सुसंगत सेट द्वारा परिभाषित किया गया है। इन नियमों का उपयोग संरचना के भीतर घटकों की व्याख्या के लिए किया जाता है। एक मॉडलिंग भाषा चित्रमय या पाठ्य हो सकती है। सॉफ़्टवेयर प्रारूप के लिए ग्राफ़िकल मॉडलिंग भाषाओं के उदाहरण हैं: | ||
*[[ वास्तुकला विवरण भाषा ]] (एडीएल) एक ऐसी भाषा है जिसका उपयोग सॉफ्टवेयर सिस्टम के सॉफ्टवेयर आर्किटेक्चर का वर्णन और प्रतिनिधित्व करने के लिए किया जाता है। | *[[ वास्तुकला विवरण भाषा ]] (एडीएल) एक ऐसी भाषा है जिसका उपयोग सॉफ्टवेयर सिस्टम के सॉफ्टवेयर आर्किटेक्चर का वर्णन और प्रतिनिधित्व करने के लिए किया जाता है। | ||
* [[बिजनेस प्रोसेस मॉडलिंग नोटेशन]] (बीपीएमएन) प्रोसेस मॉडलिंग भाषा का एक उदाहरण है। | * [[बिजनेस प्रोसेस मॉडलिंग नोटेशन]] (बीपीएमएन) प्रोसेस मॉडलिंग भाषा का एक उदाहरण है। | ||
| Line 71: | Line 71: | ||
* [[IDEF]] मॉडलिंग भाषाओं का एक परिवार है, जिनमें से सबसे उल्लेखनीय में कार्यात्मक मॉडलिंग के लिए [[IDEF0]], सूचना मॉडलिंग के लिए [[IDEF1X]] और ओन्टोलॉजी (सूचना विज्ञान) मॉडलिंग के लिए [[IDEF5]] सम्मिलित हैं। | * [[IDEF]] मॉडलिंग भाषाओं का एक परिवार है, जिनमें से सबसे उल्लेखनीय में कार्यात्मक मॉडलिंग के लिए [[IDEF0]], सूचना मॉडलिंग के लिए [[IDEF1X]] और ओन्टोलॉजी (सूचना विज्ञान) मॉडलिंग के लिए [[IDEF5]] सम्मिलित हैं। | ||
* [[ जैक्सन संरचित प्रोग्रामिंग ]] (जेएसपी) डेटा स्ट्रीम संरचना और प्रोग्राम संरचना के बीच पत्राचार के आधार पर संरचित प्रोग्रामिंग के लिए एक विधि है। | * [[ जैक्सन संरचित प्रोग्रामिंग ]] (जेएसपी) डेटा स्ट्रीम संरचना और प्रोग्राम संरचना के बीच पत्राचार के आधार पर संरचित प्रोग्रामिंग के लिए एक विधि है। | ||
* [[Lepus3]] एक [[ वस्तु के उन्मुख ]] विज़ुअल | * [[Lepus3]] एक [[ वस्तु के उन्मुख ]] विज़ुअल प्रारूप डिस्क्रिप्शन लैंग्वेज और एक [[औपचारिक विनिर्देश]] भाषा है जो मुख्य रूप से बड़े ऑब्जेक्ट-ओरिएंटेड (Java (प्रोग्रामिंग लैंग्वेज), [[C++]], C Sharp (प्रोग्रामिंग लैंग्वेज)|C#) प्रोग्राम और प्रारूप पैटर्न मॉडलिंग के लिए उपयुक्त है। | ||
* यूनिफाइड मॉडलिंग लैंग्वेज (यूएमएल) एक सामान्य मॉडलिंग भाषा है जो सॉफ्टवेयर को संरचनात्मक और व्यवहारिक रूप से वर्णित करती है। इसमें ग्राफिकल नोटेशन है और [[प्रोफाइल (यूएमएल)]] के साथ विस्तार की अनुमति देता है। | * यूनिफाइड मॉडलिंग लैंग्वेज (यूएमएल) एक सामान्य मॉडलिंग भाषा है जो सॉफ्टवेयर को संरचनात्मक और व्यवहारिक रूप से वर्णित करती है। इसमें ग्राफिकल नोटेशन है और [[प्रोफाइल (यूएमएल)]] के साथ विस्तार की अनुमति देता है। | ||
* मिश्र धातु (विनिर्देश भाषा) एक सॉफ्टवेयर सिस्टम में जटिल संरचनात्मक बाधाओं और व्यवहार को व्यक्त करने के लिए एक सामान्य प्रयोजन विनिर्देश भाषा है। यह फर्स्ट-ऑर्डर रिलेशनल लॉजिक पर एक संक्षिप्त भाषा आधार प्रदान करता है। | * मिश्र धातु (विनिर्देश भाषा) एक सॉफ्टवेयर सिस्टम में जटिल संरचनात्मक बाधाओं और व्यवहार को व्यक्त करने के लिए एक सामान्य प्रयोजन विनिर्देश भाषा है। यह फर्स्ट-ऑर्डर रिलेशनल लॉजिक पर एक संक्षिप्त भाषा आधार प्रदान करता है। | ||
| Line 80: | Line 80: | ||
== डिजाइन पैटर्न == | == डिजाइन पैटर्न == | ||
एक सॉफ्टवेयर डिजाइनर या वास्तुकार एक डिजाइन समस्या की पहचान कर सकता है जिसे पहले देखा गया है और शायद दूसरों द्वारा हल भी किया गया है। एक सामान्य समस्या के समाधान का वर्णन करने वाला एक टेम्पलेट या पैटर्न | एक सॉफ्टवेयर डिजाइनर या वास्तुकार एक डिजाइन समस्या की पहचान कर सकता है जिसे पहले देखा गया है और शायद दूसरों द्वारा हल भी किया गया है। एक सामान्य समस्या के समाधान का वर्णन करने वाला एक टेम्पलेट या पैटर्न प्रारूप पैटर्न (कंप्यूटर विज्ञान) के रूप में जाना जाता है। ऐसे पैटर्न का पुन: उपयोग सॉफ्टवेयर विकास प्रक्रिया को गति देने में मदद कर सकता है।<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 92: | ||
== तकनीक == | == तकनीक == | ||
सॉफ़्टवेयर के संबंध में | सॉफ़्टवेयर के संबंध में प्रारूप शब्द का उपयोग करने में कठिनाई यह है कि कुछ अर्थों में, किसी प्रोग्राम का स्रोत कोड उस प्रोग्राम के लिए प्रारूप होता है जिसे वह उत्पन्न करता है। इस हद तक कि यह सच है, सॉफ्टवेयर डिजाइन डिजाइन के डिजाइन को संदर्भित करता है। Edsger W. Dijkstra ने सिमेंटिक स्तरों की इस लेयरिंग को कंप्यूटर प्रोग्रामिंग की मौलिक नवीनता के रूप में संदर्भित किया,<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 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> लेकिन अधिक जटिल परियोजनाओं के लिए इसे व्यवहार्य नहीं माना जाएगा। प्रोग्रामिंग से पहले एक अलग डिजाइन बहु-विषयक डिजाइनरों और विषय-विशेषज्ञों (एसएमई) को सॉफ्टवेयर के लिए अत्यधिक कुशल प्रोग्रामर के साथ सहयोग करने की अनुमति देता है जो उपयोगी और तकनीकी रूप से ध्वनि दोनों है। | ||
== यह भी देखें == | == यह भी देखें == | ||
| Line 122: | Line 122: | ||
* पहलू-उन्मुख सॉफ्टवेयर विकास | * पहलू-उन्मुख सॉफ्टवेयर विकास | ||
* [[सूचना प्रौद्योगिकी में विज्ञान स्नातक]] | * [[सूचना प्रौद्योगिकी में विज्ञान स्नातक]] | ||
* [[डिज़ाइन]] | * [[डिज़ाइन|प्रारूप]] | ||
* [[डिजाइन तर्क]] | * [[डिजाइन तर्क]] | ||
* [[ग्राफ़िक डिज़ाइन]] | * [[ग्राफ़िक डिज़ाइन|ग्राफ़िक प्रारूप]] | ||
* [[पारस्परिक प्रभाव वाली डिज़ाइन]] | * [[पारस्परिक प्रभाव वाली डिज़ाइन|पारस्परिक प्रभाव वाली प्रारूप]] | ||
* [[चिह्न डिजाइन]] | * [[चिह्न डिजाइन]] | ||
* [[सॉफ्टवेयर की रूपरेखा]] | * [[सॉफ्टवेयर की रूपरेखा]] | ||
Revision as of 09:28, 19 May 2023
| Part of a series on |
| Software development |
|---|
सॉफ़्टवेयर प्रारूप वह प्रक्रिया है, जिसके द्वारा एक एजेंट पुराने घटकों के समुच्चय का उपयोग करके और बाधाओं के अधीन लक्ष्यों को पूरा करने के उद्देश्य से कलाकृति (सॉफ़्टवेयर विकास) का एक विनिर्देश का निर्माण करती है।[1] इस शब्द का प्रयोग अधिकांशतः सॉफ्टवेयर की संकल्पना को बनाने, तैयार करने, संचालित करने, प्रारम्भ करने और अंततः संशोधित करने में सम्मिलित सभी गतिविधियों को संदर्भित करने के लिए किया जाता है या अधिक विशेष रूप से सॉफ्टवेयर आवश्यकताओं के विनिर्देश के पश्चात और कंप्यूटर प्रोग्रामिंग से पहले की गतिविधि के रूप में एक शैलीबद्ध सॉफ्टवेयर इंजीनियरिंग प्रक्रिया में इसका प्रयोग किया जाता है।[2]
सॉफ़्टवेयर प्रारूप में सामान्यतः समस्या-समाधान और सॉफ़्टवेयर समाधान की योजना बनाना सम्मिलित होता है। इसमें निम्न-स्तरीय घटक और एल्गोरिथम प्रारूप और उच्च-स्तरीय, सॉफ़्टवेयर आर्किटेक्चर प्रारूप दोनों सम्मिलित हैं।
वलोकन
सॉफ़्टवेयर प्रारूप समस्याओं के एक या अधिक सेटों के लिए सॉफ़्टवेयर समाधानों की कल्पना करने और उन्हें परिभाषित करने की प्रक्रिया है। सॉफ़्टवेयर प्रारूप के मुख्य घटकों में से एक सॉफ़्टवेयर आवश्यकता विश्लेषण (SRA) है। एसआरए सॉफ्टवेयर डेवलपमेंट प्रोसेस का एक हिस्सा है जो सॉफ्टवेयर इंजीनियरिंग में उपयोग किए जाने वाले विनिर्देशों को सूचीबद्ध करता है।
यदि सॉफ़्टवेयर अर्ध-स्वचालित या उपयोगकर्ता केंद्रित प्रारूप है, तो सॉफ़्टवेयर प्रारूप में उन विशिष्टताओं को निर्धारित करने में सहायता के लिए स्टोरीबोर्ड प्रदान करने वाले उपयोगकर्ता अनुभव प्रारूप सम्मिलित हो सकते हैं। यदि सॉफ़्टवेयर पूरी तरह से स्वचालन (अर्थात् कोई उपयोगकर्ता (कंप्यूटिंग) या उपयोगकर्ता इंटरफ़ेस नहीं है) है, तो एक सॉफ़्टवेयर प्रारूप घटनाओं के नियोजित अनुक्रम का वर्णन करने वाले प्रवाह चार्ट या पाठ के समान सरल हो सकता है। यूनिफाइड मॉडलिंग लैंग्वेज और मौलिक मॉडलिंग अवधारणाएँ जैसी अर्ध-मानक विधियाँ भी हैं। किसी भी मामले में, योजना के कुछ दस्तावेज आमतौर पर डिजाइन के उत्पाद होते हैं। इसके अलावा, एक सॉफ्टवेयर प्रारूप प्लेटफ़ॉर्म-स्वतंत्र मॉडल | प्लेटफ़ॉर्म-स्वतंत्र या प्लेटफ़ॉर्म-विशिष्ट मॉडल | प्लेटफ़ॉर्म-विशिष्ट हो सकता है, जो प्रारूप के लिए उपयोग की जाने वाली तकनीक की उपलब्धता पर निर्भर करता है।
सॉफ़्टवेयर विश्लेषण और प्रारूप के बीच मुख्य अंतर यह है कि सॉफ़्टवेयर विश्लेषण के आउटपुट में हल करने के लिए छोटी समस्याएं होती हैं। इसके अतिरिक्त, विश्लेषण को अलग-अलग टीम के सदस्यों या समूहों में बहुत अलग तरीके से प्रारूप नहीं किया जाना चाहिए। इसके विपरीत, प्रारूप क्षमताओं पर केंद्रित है, और इस प्रकार एक ही समस्या के लिए कई प्रारूप मौजूद हो सकते हैं और मौजूद रहेंगे। पर्यावरण के आधार पर, प्रारूप अक्सर भिन्न होता है, चाहे वह विश्वसनीय सॉफ़्टवेयर ढांचे से बनाया गया हो या उपयुक्त डिजाइन पैटर्न्स के साथ कार्यान्वित किया गया हो। डिजाइन के उदाहरणों में ऑपरेशन सिस्टम, वेबपेज, मोबाइल डिवाइस या यहां तक कि नए क्लाउड कंप्यूटिंग प्रतिमान सम्मिलित हैं।
सॉफ्टवेयर डिजाइन एक प्रक्रिया और एक मॉडल दोनों है। प्रारूप प्रक्रिया चरणों का एक क्रम है जो प्रारूपर को निर्माण के लिए सॉफ़्टवेयर के सभी पहलुओं का वर्णन करने में सक्षम बनाती है। रचनात्मक कौशल, पिछला अनुभव, अच्छा सॉफ्टवेयर बनाने की भावना, और गुणवत्ता के प्रति समग्र प्रतिबद्धता एक सक्षम डिजाइन के लिए महत्वपूर्ण सफलता कारकों के उदाहरण हैं। हालांकि, यह ध्यान रखना महत्वपूर्ण है कि डिजाइन प्रक्रिया हमेशा एक सीधी प्रक्रिया नहीं होती है; डिजाइन मॉडल की तुलना एक घर के लिए आर्किटेक्ट की योजनाओं से की जा सकती है। यह उस चीज़ की समग्रता का प्रतिनिधित्व करने से शुरू होता है जिसे बनाया जाना है (उदाहरण के लिए, घर का त्रि-आयामी प्रतिपादन); धीरे-धीरे, प्रत्येक विवरण के निर्माण के लिए मार्गदर्शन प्रदान करने के लिए चीज़ को परिष्कृत किया जाता है (जैसे, नलसाजी बिछाना)। इसी प्रकार, सॉफ़्टवेयर के लिए बनाया गया प्रारूप मॉडल कंप्यूटर सॉफ़्टवेयर के विभिन्न प्रकार के विभिन्न दृश्य प्रदान करता है। मूल प्रारूप सिद्धांत सॉफ़्टवेयर इंजीनियर को प्रारूप प्रक्रिया को नेविगेट करने में सक्षम बनाते हैं। डेविस[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] लेकिन अधिक जटिल परियोजनाओं के लिए इसे व्यवहार्य नहीं माना जाएगा। प्रोग्रामिंग से पहले एक अलग डिजाइन बहु-विषयक डिजाइनरों और विषय-विशेषज्ञों (एसएमई) को सॉफ्टवेयर के लिए अत्यधिक कुशल प्रोग्रामर के साथ सहयोग करने की अनुमति देता है जो उपयोगी और तकनीकी रूप से ध्वनि दोनों है।
यह भी देखें
Wikimedia Commons has media related to Software design.
- पहलू-उन्मुख सॉफ्टवेयर विकास
- सूचना प्रौद्योगिकी में विज्ञान स्नातक
- प्रारूप
- डिजाइन तर्क
- ग्राफ़िक प्रारूप
- पारस्परिक प्रभाव वाली प्रारूप
- चिह्न डिजाइन
- सॉफ्टवेयर की रूपरेखा
- सॉफ्टवेयर विकास की रूपरेखा
- सॉफ्टवेयर इंजीनियरिंग की रूपरेखा
- खोज खोज-आधारित सॉफ्टवेयर इंजीनियरिंग
- सॉफ्टवेयर डिजाइन विवरण (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 | |||||||
