उपयोग केस आरेख में शामिल और विस्तारित करने के बीच क्या अंतर है?

377

उपयोग के मामले में includeऔर क्या अंतर है ?extend

uml use-case rational-unified-process

मैं स्कॉट अम्बलर की तुलना में यह बताने में बेहतर काम नहीं करूंगा कि उन्हें उपयोग के मामले में पुन: उपयोग के लिए कैसे इस्तेमाल किया जा सकता है और वे कैसे भिन्न होते हैं। इसलिए उसके बदले में, मैं उपयोग-केस मॉडल में पुन: उपयोग को पढ़ने का सुझाव दूंगा: & lt; & lt; विस्तार करें & gt; & lt; & lt; & lt; शामिल & gt; & gt ;, और वंशानुक्रम ।

— पास्कल थिवेंट

7

दरअसल, यह सवाल प्रोग्रामिंग से संबंधित है ...

— पास्कल थिवेंट

35

@closers: इस है एक वैध सवाल।

— हेंक होल्टरमैन 16

82

लघु के लिए -> शामिल = मैडिटरी, विस्तार = वैकल्पिक

— Thein

2

@ मैगामइंड 'विस्तार = वैकल्पिक' पूरी तरह से सच नहीं है ... इस उदाहरण लिंक को देखें

— शनाका जयलथ

262

एक्सटेंड का उपयोग तब किया जाता है जब एक उपयोग का मामला दूसरे प्रथम श्रेणी के उपयोग के मामले में कदम जोड़ता है।

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

शामिल कई उपयोग के मामलों में नकल कर रहे हैं कि उपयोग के मामले टुकड़े निकालने के लिए प्रयोग किया जाता है । सम्मिलित उपयोग का मामला अकेला नहीं चल सकता है और मूल उपयोग का मामला शामिल किए बिना पूरा नहीं होता है। इसे संयम से इस्तेमाल किया जाना चाहिए और केवल उन मामलों में जहां दोहराव महत्वपूर्ण है और डिजाइन द्वारा मौजूद है (बजाय संयोग के)।

उदाहरण के लिए, घटनाओं का प्रवाह जो प्रत्येक एटीएम उपयोग के मामले की शुरुआत में होता है (जब उपयोगकर्ता अपने एटीएम कार्ड में डालता है, अपना पिन दर्ज करता है, और मुख्य मेनू दिखाया जाता है) एक शामिल के लिए एक अच्छा उम्मीदवार होगा।

— डग नाइसेक
स्रोत

1

Include is used to extract use case fragments that are duplicated in multiple use cases, उन चरणों में क्या निकाला जाता है puts in their ATM card, enters their PIN, and is shown the main menu:? धन्यवाद

— ब्लेज़ तम

2

मुझे "लॉगिन" चरणों को शामिल करने के लिए एक अच्छा उम्मीदवार होने से असहमत होना चाहिए । वे चरण स्वयं के उपयोग के मामले का उपयोग करते हैं, और दूसरों से जुड़े होने के बाद की स्थितियों का उपयोग करना चाहिए - पूर्व-शर्तों।

— ब्रूनो ब्रेंट

22

@ ब्रूनो - कोई भी एटीएम मशीन में लॉग इन नहीं करेगा और बस खुश होकर चलेगा। कंक्रीट उपयोग के मामलों को अभिनेता को स्टैंड-अलोन मूल्य प्रदान करना चाहिए, अन्यथा वे केवल एक कार्यात्मक अपघटन में कार्य करते हैं।

— डग नाइसेक

@ ब्लेज़ - उन चरणों सहित लॉगिन प्रवाह के सभी भागों।

— डग नाइसेक

1

फीस एक यूसी कैसे हो सकती है? यह एक परिदृश्य में एक सशर्त प्रवाह है। यह एक अतिरिक्त मूल्य नहीं है। यह पूर्ण विपरीत है।

— qwerty_so

113

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

रिश्ते निर्भरता हैं

