केस स्टडी: एक फूड डिलीवरी प्लेटफॉर्म के लिए उपयोग केस डायग्राम

UML के साथ वास्तविक दुनिया के आवश्यकताओं का मॉडलिंग – एक व्यावहारिक मार्गदर्शिका

---

1. परिचय

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

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

---

2. सिस्टम अवलोकन

द फूड डिलीवरी प्लेटफॉर्म एक डिजिटल बाजार में जोड़ता है:

• ग्राहक (भोजन ऑर्डर करने वाले व्यक्ति),

• रेस्तरां भोजन के प्रदाता),

• ड्राइवर डिलीवरी कर्मचारी),

• बाहरी भुगतान गेटवे (लेनदेन का प्रबंधन करने वाले तीसरे पक्ष के प्रणाली).

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

PlantUML कोड:

@startuml
skinparam monochrome true
skinparam shadowing false

बाएं से दाएं दिशा

‘ सभी एक्टर्स को आयत के बाहर परिभाषित किया गया है
एक्टर ग्राहक
एक्टर “पंजीकृत ग्राहक” के रूप में RegCustomer
एक्टर “रेस्तरां कर्मचारी” के रूप में रेस्तरां
एक्टर ड्राइवर
एक्टर “भुगतान प्रोसेसर” के रूप में PaymentGW

आयत “खाद्य डिलीवरी प्लेटफॉर्म” {

(रेस्तरां ब्राउज़ करें)
(ऑर्डर दें)
(ऑर्डर का ट्रैक करें)
(मेनू प्रबंधित करें)
(ऑर्डर स्वीकार / तैयार करें)
(ऑर्डर डिलीवर करें)
(भुगतान प्रक्रिया करें)
(रिफंड जारी करें)
(प्रमो कोड लागू करें)
(वॉलेट का उपयोग करें)
(कार्ड भुगतान)
(डिजिटल वॉलेट भुगतान)

‘ संबंध – तीर सीमा को पार करते हैं
ग्राहक –> (रेस्तरां ब्राउज़ करें)
पंजीकृत ग्राहक –> (आदेश दें)
पंजीकृत ग्राहक –> (आदेश का ट्रैक करें)

रेस्तरां –> (मेनू प्रबंधित करें)
रेस्तरां –> (आदेश स्वीकार / तैयार करें)

ड्राइवर –> (आदेश डिलीवर करें)

भुगतान गेटवे –> (भुगतान प्रक्रिया)
भुगतान गेटवे –> (रिफंड जारी करें)

‘ शामिल करें
(आदेश दें) ..> (भुगतान प्रक्रिया) : <<शामिल करें>>

‘ विस्तारित करें
(आदेश दें) <.. (प्रमो कोड लागू करें) : <<विस्तारित करें>>
(भुगतान प्रक्रिया) <.. (वॉलेट का उपयोग करें) : <<विस्तारित करें>>

‘ सामान्यीकरण
(भुगतान प्रक्रिया) <|– (कार्ड भुगतान)
(भुगतान प्रक्रिया) <|– (डिजिटल वॉलेट भुगतान)
}

‘ अभिनेता सामान्यीकरण (बाहरी भी)
ग्राहक <|– पंजीकृत ग्राहक

PaymentGW के दाहिनी ओर नोट
बाहरी भुगतान गेटवे
(स्ट्राइप, पेपैल, एडियन, …)
नोट समाप्त

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

@enduml

✅ मुख्य अंतर्दृष्टि: आरेख मुख्य रूप से बाहरी अंतरक्रियाएँ — यह दिखाता है कि सिस्टम करता है अपने उपयोगकर्ताओं और सिस्टम के लिए, न कि इसके कार्यान्वयन के बारे में।

---

3. आरेख तत्व: व्यावहारिक अर्थ के साथ गहन अध्ययन

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

