एक उपयोग केस विवरण बताता है कि एक अभिनेता (actor) सिस्टम के साथ इंटरैक्ट करके कैसे एक लक्ष्य प्राप्त करता है। यह एक उपयोग केस डायग्राम को पूरा करता है:

• उपयोग केस डायग्राम:यह अभिनेताओं, सिस्टम की सीमा और संबंधों को दर्शाता है।

• उपयोग केस विवरण:यह विस्तृत व्यवहार, स्थितियों, नियमों और परिणामों को समझाता है।

एक डायग्राम नक्शा प्रदान करता है; विवरण रास्ता प्रदान करता है।

1. उपयोग केस क्या है?

एक उपयोग केस एक मूल्यवान लक्ष्य का प्रतिनिधित्व करता है जिसे एक बाहरी अभिनेता (actor) सिस्टम के माध्यम से प्राप्त करता है।

उदाहरण:

• ग्राहक ऑर्डर देता है

• कर्मचारी खर्च का दावा जमा करता है

• रोगी अपॉइंटमेंट शेड्यूल करता है

• प्रशासक एक उपयोगकर्ता खाता बनाता है

• ग्राहक पासवर्ड रीसेट करता है

एक अच्छा उपयोग केस होता है:

• लक्ष्य-केंद्रित

• एक अभिनेता के लिए मूल्यवान

• उपयोगकर्ता के दृष्टिकोण से वर्णित

• विशिष्ट स्क्रीन लेआउट से स्वतंत्र

• दृश्यमान सिस्टम व्यवहार पर केंद्रित

खराब और सुधरे हुए उपयोग केस नाम

एक छोटा क्रिया-संज्ञा वाक्यांश जैसे ” का उपयोग करेंखर्च दावा जमा करें, शिपिंग का पता लगाएं, या ऋण आवेदन को स्वीकृत करें.

2. मुख्य अवधारणाएं

2.1 अभिनेता

एक अभिनेता वह बाहरी भूमिका है जो सिस्टम के साथ बातचीत करती है।

एक अभिनेता हो सकता है:

• एक व्यक्ति

• एक संगठन

• कोई अन्य सॉफ्टवेयर सिस्टम

• एक हार्डवेयर डिवाइस

• एक निर्धारित या समय-आधारित ट्रिगर

उदाहरण:

• ग्राहक

• सहायता एजेंट

• गोदाम क्लर्क

• भुगतान गेटवे

• ईमेल सेवा

• प्रशासक

एक अभिनेता एक भूमिका, न कि अनिवार्य रूप से कोई विशिष्ट व्यक्ति। उदाहरण के लिए, “ग्राहक” आमतौर पर “जेन स्मिथ” से बेहतर होता है।

मुख्य और सहायक अभिनेता

वह मुख्य अभिनेताउद्देश्य प्राप्त करने के लिए उपयोग मामला शुरू करता है।

वह सहायक अभिनेताकार्यान्वयन के दौरान प्रणाली की सहायता करता है।

उदाहरण:

• मुख्य अभिनेता: ग्राहक

• सहायक अभिनेता: भुगतान गेटवे

• उपयोग मामला: ऑर्डर दें

ग्राहक ऑर्डर शुरू करता है, जबकि भुगतान गेटवे भुगतान की अनुमति देता है।

2.2 प्रणाली सीमा

प्रणाली सीमा परिभाषित करती है कि मॉडल की जा रही प्रणाली के भीतर क्या है।

एक ऑनलाइन स्टोर के लिए, सीमा में शामिल हो सकता है:

• उत्पाद देखें

• उत्पाद को कार्ट में जोड़ें

• ऑर्डर दें

• भुगतान करें

• ऑर्डर ट्रैक करें

निम्नलिखित सीमा के बाहर हैं:

• ग्राहक

• भुगतान गेटवे

• डिलीवरी कंपनी

• ईमेल प्रदाता

सीमा प्रणाली की जिम्मेदारी के बारे में भ्रम को रोकती है।

2.3 उपयोग मामला

एक उपयोग मामला एक पूर्ण अंतःक्रिया का वर्णन करना चाहिए जो एक अर्थपूर्ण परिणाम उत्पन्न करती है।

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

ऑर्डर दें:एक ग्राहक उत्पादों का चयन करता है, डिलीवरी की जानकारी प्रदान करता है, ऑर्डर के लिए भुगतान करता है और ऑर्डर पुष्टि प्राप्त करता है।

‘क्रेडिट कार्ड संख्या की जाँच करना’ एक सिस्टम फ़ंक्शन हो सकता है, लेकिन यह आमतौर पर एक स्वतंत्र उपयोगकर्ता लक्ष्य के लिए बहुत छोटा होता है। इसके बजाय यह इसका हिस्सा हो सकता है ऑर्डर दें या भुगतान करें.

2.4 पूर्व-शर्तें

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

उदाहरण:

• ग्राहक के पास सक्रिय खाता है।

• उत्पाद बिक्री के लिए उपलब्ध है।

