4 + 1 आर्किटेक्चरल व्यू मॉडल और UML के बीच मैपिंग

Question

मैं थोड़ा उलझन में हूं कि 4 + 1 आर्किटेक्चरल व्यू मॉडल मैप्स यूएमएल के लिए कैसे हैं।

विकिपीडिया निम्नलिखित मानचित्रण देता है:

• तार्किक दृश्य: कक्षा आरेख, संचार आरेख, अनुक्रम आरेख।
• विकास दृश्य: घटक आरेख, पैकेज आरेख
• प्रक्रिया दृश्य: गतिविधि आरेख
• भौतिक दृश्य: परिनियोजन आरेख
• परिदृश्य: उपयोग-केस आरेख

यूएमएल सीक्वेंस डायग्राम कंस्ट्रक्ट्स ऑफ़ द पेपर लाइफ़साइकल कॉन्सेप्ट में पेपर रोल निम्नलिखित मैपिंग देता है:

• तार्किक दृश्य (वर्ग आरेख (सीडी), ऑब्जेक्ट आरेख (OD), अनुक्रम आरेख (SD), सहयोग आरेख (COD), राज्य चार्ट आरेख (SCD), गतिविधि आरेख (AD)
• विकास दृश्य (पैकेज आरेख, घटक आरेख),
• प्रक्रिया दृश्य (उपयोग केस आरेख, सीडी, OD, SD, COD, SCD, AD),
• भौतिक दृश्य (परिनियोजन आरेख), और
• केस व्यू का उपयोग करें (केस डायग्राम, OD, SD, COD, SCD, AD का उपयोग करें) जो ऊपर वर्णित चार को जोड़ती है।

वेब पेज UML 4 + 1 दृश्य सामग्री निम्नलिखित मानचित्रण प्रस्तुत करती है:

अंत में, श्वेत पत्र यूएमएल 2 के साथ 4 + 1 व्यू आर्किटेक्चर को लागू करते हुए अभी तक एक और मानचित्रण देता है:

• लॉजिकल व्यू क्लास डायग्राम, ऑब्जेक्ट डायग्राम, स्टेट चार्ट और कंपोजिट स्ट्रक्चर
• प्रक्रिया दृश्य अनुक्रम आरेख, संचार आरेख, गतिविधि आरेख, समय आरेख, इंटरैक्शन अवलोकन आरेख
• विकास दृश्य घटक आरेख
• भौतिक दृश्य परिनियोजन आरेख
• केस व्यू यूज केस डायग्राम, एक्टिविटी डायग्राम का उपयोग करें

मुझे यकीन है कि आगे की खोज अन्य मानचित्रणों को भी प्रकट करेगी।

जबकि विभिन्न लोगों के पास आमतौर पर अलग-अलग दृष्टिकोण होते हैं, मैं यह नहीं देखता कि यहां ऐसा क्यों है। विशेष रूप से, प्रत्येक यूएमएल आरेख एक विशेष पहलू से सिस्टम का वर्णन करता है। इसलिए, उदाहरण के लिए, "अनुक्रम आरेख" को एक लेखक द्वारा प्रणाली के "तार्किक दृष्टिकोण" का वर्णन करने के रूप में क्यों माना जाता है, जबकि दूसरा लेखक इसे "प्रक्रिया दृश्य" के रूप में मानता है?

क्या आप कृपया मुझे भ्रम को स्पष्ट करने में मदद कर सकते हैं?

Answer 1

हालांकि मैं आम तौर पर बार्ट वैन इनगेन शेनॉ के जवाब से सहमत हूं , मुझे लगता है कि कुछ बिंदुओं को अतिरिक्त विस्तार की आवश्यकता है।

4 + 1 दृश्य मॉडल का लाभ यह है कि यह हितधारकों को उन सूचनाओं के प्रकार को मैप करता है जिनकी उन्हें आवश्यकता होती है, बिना विशिष्ट मॉडलिंग नोटेशन के उपयोग की आवश्यकता होती है। जोर यह सुनिश्चित करने पर है कि सभी समूहों के पास सिस्टम को समझने और अपना काम जारी रखने की जानकारी हो।

सॉफ्टवेयर आर्किटेक्चर के 4 + 1 व्यू मॉडल को फिलिप क्रुकटेन के पेपर आर्किटेक्चरल ब्लूप्रिंट में वर्णित किया गया था - "4 + 1" सॉफ्टवेयर आर्किटैक्चर का मॉडल जो मूल रूप से IEEE सॉफ्टवेयर (नवंबर 1995) में प्रकाशित हुआ था। यह प्रकाशन UML के लिए विशिष्ट संदर्भ नहीं बनाता है। वास्तव में, पेपर तार्किक दृष्टिकोण के लिए बूच नोटेशन का उपयोग करता है , प्रोसेस व्यू और डेवलपमेंट व्यू के लिए बूच नोटेशन को एक्सटेंशन करता है, भौतिक दृश्य विकसित करने के "कई रूपों" का उपयोग करता है, और परिदृश्यों के लिए एक नया नोटेशन।

प्रत्येक विचार को विशेष प्रकार के आरेखों में मैप करने की कोशिश करने के बजाय, विचार करें कि प्रत्येक दृश्य के लक्षित दर्शक कौन हैं और उन्हें किस जानकारी की आवश्यकता है। यह जानते हुए कि, विभिन्न प्रकार के मॉडल देखें और कौन से (एस) आवश्यक जानकारी प्रदान करते हैं।

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

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

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

भौतिक दृश्य मुख्य रूप से सिस्टम डिजाइनरों और प्रशासकों के लिए है, जिन्हें सॉफ़्टवेयर के भौतिक स्थानों, नोड्स, परिनियोजन और स्थापना, और स्केलेबिलिटी के बीच भौतिक कनेक्शन को समझने की आवश्यकता होती है।

अंत में, परिदृश्य आवश्यकताओं को पकड़ने में मदद करते हैं ताकि सभी हितधारक समझें कि सिस्टम का उपयोग करने का इरादा कैसे है।

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

Comments

The logical view is designed to address the end user's concerns about ensuring that all of their desired functionality is captured by the system. In an object-oriented system, this is often at the class level। क्या आपको पता नहीं है, कि अगर हम अंतिम उपयोगकर्ताओं के लिए कुछ करना चाहते हैं तो हमें कम से कम उनके साथ संवाद करना चाहिए और एक भाषा बोलनी चाहिए। अपने उपयोगकर्ताओं को अपने वर्ग आरेख दिखाने की कोशिश करें और आइए देखें कि वे क्या कहेंगे।

— पावेल

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

— थॉमस ओवेन्स

Answer 2

इसका कारण यह है कि आप 4 + 1 आर्किटेक्चरल मॉडल और विभिन्न यूएमएल आरेखों के विचारों के बीच एक-से-एक मैपिंग नहीं पा सकते हैं क्योंकि ऐसी मैपिंग मौजूद नहीं है।

उन सभी लेखकों ने अपने 'मैपिंग' के साथ जो बताने की कोशिश की है, वह यह है कि प्रत्येक दृश्य के लिए, यूएमएल आरेखों का एक अलग सेट है जो उस दृश्य में बताए गए जानकारी को बताने के लिए उपयोगी हो सकता है।

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

Answer 3

यद्यपि मैं थॉमस ओवेन्स के जवाब से सहमत हूं कि आपके अंतिम-उपयोगकर्ता की जरूरतों को पूरा करने के लिए दृष्टिकोण, एक बात जो उल्लेख करने में विफल रही है, यही कारण है कि क्रुचेन द्वारा "4 + 1 व्यू मॉडल आर्किटेक्चर" की मूल परिभाषा कोई भी नहीं बनाता है यूएमएल के लिए विशिष्ट संदर्भ है क्योंकि लेख 1995 में लिखा गया था (उत्तर राज्यों के रूप में), लेकिन यूएमएल को वास्तव में 1997 तक एक मानक के रूप में नहीं अपनाया गया था ।

लेख में बूच संकेतन के निरंतर उपयोग से पता चलता है कि प्रत्येक मॉडल के एक विशिष्ट यूएमएल आरेख से संबंधित विचार उपयुक्त हो सकते हैं, क्योंकि ग्रैडी बूच यूएमएल के विकास में शामिल लोगों में से एक था।

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

आशा है कि यह किसी और के लिए कुछ और चीजों को स्पष्ट करता है।

Answer 4

क्या आप अभी भी VCR का उपयोग करते हैं जो आपने 1995 में वापस खरीदा था। 4 + 1 तब लागू होता था, जब सॉफ्टवेयर प्रारंभिक अवस्था में होता था। लेकिन फिर भी, किसी ने भी 2 या 3 से अधिक "विचारों" का उपयोग नहीं किया। पिछले 20 वर्षों में सॉफ्टवेयर इंजीनियरिंग में बदलाव आया। आजकल, गुंजाइश / संदर्भ और वैचारिक और तार्किक और भौतिक और ... सभी विभेदित हैं। बहुत सारे COTS समाधानों को एकीकृत किया जाना है, और इसी तरह। आज, हम लैंडस्केप मैप्स, सर्विस अहसास और दर्जनों अन्य दृश्यों और दृष्टिकोणों के बारे में बात कर रहे हैं। इसे देखने का सबसे अच्छा तरीका ज़चमान की तरह एक सरल वर्गीकरण के माध्यम से है: 6 दृश्य और 6 दृष्टिकोण। उसे अपना शुरुआती बिंदु बनने दें। 6 विचार हैं: प्रासंगिक वैचारिक या व्यावसायिक तार्किक या प्रणाली भौतिक या प्रौद्योगिकी वितरण या कलाकृतियों का काम करने वाला उद्यम

6 दृष्टिकोण हैं: डेटा या क्या फ़ंक्शन या कैसे नेटवर्क या कहां लोग या कौन समय या कब प्रेरणा या क्यों

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

क्रचेन 4 + 1 संभवतः इन सभी जरूरतों को पूरा नहीं कर सकता था

Comments

यह उत्तर बहुत पक्षपाती है और मैं आपके तर्क से असहमत हूं कि क्रुचेन 4 + 1 "बहुत पुराना" क्यों है। 20 साल पहले 1999 था। सॉफ्टवेयर अपनी प्रारंभिक अवस्था में नहीं था; क्रुचेन अभी भी 4 + 1 की प्रासंगिकता के बारे में बात करता है, खासकर चुस्त वातावरण में। वास्तु विवरण के संबंध में IEEE मानकों में एक कारण और दृष्टिकोण है।

— ज़िमानो