#	तत्व	प्रतीक	अर्थ और उद्देश्य	मॉडलिंग निर्णय / टिप्पणी
1	सिस्टम सीमा	आयत "फूड डिलीवरी प्लेटफॉर्म"	निर्धारित करता है परिसर मॉडल किए जा रहे सिस्टम का। सभी उपयोग केस अंदर इस सिस्टम का हिस्सा हैं।	नाम संक्षिप्त है लेकिन वर्णनात्मक है। उद्यम प्रासंगिकता में, लंबे नाम (जैसे “ग्राहक आदेश प्रबंधन सिस्टम”) का उपयोग किया जा सकता है।
2	प्राथमिक मानव अभिनेता	अभिनेता ग्राहक, अभिनेता ड्राइवर	प्रतिनिधित्व करता है बाहरी भूमिकाएँजो उपयोग केस की शुरुआत करते हैं या उनमें भाग लेते हैं।	नाम सरल और स्पष्ट होते हैं। अनावश्यक स्टीरियोटाइप्स जैसे बचाते हैं<<व्यक्ति>>बड़े मॉडल के लिए आवश्यक होने पर छोड़कर।
3	एलियास के साथ एक्टर	एक्टर "रेस्तरां स्टाफ" के रूप में रेस्तरां	एक्टर के नाम को जोड़ने में स्पष्टता के लिए लंबे और विवरणात्मक नाम को छोटा करने की अनुमति देता है।	जब एक्टर के नाम में स्पेस होते हैं या वे विस्तृत होते हैं तो बहुत प्रभावी होता है। गड़बड़ी कम करता है और पठनीयता में सुधार करता है।
4	बाहरी सिस्टम एक्टर	एक्टर "पेमेंट प्रोसेसर" के रूप में पेमेंटजीडब्ल्यू	मॉडल्सतीसरे पक्ष के सिस्टमप्लेटफॉर्म के साथ बातचीत करता है।	कोई स्टीरियोटाइप नहीं«सिस्टम»का उपयोग किया जाता है — हल्के डायग्राम में स्वीकार्य है। हालांकि, जोड़ने से«सिस्टम»जटिल सिस्टम में इरादे को स्पष्ट कर सकता है।
5	एक्टर जनरलाइजेशन	`ग्राहक <	— रजिस्टर्ड कस्टमर`	दर्शाता है कि एकपंजीकृत ग्राहकएक विशिष्ट रूप है एक केअतिथि ग्राहक.
6	सामान्य संबंध	ग्राहक --> (रेस्तरां का ब्राउज़ करें)	दर्शाता है कि एक्टर प्रारंभ करता है या में भाग लेता है उपयोग केस के।	ठोस रेखा = संचार। दिशा एक्टर से उपयोग केस की ओर स्पष्ट है (तीर के छोर की आवश्यकता नहीं है)।
7	«include» संबंध	(आदेश दें) ..> (भुगतान प्रक्रिया) : <<include>>	भुगतान प्रक्रिया है हमेशा आवश्यक है आदेश देते समय।	तीर का निर्देश शामिल करने वाले → शामिल. यह महत्वपूर्ण है: आदेश दें शामिल करता है भुगतान प्रक्रिया एक अनिवार्य चरण के रूप में।
8	«extend» संबंध	(आदेश दें) <.. (प्रमोशन कोड लागू करें) : <<extend>>	प्रमोशन कोड लागू करना है वैकल्पिक और कुछ निश्चित स्थितियों में ही होता है।	तीर का निर्देश विस्तार → आधार. मूल उपयोग केस (आदेश रखें) को विस्तारित किया जा सकता है शर्तों के आधार पर.
9	उपयोग केस सामान्यीकरण	`(भुगतान प्रक्रिया) <	— (कार्ड भुगतान)<br>(भुगतान प्रक्रिया) <	— (डिजिटल वॉलेट भुगतान)`
10	नोट	PaymentGW के दाहिनी ओर नोट (प्रमोशन कोड लागू करें) के नीचे नोट	प्रदान करता है संदर्भित स्पष्टीकरण कार्यान्वयन या व्यापार नियमों के बारे में।	नोट्स का उपयोग कम होता है लेकिन अत्यधिक मूल्यवान. वे गलत व्याख्या को रोकते हैं (उदाहरण के लिए, स्पष्ट करना कि PaymentGW बाहरी है)।
11	सीमा के बाहर अभिनेता	सभी अभिनेता घोषणाएँ आयत के पहले आती हैं	हाइलाइट करता है कि कोई अभिनेता प्रणाली का हिस्सा नहीं है — स्पष्ट चिंता का विभाजन।	दो मानक लेआउट में से एक। जब अभिनेता अधिक संख्या में हों या बाहरी हों तो प्राथमिकता दी जाती है।
12	आरेख दिशा	बाएं से दाएं दिशा	जब बाएं ओर कई अभिनेता हों तो लेआउट में सुधार करता है।	पठनीयता में सुधार करता है। 4–8 अभिनेताओं के साथ विशेष रूप से प्रभावी। विकल्प: कम अभिनेताओं के लिए ऊपर से नीचे का लेआउट।