• कर्मचारी की पहचान सत्यापित की गई है।

• अपॉइंटमेंट का समय स्लॉट मौजूद है।

• खरीदारी टोकरी में कम से कम एक वस्तु है।

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

खराब पूर्व-शर्त:

ग्राहक लॉग इन करता है।

बेहतर पूर्व-शर्त:

ग्राहक की पहचान सत्यापित की गई है।

2.5 पश्च-शर्तें

एक पश्च-शर्त बताती है कि उपयोग मामला समाप्त होने के बाद क्या सत्य है।

उदाहरण:

• ऑर्डर रिकॉर्ड किया गया है।

• भुगतान की अनुमति दी गई है।

• एक पुष्टि ईमेल भेजा जाता है।

• खर्च का दावा जमा किया गया है।

• उपयोगकर्ता खास को सक्रिय के रूप में चिह्नित किया गया है।

पश्च-स्थिति को परिणामों का वर्णन करना चाहिए, कार्यान्वयन की विस्तृत जानकारी नहीं।

खराब पश्च-स्थिति:

वह आदेश तालिका अपडेट की गई है।

बेहतर पश्च-स्थिति:

आदेश संग्रहित किया गया है और पूर्ति के लिए उपलब्ध है।

2.6 मुख्य सफलता परिदृश्य

मुख्य सफलता परिदृश्य, जिसे मूल प्रवाह या खुश रास्ता, सामान्य सफल बातचीत का वर्णन करता है।

प्रत्येक चरण का वर्णन होना चाहिए:

1. अभिनेता और प्रणाली के बीच की बातचीत

2. प्रणाली का प्रतिक्रिया

3. एक अर्थपूर्ण व्यावसायिक कार्रवाई

उदाहरण:

1. ग्राहक उत्पाद चुनता है।

2. प्रणाली वर्तमान कार्ट प्रदर्शित करता है।

3. ग्राहक डिलीवरी जानकारी दर्ज करता है।

4. प्रणाली डिलीवरी जानकारी की जाँच करता है।

5. ग्राहक आदेश जमा करता है।

6. प्रणाली भुगतान अनुमति का अनुरोध करता है।

7. भुगतान गेटवे भुगतान को अनुमति देता है।

8. प्रणाली आदेश को रिकॉर्ड करता है।

9. प्रणाली आदेश की पुष्टि प्रदर्शित करता है।

इंटरफ़ेस-विशिष्ट विवरणों से बचें, जब तक कि वे आवश्यकता के लिए आवश्यक न हों।

खराब चरण:

ग्राहक निचले-दाएं कोने में नीले बटन पर क्लिक करता है।

बेहतर चरण:

ग्राहक ऑर्डर जमा करता है।

2.7 वैकल्पिक प्रवाह

एक वैकल्पिक प्रवाह मुख्य परिदृश्य का एक वैध विविधता का वर्णन करता है।

उदाहरण:

• ग्राहक डिलीवरी के बजाय स्टोर पिकअप चुनता है।

• ग्राहक सहेजे गए भुगतान विधि का उपयोग करके भुगतान करता है।

• प्रशासक शर्तों के साथ दावे को स्वीकृति देता है।

• उपयोगकर्ता एक बार का उपयोग करने वाले कोड का उपयोग करके प्रमाणीकरण करता है।

वैकल्पिक प्रवाह मुख्य प्रवाह में फिर से जुड़ सकते हैं।

उदाहरण:

A1. ग्राहक सहेजे गए भुगतान विधि का उपयोग करता है
चरण 6 पर, ग्राहक एक सहेजे गए भुगतान विधि का चयन करता है। प्रणाली उस विधि का उपयोग करके अनुमति के लिए अनुरोध करती है, फिर चरण 7 पर जारी रखती है।

2.8 अपवाद प्रवाह

एक अपवाद प्रवाह एक असफल या असामान्य स्थिति का वर्णन करता है।

उदाहरण:

• भुगतान अस्वीकार कर दिया गया है।

• उत्पाद स्टॉक में नहीं है।

• प्रमाणीकरण विफल हो जाता है।

• बाहरी सेवा उपलब्ध नहीं है।

• आवश्यक डेटा अमान्य है।

एक अपवाद प्रवाह को समझाना चाहिए:

• समस्या कहाँ होती है

• प्रणाली क्या करती है

• अभिनेता क्या देखता है

• क्या उपयोग मामला समाप्त होता है या फिर से शुरू होता है

उदाहरण:

E1. भुगतान अस्वीकृत कर दिया गया है
चरण 7 पर, पेमेंट गेटवे लेन-देन को अस्वीकार कर देता है। सिस्टम कारण प्रदर्शित करता है, ऑर्डर को अदायदा के रूप में चिह्नित करता है, और ग्राहक को दूसरा भुगतान विधि चुनने की अनुमति देता है।

2.9 शामिल और विस्तारित संबंध

शामिल करें

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

उदाहरण:

• ऑर्डर स्थान करना शामिल है कुल गणना