यूज़ एमएमएल के बाकी हिस्सों के साथ साझा करने के लिए, उपयोग के मामलों को शामिल करने और विस्तारित करने की कुंजी यह है कि, उपयोग के मामलों के बीच बिंदीदार तीर निर्भरता संबंध है। मैं उपयोग केस भूमिकाओं को संदर्भित करने के लिए 'आधार', 'शामिल' और 'विस्तार' का उपयोग करूँगा।

शामिल

एक बेस उपयोग मामला शामिल उपयोग मामले (ओं) पर निर्भर है; इसके बिना / उन्हें आधार उपयोग का मामला अधूरा है क्योंकि इसमें शामिल उपयोग मामला (एस) उस सहभागिता के उप-अनुक्रमों का प्रतिनिधित्व करता है जो कभी-कभी हो सकता है। (यह इस बारे में एक लोकप्रिय गलत धारणा के विपरीत है, जो आपके उपयोग का मामला हमेशा मुख्य परिदृश्य में होता है और कभी-कभी वैकल्पिक प्रवाह में होता है, बस इस पर निर्भर करता है कि आप अपने मुख्य परिदृश्य के रूप में क्या चुनते हैं? उपयोग के मामलों को आसानी से एक अलग प्रवाह का प्रतिनिधित्व करने के लिए पुनर्गठन किया जा सकता है; मुख्य परिदृश्य के रूप में और यह बात नहीं होनी चाहिए)।

एक तरह से निर्भरता के सर्वोत्तम अभ्यास में शामिल उपयोग मामले के बारे में (और संदर्भित) आधार उपयोग मामले को जानता है, लेकिन शामिल उपयोग मामले को आधार उपयोग मामले के बारे में 'पता' नहीं होना चाहिए। यही कारण है कि शामिल उपयोग के मामले हो सकते हैं: ए) आधार उपयोग के मामले अपने आप में और बी) कई आधार उपयोग मामलों द्वारा साझा किए जाते हैं।

विस्तार

मौजूदा उपयोग का मामला आधार उपयोग के मामले पर निर्भर है; यह शाब्दिक रूप से आधार उपयोग मामले द्वारा वर्णित व्यवहार का विस्तार करता है। आधार उपयोग का मामला पूरी तरह से कार्यात्मक उपयोग का मामला होना चाहिए, जो कि मौजूदा उपयोग मामले की अतिरिक्त कार्यक्षमता के बिना (निश्चित रूप से शामिल है)।

उपयोग के मामलों का विस्तार कई स्थितियों में किया जा सकता है:

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

विचार करने के लिए एक महत्वपूर्ण पहलू यह है कि मौजूदा उपयोग का मामला आधार उपयोग के मामले में कई स्थानों पर व्यवहार को 'सम्मिलित' कर सकता है, न कि केवल एक ही स्थान पर जैसा कि एक सम्मिलित उपयोग मामला करता है। इस कारण से, यह अत्यधिक संभावना नहीं है कि एक विस्तारित उपयोग का मामला एक से अधिक आधार उपयोग मामले का विस्तार करने के लिए उपयुक्त होगा।

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

सारांश

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

— जूलियन सी
स्रोत

3

बहुत अच्छा होगा अगर आप उस दावे के लिए कुछ संदर्भ जोड़ सकते हैं

— mibollma

1

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

— BigMac66

1

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

— डग नसेक

81

मैं अक्सर दो को याद करने के लिए इसका उपयोग करता हूं:

मेरा उपयोग मामला: मैं शहर जा रहा हूं।

शामिल हैं -> कार चलाएं

विस्तार -> पेट्रोल भरें

"पेट्रोल भरें" हर समय आवश्यक नहीं हो सकता है, लेकिन कार में छोड़े गए पेट्रोल की मात्रा के आधार पर वैकल्पिक रूप से आवश्यक हो सकता है। "ड्राइव द कार" एक शर्त है इसलिए मैं इसमें शामिल हूं।

— skipy
स्रोत

लेकिन, "पेट्रोल भरें" वास्तव में "शहर में जा रहा है" फैली हुई है, न कि दूसरे तरीके से, सही?

— पेट्र हुडेक

1

मुझे लगता है कि यह पेट्र के दृष्टिकोण पर निर्भर करता है। Imho "पेट्रोल भरें" वास्तव में कार के रूप में अच्छी तरह से ड्राइव का विस्तार कर सकता है।