---

4. मॉडलिंग निर्णयों और तर्क

✅ क्यों अभिनेता प्रणाली सीमा के बाहर हैं

• सर्वोत्तम प्रथा: अभिनेता भूमिकाओं का प्रतिनिधित्व करते हैंबाहरप्रणाली के बाहर।

• यह क्यों महत्वपूर्ण है: प्रणाली के घटकों और बाहरी तत्वों के बीच भ्रम को रोकता है।

• उदाहरण: चालकप्लेटफॉर्म का एक मॉड्यूल नहीं है — वे इसके साथ बातचीत करने वाली तीसरी पक्ष की भूमिका हैं।

📌 प्रो टिप: यदि सभी अभिनेता सीमा के भीतर होते, तो यह इंगित करता कि प्रणाली उन्हें शामिल करती है — जो भ्रमित करने वाला है।

---

✅ क्यों उपयोग करेंग्राहक <|-- निर्मित ग्राहकलिंक की दोहराव के बजाय

• सामान्यीकरण के बिना, आपको खींचना होगा:

  ग्राहक --> (रेस्तरां ब्राउज़ करें)
  निर्मित ग्राहक --> (रेस्तरां ब्राउज़ करें)
  निर्मित ग्राहक --> (आदेश दें)
  

• सामान्यीकरण के साथ, आपको केवल आवश्यकता होगी:

  ग्राहक <|-- निर्मित ग्राहक
  ग्राहक --> (रेस्तरां ब्राउज़ करें)
  निर्मित ग्राहक --> (आदेश दें)
  

• परिणाम: साफ, अधिक बनाए रखने योग्य आरेख।

📌 सर्वोत्तम अभ्यास: जब भी एक विशिष्ट अभिनेता एक अधिक सामान्य अभिनेता के सभी व्यवहारों को विरासत में प्राप्त करता है, अभिनेता सामान्यीकरण का उपयोग करें।

---

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

संबंध	उद्देश्य	दिशा	उदाहरण
<<शामिल करें>>	अनिवार्य उप-प्रवाह	से शामिल करते हुए → शामिल	आदेश दें करना चाहिए शामिल करें भुगतान प्रक्रिया
<<विस्तारित करें>>	वैकल्पिक विस्तार	से विस्तार → आधार	प्रमोशन कोड लागू करें विस्तारित करता है आदेश रखेंकेवल यदि कोड वैध है

❗ आम गलती: तीर की दिशा को उलटना। हमेशा याद रखें:

• शामिल करें: आधार ..> शामिल

• विस्तारित करें: विस्तार <.. आधार

---

✅ क्यों भुगतान प्रक्रियासामान्यीकरण है

• कार्ड भुगतान और डिजिटल वॉलेट भुगतान हैं विशिष्ट रूप के भुगतान प्रक्रिया.

• यह दिखाता है कि प्लेटफॉर्म का समर्थन करता है कई भुगतान विधियाँ, लेकिन वे सभी एक ही मुख्य प्रवाह का पालन करते हैं।

• सामान्यीकरण की अनुमति देता है साझा व्यवहार और भविष्य के विस्तार के लिए अनुकूलता.