• ऑर्डर स्थान करना शामिल है ग्राहक की पहचान सत्यापित करना

• नकद निकासी शामिल है PIN की जाँच करना

शामिल किया गया व्यवहार आवश्यक है।

ऑर्डर स्थान करना <<शामिल>> कुल गणना

विस्तार करें

का उपयोग करें विस्तार करें जब कोई वैकल्पिक या शर्त आधारित व्यवहार एक आधार उपयोग मामला पूरक करता है।

उदाहरण:

• ऑर्डर स्थान करना छूट कोड लागू करने द्वारा विस्तारित किया जा सकता है

• चेकआउट उपहार संदेश जोड़ने द्वारा विस्तारित किया जा सकता है

विस्तारित व्यवहार हमेशा निष्पादित नहीं होता है।

छूट कोड लागू करें <<विस्तार>> ऑर्डर स्थान करें

एक उपयोगी नियम:

• शामिल करें: “यह उपयोग मामले का हिस्सा होने के रूप में हमेशा होता है।”

• विस्तार करें: “यह कुछ स्थितियों के तहत हो सकता है।”

का उपयोग न करें शामिल करें और विस्तार करें केवल प्रत्येय प्रवाह को छोटे टुकड़ों में तोड़ने के लिए। अत्यधिक विघटन मॉडल को समझना कठ बना देता है।

2.10 सामान्यीकरण

सामान्यीकरण अभिनेताओं या उपयोग मामलों के बीच वंशावली को दर्शाता है।

उदाहरण:

• कर्मचारी एक सामान्य अभिनेता है।

• प्रबंधक एक विशेष अभिनेता है जो कर्मचारी के व्यवहार को विरासत में प्राप्त करता है।

प्रबंधक --|> कर्मचारी

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

3. मानक उपयोग मामला विवरण टेम्पलेट

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

उपयोग मामला आईडी:
उपयोग मामला नाम:
लक्ष्य:
परिसर:
स्तर:
प्रमुख अभिनेता:
सहायक अभिनेता:
हितधारक और हित:

ट्रिगर:

पूर्व शर्तें:

न्यूनतम गारंटी:

सफलता की गारंटी:

मुख्य सफलता परिदृश्य:
1.
2.
3.

वैकल्पिक प्रवाह:
A1.
A2.

अपवाद प्रवाह:
E1.
E2.

विशेष आवश्यकताएं:
- प्रदर्शन
- सुरक्षा
- उपयोगिता
- उपलब्धता
- अनुपालन

व्यापार नियम:

डेटा आवश्यकताएं:

आवृत्ति और मात्रा:

अनुमान:

खुले प्रश्न:

संबंधित उपयोग मामले:

क्षेत्रों की व्याख्या

4. उदाहरण: ऑर्डर दें

UC-001 — ऑर्डर दें

लक्ष्य:
एक ग्राहक को एक या अधिक उत्पाद खरीदने की अनुमति दें।

परिसर:
ऑनलाइन स्टोर

स्तर:
उपयोगकर्ता का उद्देश्य

प्रमुख अभिनेता:
ग्राहक

सहायक अभिनेता:

• भुगतान गेटवे

• इन्वेंट्री सेवा

• ईमेल सेवा

• डिलीवरी सेवा

हितधारक और हित:

• ग्राहक:उत्पादों को सफलतापूर्वक खरीदना चाहता है और पुष्टि प्राप्त करना चाहता है।

• दुकान:एक वैध ऑर्डर दर्ज करना और भुगतान वसूल करना चाहता है।

• गोदाम:सटीक पूर्ति जानकारी की आवश्यकता है।

• भुगतान गेटवे:एक वैध भुगतान अनुरोध की आवश्यकता है।

• डिलीवरी सेवा:एक पूर्ण डिलीवरी पते की आवश्यकता है।

ट्रिगर:
ग्राहक चेकआउट के लिए शॉपिंग कार्ट जमा करता है।

पूर्व शर्तें:

• ग्राहक के पास कार्ट में कम से कम एक वस्तु है।

• ऑर्डर के लिए उत्पाद उपलब्ध हैं।

• ग्राहक एक वैध डिलीवरी पता प्रदान करता है।

• सिस्टम भुगतान सेवा के साथ संचार कर सकता है।

न्यूनतम गारंटी:

• कोई अदायदा ऑर्डर पुष्टि के रूप में नहीं माना जाता है।

• यदि ऑर्डर पूरा नहीं किया जा सकता है, तो ग्राहक को सूचित किया जाएगा।

• यदि भुगतान विफल हो जाता है, तो आरक्षित इन्वेंट्री रिलीज कर दी जाती है।

सफलता की गारंटी:

• भुगतान की अनुमति दी गई है।

• ऑर्डर रिकॉर्ड किया गया है।

• इन्वेंटरी आरक्षित की गई है।

• ग्राहक को पुष्टि प्राप्त होती है।

• पूरण जानकारी गोदाम के लिए उपलब्ध करा दी गई है।

मुख्य सफलता परिदृश्य