— डैनियल पर्निक

2

शहर में जा रहे हैं और दो पूरी तरह से असंबंधित चीजों की तरह पेट्रोल ध्वनि भर रहे हैं जो केवल संयोग से हो सकता है।

— OdraEncoded

1

@OdraEncoded सही है। भरा पेट्रोल शहर जाने के लिए निर्भर नहीं है।

— nonybrighto

57

उपयोग मामलों का उपयोग दस्तावेज़ व्यवहार के लिए किया जाता है, उदाहरण के लिए इस प्रश्न का उत्तर दें।

एक व्यवहार दूसरे का विस्तार करता है यदि यह इसके अतिरिक्त है, लेकिन आवश्यक रूप से व्यवहार का हिस्सा नहीं है, उदाहरण के लिए उत्तर पर शोध करें।

यह भी ध्यान दें कि यदि आप प्रश्न का उत्तर देने का प्रयास नहीं कर रहे हैं तो उत्तर पर शोध करना बहुत मायने नहीं रखता है।

एक व्यवहार को दूसरे में शामिल किया जाता है यदि यह शामिल व्यवहार का हिस्सा है, जैसे स्टैक एक्सचेंज में लॉगिन करें।

स्पष्ट करने के लिए, उदाहरण केवल सच है यदि आप स्टैक ओवरफ्लो में यहां उत्तर देना चाहते हैं :)।

ये यूएमएल 2.5 पेज 671-672 से तकनीकी परिभाषाएं हैं ।

मुझे लगता है कि मुझे लगता है कि महत्वपूर्ण बिंदु हैं।

का विस्तार

एक्सटेंड एक विस्तारित यूसेजकैसे ( एक्सटेंडेड ) से एक एक्सटेंडेड कैशे ( एक्सटेंडकेस) से एक संबंध है जो यह निर्दिष्ट करता है कि फैली हुई यूसेज कैसैस में परिभाषित व्यवहार को कैसे और कब बढ़ाया गया है। विस्तार एक या एक से अधिक विशिष्ट विस्तार बिंदुओं पर होता है जो विस्तारित यूसेजकेस में परिभाषित होता है।

एक्सटेंड का उपयोग तब किया जाता है जब कुछ अतिरिक्त व्यवहार हो, जो संभवत: सशर्त रूप से एक या एक से अधिक उपयोग किए गए व्यवहार में जोड़े जाएं ।

विस्तारित USECASE विस्तार USECASE की स्वतंत्र रूप से परिभाषित किया गया है विस्तार USECASE की स्वतंत्र रूप से सार्थक है । दूसरी ओर, मौजूदा UseCase आमतौर पर ऐसे व्यवहार को परिभाषित करता है जो जरूरी नहीं कि स्वयं ही सार्थक हो । इसके बजाय, विस्तृत UseCase मॉड्यूलर व्यवहार वेतन वृद्धि का एक सेट परिभाषित करता है जो विशिष्ट शर्तों के साथ विस्तारित UseCase के निष्पादन को बढ़ाता है।

...

शामिल

शामिल दो UseCases के बीच एक DirectedRelationship है , यह दर्शाता है कि शामिल UseCase (जोड़) के व्यवहार में UseCase ( सहित सम्मिलित ) के व्यवहार में डाला गया है । यह एक तरह का NamedElement भी है, ताकि इसके अपने UseCase (निमज्जन) के संदर्भ में एक नाम हो सके। शामिल उपयोगकैस शामिल यूसेजकैस को निष्पादित करके उत्पादित परिवर्तनों पर निर्भर हो सकता है। शामिल UseCase पूरी तरह से वर्णित किया जा करने के लिए सहित UseCase के व्यवहार के लिए उपलब्ध होना चाहिए।

