2.12 सॉफ़्टवेयर मॉडल और विधियां

अवलोकन और प्रेरणा

एक सॉफ़्टवेयर मॉडल किसी सिस्टम का एक जानबूझकर किया गया सरलीकरण है, जो किसी विशिष्ट प्रश्न का उत्तर देने के लिए बनाया जाता है। एक विधि (method) सॉफ़्टवेयर बनाने का एक अनुशासित तरीका है, जिसमें रास्ते में उपयोग किए जाने वाले मॉडल भी शामिल हैं। साथ मिलकर वे एक Software Engineering Body of Knowledge (SWEBOK) ज्ञान क्षेत्र बनाते हैं, क्योंकि वे वे मानसिक उपकरण हैं जिनका उपयोग आप किसी सिस्टम को बनाने से पहले, बनाते समय, और बनाने के बाद उसके बारे में तर्क करने के लिए करते हैं। एक UML (Unified Modeling Language) क्लास डायग्राम, एक एंटिटी-रिलेशनशिप डायग्राम (ERD), एक स्टेट मशीन, एक औपचारिक विनिर्देश (formal specification), और एक फेंक-देने-योग्य प्रोटोटाइप (ये सभी मॉडल हैं। वॉटरफ़ॉल, प्रोटोटाइपिंग, औपचारिक विकास, और एजाइल) ये सभी विधियां हैं।

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

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

मुख्य सिद्धांत

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

सिफारिशें

एब्स्ट्रैक्शन, उद्देश्य, और स्थिरता के साथ मॉडल बनाएं

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

संरचनात्मक या व्यवहारिक मॉडल को प्रश्न के अनुसार चुनें

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

मॉडलों का विश्लेषण करें, केवल उन्हें बनाएं नहीं

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

डिफ़ॉल्ट के रूप में ह्यूरिस्टिक विधियां लागू करें

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

उच्च-परिणाम वाले कोरों के लिए औपचारिक विधियां सुरक्षित रखें

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

अनिश्चितता को दूर करने के लिए प्रोटोटाइपिंग का उपयोग करें

जब आवश्यकताएं या व्यवहार्यता स्पष्ट न हों, तो सीखने के लिए एक प्रोटोटाइप बनाएं, फिर जानबूझकर तय करें कि उसे विकसित करना है या त्यागना है। फेंक-देने-योग्य प्रोटोटाइप किसी प्रश्न को सस्ते में खोजते हैं और फिर हटा दिए जाते हैं। विकासशील (evolutionary) प्रोटोटाइप उत्पाद बन जाते हैं और उन्हें उत्पादन मानकों के अनुसार बनाया जाना चाहिए। क्लासिक विफलता यह है कि एक फेंक-देने-योग्य प्रोटोटाइप गलती से उत्पादन में खिसक जाए। इसलिए प्रोटोटाइप को बनाने से पहले उसके प्रकार का नाम तय करें।

विधि को जोखिम से मिलाएं, फ़ैशन से नहीं

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

समझौते: लाभ और हानि

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

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

अपनी टीम के साथ चर्चा करने के लिए प्रश्न

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

क्षेत्रीय दृष्टिकोण

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

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

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

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

उदाहरण

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

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

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

व्यावसायिक मामला: प्रेरणाएं, ROI, और TCO

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

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

एंटी-पैटर्न और नुकसान

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

परिपक्वता मॉडल

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

चर्चा के लिए विचार

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

मुख्य निष्कर्ष

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

संदर्भ और आगे पढ़ने के लिए

IEEE Computer Society, SWEBOK Guide (Software Engineering Body of Knowledge), Version 4.0, Software Engineering Models and Methods knowledge area
Martin Fowler, UML Distilled: A Brief Guide to the Standard Object Modeling Language
Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User Guide
Frederick P. Brooks, The Mythical Man-Month and No Silver Bullet: Essence and Accident in Software Engineering
Daniel Jackson, Software Abstractions: Logic, Language, and Analysis (the Alloy modeling language)
Leslie Lamport, Specifying Systems (TLA+)
Simon Brown, Software Architecture for Developers (the C4 model)
David Harel, Statecharts: A Visual Formalism for Complex Systems