1. ग्राहक शॉपिंग कार्ट की समीक्षा करता है।

2. सिस्टम उत्पादों, मात्राओं, कीमतों, करों, शिपिंग लागत और कुल राशि को प्रदर्शित करता है।

3. ग्राहक डिलीवरी जानकारी प्रदान करता है।

4. सिस्टम डिलीवरी जानकारी की सत्यापन करता है।

5. ग्राहक भुगतान विधि का चयन करता है।

6. ग्राहक ऑर्डर जमा करता है।

7. सिस्टम उत्पाद की उपलब्धता की जांच करता है।

8. सिस्टम पेमेंट गेटवे से भुगतान की अनुमति के लिए अनुरोध करता है।

9. पेमेंट गेटवे भुगतान की अनुमति देता है।

10. सिस्टम ऑर्डर बनाता है।

11. सिस्टम ऑर्डर किए गए उत्पादों को आरक्षित करता है।

12. सिस्टम ग्राहक को ऑर्डर पुष्टि भेजता है।

13. सिस्टम ऑर्डर नंबर और अनुमानित डिलीवरी तिथि प्रदर्शित करता है।

वैकल्पिक प्रवाह

A1. ग्राहक एक सहेजी हुई पता का उपयोग करता है

चरण 3 पर, ग्राहक एक पूर्व में सहेजे गए पते का चयन करता है। सिस्टम पते को प्रदर्शित करता है और चरण 4 पर जारी रखता है।

A2. ग्राहक एक सहेजी हुई भुगतान विधि का उपयोग करता है

चरण 5 पर, ग्राहक एक सहेजी हुई भुगतान विधि का चयन करता है। सिस्टम उस विधि का उपयोग करता है और चरण 6 पर जारी रखता है।

A3. ग्राहक स्टोर पिकअप चुनता है

चरण 3 पर, ग्राहक डिलीवरी के बजाय स्टोर पिकअप का चयन करता है। सिस्टम उपलब्ध स्टोर और पिकअप तिथियों को प्रदर्शित करता है, फिर चरण 5 पर जारी रखता है।

अपवाद प्रवाह

E1. उत्पाद उपलब्ध नहीं है

चरण 7 पर, सिस्टम निर्धारित करता है कि एक उत्पाद उपलब्ध नहीं है। सिस्टम उपलब्ध नहीं उत्पाद की पहचान करता है, कार्ट को अपडेट करता है, और ग्राहक से ऑर्डर की समीक्षा करने के लिए कहता है।

E2. भुगतान अस्वीकृत कर दिया गया है

चरण 9 पर, पेमेंट गेटवे भुगतान को अस्वीकृत कर देता है। सिस्टम ऑर्डर की पुष्टि नहीं करता, इन्वेंटरी आरक्षणों को रिलीज करता है, विफलता संदेश प्रदर्शित करता है, और ग्राहक को दूसरा भुगतान विधि चुनने की अनुमति देता है।

E3. पेमेंट गेटवे उपलब्ध नहीं है

चरण 8 पर, पेमेंट गेटवे निर्धारित टाइमआउट के भीतर प्रतिक्रिया नहीं देता। सिस्टम भुगतान प्रयास को लंबित (pending) के रूप में चिह्नित करता है, ग्राहक को सूचित करता है, और डुप्लिकेट ऑर्डर सबमिशन को रोकता है।

व्यापारिक नियम

• एक ऑर्डर में कम से कम एक उत्पाद होना चाहिए।

• उत्पाद की मात्रा शून्य से अधिक होनी चाहिए।

• जब उपलब्ध स्टॉक अपर्याप्त हो, तो उत्पाद का ऑर्डर नहीं दिया जा सकता।

• ऑर्डर की पुष्टि करने से पहले भुगतान की अनुमति होनी चाहिए।

• मूल्य और कर वर्तमान मूल्य निर्धारण नियमों का उपयोग करके गणना किए जाते हैं।

• एक ग्राहक केवल पूर्णता शुरू होने से पहले ही ऑर्डर रद्द कर सकता है।

विशेष आवश्यकताएं

• सामान्य लोड के तहत ऑर्डर सारांश दो सेकंड के भीतर प्रदर्शित होना चाहिए।

• भुगतान जानकारी को सादे पाठ (plain text) में संग्रहीत नहीं किया जाना चाहिए।

• डुप्लिकेट सबमिशन डुप्लिकेट ऑर्डर नहीं बना सकते।

• सिस्टम को भुगतान और ऑर्डर स्थिति में परिवर्तनों के लिए ऑडिट ट्रेल रिकॉर्ड करना चाहिए।

5. उपयोग मामलों के स्तर

उपयोग मामलों के विवरण विस्तार के विभिन्न स्तरों पर लिखे जा सकते हैं।

सारांश-स्तर का उपयोग मामला

एक सारांश उपयोग मामला एक व्यापक व्यापारिक प्रक्रिया का वर्णन करता है।

उदाहरण:

ग्राहक ऑर्डर पूर्ण करें