सम्मिलित संबंध का उपयोग तब किया जाता है जब दो या दो से अधिक UseCases के व्यवहार के सामान्य हिस्से होते हैं। इस आम हिस्से को तब एक अलग यूसेजकैसे में निकाला जाता है, जिसमें इस बेस वाले सभी बेसस को शामिल किया जाए । जैसा कि सम्‍मिलित संबंध का प्राथमिक उपयोग आम भागों के पुन: उपयोग के लिए है, जो एक आधार में छोड़ा गया है उसका उपयोग आमतौर पर अपने आप में पूर्ण नहीं होता है, लेकिन इसमें शामिल भागों पर निर्भर होना सार्थक होता है। यह संबंध की दिशा में परिलक्षित होता है, यह दर्शाता है कि आधार का उपयोग इसके अतिरिक्त पर निर्भर करता है, लेकिन इसके विपरीत नहीं।

...

— user1874524
स्रोत

23

मुझे लगता है कि इसमें शामिल करने और विस्तार करने के इरादे को समझना महत्वपूर्ण है:

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

यह मुझे इस प्रकार है:

शामिल करें = कार्यक्षमता का पुन : उपयोग (अर्थात शामिल कार्यक्षमता का उपयोग किया जाता है या सिस्टम में कहीं और इस्तेमाल किया जा सकता है)। इसलिए शामिल करें एक और उपयोग के मामले पर निर्भरता को दर्शाता है।

फैली = जोड़ (पुन: उपयोग नहीं) कार्यक्षमता और भी कोई वैकल्पिक कार्यक्षमता। इसलिए विस्तार दो चीजों में से एक को निरूपित कर सकता है:
1. उपयोग की स्थिति में नई सुविधाओं / क्षमताओं को जोड़ना (वैकल्पिक या नहीं)
2. कोई वैकल्पिक उपयोग के मामले (मौजूदा या नहीं)।

सारांश:
शामिल करें = कार्यक्षमता का पुन: उपयोग
= नई और / या वैकल्पिक कार्यक्षमता बढ़ाता है

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

— रिम्स जिमास्प
स्रोत

23

सरल करने के लिए,

के लिये include

जब आधार उपयोग के मामले को निष्पादित किया जाता है, तो शामिल उपयोग के मामले को कभी भी निष्पादित किया जाता है ।
आधार उपयोग के मामले को पूरा करने के लिए शामिल उपयोग के मामले को पूरा करने की आवश्यकता है।

एक विशिष्ट उदाहरण: लॉगिन और सत्यापित पासवर्ड के बीच

(लॉगिन) --- << शामिल हैं >> --- > (पासवर्ड सत्यापित करें)

सफलता के लिए लॉगिन प्रक्रिया के लिए, "पासवर्ड की पुष्टि करें" भी सफल होना चाहिए।

के लिये extend

जब आधार उपयोग के मामले को निष्पादित किया जाता है, तो विस्तारित उपयोग के मामले को केवल SOMETIMES निष्पादित किया जाता है
विस्तारित उपयोग का मामला तभी होगा जब कुछ मानदंड पूरे होंगे।

एक विशिष्ट उदाहरण: लॉगिन और शो त्रुटि संदेश के बीच (केवल कभी-कभी हुआ)

(लॉगिन) < --- << विस्तार >> --- (त्रुटि संदेश दिखाएं)

"त्रुटि संदेश दिखाएं" केवल कभी-कभी तब होता है जब लॉगिन प्रक्रिया विफल हो जाती है।

— bohbian
स्रोत

महान उदाहरण!

— पावेल ड्यूरोव

15

मुझे लगता है कि एमएसडीएन ने यहां जो समझाया है वह समझने में काफी आसान है।

[5] शामिल करें

उपयोग केस कॉल सहित या शामिल एक को आमंत्रित करता है। समावेशन का उपयोग यह दिखाने के लिए किया जाता है कि कैसे उपयोग का मामला छोटे चरणों में टूट जाता है। शामिल उपयोग मामला एरोहेड एंड पर है।

विस्तार [6]

इस बीच, एक विस्तारित उपयोग मामला विस्तारित उपयोग के मामले में लक्ष्य और कदम जोड़ता है। एक्सटेंशन केवल कुछ शर्तों के तहत काम करते हैं। विस्तारित उपयोग मामला एरोहेड एंड पर है।

— etic
स्रोत