📌 उपयोग केस: एक नए भुगतान विधि (उदाहरण के लिए, ऐपल पे) को जोड़ना केवल एक और सामान्यीकरण होगा भुगतान प्रक्रिया.

---

5. वास्तविक दुनिया की व्याख्या और प्रश्नों के उत्तर

यह आरेख केवल एक दृश्य सहायता नहीं है — यह महत्वपूर्ण व्यावसायिक और तकनीकी प्रश्नों के उत्तर देता है:

प्रश्न	आरेख से उत्तर
मुख्य उपयोगकर्ता कौन हैं?	ग्राहक, पंजीकृत ग्राहक, रेस्तरां के कर्मचारी, ड्राइवर, भुगतान गेटवे
अपंजीकृत उपयोगकर्ता आदेश दे सकते हैं?	❌ नहीं — केवल पंजीकृत ग्राहक कर सकता है आदेश दें. ग्राहक केवल कर सकता है रेस्तरां ब्राउज़ करें.
क्या भुगतान हमेशा आवश्यक है?	✅ हां — आदेश दें शामिल है भुगतान प्रक्रिया. अनिवार्य।
क्या ग्राहक प्रोमो कोड लागू कर सकते हैं?	✅ हां — लेकिन केवल वैकल्पिक रूप से के माध्यम से <<विस्तारित>>. केवल तभी जब एक वैध कोड दर्ज किया जाता है।
कौन से भुगतान विधियाँ समर्थित हैं?	कार्ड और डिजिटल वॉलेट (सामान्यीकरण के माध्यम से)। बाहरी प्रणाली वास्तविक प्रसंस्करण का निपटारा करती है।
भुगतान किसने संभालता है?	बाहरी भुगतान गेटवे — प्लेटफॉर्म का हिस्सा नहीं।
क्या रेस्तरां अपने मेनू का प्रबंधन कर सकते हैं?	✅ हां — रेस्तरां कार्यकर्ता के साथ बातचीत करता है मेनू प्रबंधित करें और आदेश स्वीकार / तैयार करें.

✅ व्यापार मूल्य: आरेख स्पष्ट रूप से संचारित करता है प्रणाली क्या करती है, कौन इसका उपयोग करता है, और कौन से व्यवहार अनिवार्य हैं बनाम वैकल्पिक.

---

6. सामान्य मॉडलिंग दिशानिर्देशों का प्रदर्शन

आरेख कई उदाहरण प्रस्तुत करता हैश्रेष्ठ अभ्यासयूएमएल उपयोग केस मॉडलिंग में:

दिशानिर्देश	इसके लागू करने का तरीका
लक्ष्य-केंद्रित उपयोग केस नामों का उपयोग करें	आदेश दें, आदेश का ट्रैक करें, प्रमोशन कोड लागू करें— सभी क्रिया से शुरू होते हैं और उपयोगकर्ता के लक्ष्य का वर्णन करते हैं।
आरेख पठनीय रखें	केवल10 उपयोग केसदिखाए गए हैं — अधिकांश व्यावसायिक क्षेत्रों के लिए आदर्श (5–12 की सिफारिश की गई है)।
एक्सटर्नल सिस्टम को एक्टर के रूप में	पेमेंटजीडब्ल्यूएक एक्टर के रूप में मॉडल किया गया है, उपयोग केस के रूप में नहीं। सही तरीके से चिंताओं को अलग करता है।
अस्पष्टता को स्पष्ट करने के लिए नोट्स का उपयोग करें	नोट्स स्पष्ट करते हैं किपेमेंटजीडब्ल्यूबाहरी है और प्रमोशन कोड वैकल्पिक है — गलत व्याख्या से बचने के लिए महत्वपूर्ण।
गुंजाइश कम करने के लिए एक्टर विशेषीकरण का उपयोग करें	`ग्राहक <
उपयोग करेंशामिल करेंऔरविस्तारित करें सही तरीके से	अनिवार्य और वैकल्पिक व्यवहार के बीच स्पष्ट अंतर।

📌 चेतावनी: कई आरेख गलत तरीके से उपयोग करते हैं <<extend>> का अर्थ “वैकल्पिक” के रूप में समझे बिना शर्ती प्रकृति एक्सटेंशन की। इस आरेख में उस त्रुटि से बचा गया है।

---

7. संभावित सुधार और समीक्षा

जबकि आरेख मजबूत है, यहाँ कुछ निर्माणात्मक सुझाव हैं सुधार के लिए:

🔧 1. स्पष्टता के लिए स्टीरियोटाइप जोड़ें

एक्टर "पेमेंट प्रोसेसर" को PaymentGW <<system>> के रूप में निर्दिष्ट करें

• क्यों: यह स्पष्ट करता है कि यह एक बाहरी प्रणाली है, मानव भूमिका नहीं।

• लाभ: अस्पष्टता को कम करता है, विशेष रूप से बड़े मॉडल में।

🔧 2. स्पष्ट करें प्रमोशन कोड लागू करें एक्सटेंशन की शर्त

वर्तमान में:

नोट (प्रमोशन कोड लागू करें) के नीचे
  वैकल्पिक – केवल तभी जब एक मान्य कोड दर्ज किया जाता है
अंत नोट

• बेहतर: एक शर्त नोटेशन या गार्ड इन द <<एक्सटेंड>> तीर:

(ऑर्डर रखें) <.. (प्रमो कोड लागू करें) : <<एक्सटेंड>> [वैध प्रमो कोड]

• क्यों: नोट की तुलना में अधिक सटीक — विस्तार को सीधे एक शर्त से जोड़ता है।

🔧 3. एक के लिए विचार करें ऑर्डर इतिहास देखें उपयोग केस

• वर्तमान में अनुपस्थित है, लेकिन ग्राहकों और रेस्तरां दोनों के लिए संभवतः महत्वपूर्ण है।

• एक के रूप में जोड़ा जा सकता है रजिस्टर्ड ग्राहक उपयोग केस।

🔧 4. संबंधित उपयोग केस को समूहित करें (वैकल्पिक)

बड़े आरेखों के लिए, उपयोग केस को पैकेज:

पैकेज "ऑर्डर प्रबंधन" {
    (ऑर्डर रखें)
    (ऑर्डर का ट्रैक करें)
    (प्रमो कोड लागू करें)
}
पैकेज "भुगतान" {
    (भुगतान प्रक्रिया)
    (वॉलेट का उपयोग करें)
    (कार्ड भुगतान)
    (डिजिटल वॉलेट भुगतान)
}

• लाभ: स्केलेबिलिटी और पठनीयता में सुधार करता है।

---

8. अगला क्या?

यह केस स्टडी दिखाती है कि कैसे एक अच्छी तरह से संरचित उपयोग केस आरेख जटिल व्यावसायिक तर्क को स्पष्ट और संक्षिप्त ढंग से कैप्चर कर सकता है। अपनी समझ को गहरा करने के लिए, यहां हैं सुझाए गए अगले चरण:

🔄 विकल्प 1: रेस्तरां केंद्रित दृष्टिकोण

उसी क्षेत्र का मॉडल उसके दृष्टिकोण से बनाएंरेस्तरां के दृष्टिकोण से:

• केंद्रित रहेंमेनू प्रबंधित करें, आदेश स्वीकारें / तैयार करें, आदेश देखें, स्थिति अद्यतन करें.

• दिखाएंरेस्तरांप्राथमिक कार्यकर्ता के रूप में।

• शामिल करेंग्राहकगौण कार्यकर्ता के रूप में (उदाहरण के लिएग्राहकआदेश भेजता है →रेस्तरांइसे प्राप्त करता है।)

✅ लाभ: विभिन्न प्रणाली लक्ष्यों और कार्यकर्ता भूमिकाओं को उजागर करता है।

🔄 विकल्प 2: अधिक विस्तार बिंदु जोड़ें

सुधारेंआदेश दें के साथ:

• कूपन लागू करें (यदि प्रोमो कोड अमान्य है → <<विस्तारित करें>> त्रुटि संदेश के साथ)

• विशेष निर्देश मांगें (वैकल्पिक)

• आदेश योजना बनाएं (भविष्य के डिलीवरी के लिए)

🔄 विकल्प 3: तुलना करें शामिल करें विरुद्ध विस्तारित करें उदाहरणों के साथ

उपयोग के मामले	<<शामिल करें>>	<<विस्तारित करें>>
आदेश दें → भुगतान प्रक्रिया	✅ अनिवार्य	❌ वैकल्पिक नहीं
आदेश दें → प्रोमो कोड लागू करें	❌ अनिवार्य नहीं	✅ शर्त आधारित
लॉगिन → पहचान की पुष्टि करें	✅ हमेशा आवश्यक	❌ लागू नहीं होता
चेक आउट करें → छूट लागू करें	✅ हमेशा	✅ केवल तभी जब छूट उपलब्ध हो

📌 नियम ऑफ थम्ब:

• उपयोग करें <<शामिल करें>> जब व्यवहार होना चाहिए.

• उपयोग करें <<विस्तारित करें>> जब व्यवहार हो सकता है कुछ निश्चित स्थितियों के तहत।

🔄 विकल्प 4: अनुक्रम या गतिविधि आरेखों में परिवर्तित करें

गहन विश्लेषण के लिए:

• अनुक्रम आरेख: प्रवाह को दिखाएं आदेश दें → भुगतान प्रक्रिया करें → आदेश डिलीवर करें एक्टर्स और सिस्टम के बीच संदेशों के साथ।

• गतिविधि आरेख: निर्णय बिंदुओं को मॉडल करें भुगतान प्रक्रिया (उदाहरण के लिए, कार्ड अस्वीकृत → पुनः प्रयास या वॉलेट में स्विच करें)।

---

9. निष्कर्ष

यह केस स्टडी दिखाता है कि एक अच्छी तरह से बनाया गया उपयोग केस आरेख केवल एक दृश्य चित्र नहीं है — यह एक रणनीतिक संचार उपकरण जो कि:

• सिस्टम के दायरे को स्पष्ट करता है,

• व्यापार नियमों को कैप्चर करता है,

• विकास का मार्गदर्शन करता है,

• गलतफहमियों को रोकता है।

द फूड डिलीवरी प्लेटफॉर्म आरेख एक मजबूत उदाहरण का:

• UML नोटेशन का सही उपयोग,

• ठोस मॉडलिंग निर्णय,

• चिंताओं का स्पष्ट अलगाव,

• नोट्स और सामान्यीकरण का प्रभावी उपयोग।

यहां दिखाए गए सिद्धांतों का पालन करके — लक्ष्य-केंद्रित नामकरण, सही उपयोग of शामिल करें/विस्तारित करें, एक्टर सामान्यीकरण, और नोट्स का रणनीतिक उपयोग — आप उपयोग केस आरेख बना सकते हैं जो दोनों हैं सटीक और कार्यान्वयन योग्य.

---

✅ अंतिम निष्कर्ष

सिद्धांत	यहाँ लागू किया गया?	यह क्यों महत्वपूर्ण है
लक्ष्य-केंद्रित उपयोग केस नामों का उपयोग करें	✅ हाँ	स्पष्टता और उपयोगकर्ता केंद्रितता में सुधार करता है
आरेख के आकार को प्रबंधन योग्य रखें	✅ हाँ (10 उपयोग केस)	संज्ञानात्मक ओवरलोड से बचाता है
एक्टर्स के रूप में बाहरी प्रणालियाँ	✅ हाँ	चिंताओं का सही विभाजन
संदर्भ के लिए नोट्स का उपयोग करें	✅ हाँ	गलत व्याख्या से बचाता है
आवृत्ति कम करने के लिए सामान्यीकरण का उपयोग करें	✅ हाँ	आरेख को स्केलेबल और रखरखाव योग्य बनाता है
सही<<शामिल करें>> और <<विस्तारित करें>> दिशा	✅ हां	सही व्यवहार मॉडलिंग सुनिश्चित करता है

---