इसमें शामिल हो सकता है:

• ऑर्डर प्राप्त करें

• उत्पाद चुनें

• ऑर्डर पैक करें

• ऑर्डर भेजें

उपयोगकर्ता-लक्ष्य-स्तर का उपयोग मामला

यह आमतौर पर आवश्यकता विश्लेषण के लिए सबसे उपयोगी स्तर है।

उदाहरण:

ऑर्डर दें

यह एक ऐसा लक्ष्य वर्णित करता है जिसे एक प्राथमिक अभिनेता एक ही बैठक में प्राप्त कर सकता है।

उप-कार्य-स्तर का उपयोग मामला

यह एक छोटे, पुनः उपयोग योग्य सिस्टम व्यवहार का वर्णन करता है।

उदाहरण:

• ऑर्डर का कुल योग गणना करें

• भुगतान की जाँच करें

• बिल उत्पन्न करें

उप-कार्य-स्तर के उपयोग मामले तब उपयोगी होते हैं जब व्यवहार पुनः उपयोग किया जाता है या तकनीकी रूप से जटिल होता है, लेकिन उन्हें उपयोगकर्ता-लक्ष्य वाले उपयोग मामलों के स्थान पर नहीं होना चाहिए।

6. उच्च-गुणवत्ता वाले उपयोग मामलों का विवरण लिखना

अभिनेता-केंद्रित भाषा का उपयोग करें

अभिनेता के दृष्टिकोण से लिखें:

ग्राहक एक ऑर्डर जमा करता है।

कार्यान्वयन-केंद्रित शब्दावली से बचें:

ऑर्डर नियंत्रक ऑर्डर सेवा को कॉल करता है।

दूसरा भाग डिज़ाइन दस्तावेज़ीकरण में होना चाहिए, न कि व्यापारिक उपयोग मामले में।

प्रत्येक चरण को परमाणु (atomic) रखें

बहुत सारे कार्यों को मिलाकर न करें:

ग्राहक विवरण दर्ज करता है, भुगतान चुनता है, ऑर्डर की पुष्टि करता है और एक ईमेल प्राप्त करता है।

इसे अंतःक्रिया को अलग करके सुधारें:

1. ग्राहक डिलीवरी जानकारी दर्ज करता है।

2. सिस्टम जानकारी की जाँच करता है।

3. ग्राहक एक भुगतान विधि चुनता है।

4. ग्राहक ऑर्डर की पुष्टि करता है।

5. सिस्टम पुष्टि भेजता है।

प्रेक्षणीय व्यवहार का वर्णन करें

एक पाठक को यह निर्धारित करने में सक्षम होना चाहिए कि क्या आवश्यकता कार्यान्वित की गई है।

कमजोर:

सिस्टम अनुरोध को संसाधित करता है।

मजबूत:

सिस्टम अनुरोध की सत्यापन करता है, दावे को रिकॉर्ड करता है, इसे एक दावा संख्या आवंटित करता है, और सबमिशन स्थिति प्रदर्शित करता है।

अकाल यूआई डिज़ाइन से बचें

इसका उपयोग करें:

ग्राहक डिलीवरी जानकारी प्रदान करता है।

इसके बजाय:

ग्राहक पता को टेक्स्ट बॉक्स में दर्ज करता है और हरे रंग के ‘जारी रखें’ बटन पर क्लिक करता है।

दूसरा संस्करण अनावश्यक रूप से इंटरफ़ेस को सीमित करता है।

मुख्य प्रवाह को सफल रखें

मूल प्रवाह को संभावित हर त्रुटि से न भरें। त्रुटियों को अपवाद प्रवाह में रखें।

व्यापारिक नियमों को अलग से पहचानें

व्यापारिक नियम अक्सर कई उपयोग मामलों पर लागू होते हैं। उन्हें अलग रखने से दोहराए गए और असंगत पाठ को रोका जाता है।

विफलता व्यवहार को स्पष्ट करें

प्रत्येक महत्वपूर्ण विफलता के लिए, निर्दिष्ट करें:

• क्या डेटा सहेजा गया है

• क्या लेन-देन को रद्द किया गया है

• क्या अभिनेता पुनः प्रयास कर सकता है

• क्या प्रशासक को सूचित किया गया है

• क्या उपयोग मामला समाप्त होता है या पुनः शुरू होता है

7. आवश्यकताओं से उपयोग मामलों तक

एक व्यावहारिक कार्यप्रवाह है:

1. मॉडल किए जा रहे सिस्टम को पहचानें।

2. बाहरी अभिनेताओं की सूची बनाएं।

3. प्रश्न करें कि प्रत्येक अभिनेता क्या प्राप्त करना चाहता है।

4. प्रत्येक लक्ष्य को एक उपयोग मामला नाम में परिवर्तित करें।

5. सिस्टम की सीमा परिभाषित करें।

6. मुख्य सफलता परिदृश्य लिखें।

7. वैकल्पिक और अपवाद प्रवाह जोड़ें।