आपको अपने उत्तर में कम से कम सार को उद्धृत करना चाहिए, न कि केवल उत्तर के लिए लिंक जोड़ना चाहिए। उस स्पष्टीकरण के शीर्ष पर जो संदर्भ आप देखते हैं वह वास्तव में अच्छा या सटीक नहीं है।

— गीर्ट बेलेकेंस

हाय @GeertBellekens, मैंने कुछ विस्तार को शामिल करने और विस्तार करने के बीच का अंतर समझाया है। IMHO आरेख ही स्पष्ट रूप से अंतर को बताता है और यही आरेख का उपयोग किया जाता है।

— एटिक

मुझे खुशी है कि आपने स्पष्टीकरण जोड़ा है, लेकिन मुझे अभी भी लगता है कि वे बहुत अच्छे या सटीक नहीं हैं। लोगों (यहां तक कि, या विशेष रूप से यदि वे एमएसडीएन के लिए लिखते हैं) को किसी चीज के लिए अपनी परिभाषाओं का आविष्कार करना बंद कर देना चाहिए जो पहले से ही एक मानक में परिभाषित है।

— गीर्ट बेलेकेंस

15

इसे स्पष्ट करते हैं। हम includeहर बार इस तथ्य को व्यक्त करना चाहते हैं कि एक मामले का अस्तित्व दूसरे के अस्तित्व पर निर्भर करता है।

उदाहरण:

उपयोगकर्ता अपने खाते में लॉग इन करने के बाद ही ऑनलाइन खरीदारी कर सकता है। दूसरे शब्दों में, वह तब तक कोई खरीदारी नहीं कर सकता जब तक कि वह अपने खाते में लॉग इन न कर ले।

सामग्री अपलोड होने से पहले उपयोगकर्ता साइट से डाउनलोड नहीं कर सकता है। यदि अपलोड नहीं किया गया है तो मैं डाउनलोड नहीं कर सकता।

क्या आपको यह समझ आया?

यह वातानुकूलित परिणाम के बारे में है। अगर मैं पहले ऐसा नहीं करता तो मैं ऐसा नहीं कर सकता ।

कम से कम, मुझे लगता है कि यह सही तरीका है जिसका हम उपयोग करते हैं Include। मुझे लगता है कि ऊपर से लैपटॉप और वारंटी के साथ उदाहरण सबसे ठोस है!

— एलिन आंद्रेई
स्रोत

1

विस्तार के बारे में?

— अल्फोकोकू

8

जब भी एक usecase के लिए आवश्यक शर्तें हैं, तो शामिल करने के लिए जाएं।

प्रमाणीकरण के लिए usecases, सबसे खराब स्थिति, या वैकल्पिक हैं तो विस्तार के लिए जाएं ..

उदाहरण: प्रवेश, नियुक्ति, टिकट आरक्षण चाहने के उपयोग के मामले में, आपको एक फार्म भरना होगा (पंजीकरण या फीडबैक फॉर्म) .... यह है कि यह भी शामिल है:

उदाहरण: आपके खाते में लॉगिन या साइन की पुष्टि करने वाले उपयोग के मामले में, आपका प्रमाणीकरण एक महत्वपूर्ण है। सबसे खराब स्थिति के बारे में सोचें। ठीक के साथ पुस्तक वापस करने के लिए..कभी आरक्षण नहीं मिल रहा है। बिल के बारे में बिल के बारे में जानें। जहां खेलने के लिए विस्तार आता है ...

अति प्रयोग को शामिल न करें और आरेख में विस्तार करें।

KEEP IT SIMPLE SILLY !!!

— विनय नारंग
स्रोत

6

यूएमएल संस्करण से भी सावधान रहें: यह अब एक लंबा समय हो गया है कि << >> का उपयोग करता है और << शामिल हैं >> द्वारा प्रतिस्थापित किया गया है << >> शामिल हैं, और << का विस्तार करता है >> << विस्तार >> और सामान्यीकरण ।
मेरे लिए यह अक्सर भ्रामक बिंदु है: उदाहरण के लिए स्टेफ़नी की पोस्ट और लिंक एक पुराने संस्करण के बारे में है:

किसी आइटम के लिए भुगतान करते समय, आप डिलीवरी पर भुगतान करना चुन सकते हैं, पेपाल का उपयोग कर भुगतान कर सकते हैं या कार्ड से भुगतान कर सकते हैं। ये "आइटम के लिए भुगतान" उपयोग के मामले के सभी विकल्प हैं। मैं अपनी पसंद के आधार पर इनमें से कोई भी विकल्प चुन सकता हूं।

वास्तव में "आइटम के लिए भुगतान" करने के लिए वास्तव में कोई विकल्प नहीं है! आजकल यूएमएल में, "पे ऑन डिलीवरी" एक विस्तार है, और "पेपल का उपयोग करके भुगतान" / "कार्ड द्वारा भुगतान" विशेषज्ञता हैं।

— सिल्वेन एच।
स्रोत

5

"शामिल करें" का उपयोग आधार उपयोग के मामले को बढ़ाने के लिए किया जाता है और यह एक आवश्यक शर्त है। इसमें शामिल उपयोग रन बेस को पूरा करने के लिए सफलतापूर्वक चलना चाहिए।

उदा। ईमेल सेवा के एक मामले पर विचार करें, यहाँ "लॉगिन" एक सम्मिलित उपयोग का मामला है जिसे ईमेल भेजने के लिए चलाया जाना चाहिए (बेस उपयोग का मामला)

दूसरी ओर "बहिष्कृत" वैकल्पिक उपयोग का मामला है जो आधार उपयोग के मामले को बढ़ाता है, आधार उपयोग का मामला मौजूदा उपयोग मामले को आमंत्रित / कॉल किए बिना भी सफलतापूर्वक चल सकता है।

उदाहरण के लिए "लैपटॉप खरीद" को आधार उपयोग के मामले के रूप में और "अतिरिक्त वारंटी" को मौजूदा उपयोग के मामले के रूप में देखें, यहां आप अतिरिक्त वारंटी न लेते हुए भी आधार उपयोग के मामले "लैपटॉप खरीद" को चला सकते हैं।

— सरबजीत
स्रोत

शायद "भुगतान" करने का मामला लैपटॉप खरीदने के लिए "शामिल" के रूप में काम करेगा? मैं यह कहता हूं कि उदाहरणों को एक ही परिदृश्य में एक साथ रखना अच्छा है। इसके अलावा, भुगतान करना कुछ ऐसा है जो कई अलग-अलग परिदृश्यों में उपयोग किया जाएगा, इसलिए ऐसा लगता है कि यह << के लिए उपयुक्त उम्मीदवार हो सकता है >>

— बैक्सक्स

Loginउपयोग का मामला नहीं है। यह एक पूर्व-शर्त को पूरा करने के लिए किया गया कार्य है।

— qwerty_so

5

यह महान स्पष्टीकरण के साथ महान संसाधन है: उपयोग के मामले में क्या शामिल है? उपयोग के मामले में विस्तार क्या है?

उपयोग के मामले का विस्तार आमतौर पर वैकल्पिक व्यवहार को परिभाषित करता है। यह प्रचलित उपयोग के मामले से स्वतंत्र है

दो या अधिक उपयोग मामलों के व्यवहार के सामान्य भागों को निकालने के लिए उपयोग किया जाता है

— गिरगिट
स्रोत

4

आरेख तत्व

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

— चारु कुमार
स्रोत

4

दोनों <include>और <extend>आधार वर्ग पर निर्भर हैं लेकिन <extend>वैकल्पिक यानी, यह आधार वर्ग से लेकिन उन की बात में ली गई है है यह या इस्तेमाल किया जा सकता नहीं किया जा सकता देखने।

<include>को आधार वर्ग में शामिल किया गया है अर्थात, <include>आपके उपयोग के मामले में उपयोग करना अनिवार्य है अन्यथा इसे अधूरा माना जाएगा।

उदाहरण के लिए:

एटीएम मशीन निर्माण में (उपयोगकर्ताओं के दृष्टिकोण के अनुसार):

1: निकासी, नकद जमा करना और खाते की जांच करना <extend>इसलिए आता है क्योंकि यह उपयोगकर्ता पर निर्भर करता है कि वह निकासी करे या जमा करे या चेक करे। ये वैकल्पिक चीजें हैं जो उपयोगकर्ता करता है।

