वस्तु-उन्मुख विश्लेषण और प्रारुप

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

आधुनिक सॉफ्टवेयर इंजीनियरिंग में OOAD आमतौर पर पुनरावृत्तीय और वृद्धिशील तरीके से संचालित किया जाता है। OOAD गतिविधियों के आउटपुट क्रमशः विश्लेषण मॉडल (OOA के लिए) और डिज़ाइन मॉडल (OOD के लिए) हैं। इरादा यह है कि जोखिम और व्यावसायिक मूल्य जैसे प्रमुख कारकों द्वारा संचालित इन्हें लगातार परिष्कृत और विकसित किया जाए।

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

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

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

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

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

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

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

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

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

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

वस्तु-उन्मुख मॉडलिंग
ऑब्जेक्ट-ओरिएंटेड मॉडलिंग (ओओएम) संपूर्ण सॉफ़्टवेयर विकास प्रक्रिया में ऑब्जेक्ट-ओरिएंटेड प्रतिमान का उपयोग करके मॉडलिंग अनुप्रयोगों, SysML और व्यावसायिक डोमेन के लिए एक सामान्य दृष्टिकोण है। OOM एक मुख्य तकनीक है जिसका उपयोग आधुनिक सॉफ्टवेयर इंजीनियरिंग में OOD और OOA दोनों गतिविधियों द्वारा बड़े पैमाने पर किया जाता है।

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

कुशल एवं प्रभावी संचार

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

उपयोगी एवं स्थिर अमूर्तन

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

यह भी देखें

 * एटलस परिवर्तन भाषा (एटीएल)
 * वर्ग-जिम्मेदारी-सहयोग कार्ड (सीआरसी कार्ड)
 * डोमेन विशिष्ट भाषा (डीएसएल)
 * डोमेन-संचालित डिज़ाइन
 * डोमेन-विशिष्ट मॉडलिंग (डीएसएम)
 * मेटा-ऑब्जेक्ट सुविधा (एमओएफ)
 * मेटामॉडलिंग
 * मॉडल-संचालित इंजीनियरिंग (एमडीई)
 * मॉडल-आधारित परीक्षण (एमबीटी)
 * ऑब्जेक्ट मॉडलिंग भाषा
 * वस्तु-उन्मुख मॉडलिंग
 * ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग
 * ऑब्जेक्ट-ओरिएंटेड यूजर इंटरफ़ेस
 * QVT
 * श्लेर-मेलोर
 * सॉफ्टवेयर विश्लेषण पैटर्न
 * कहानी-संचालित मॉडलिंग
 * एकीकृत मॉडलिंग भाषा (यूएमएल)
 * एक्सएमएल मेटाडेटा इंटरचेंज (XMI)

अग्रिम पठन

 * Grady Booch. "Object-oriented Analysis and Design with Applications, 3rd edition":http://www.informit.com/store/product.aspx?isbn=020189551X Addison-Wesley 2007.
 * Rebecca Wirfs-Brock, Brian Wilkerson, Lauren Wiener. Designing Object Oriented Software. Prentice Hall, 1990. [A down-to-earth introduction to the object-oriented programming and design.]
 * A Theory of Object-Oriented Design: The building-blocks of OOD and notations for representing them (with focus on design patterns.)
 * Martin Fowler. Analysis Patterns: Reusable Object Models. Addison-Wesley, 1997. [An introduction to object-oriented analysis with conceptual models]
 * Bertrand Meyer. Object-oriented software construction. Prentice Hall, 1997
 * Craig Larman. Applying UML and Patterns – Introduction to OOA/D & Iterative Development. Prentice Hall PTR, 3rd ed. 2005.,mnnm,n,nnn
 * Setrag Khoshafian. Object Orientation.
 * Ulrich Norbisrath, Albert Zündorf, Ruben Jubeh. Story Driven Modeling. Amazon Createspace. p. 333., 2013. ISBN 9781483949253.

बाहरी संबंध

 * Article Object-Oriented Analysis and Design with UML and RUP an overview (also about CRC cards).
 * Applying UML – Object Oriented Analysis & Design tutorial
 * OOAD & UML Resource website and Forums – Object Oriented Analysis & Design with UML.
 * Software Requirement Analysis using UML article by Dhiraj Shetty.
 * Article Object-Oriented Analysis in the Real World