8. व्यापारिक नियम और विशेष आवश्यकताएं जोड़ें।

9. उपयोग मामला आरेख बनाएं।

10. हितधारकों के साथ मॉडल की समीक्षा करें।

11. उपयोग के मामलों को आवश्यकताओं, परीक्षणों और डिज़ाइन दस्तावेज़ों से जोड़ें।

अभिनेता-लक्ष्य विश्लेषण

एक उपयोगी प्रश्न है:

इस अभिनेता को सिस्टम से क्या व्यावसायिक परिणाम चाहिए?

8. उपयोग के मामलों का आरेख प्रतीक

सबसे सामान्य तत्व हैं:

• अभिनेता:बाहरी भूमिका

• उपयोग का मामला: सिस्टम क्षमता या एक्टर का लक्ष्य

• सिस्टम की सीमा:सिस्टम की सीमा

• संबंध:एक्टर किसी उपयोग मामले में भाग लेता है

• शामिल करें:आवश्यक पुनः उपयोग योग्य व्यवहार

• विस्तार करें:वैकल्पिक या शर्तवार व्यवहार

• सामान्यीकरण:विशिष्ट एक्टर या उपयोग मामले

एक उपयोग मामले का चित्र दिखाने का प्रयास नहीं करना चाहिए:

• हर कार्यप्रवाह चरण

• डेटाबेस तालिकाएं

• वर्ग विशेषताएं

• विस्तृत व्यापारिक नियम

• स्क्रीन लेआउट

• आंतरिक एल्गोरिदम

वे गतिविधि चित्रों, वर्ग चित्रों, अनुक्रम चित्रों या लिखित आवश्यकताओं में आते हैं।

9. PlantUML चित्र उदाहरण

निम्नलिखित उदाहरण मॉडल करता है ऑर्डर स्थान उपयोग मामले और संबंधित व्यवहार।

@startuml
left to right direction

skinparam packageStyle rectangle
skinparam shadowing false
skinparam usecase {
    BackgroundColor #F8FBFF
    BorderColor #2F5597
    ArrowColor #555555
}

actor Customer
actor "Payment Gateway" as Payment
actor "Inventory Service" as Inventory
actor "Email Service" as Email
actor "Delivery Service" as Delivery

rectangle "Online Store" {
    usecase "Browse Products" as Browse
    usecase "Manage Cart" as Cart
    usecase "Place Order" as PlaceOrder
    usecase "Calculate Order Total" as CalculateTotal
    usecase "Check Product Availability" as CheckStock
    usecase "Authorize Payment" as AuthorizePayment
    usecase "Reserve Inventory" as ReserveInventory
    usecase "Send Order Confirmation" as SendConfirmation
    usecase "Track Order" as TrackOrder
    usecase "Apply Discount Code" as ApplyDiscount
}

Customer --> Browse
Customer --> Cart
Customer --> PlaceOrder
Customer --> TrackOrder

Payment --> AuthorizePayment
Inventory --> CheckStock
Inventory --> ReserveInventory
Email --> SendConfirmation
Delivery --> TrackOrder

PlaceOrder ..> CalculateTotal : <<include>>
PlaceOrder ..> CheckStock : <<include>>
PlaceOrder ..> AuthorizePayment : <<include>>
PlaceOrder ..> ReserveInventory : <<include>>
PlaceOrder ..> SendConfirmation : <<include>>

ApplyDiscount ..> PlaceOrder : <<extend>>

@enduml

व्याख्या

• वह ग्राहक प्रारंभ करता है ऑर्डर दें.

• ऑर्डर दें हमेशा गणना, स्टॉक जांच, भुगतान प्राधिकरण, इन्वेंटरी आरक्षण और पुष्टि को शामिल करता है।

• डिस्काउंट कोड लागू करें वैकल्पिक है, इसलिए यह विस्तार करता है ऑर्डर दें.

• बाहरी सेवाएं विशिष्ट सिस्टम व्यवहारों में भाग लेती हैं।

• सिस्टम की सीमा है ऑनलाइन स्टोर आयत।

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

10. Visual Paradigm VPasCode में डायग्राम बनाना

VPasCode एक ब्राउज़र-आधारित टेक्स्ट-टू-डायग्राम प्लेटफॉर्म है जो PlantUML, Mermaid, Graphviz और अन्य डायग्राम प्रारूपों का समर्थन करता है। यह स्रोत संपादन और लाइव रेंडरिंग प्रदान करता है, जिससे कोड बदलने पर डायग्राम अपडेट होता रहता है।

मूल कार्यप्रवाह

1. VPasCode एडिटर खोलें।

2. एक नया PlantUML डायग्राम बनाएं।

3. PlantUML स्रोत पेस्ट करें।

4. पुष्टि करें कि एडिटर PlantUML सिंटैक्स को पहचानता है।

5. लाइव पूर्वावलोकन की समीक्षा करें।

6. स्रोत पैनल में अभिनेताओं, उपयोग के मामलों, संबंधों और स्टाइलिंग को संपादित करें।