2: "पिन दर्ज करें, कार्ड <include>रखना, कार्ड निकालना" ये वे चीजें हैं जो उपयोगकर्ता के पास होनी चाहिए, क्योंकि उन्हें कार्ड रखना चाहिए और सत्यापन के लिए एक वैध पिन दर्ज करना चाहिए।

— नव्या रेड्डी मिस्त्री
स्रोत

3

मैं दो को याद करने के लिए इसके उपयोग की अनुशंसा नहीं करता:

मेरा उपयोग मामला: मैं शहर जा रहा हूं।

शामिल हैं -> कार चलाएं

विस्तार -> पेट्रोल भरें

मैं आपको उपयोग करना चाहूंगा: मेरा उपयोग मामला: मैं शहर जा रहा हूं।

फैली -> कार चला रहा है

शामिल हैं -> पेट्रोल भरें

एएम ने सिखाया कि संबंध बढ़ाना एक आधार वर्ग के व्यवहार को जारी रखता है। बेस क्लास फंक्शनलिटीज होनी चाहिए। दूसरी ओर संबंध शामिल हैं, ऐसे कार्यों के समान हैं जिन्हें कहा जा सकता है। मई बोल्ड में है।

यह एगिलमोडेलिंग रियूज़ इन यूज-केस मॉडल्स से देखा जा सकता है

— सिखाने वाला
स्रोत

इसके बजाय "पेट्रोल भरना -> फैली हुई" को पढ़ना चाहिए क्योंकि आपका मुख्य यूसी "भरने वाले पेट्रोल" का विस्तार नहीं करता है। सिवाय आप एक पेट्रोल कंपनी के।

— qwerty_so

3

दोनों के बीच अंतर को यहां समझाया गया है। लेकिन जो नहीं समझाया गया है वह तथ्य यह है कि <<include>>और <<extend>>बस इसका उपयोग नहीं किया जाना चाहिए।

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

जब भी मैं उन संबंधों में से किसी एक का उपयोग करते हुए लोगों को देखता हूं तो यह तब होता है जब वे कार्यात्मक अपघटन करने की कोशिश करते हैं। और यह गलत है।

इसे सरल करने के लिए: यदि आप अपने बॉस को बिना किसी हिचकिचाहट के जवाब दे सकते हैं "मैंने किया है ..." तो "..." आपका उपयोग मामला है क्योंकि आपको इसे करने के लिए पैसा मिला है। (इससे यह भी स्पष्ट हो जाएगा कि "लॉगिन" उपयोग का मामला नहीं है।)

उस संबंध में, स्वयं उपयोग किए जाने वाले मामलों को शामिल करना या अन्य उपयोग के मामलों का विस्तार करना बहुत संभावना नहीं है। आखिरकार आप <<extend>>अपने सिस्टम की वैकल्पिकता दिखाने के लिए उपयोग कर सकते हैं , अर्थात कुछ लाइसेंस स्कीमा जो कुछ लाइसेंस के लिए उपयोग के मामलों को शामिल करने या उन्हें छोड़ने की अनुमति देता है। लेकिन और - बस उनसे बचें।

— qwerty_so
स्रोत

3

का विस्तार किया जाता है जब आप समझते हैं कि आपके उपयोग के मामले में बहुत ज्यादा जटिल है। तो आप अपने स्वयं के "विस्तार" मामलों में जटिल चरणों को निकालते हैं।

शामिल इस्तेमाल किया है जब आप दो उपयोग के मामलों में आम व्यवहार देख रहा है। तो आप एक अलग "अमूर्त" उपयोग के मामले में सामान्य व्यवहार को अमूर्त करते हैं।

(रेफरी: जेफरी एल। व्हाईट, लोनी डी। बेंटले, सिस्टम विश्लेषण और डिजाइन के तरीके, मैकग्रा-हिल / इरर्स, 2007)

— mrmashal
स्रोत

1