7. रेंडर किए गए डायग्राम को निर्यात करें या कॉपी करें।

8. डायग्राम को परियोजना दस्तावेज़ीकरण में जोड़ें।

VPasCode PlantUML उपयोग के मामलों के डायग्राम का समर्थन करता है और ब्राउज़र में रियल-टाइम रेंडरिंग प्रदान करता है। यह PlantUML डायग्राम के लिए उदाहरण और स्टाइलिंग विकल्प भी प्रदान करता है।

AI-सहायित जनरेशन के लिए उदाहरण प्रॉम्प्ट

यदि आप AI डायग्राम-जनरेशन विशेषता का उपयोग कर रहे हैं, तो एक उपयोगी प्रॉम्प्ट है:

एक ऑनलाइन स्टोर के लिए एक PlantUML उपयोग के मामलों का डायग्राम बनाएं।

प्राथमिक अभिनेता:
- ग्राहक

सहायक अभिनेता:
- भुगतान गेटवे
- इन्वेंटरी सेवा
- ईमेल सेवा
- डिलीवरी सेवा

मुख्य उपयोग के मामले:
- उत्पाद ब्राउज़ करें
- कार्ट प्रबंधित करें
- ऑर्डर दें
- ऑर्डर ट्रैक करें

ऑर्डर देने में शामिल होना चाहिए:
- ऑर्डर कुल की गणना करें
- उत्पाद की उपलब्धता जांचें
- भुगतान को प्राधिकृत करें
- इन्वेंटरी आरक्षित करें
- ऑर्डर पुष्टि भेजें

डिस्काउंट कोड लागू करना ऑर्डर देने को विस्तारित करना चाहिए।

'Online Store' नामक एक सिस्टम सीमा का उपयोग करें।

जनरेट किए गए कोड को एक शुरुआती बिंदु के रूप में मानें। समीक्षा करें कि:

• अभिनेता वास्तव में बाहरी होते हैं

• उपयोग के मामले उपयोगकर्ता के लक्ष्यों को दर्शाते हैं

• शामिल करें और विस्तार करेंसही ढंग से उपयोग किए जाते हैं

• सिस्टम की सीमा सटीक है

• संबंध वास्तविक व्यवसायिक व्यवहार को दर्शाते हैं

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

11. PlantUML उपयोग के मामले आरेखों को बनाए रखना

अर्थपूर्ण उपनाम का उपयोग करें

उपनाम संबंधों को बनाए रखना आसान बनाते हैं:

usecase "Place Order" as PlaceOrder
Customer --> PlaceOrder

टिप्पणियां जोड़ें

' Core customer transaction
usecase "Place Order" as PlaceOrder

टिप्पणियां अन्य टीम सदस्यों को स्रोत को समझने और आरेख को बनाए रखने में मदद करती हैं।

आरेख को केंद्रित रखें

यदि एक आरेख में बहुत सारे उपयोग के मामले हैं:

• एक संदर्भ आरेख बनाएं

• व्यावसायिक क्षेत्र के आधार पर अलग-अलग आरेख बनाएं

• पैकेज समूहों का उपयोग करें

• दस्तावेज़ के माध्यम से संबंधित आरेखों को लिंक करें

• उच्चतम स्तर पर प्रत्येक उप-कार्य को दिखाने से बचें

सुसंगत नामकरण का उपयोग करें

एक रूढ़ि चुनें और इसे सुसंगत रूप से लागू करें:

• ऑर्डर दें

• ऑर्डर रद्द करें

• ऑर्डर ट्रैक करें

शैलियों को मिलाकर न करें, जैसे:

• ऑर्डर दें

• ऑर्डररद्दीकरण

• ट्रैकिंग_फ़ंक्शन

स्रोत को परियोजना के साथ संग्रहित करें

एक सामान्य रिपॉजिटरी संरचना कुछ इस प्रकार हो सकती है:

docs/
  use-cases/
    UC-001-place-order.md
    UC-002-track-order.md
  diagrams/
    online-store-use-cases.puml

इसे बनाए रखने से .pumlस्रोत को संस्करण नियंत्रण के अंतर्गत रखने से परिवर्तनों की समीक्षा और पुनरुत्पादन संभव हो जाता है।

12. अनुगमनीयता

एक परिपक्व आवश्यकता प्रक्रिया उपयोग मामलों को अन्य परियोजना आइटम से जोड़ती है।

ट्रेसिबिलिटी (प्राप्ति-पथ) उत्तर देने में मदद करती है:

• कौन से आवश्यकताएं कवर की गई हैं?

• कौन से उपयोग के मामले परीक्षण किए गए नहीं हैं?

• कौन से डिज़ाइन घटक एक व्यावसायिक लक्ष्य का समर्थन करते हैं?

• यदि कोई आवश्यकता बदलती है, तो क्या प्रभावित होता है?

13. सामान्य गलतियां

आंतरिक घटकों को एक्टर के रूप में मॉडल करना

यदि कोई डेटाबेस या आंतरिक सेवा सिस्टम की सीमा के भीतर है, तो वह आमतौर पर एक एक्टर नहीं होता है।

एक एक्टर को मॉडल किए जा रहे सिस्टम के बाहरी होना चाहिए।

स्क्रीनों को उपयोग के मामले के रूप में मानना

एक स्क्रीन एक उपयोगकर्ता-इंटरफ़ेस तत्व है, न कि आवश्यक रूप से एक उपयोगकर्ता लक्ष्य।

उपयोग करें:

खर्च दावा जमा करें

इसके बजाय:

खर्च दावा स्क्रीन

का उपयोग करकेincludeहर साझा चरण के लिए

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

का उपयोग करकेextendसामान्य चरणों के लिए

यदि कोई व्यवहार हमेशा होता है, तो उसे विस्तार के रूप में मॉडल नहीं किया जाना चाहिए।

कार्यान्वयन विवरण लिखना

इसके संदर्भों से बचें:

• नियंत्रक

• डेटाबेस तालिकाएं

• API एंडपॉइंट्स

• वर्ग

• आंतरिक विधियां

जब तक कि दस्तावेज़ विशेष रूप से तकनीकी डिज़ाइन न हो।

विफलता व्यवहार को छोड़ देना

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

उपयोग मामलों को बहुत व्यापक बनाना

“पूरे व्यवसाय का प्रबंधन करना” कार्यान्वयन योग्य नहीं है। व्यापक लक्ष्यों को उपयोगकर्ता-लक्ष्य-स्तर के उपयोग मामलों में विभाजित करें।

उपयोग मामलों को बहुत छोटा बनाना

“फ़ील्ड सत्यापित करें” और “संदेश प्रदर्शित करें” आमतौर पर सिस्टम चरण हैं, स्वतंत्र अभिनेता लक्ष्य नहीं।

14. समीक्षा चेकलिस्ट

किसी उपयोग मामला विवरण को स्वीकृत करने से पहले, सत्यापित करें:

परिसर और अभिनेता

• क्या सिस्टम की सीमा स्पष्ट है?

• क्या सभी बाहरी अभिनेताओं की पहचान की गई है?

• क्या अभिनेता व्यक्तिगत नामों के बजाय भूमिकाएं हैं?

• क्या सहायक सिस्टम केवल तभी मॉडल किए जाते हैं जब वे बाहरी होते हैं?

लक्ष्य की गुणवत्ता

• क्या उपयोग मामला प्राथमिक अभिनेता को मूल्य प्रदान करता है?

• क्या नाम एक स्पष्ट क्रिया-संज्ञा वाक्यांश है?

• क्या उपयोग मामला उचित स्तर पर है?

प्रवाह की गुणवत्ता

• क्या मुख्य परिदृश्य एक सफल परिणाम का वर्णन करता है?

• क्या प्रत्येक चरण परमाणु और अवलोकनीय है?

• क्या वैकल्पिक पथ दस्तावेज़ीकृत हैं?

• क्या अपवाद पथ दस्तावेज़ीकृत हैं?

• क्या पुनर्प्राप्ति व्यवहार स्पष्ट है?

शर्तें और परिणाम

• क्या पूर्व-शर्तें परीक्षण योग्य हैं?

• क्या सफलता की गारंटी स्पष्ट है?

• क्या न्यूनतम गारंटी परिभाषित की गई है?

• क्या व्यापारिक नियम प्रक्रियात्मक चरणों से अलग किए गए हैं?

आरेख की गुणवत्ता

• क्या सभी उपयोग मामला सही सीमा के भीतर हैं?

• क्या अभिनेता संबंध अर्थपूर्ण हैं?

• क्या समावेश संबंध अनिवार्य हैं?

• क्या विस्तार संबंध वैकल्पिक या शर्तवार हैं?

• क्या आरेख अत्यधिक विवरण के बिना पठनीय है?

आवश्यकताओं की गुणवत्ता

• क्या प्रत्येक महत्वपूर्ण चरण का परीक्षण किया जा सकता है?

• क्या गैर-कार्यात्मक आवश्यकताएं शामिल हैं?

• क्या अनसुलझे प्रश्न रिकॉर्ड किए गए हैं?

• क्या उपयोग मामला आवश्यकताओं और परीक्षण मामलों से जुड़ा है?

15. अनुशंसित वितरण संरचना

एक पूर्ण परियोजना पैकेज के लिए, निम्नलिखित संरचना का उपयोग करें:

1. सिस्टम संदर्भ
2. अभिनेता सूची
3. उपयोग मामला आरेख
4. उपयोग मामला सूची
5. विस्तृत उपयोग मामला विवरण
6. व्यापारिक नियम
7. गैर-कार्यात्मक आवश्यकताएं
8. ट्रेसिबिलिटी मैट्रिक्स
9. खुले प्रश्न और मान्यताएं
10. PlantUML स्रोत फाइलें

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

संदर्भ

यह पोस्ट English और Français में भी उपलब्ध है।