एक्सटेंड का उपयोग के मामले से कोई लेना-देना नहीं है जो कि बहुत जटिल है। यह दृष्टिकोण वास्तविक उपयोग के मामले के मॉडल के बजाय एक कार्यात्मक अपघटन का निर्माण करेगा।

— डग नाइसेक

1

मुझे लगता है कि सॉफ्टवेयर इंजीनियरिंग अवधारणाएं और सामान्य तौर पर, मानव विज्ञान के दृष्टिकोण वाली सभी चीजें बहुत अधिक राय आधारित हो जाती हैं। मैंने रेफरी शामिल किया है (पृष्ठ 248 देखें)। इस पर बहुत मुश्किल मत बनो यार :)

— मर्मशाला

3

शामिल संबंध एक उपयोग के मामले में एक और उपयोग के मामले के कदम शामिल करने के लिए अनुमति देता है।

उदाहरण के लिए, मान लें कि आपके पास एक अमेज़ॅन खाता है और आप किसी ऑर्डर पर जांच करना चाहते हैं, तो पहले अपने खाते में प्रवेश किए बिना आदेश पर जांच करना असंभव है। इसलिए घटनाओं का प्रवाह ऐसा होगा ...

विस्तार संबंध एक उपयोग के मामले के प्रवाह के एक अतिरिक्त कदम, आम तौर पर एक वैकल्पिक चरण है कि जोड़ने के लिए प्रयोग किया जाता है ...

कल्पना कीजिए कि हम अभी भी आपके अमेज़न खाते के बारे में बात कर रहे हैं। मान लें कि आधार मामला ऑर्डर है और विस्तार उपयोग का मामला अमेज़ॅन प्राइम है । उपयोगकर्ता केवल नियमित रूप से आइटम को ऑर्डर करने के लिए चुन सकता है, या, उपयोगकर्ता के पास अमेज़ॅन प्राइम का चयन करने का विकल्प है जो यह सुनिश्चित करता है कि उसका ऑर्डर उच्च लागत पर तेजी से पहुंचेगा।

हालांकि, ध्यान दें कि उपयोगकर्ता को अमेज़ॅन प्राइम का चयन करने की आवश्यकता नहीं है, यह केवल एक विकल्प है, वे इस उपयोग के मामले को अनदेखा करना चुन सकते हैं।

— buydadip
स्रोत

किस तरह का उपयोग मामला होना Amazon Primeचाहिए? इसमें एक क्रिया भी नहीं है।

— qwerty_so

0

मुझे आधार उपयोग मामले की एक आवश्यक शर्त / संगत के रूप में "शामिल" के बारे में सोचना पसंद है। इसका मतलब यह है कि बेस केस के उपयोग के मामले के बिना इसे पूरा नहीं माना जा सकता है। मैं एक ई-कॉमर्स वेबसाइट का उदाहरण दूंगा जो ग्राहकों को आइटम बेचती है। ऐसा कोई तरीका नहीं है कि आप किसी आइटम के लिए पहले उस आइटम का चयन किए बिना उसे कार्ट में डाल सकें। तात्पर्य यह है कि उपयोग मामले "वेतन के लिए आइटम" में "चयनित आइटम" शामिल है।

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

अधिक स्पष्टता और उपयोग के मामलों के नियमों के लिए, मेरा लेख यहां पढ़ें:

http://businessanalystlearnings.com/ba-techniques/2013/2/20/use-case-diagram-the-basics

— स्टेफनी फेमुइड
स्रोत

1

ढेर अतिप्रवाह में आपका स्वागत है! अपना उत्तर पोस्ट करने के लिए धन्यवाद! कृपया सेल्फ-प्रमोशन पर अक्सर पूछे जाने वाले प्रश्नों को ध्यान से पढ़ें । एक बुरा जवाब नहीं, वास्तव में; लेकिन बस इस बात से अवगत रहें कि स्व-प्रचारक पोस्ट के बारे में FAQ क्या कहता है।

— एंड्रयू नाई

आपके लिंक के नीचे यूसी आरेख सिर्फ एक विरोधी पैटर्न है। न तो खाते का उपयोग किया जाता है loginऔर न ही createमामलों का। दोनों कार्य हैं। इसलिए -1

— qwerty_so