न्यूनतम प्रभावी UML: सॉफ़्टवेयर सिस्टम के मॉडलिंग के लिए एक व्यावहारिक गाइड

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

1. उपयोग केस आरेख

2. गतिविधि आरेख

3. क्रम आरेख

4. वर्ग आरेख

5. घटक आरेख

6. वितरण आरेख

7. अवस्था-यंत्र आरेख

एक साथ, ये आरेख सिस्टम को पूरक दृष्टिकोणों से वर्णित करते हैं:

• लक्ष्य: उपयोगकर्ता और बाहरी सिस्टम को क्या चाहिए

• व्यवहार: कार्य सिस्टम के माध्यम से कैसे प्रवाहित होता है

• अंतःक्रिया: वस्तुएँ और सेवाएँ कैसे सहयोग करती हैं

• संरचना:कौन सी इकाइयाँ और संबंध मौजूद हैं

• वास्तुकला: प्रमुख सॉफ़्टवेयर भाग कैसे व्यवस्थित हैं

• संचालन: सिस्टम कहाँ चलता है

• जीवनचक्र: महत्वपूर्ण वस्तु समय के साथ कैसे बदलते हैं

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

1. ‘न्यूनतम प्रभावी UML’ का क्या अर्थ है

न्यूनतम प्रभावी UML चार सिद्धांतों पर आधारित एक मॉडलिंग रणनीति है:

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

• सबसे सरल पर्याकृत संकेतन का उपयोग करें:अनावश्यक प्रतीक, सजावट और विवरण से बचें।

• पारदर्शिता बनाए रखें:जहाँ व्यावहारिक हो, आवश्यकताओं को व्यवहार, संरचना, कोड, परीक्षण और विन्यास से जोड़ें।

• आरेखों को समझने योग्य रखें:एक आरेख जो सब कुछ शामिल करता है, अक्सर कुछ भी संदेश नहीं देता।

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

• कौन सिस्टम के साथ इंटरैक्ट करता है?

• सिस्टम को किन क्षमताओं को प्रदान करना होगा?

• कौन से चरण एक व्यावसायिक प्रक्रिया बनाते हैं?

• प्रत्येक क्रिया के लिए कौन सा वस्तु या सेवा जिम्मेदार है?

• किस डेटा और डोमेन अवधारणाओं को दर्शाया जाना चाहिए?

• उप-सिस्टम कैसे विभाजित किए गए हैं?

• एप्लिकेशन, डेटाबेस और बाहरी सेवाओं को कहाँ विन्यस्त किया गया है?

• एक महत्वपूर्ण इकाई अपने जीवन चक्र से कैसे गुजरती है?

यदि कोई आरेख इन प्रश्नों में से किसी एक का उत्तर देने में सहायता नहीं करता है, तो वह आवश्यक नहीं हो सकता है।

2. सात आरेखों का कोर

ये चित्र स्वतंत्र नहीं हैं। वे एक श्रृंखला बनाते हैं:

स्टेट-मशीन आरेख इस श्रृंखला में इस प्रकार प्रवेश करते हैं कि वे ऐसे वस्तुओं के जीवनचक्र का वर्णन करते हैं जिनके अर्थपूर्ण अवस्थाएँ होती हैं।

उदाहरण के लिए, एक ऑनलाइन ऑर्डर को निम्नलिखित रूप में दर्शाया जा सकता है:

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

• गतिविधि:कार्ट की जाँच करें, भुगतान की अनुमति दें, स्टॉक आरक्षित करें, ऑर्डर की पुष्टि करें

• क्रम:ग्राहक इंटरफ़ेस ऑर्डर सेवा, भुगतान सेवा और इन्वेंट्री सेवा को कॉल करता है

• वर्ग: ऑर्डर, ऑर्डर लाइन, भुगतान, और उत्पाद

• घटक:वेब एप्लिकेशन, ऑर्डर सेवा, भुगतान एडाप्टर, इन्वेंट्री सेवा

• वितरण:ब्राउज़र, एप्लिकेशन क्लस्टर, डेटाबेस, भुगतान प्रदाता

• स्टेट मशीन:ड्राफ्ट → भुगतान लंबित → भुगतान किया गया → शिप किया गया → वितरित किया गया

3. उपयोग मामला आरेख: सिस्टम लक्ष्य परिभाषित करना

एक उपयोग मामला आरेख सिस्टम को बाहर से प्रस्तुत करता है। यह उन अभिनेताओं की पहचान करता है जो सिस्टम के साथ बातचीत करते हैं और वे लक्ष्य जो वे प्राप्त करते हैं।

3.1 एक उपयोग मामला आरेख क्या रखता है

मुख्य तत्व हैं:

• सिस्टम सीमा:परिभाषित करता है कि मॉडल किए जा रहे सिस्टम के अंदर क्या है

• अभिनेता: व्यक्ति, संगठन, उपकरण या बाहरी प्रणालियाँ

• उपयोग के मामले: लक्ष्य या सेवाएँ जो प्रणाली प्रदान करती है

• संबंध: अभिनेताओं और उपयोग के मामलों के बीच संबंध

• शामिल संबंध: किसी अन्य उपयोग के मामले द्वारा आवश्यक पुन: उपयोग योग्य व्यवहार

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

उदाहरण:

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

अभिनेता ग्राहक
अभिनेता "भुगतान प्रदाता" को PaymentProvider के रूप में
अभिनेता "गोदाम प्रणाली" को Warehouse के रूप में

रेक्टेंगल "ऑनलाइन स्टोर" {
  उपयोग के मामले "उत्पाद देखें" को UC1 के रूप में
  उपयोग के मामले "ऑर्डर दें" को UC2 के रूप में
  उपयोग के मामले "भुगतान की अनुमति दें" को UC3 के रूप में
  उपयोग के मामले "ऑर्डर पूरा करें" को UC4 के रूप में
}

ग्राहक --> UC1
ग्राहक --> UC2
UC2 ..> UC3 : <<include>>
PaymentProvider --> UC3
Warehouse --> UC4
@enduml

3.2 अभिनेताओं को सही ढंग से पहचानें

एक अभिनेता अनिवार्य रूप से एक मानव भूमि नहीं है। यह वह कुछ भी है जो बाहरी रूप से प्रणाली के साथ बातचीत करता है।

संभावित अभिनेताओं में शामिल हैं:

• ग्राहक

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

• प्रशासक

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

• पहचान प्रदाता

• गोदाम प्रबंधन प्रणाली

• निर्धारित कार्य

• मोबाइल अनुप्रयोग

• IoT उपकरण

आंतरिक कार्यान्वयन विवरण के आधार पर अभिनेताओं का नाम न दें। “REST कंट्रोलर” आमतौर पर एक अभिनेता नहीं होता है। “साझेदार अनुप्रयोग” एक हो सकता है।

3.3 उपयोग के मामलों को लक्ष्यों के रूप में नाम दें

अच्छे उपयोग के मामले के नाम परिणामों का वर्णन करते हैं:

• खर्च रिपोर्ट जमा करें

• खरीद का अनुरोध स्वीकार करें

• नए रोगी का पंजीकरण करें

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

• पासवर्ड रीसेट करें

कमजोर नाम कार्यान्वयन तंत्रों का वर्णन करते हैं:

• API कॉल करें

• SQL क्वेरी चलाएं

• फॉर्म खोलें

• नियंत्रक को कॉल करें

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

एक अभिनेता प्रणाली के साथ क्या अर्थपूर्ण परिणाम प्राप्त करना चाहता है?

3.4 शामिल और विस्तारित कब करें

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

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

• “ऑर्डर दें” में “कुल गणना करें” शामिल है

• “खाता पंजीकृत करें” में “ईमेल सत्यापित करें” शामिल है

का उपयोग करें <<extend>>जब व्यवहार वैकल्पिक या शर्तवाला हो।

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

• “ऑर्डर दें” को “प्रमोशनल छूट लागू करें” द्वारा विस्तारित किया जा सकता है

• “साइन इन करें” को “बहु-कारक प्रमाणीकरण पूरा करें” द्वारा विस्तारित किया जा सकता है

केवल एक आरेख को अधिक जटिल दिखाने के लिए इन संबंधों का उपयोग न करें। अक्सर, एक छोटा लिखित परिदृश्य या गतिविधि आरेख अधिक स्पष्ट होता है।

3.5 उपयोग मामला आरेख क्या नहीं दिखाते हैं

उपयोग मामला आरेखों का उद्देश्य इनका वर्णन करना नहीं है:

• विस्तृत उपयोगकर्ता इंटरफेस लेआउट

• सटीक कार्यान्वयन वर्ग

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

• संदेशों का क्रम

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

• इंफ्रास्ट्रक्चर टोपोलॉजी

वे सीमा और लक्ष्य परिभाषित करते हैं। अन्य आरेख विस्तार प्रदान करते हैं।

4. गतिविधि आरेख: कार्यप्रवाह और प्रक्रियाओं का मॉडलिंग

गतिविधि आरेख दिखाते हैं कि कार्य कैसे प्रगति करता है। वे व्यापार प्रक्रियाओं, कार्यप्रवाहों, शाखा तर्क, समानांतर कार्य और अपवाद हैंडलिंग के लिए विशेष रूप से प्रभावी हैं।

4.1 मुख्य तत्व

गतिविधि आरेख आम तौर पर निम्नलिखित का उपयोग करते हैं:

• प्रारंभिक नोड

• क्रियाएं

• निर्णय नोड

• मर्ज नोड

• फर्क और जॉइन

• स्विमलेन

• अंतिम नोड

• गार्ड जैसे कि [अनुमोदित] या [अस्वीकृत]

उदाहरण:

@startuml
|ग्राहक|
start
:ऑर्डर जमा करें;

|ऑर्डर सेवा|
:ऑर्डर सत्यापित करें;

if (ऑर्डर वैध?) then (हाँ)
  :कुल गणना करें;

  fork
    |भुगतान सेवा|
    :भुगतान अधिकृत करें;
  fork again
    |इन्वेंट्री सेवा|
    :इन्वेंट्री आरक्षित करें;
  end fork

  |ऑर्डर सेवा|
  :ऑर्डर पुष्टि करें;
  stop
else (नहीं)
  :सत्यापन त्रुटियां लौटाएं;
  stop
endif
@enduml

4.2 जिम्मेदारी दिखाने के लिए स्विमलेन का उपयोग करें

स्विमलेन स्पष्ट करते हैं कि प्रत्येक क्रिया कौन सा भूमिका, सिस्टम या घटक निष्पादित करता है।

उपयोगी लेन निम्नलिखित का प्रतिनिधित्व कर सकते हैं:

• ग्राहक

• ग्राहक सेवा एजेंट

• ऑर्डर सेवा

• भुगतान प्रदाता

• गोदाम

• स्वचालित शेड्यूलर

स्विमलेन तब विशेष रूप से मूल्यवान होते हैं जब कोई प्रक्रिया संगठनात्मक या सिस्टम की सीमाओं को पार करती है।

4.3 निर्णय स्पष्ट रूप से मॉडल करें

एक निर्णय में अर्थपूर्ण गार्ड होने चाहिए:

[भुगतान स्वीकृत]
[भुगतान अस्वीकृत]

अस्पष्ट लेबल जैसे इनसे बचें:

[हाँ]
[नहीं]

जब तक कि निर्णय प्रश्न तुरंत स्पष्ट न हो।

4.4 जब महत्व हो तो समानांतरता दिखाएं

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

• भुगतान को स्वीकृति दी जा सकती है

• इन्वेंटरी को आरक्षित किया जा सकता है

• धोखाधड़ी जांच चलाई जा सकती है

हालाँकि, केवल तभी समानांतरता मॉडल करें जब यह समय, स्थिरता, विफलता प्रबंधन या सिस्टम डिजाइन को प्रभावित करती हो। केवल आरेख को अधिक जटिल बनाने के लिए समानांतर शाखाओं का उपयोग न करें।

4.5 गतिविधि आरेख और आवश्यकताएँ

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

• यदि स्वीकर्ता उपलब्ध नहीं है तो क्या होता है?

• क्या एक अनुरोध को अस्वीकार किया जा सकता है और पुनः प्रस्तुत किया जा सकता है?

• उत्तरण समय क्या है?

• क्या दो लोग एक साथ स्वीकृति दे सकते हैं?

• यदि डाउनस्ट्रीम सिस्टम उपलब्ध नहीं है तो क्या होता है?

यह कार्यान्वयन शुरू होने से पहले गतिविधि आरेखों को उपयोगी बनाता है।

5. अनुक्रम आरेख: समय के साथ सहयोग को समझाना

अनुक्रम आरेख दिखाते हैं कि भागीदार समय-क्रमबद्ध अंतःक्रिया में संदेश कैसे आदान-प्रदान करते हैं। वे महत्वपूर्ण परिदृश्यों को विस्तार से वर्णन करने के लिए आदर्श हैं।

5.1 मुख्य तत्व

एक अनुक्रम आरेख में आमतौर पर शामिल होते हैं:

• अभिनेता

• वस्तुएँ या सेवाएँ

• जीवन रेखाएँ

• संदेश

• प्रत्यावर्तन संदेश

• सक्रियता पट्टियाँ

• शर्तें

• लूप

• वैकल्पिक पथ

• असमकालिक संदेश

उदाहरण:

@startuml
actor ग्राहक
boundary "वेब एप" as वेब
control "ऑर्डर सेवा" as ऑर्डर
control "भुगतान सेवा" as भुगतान
database "ऑर्डर डीबी" as डीबी

ग्राहक -> वेब : ऑर्डर जमा करें
वेब -> ऑर्डर : createOrder(कार्ट)

ऑर्डर -> डीबी : save(ऑर्डर)
डीबी --> ऑर्डर : orderId

ऑर्डर -> भुगतान : authorize(राशि)

alt भुगतान स्वीकृत
  भुगतान --> ऑर्डर : स्वीकृत
  ऑर्डर -> डीबी : updateStatus(PAID)
  ऑर्डर --> वेब : पुष्टि
  वेब --> ग्राहक : पुष्टि प्रदर्शित करें
else भुगतान अस्वीकृत
  भुगतान --> ऑर्डर : अस्वीकृत
  ऑर्डर -> डीबी : updateStatus(PAYMENT_FAILED)
  ऑर्डर --> वेब : भुगतान त्रुटि
  वेब --> ग्राहक : त्रुटि प्रदर्शित करें
end
@enduml

5.2 परिदृश्यों को रणनीतिक रूप से चुनें

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

• व्यावसायिक रूप से महत्वपूर्ण

• तकनीकी रूप से जोखिमपूर्ण

• एकीकरण-प्रधान

• सुरक्षा-संवेदनशील

• लेनदेन-संबंधी

• समझने में कठिन

• संरचनात्मक समस्याओं को उजागर करने की संभावना

आम उदाहरण शामिल हैं:

• उपयोगकर्ता प्रमाणीकरण

• भुगतान प्रसंस्करण

• फ़ाइल अपलोड

• ऑर्डर जमा करना

• पासवर्ड रीसेट

• घटना प्रकाशन

• विफलता पुनर्प्राप्ति

• पृष्ठभूमि कार्य निष्पादन

5.3 समकालीन और असमकालीन अंतःक्रियाओं में अंतर करें

एक समकालीन कॉल का अर्थ है कि प्रेषक प्रतिक्रिया का प्रतीक्षा करता है। एक असमकालीन संदेश प्रेषक को जारी रखने की अनुमति देता है।

यह अंतर प्रभावित करता है:

• उपयोगकर्ता अनुभव

• लेन-देन की सीमाएँ

• त्रुटि प्रबंधन

• मौलिकता

• पुनः प्रयास व्यवहार

• प्रेक्षणीयता

विभिन्न संकेतन का सुसंगत रूप से उपयोग करें और महत्वपूर्ण असमकालीन व्यवहार को नोट या साथ में दिए गए पाठ में समझाएं।

5.4 विफलता पथों का मॉडल बनाएं

एक अनुक्रम आरेख जो केवल सफल पथ को दर्शाता है, वह प्रमुख डिज़ाइन जोखिमों को छिपा सकता है। उपयोग करें वैकल्पिक, विकल्प, और लूप खंडों का उपयोग करें:

• सत्यापन विफलता

• अनुमति विफलता

• समय समाप्ति

• पुनः प्रयास

• आंशिक विफलता

• दोहराया गया अनुरोध

• सेवा की अनुपलब्धता

• पुनर्पूर्ति या रोलबैक

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

@startuml
क्लाइंट -> API : अनुरोध जमा करें

API -> सेवा : अनुरोध प्रसंस्करण करें

यदि सेवा प्रतिक्रिया देती है
  सेवा --> API : परिणाम
  API --> क्लाइंट : सफलता
अन्यथा टाइमआउट
  API -> सेवा : अनुरोध पुनः प्रयास करें
  यदि पुनः प्रयास सफल होता है
    सेवा --> API : परिणाम
    API --> क्लाइंट : सफलता
  अन्यथा पुनः प्रयास विफल
    API --> क्लाइंट : अस्थायी विफलता
  अंत
अंत
@enduml

5.5 अत्यधिक विस्तृत क्रम चित्रों से बचें

जब एक क्रम चित्र में प्रत्येक आंतरिक विधि कॉल शामिल होता है, तो उसे बनाए रखना कठिन हो जाता है। अर्थपूर्ण जिम्मेदारियों और सीमाओं पर ध्यान दें:

• उपयोगकर्ता इंटरफ़ेस

• आवेदन सेवा

• डोमेन ऑब्जेक्ट

• भंडार

• बाहरी सेवा

• संदेश ब्रोकर

• डेटाबेस

विस्तृत कार्यान्वयन चित्र डिबगिंग के दौरान उपयोगी हो सकते हैं, लेकिन उन्हें प्राथमिक वास्तुकला दस्तावेज़ीकरण नहीं बनना चाहिए।

6. वर्ग चित्र: संरचना और डोमेन अवधारणाओं का वर्णन

वर्ग चित्र स्थैतिक संरचना को दर्शाते हैं। वे या तो का वर्णन कर सकते हैं:

• एक अवधारणात्मक डोमेन मॉडल

• एक डिजाइन-स्तर का ऑब्जेक्ट मॉडल

• एक कार्यान्वयन-उन्मुख वर्ग संरचना

ये अलग-अलग अमूर्तता के स्तर हैं और सावधानीपूर्वक नहीं मिलाने चाहिए।

6.1 अवधारणात्मक बनाम कार्यान्वयन वर्ग चित्र

एक अवधारणात्मक मॉडल में हो सकता है:

• ग्राहक

• ऑर्डर

• उत्पाद

• भुगतान

एक कार्यान्वयन मॉडल में हो सकता है:

• ऑर्डर नियंत्रक

• ऑर्डर आवेदन सेवा

• ऑर्डर भंडार

• भुगतान गेटवे अनुकूलक

दोनों मान्य हैं, लेकिन वे अलग-अलग प्रश्नों के उत्तर देते हैं।

6.2 मुख्य संबंध

सामान्य संबंधों में शामिल हैं:

• संबंध

• समूहीकरण

• संरचना

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

• निर्भरता

• वास्तविकीकरण

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

उदाहरण:

@startuml
class Customer {
  +id: CustomerId
  +name: String
  +email: EmailAddress
}

class Order {
  +id: OrderId
  +status: OrderStatus
  +total(): Money
  +submit()
}

class OrderLine {
  +quantity: int
  +unitPrice: Money
  +lineTotal(): Money
}

class Product {
  +sku: String
  +name: String
}

Customer "1" -- "0..*" Order : places
Order "1" *-- "1..*" OrderLine : contains
OrderLine "*" --> "1" Product : refers to
@enduml

6.3 बहुलता महत्वपूर्ण है

बहुलता प्रतिबंधों को व्यक्त करती है:

• 1 — ठीक एक

• 0..1 — वैकल्पिक

• * — कई

• 1..* — एक या अधिक

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

Customer "1" -- "0..*" Order

इसका अर्थ है कि प्रत्येक ऑर्डर एक ग्राहक से संबंधित होता है, जबकि एक ग्राहक के पास शून्य या अधिक ऑर्डर हो सकते हैं।

6.4 जिम्मेदारियों का मॉडल, केवल डेटा फ़ील्ड नहीं

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

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

Order.submit()
Order.cancel()
Order.calculateTotal()
Payment.authorize()

सटीक कार्रवाइयाँ डिज़ाइन दृष्टिकोण पर निर्भर करती हैं, लेकिन सिद्धांत सुसंगत है:

महत्वपूर्ण व्यावसायिक जिम्मेदारियों को उनके स्वामी अवधारणाओं के करीब रखें।

6.5 वर्ग आरेखों को डेटाबेस स्कीमा में बदलने से बचें

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

एक उपयोगी भेद है:

• डोमेन मॉडल:व्यावसायिक अवधारणाएं और नियम

• डिज़ाइन मॉडल:सॉफ़्टवेयर वर्ग और जिम्मेदारियां

• डेटा मॉडल:तालिकाएं, कुंजियां, सूचकांक और प्रतिबंध

ये संबंधित हो सकते हैं, लेकिन इन्हें भ्रमित नहीं किया जाना चाहिए।

7. घटक आरेख: वास्तुकला सीमाओं को दर्शाना

घटक आरेख किसी प्रणाली के प्रमुख प्रतिस्थापनीय या विन्यास योग्य भागों और उन इंटरफ़ेसों का वर्णन करते हैं जिनके माध्यम से वे परस्पर क्रिया करते हैं।

ये उत्तर देने के लिए उपयोगी हैं:

• प्रमुख उप-प्रणालियां क्या हैं?

• कौन सा घटक एक जिम्मेदारी का स्वामी है?

• प्रत्येक घटक क्या प्रदान करता है?

• प्रत्येक घटक क्या आवश्यकता रखता है?

• एकीकरण सीमाएं कहाँ हैं?

• कौन से निर्भरता स्थिर या जोखिम भरे हैं?

उदाहरण:

@startuml
component "Web Application" as Web
component "Order Service" as Order
component "Payment Adapter" as Payment
component "Inventory Service" as Inventory
database "Order Database" as DB
cloud "External Payment Provider" as Provider

Web --> Order : REST API
Order --> Payment : Payment interface
Order --> Inventory : Inventory API
Order --> DB : Persistence
Payment --> Provider : Provider API
@enduml

7.1 घटक आरेख पैकेज आरेख नहीं हैं

एक पैकेज आरेख मॉडल तत्वों को समूहित करता है, अक्सर संगठन के लिए। एक घटक आरेख उन वास्तुकला इकाइयों का वर्णन करता है जो कार्यक्षमता प्रदान और उपभोग करते हैं।

एक घटक हो सकता है:

• एक डिप्लॉय करने योग्य सेवा

• एक वेब एप्लिकेशन

• एक मोबाइल एप्लिकेशन

• एक लाइब्रेरी

• एक संदेश ब्रोकर

• एक बाहरी प्लेटफॉर्म

• एक डेटाबेस

• एक तृतीय-पक्ष एकीकरण

उचित स्तर वास्तुकला पर निर्भर करता है।

7.2 उन स्थानों पर इंटरफ़ेस दिखाएं जहाँ वे अनुबंधों को स्पष्ट करते हैं

इंटरफ़ेस निर्भरताओं को अधिक स्पष्ट बनाते हैं:

@startuml
interface PaymentGateway

component "Order Service" as Order
component "Payment Adapter" as Adapter

Order ..> PaymentGateway
Adapter - PaymentGateway
@enduml

यह संकेत देता है कि ऑर्डर सेवा किसी विशिष्ट प्रदाता के बजाय एक अभिन्नता पर निर्भर करती है।

7.3 वास्तुकला निर्णयों का समर्थन करने के लिए घटक आरेखों का उपयोग करें

एक घटक आरेख छोटे डिज़ाइन नोट्स के साथ संयुक्त होने पर अधिक मूल्यवान हो जाता है:

• यह सीमा क्यों मौजूद है?

• डेटा किसका है?

• क्या अंतःक्रिया समकालिक है या असमकालिक?

• जब निर्भरता विफल हो जाती है तो क्या होता है?

• क्या घटक स्वतंत्र रूप से डिप्लॉय किया जा सकता है?

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

• कौन सी संगति गारंटी मौजूद है?

आरेख को हर उत्तर को शामिल करने की आवश्यकता नहीं होनी चाहिए, लेकिन इसे महत्वपूर्ण उत्तरों की ओर ध्यान आकर्षित करना चाहिए।

8. डिप्लॉयमेंट आरेख: सॉफ़्टवेयर को इंफ्रास्ट्रक्चर से जोड़ना

डिप्लॉयमेंट आरेख उन भौतिक या आभासी वातावरण को दर्शाते हैं जहाँ सॉफ़्टवेयर आर्टिफैक्ट्स निष्पादित होते हैं।

वे उत्तर देने में मदद करते हैं:

• प्रत्येक अनुप्रयोग कहाँ चलता है?

• कौन से नोड संचार करते हैं?

• डेटाबेस कहाँ स्थित हैं?

• कौन से सेवाएँ बाहरी रूप से सुलभ हैं?

• कौन से नेटवर्क सीमाएँ मौजूद हैं?

• सिस्टम कैसे वितरित है?

• कौन से इंफ्रास्ट्रक्चर विकल्प विश्वसनीयता या प्रदर्शन को प्रभावित करते हैं?

उदाहरण:

@startuml
node "उपयोगकर्ता उपकरण" as Device {
  artifact "ब्राउज़र" as Browser
}

node "क्लाउड क्षेत्र" as Cloud {
  node "वेब स्तर" as WebTier {
    artifact "वेब अनुप्रयोग" as WebApp
  }

  node "अनुप्रयोग स्तर" as AppTier {
    artifact "ऑर्डर सेवा" as OrderSvc
    artifact "भुगतान एडाप्टर" as PaymentSvc
  }

  database "ऑर्डर डेटाबेस" as DB
}

cloud "भुगतान प्रदाता" as Provider

Browser --> WebApp : HTTPS
WebApp --> OrderSvc : HTTPS
OrderSvc --> DB : TLS
OrderSvc --> PaymentSvc
PaymentSvc --> Provider : HTTPS
@enduml

8.1 नोड, आर्टिफैक्ट और वातावरण में अंतर करें

• एक नोड एक निष्पादन वातावरण है, जैसे कि सर्वर, कंटेनर, उपकरण, वर्चुअल मशीन, या प्रबंधित प्लेटफॉर्म।

• एक आर्टिफैक्ट एक डिप्लॉय करने योग्य सॉफ़्टवेयर इकाई है, जैसे कि बाइनरी, कंटेनर इमेज, पैकेज, या अनुप्रयोग।

• एक वातावरण विकास, परीक्षण, स्टेजिंग, या उत्पादन का प्रतिनिधित्व कर सकता है।

8.2 संचालन रूप से महत्वपूर्ण विवरण शामिल करें

उद्देश्य के आधार पर, डिप्लॉयमेंट आरेख दिखा सकते हैं:

• लोड बालेंसर

• फ़ायरवॉल

• नेटवर्क क्षेत्र

• कंटेनर क्लस्टर

• उपलब्धता क्षेत्र

• डेटाबेस और प्रतिलिपियाँ

• कैश

• संदेश ब्रोकर

• वस्तु भंडारण

• बाहरी सेवाएं

• निगरानी और लॉगिंग प्रणालियां

ऐसी बुनियादी ढांचे की विवरण न जोड़ें जिनका दस्तावेज़ीकृत निर्णय पर कोई प्रभाव नहीं पड़ता।

8.3 जोखिम विश्लेषण के लिए विन्यास आरेखों का उपयोग करें

विन्यास मॉडलिंग निम्नलिखित को प्रकट कर सकती है:

• विफलता का एकल बिंदु

• एक खुला डेटाबेस

• एक अनुपस्थित नेटवर्क सीमा

• अत्यधिक क्षेत्र-विशिष्ट यातायात

• कोई विफलता-प्राथमिकता रणनीति वाला निर्भरता

• वातावरणों के बीच अपर्याप्त अलगाव

• एक अएन्क्रिप्टेड कनेक्शन

• एक अवास्तविक स्केलिंग मान्यता

9. अवस्था-मशीन आरेख: जीवनचक्रों का मॉडलिंग

अवस्था-मशीन आरेख बताते हैं कि एक इकाई अवस्थाओं के बीच गति करके घटनाओं का如何应对 करती है।

वे तब मूल्यवान होते हैं जब किसी वस्तु का व्यवहार उसके वर्तमान अवस्था पर मजबूती से निर्भर करता है।

सामान्य उदाहरण निम्नलिखित हैं:

• ऑर्डर

• भुगतान

• शिपमेंट

• सहायता टिकट

• उपयोगकर्ता खाता

• कार्यप्रवाह अनुरोध

• सदस्यता

• दस्तावेज़

• उपकरण

• कार्य निष्पादन

उदाहरण:

@startuml
[*] --> Draft

Draft --> PendingPayment : submit
PendingPayment --> Paid : payment approved
PendingPayment --> PaymentFailed : payment declined
PaymentFailed --> PendingPayment : retry payment
Paid --> Processing : begin fulfillment
Processing --> Shipped : dispatch
Shipped --> Delivered : confirm delivery
Paid --> Cancelled : cancel
Processing --> Cancelled : cancel if allowed
Delivered --> [*]
Cancelled --> [*]
@enduml

9.1 अवस्थाओं को सावधानी से परिभाषित करें

एक अवस्था एक अर्थपूर्ण स्थिति को दर्शानी चाहिए, न कि केवल एक क्रिया को।

अच्छी अवस्थाएँ:

• अनुमोदन के लिए लंबित

• अनुमोदित

• अस्वीकृत

• भुगतान विफल

• भेजा गया

कमजोर अवस्थाएँ:

• बटन पर क्लिक करना

• सेवा को कॉल करना

• विधि को चला रहा है

क्रियाएँ घटनाएँ या संक्रमण हैं। अवस्थाएँ ऐसी स्थितियाँ हैं जो बनी रहती हैं।

9.2 संक्रमण नियम शामिल करें

एक संक्रमण निम्नलिखित शामिल कर सकता है:

• घटना

• रक्षा शर्त

• क्रिया

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

अनुमोदन के लिए लंबित -- approve [manager authorized] / recordApproval --> Approved

इससे व्यापारिक नियम दृश्यमान और परीक्षण योग्य बन जाते हैं।

9.3 परीक्षण प्राप्त करने के लिए अवस्था मशीनों का उपयोग करें

प्रत्येक संक्रमण परीक्षण मामलों का सुझाव देता है:

• मान्य संक्रमण

• अमान्य संक्रमण

• गार्ड विफल

• पुनरावृत्त घटना

• समय सीमा समाप्त

• पुनः प्रयास

• रद्द करना

• पुनर्प्राप्ति

ऑर्डर जीवन चक्र के लिए, परीक्षण सत्यापित कर सकते हैं:

• ड्राफ्ट ऑर्डर जमा किया जा सकता है

• डिलीवर किया गया ऑर्डर रद्द नहीं किया जा सकता

• भुगतान विफलता पुनः प्रयास की अनुमति देती है

• रद्द किया गया ऑर्डर भुगतान की स्थिति में वापस नहीं आ सकता

10. सात आरेख एक साथ कैसे काम करते हैं

आरेखों को सात अलग-अलग चित्रों के बजाय एक सुसंगत मॉडल बनाना चाहिए।

एक “खर्च रिपोर्ट जमा करें” क्षमता पर विचार करें।

उपयोग मामला

• कर्मचारी खर्च रिपोर्ट जमा करता है

• प्रबंधक खर्च रिपोर्ट को स्वीकृत करता है

• वित्त अधिकारी प्रतिपूर्ति प्रसंस्करण करता है

गतिविधि

• खर्च दर्ज करें

• रसीदें संलग्न करें

• डेटा सत्यापित करें

• रिपोर्ट जमा करें

• प्रबंधक को रूट करें

• स्वीकृत करें या अस्वीकार करें

• वित्त को भेजें

क्रम

• कर्मचारी इंटरफ़ेस खर्च सेवा को कॉल करता है

• खर्च सेवा रिपोर्ट को सत्यापित करता है

• रसीद सेवा संलग्नक संग्रहीत करता है

• वर्कफ्लो सेवा प्रबंधक नियुक्त करती है

• सूचना सेवा अलर्ट भेजती है

वर्ग

• कर्मचारी

• खर्च रिपोर्ट

• खर्च आइटम

• रसीद

• अनुमोदन

• मुआवजा

घटक

• वेब अनुप्रयोग

• खर्च सेवा

• रसीद भंडारण

• वर्कफ्लो सेवा

• सूचना सेवा

• वित्त एकीकरण

डिप्लॉयमेंट

• ब्राउज़र

• वेब स्तर

• अनुप्रयोग क्लस्टर

• वस्तु भंडारण

• संबंधित डेटाबेस

• वित्त मंच

राज्य मशीन

मसौदा → जमा किया गया → समीक्षाधीन → अनुमोदित → मुआवजा दिया गया
                         ↓
                      अस्वीकृत

प्रत्येक चित्र एक अलग दृष्टिकोण जोड़ता है बिना अन्य सभी को दोहराए।

11. कौन से चित्र बनाने हैं, यह चुनना

एक व्यावहारिक चयन प्रक्रिया यह पूछना है कि टीम के पास किस प्रकार की अनिश्चितता है।

आपको प्रत्येक विशेषता के लिए प्रत्येक आरेख की आवश्यकता नहीं है।

एक हल्का निर्णय नियम

जब निम्नलिखित में से कम से कम एक सत्य हो, तो एक आरेख बनाएं:

• एकाधिक हितधारक आवश्यकता को अलग-अलग तरीके से व्याख्या करते हैं।

• एक प्रक्रिया में महत्वपूर्ण शाखा या समानांतर व्यवहार होता है।

• एक परिदृश्य कई सिस्टम सीमाओं को पार करता है।

• एक क्षेत्र वस्तु में गैर-नगण्य नियम होते हैं।

• एक वास्तुकला निर्णय को संचारित करने की आवश्यकता है।

• वितरण टोपोलॉजी विश्वसनीयता, सुरक्षा या प्रदर्शन को प्रभावित करती है।

• जीवनचक्र के नियमों को प्रसंग में समझाना कठिन होता है।

• आरेख को कार्यान्वयन, समीक्षा, परीक्षण या संचालन के लिए पुनः उपयोग किया जाएगा।

केवल इसलिए आरेख बनाने से बचें क्योंकि एक टेम्पलेट में एक की उम्मीद की गई है।

12. विस्तार के स्तर

एक मजबूत मॉडलिंग अभ्यास अमूर्तता के कई स्तरों का उपयोग करता है।

संदर्भ स्तर

यह सिस्टम और प्रमुख बाहरी कर्ता या सिस्टम को दर्शाता है।

उपयोगी है:

• सीमा

• हितधारक संचार

• सिस्टम की सीमाएँ

कंटेनर या उप-सिस्टम स्तर

यह अनुप्रयोगों, सेवाओं, डेटाबेसों और प्रमुख एकीकरणों को दर्शाता है।

उपयोगी है:

• वास्तुकला

• स्वामित्व

• वितरण योजना

घटक स्तर

यह आंतरिक वास्तुकला के भागों और इंटरफेसों को दर्शाता है।

उपयोगी है:

• विस्तृत डिजाइन

• निर्भरता समीक्षा

• टीम की सीमाएँ

कोड स्तर

यह कक्षाओं, विधियों और कार्यान्वयन निर्भरताओं को दर्शाता है।

उपयोगी है:

• विकासक का कार्य

• पुनर्गठन

• डिबगिंग

सभी स्तरों को एक ही आरेख में न रखें। एक संदर्भ आरेख में प्रत्येक कक्षा नहीं होनी चाहिए, और एक कक्षा आरेख को पूरे उत्पादन नेटवर्क को दर्शाने का प्रयास नहीं करना चाहिए।

13. विजुअल पैराडाइम UML

विजुअल पैराडाइम उन टीमों के लिए अच्छी तरह से उपयुक्त है जो ग्राफिकल मॉडलिंग और एकीकृत दस्तावेज़ीकरण को प्राथमिकता देती हैं।

यह उपयोगी हो सकता है:

• UML आरेखों को इंटरैक्टिव रूप से बनाना

• मॉडल भंडार को बनाए रखना

• आरेखों को आवश्यकताओं से जोड़ना

• प्राप्ति संबंध बनाना

• दस्तावेज़ तैयार करना

• एक साझा मॉडलिंग वातावरण के माध्यम से सहयोग करना

• चयनित आइटमों का उत्पादन या रिवर्स-इंजीनियरिंग

• नेविगेशन और संगठन सुविधाओं के साथ बड़े मॉडलों का प्रबंधन

13.1 ताकतें

ग्राफिकल UML टूल्स विशेष रूप से तब सहायक होते हैं जब:

• विश्लेषकों और गैर-विकसकों को डायग्राम संपादित करने की आवश्यकता होती है

• हितधारक दृश्य संशोधन को प्राथमिकता देते हैं

• एक परियोजना को औपचारिक मॉडल संगठन की आवश्यकता होती है

• ट्रेसिबिलिटी महत्वपूर्ण है

• टीम एक केंद्रीय भंडार बनाए रखती है

• दस्तावेज़ों को सुसंगत रूप से उत्पन्न किया जाना चाहिए

13.2 अनुशंसित उपयोग

उन मॉडल दृश्यों के लिए Visual Paradigm का उपयोग करें जो इनसे लाभान्वित होते हैं:

• अंतःक्रियात्मक लेआउट

• समृद्ध टिप्पणियां

• डायग्राम के बीच नेविगेशन

• औपचारिक भंडार प्रबंधन

• ट्रेसिबिलिटी

• हितधारक कार्यशालाएं

टूल को मॉडलिंग रणनीति निर्धारित करने की अनुमति न दें। पहले निर्णय लें:

• कौन सा निर्णय डायग्राम समर्थन करता है

• कौन इसे पढ़ेगा

• कितनी विस्तृत जानकारी उपयुक्त है

• इसे कैसे बनाए रखा जाएगा

• क्या मॉडल को आवश्यकताओं या कोड से जोड़ने की आवश्यकता है

13.3 भंडार अनुशासन

एक साझा मॉडल भंडार स्रोत नियंत्रण के समान अभ्यासों से लाभान्वित होता है:

• नामकरण रूढ़ियों को स्थापित करें

• प्रमुख मॉडल क्षेत्रों की स्वामित्व नियत करें

• महत्वपूर्ण परिवर्तनों की समीक्षा करें

• अनावश्यक दोहराए गए आरेखों से बचें

• पुराने दृश्यों को संग्रहित करें

• महत्वपूर्ण आरेखों के उद्देश्य को दर्ज करें

• मॉडल तत्वों को सुसंगत नाम दें

14. VPasCode और पाठ-आधारित मॉडलिंग

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

पाठ-आधारित आरेख निम्नलिखित प्रदान कर सकते हैं:

• संस्करण नियंत्रण के साथ संगतता

• कोड समीक्षा

• शाखा बनाना और विलय करना

• स्वचालित निर्माण

• पुनरावृत्त योग्य निर्माण

• आसान बैच अपडेट

• स्रोत कोड और दस्तावेज़ीकरण के निकटता

एक पाठ-आधारित मॉडल इस प्रकार दिख सकता है:

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

सटीक संरचना उपकरण और कार्यप्रवाह पर निर्भर करती है, लेकिन व्यापक लाभ यह है कि आरेख केवल एक ग्राफिकल फ़ाइल के रूप में नहीं, बल्कि संपादनीय पाठ के रूप में दर्शाया जाता है।

14.1 जब पाठ-आधारित मॉडलिंग अच्छी तरह काम करती है

पाठ-आधारित आरेखों का उपयोग तब करें जब:

• विकसक मॉडल बनाए रखते हैं

• आरेख बार-बार बदलते हैं

• टीम Git या किसी अन्य संस्करण नियंत्रण प्रणाली का उपयोग करती है

• समीक्षक पाठिक परिवर्तनों की जांच करना चाहते हैं

• आरेख दस्तावेज़ीकरण का हिस्सा होने के रूप में उत्पन्न किए जाते हैं

• एकाधिक शाखाओं को स्वतंत्र रूप से विकसित होने की आवश्यकता होती है

14.2 संभावित सीमाएँ

पाठ-आधारित मॉडलिंग तब कम सुविधाजनक हो सकती है जब:

• व्यापार हितधारकों को आरेखों को सीधे संपादित करने की आवश्यकता होती है

• लेआउट को دستی रूप से अनुकूलित किया जाना चाहिए

• मॉडल में समृद्ध दृश्य टिप्पणियाँ शामिल हैं

• टीम को डायग्राम सिंटैक्स से परिचित नहीं है

• एक रिपॉजिटरी में उन्नत दृश्य नेविगेशन की आवश्यकता होती है

एक मिश्रित दृष्टिकोण अक्सर प्रभावी होता है: कोड-केंद्रित वास्तुकला के लिए पाठ-आधारित डायग्राम और हितधारकों के विश्लेषण के लिए ग्राफिकल टूल्स का उपयोग करें।

15. PlantUML

PlantUML एक लोकप्रिय पाठ-आधारित डायग्रामिंग दृष्टिकोण है जो सादे पाठ से UML और संबंधित वास्तुकला डायग्राम उत्पन्न कर सकता है।

उदाहरण:

@startuml
actor User
participant "Web App" as Web
participant "Application Service" as App
database Database

User -> Web : Request
Web -> App : Execute operation
App -> Database : Read/write data
Database --> App : Result
App --> Web : Response
Web --> User : Display result
@enduml

15.1 लाभ

PlantUML इसलिए मूल्यवान है क्योंकि डायग्राम हो सकते हैं:

• स्रोत कोड के बगल में संग्रहीत

• पुल अनुरोधों में समीक्षित

• स्वचालित रूप से उत्पन्न

• सरल पाठ संपादन के साथ अपडेट किया गया

• Markdown या दस्तावेज़ीकरण पाइपलाइन में शामिल

• वातावरणों में सुसंगत रूप से उत्पादित

15.2 PlantUML फ़ाइलों का संगठन

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

docs/
  architecture/
    system-context.puml
    components.puml
    deployment.puml
  workflows/
    place-order.puml
    refund-payment.puml
  domain/
    order-model.puml
    order-lifecycle.puml

वर्णनात्मक नामों का उपयोग करें और डायग्रामों को टूल के बजाय उद्देश्य के आधार पर संगठित करें।

15.3 उत्पन्न की गई छवियों को सत्य के स्रोत से बाहर रखें

जब संभव हो:

• संग्रहीत करें .pumlफ़ाइलों को प्राधिकृत स्रोत के रूप में

• दस्तावेज़ीकरण निर्माण के दौरान PNG, SVG, या PDF फ़ाइलें उत्पन्न करें

• उत्पन्न की गई छवियों को मैन्युअल रूप से संपादित करने से बचें

• सत्यापित करें कि स्वचालन में आरेख सफलतापूर्वक रेंडर होते हैं

15.4 सुसंगत शैली का उपयोग करें

एक छोटी दृश्य शब्दावली परिभाषित करें:

• बाहरी सिस्टम के लिए एक रंग

• आंतरिक सेवाओं के लिए एक रंग

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

• एसिंक्रोनस संदेशन के लिए एक नोटेशन

• इंटरफ़ेस के लिए एक नामकरण परंपरा

• सुरक्षा सीमाओं को दर्शाने का एक तरीका

सुसंगति सजावट से अधिक मूल्यवान है।

16. एआई-सहायक UML मॉडलिंग

एआई मॉडलिंग को तेज कर सकता है, लेकिन इसे एक अधिकारी के बजाय एक मॉडलिंग सहायक के रूप में देखा जाना चाहिए।

एआई इन कार्यों के लिए उपयोगी है:

• आवश्यकताओं को उम्मीदवार उपयोग मामलों में परिवर्तित करना

• अभिनेताओं और लक्ष्यों को निकालना

• गतिविधि प्रवाह प्रस्तावित करना

• PlantUML उत्पन्न करना

• क्रम भागीदारों का सुझाव देना

• डोमेन एंटिटी की पहचान करना

• गुम हुए वैकल्पिक पथों का पता लगाना

• आरेख सुसंगति की समीक्षा करना

• आरेखों से दस्तावेज़ तैयार करना

• ग्राफिकल और पाठिक प्रतिनिधित्व के बीच अनुवाद करना

• राज्य संक्रमणों से परीक्षण विचार उत्पन्न करना

16.1 एक उत्पादक एआई कार्यप्रवाह

एक विश्वसनीय कार्यप्रवाह यह है:

1. आवश्यकताओं, बाधाओं और सिस्टम संदर्भ प्रदान करें।

2. एआई से मान्यताओं और अस्पष्टताओं की पहचान करने के लिए कहें।

3. एक उम्मीदवार आरेख उत्पन्न करें।

4. वास्तविक आवश्यकताओं के खिलाफ आरेख की समीक्षा करें।

5. इसे कार्यान्वयन और बुनियादी ढांचे से तुलना करें।

6. गलत या काल्पनिक विवरणों को सुधारें।

7. परिणाम को दृश्य रूप में रेंडर करें और निरीक्षण करें।

8. संबंधित हितधारकों से समीक्षा प्राप्त करें।

9. अनुमोदित मॉडल को प्रोजेक्ट रिपॉजिटरी में संग्रहित करें।

10. जब सिस्टम बदलता है, तो इसे अपडेट करें।

16.2 प्रतिबंधों के साथ AI को प्रॉम्प्ट करें

कमजोर प्रॉम्प्ट:

ऑर्डरिंग सिस्टम के लिए एक UML आरेख बनाएं।

अधिक प्रभावी प्रॉम्प्ट:

ऑर्डर जमा करने के लिए एक PlantUML क्रम आरेख बनाएं।

भागीदार:
- ग्राहक
- वेब एप्लिकेशन
- ऑर्डर सेवा
- भुगतान प्रदाता
- इन्वेंट्री सेवा
- ऑर्डर डेटाबेस

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

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

16.3 AI से केवल उत्पादन के लिए नहीं, बल्कि आलोचना के लिए भी पूछें

उपयोगी समीक्षा प्रॉम्प्ट शामिल हैं:

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

• कौन से शाखाएँ अनुपस्थित हैं?

• क्या यह क्रम आरेख अवस्था मशीन के विरुद्ध है?

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

• क्या जिम्मेदारियाँ गलत घटक को सौंपी गई हैं?

• क्या विन्यास मॉडल उपलब्धता आवश्यकता का समर्थन करता है?

• कौन से संक्रमण परीक्षण मामलों में बदलने चाहिए?

• कौन से अनुमान पुष्टि की आवश्यकता रखते हैं?

16.4 सामान्य AI मॉडलिंग विफलताएँ

AI-जनित मॉडल हो सकते हैं:

• अभिनेताओं या सेवाओं का आविष्कार करें

• व्यापारिक भूमिकाओं को तकनीकी घटकों के साथ भ्रमित करें

• असमर्थित डेटाबेस तालिकाएं जोड़ें

• समकालिक संचार का अनुमान लगाएं

• विफलता पथों को छोड़ दें

• स्वामित्व का गलत प्रतिनिधित्व करें

• UML संबंधों का गलत उपयोग करें

• ऐसे आरेख तैयार करें जो व्याकरणिक रूप से सही हों लेकिन अर्थपूर्ण रूप से गलत हों

• अमूर्तता के स्तरों को मिलाएं

• अंदाजों को आवश्यकताओं के रूप में मानें

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

एआई जल्दी से मसौदा तैयार कर सकता है, लेकिन केवल क्षेत्र और तकनीकी समीक्षा यह स्थापित कर सकती है कि क्या मसौदा सत्य है।

17. वास्तविकता के खिलाफ UML की सत्यापन

एक आरेख तभी मूल्यवान है जब यह सिस्टम के साथ समन्वित रहता है।

17.1 आवश्यकताओं के खिलाफ सत्यापन

जांचें:

• क्या प्रत्येक महत्वपूर्ण आवश्यकता एक या अधिक मॉडलों में दिखाई देती है?

• क्या अभिनेता और लक्ष्य सही हैं?

• क्या व्यापारिक नियमों का प्रतिनिधित्व किया गया है?

• क्या अपवाद शामिल हैं?

• कहाँ प्रासंगिक है, क्या गैर-कार्यात्मक आवश्यकताओं को दर्शाया गया है?

17.2 कार्यान्वयन के खिलाफ सत्यापन

जांचें:

• क्या घटक सीमाएं कोड से मेल खाती हैं?

• क्या अनुक्रम के भागीदार मौजूद हैं?

• क्या इंटरफेस और संदेश सटीक हैं?

• क्या कक्षा की जिम्मेदारियां यथार्थवादी हैं?

• क्या असिंक्रोनस ऑपरेशन सही ढंग से दिखाए गए हैं?

• क्या अवस्था संक्रमण कार्यान्वयन द्वारा लागू किए जाते हैं?

17.3 संचालन के खिलाफ सत्यापन

जांचें:

• क्या विन्यास आरेख को वास्तव में विन्यस्त किया जा सकता है?

• क्या नेटवर्क कनेक्शन यथार्थवादी हैं?

• क्या बाहरी सिस्टमों का प्रतिनिधित्व किया गया है?

• कहाँ महत्वपूर्ण है, क्या डेटाबेस, कतारें, कैश और भंडारण शामिल हैं?

• क्या विफलता और स्केलिंग की धारणाएं युक्तियुक्त हैं?

17.4 आरेखों के बीच सत्यापन करें

विरोधाभास खोजें, जैसे कि:

• एक उपयोग-केस एक अभिनेता का नाम देता है जो सिस्टम संदर्भ में अनुपस्थित है

• एक अनुक्रम आरेख एक घटक को कॉल करता है जो वास्तुकला में दिखाया नहीं गया है

• एक स्टेट मशीन एक संक्रमण की अनुमति देती है जो व्यवसाय नियमों द्वारा समर्थित नहीं है

• एक कक्षा आरेख एक-से-अनेक दिखाता है जबकि डेटाबेस एक-से-एक लागू करता है

• एक विन्यास आरेख उन सेवाओं को छोड़ देता है जो अनुक्रम आरेखों द्वारा आवश्यक हैं

• एक गतिविधि आरेख समानांतर संचालन दिखाता है जबकि कार्यान्वयन कठोरता से अनुक्रमिक है

आरेखों के बीच संगति अक्सर किसी व्यक्तिगत आरेख की कलात्मक गुणवत्ता से अधिक महत्वपूर्ण होती है।

18. अनुगमन

अनुगमन मॉडलों को आवश्यकताओं, कोड, परीक्षणों और संचालन सामग्री से जोड़ता है।

एक सरल अनुगमन श्रृंखला कुछ इस प्रकार हो सकती है:

आवश्यकता
  → उपयोग-केस
    → गतिविधि प्रवाह
      → अनुक्रम परिदृश्य
        → घटक
          → कार्यान्वयन
            → स्वचालित परीक्षण

एक स्टेटफुल डोमेन ऑब्जेक्ट के लिए:

व्यवसाय नियम
  → स्टेट संक्रमण
    → गार्ड शर्त
      → परीक्षण केस

अनुगमन को प्रत्येक तत्व को अन्य सभी से जोड़ने की आवश्यकता नहीं है। उच्च-मूल्य संबंधों पर ध्यान दें:

• सुरक्षा-संवेदनशील व्यवहार

• नियामक आवश्यकताएं

• सुरक्षा नियंत्रण

• महत्वपूर्ण एकीकरण

• जटिल व्यवसाय नियम

• उच्च-जोखिम वाली वास्तुकला निर्णय

19. संस्करण नियंत्रण और मॉडल रखरखाव

एक आरेख दस्तावेज़ है, और दस्तावेज़ तब अविश्वसनीय हो जाता है जब इसे बनाए नहीं रखा जाता।

19.1 उन कार्यों के निकट मॉडल संग्रहित करें जो वे वर्णन करते हैं

संभावित दृष्टिकोण शामिल हैं:

• स्रोत भंडार में UML फ़ाइलें

• वास्तुकला दस्तावेज़ भंडार

• एक साझा मॉडलिंग भंडार

• तकनीकी दस्तावेज़ों के साथ प्रकाशित किए गए उत्पन्न आरेख

• मांगों और मॉडल तत्वों के बीच के संबंध

19.2 कोड के साथ आरेखों की समीक्षा करें

वास्तुकला या व्यवहार में परिवर्तनों के लिए, जहाँ व्यावहारिक हो, प्रासंगिक आरेख अपडेट को कार्यान्वयन के साथ ही उसी परिवर्तन में शामिल करें।

समीक्षक फिर इसका आकलन कर सकते हैं:

• क्या कार्यान्वयन इच्छित डिज़ाइन से मेल खाता है

• क्या डिज़ाइन परिवर्तन पूर्ण है

• क्या निर्भरताएँ बदल गई हैं

• क्या नए विफलता पथ मौजूद हैं

• क्या विन्यास के प्रभावों पर विचार किया गया था

19.3 कम संख्या में अधिकारिक आरेखों को प्राथमिकता दें

एक से अधिक विरोधाभासी आरेख एक अधूरे आरेख से भी बुरे होते हैं। निर्धारित करें कि प्रत्येक चिंता के लिए कौन सा आरेख अधिकारिक है।

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

• घटक आरेख: प्रमुख सेवा सीमाओं के लिए अधिकारिक

• विन्यास आरेख: उत्पादन टोपोलॉजी के लिए अधिकारिक

• राज्य मशीन: ऑर्डर जीवन चक्र के लिए अधिकारिक

• वर्ग आरेख: डोमेन संबंधों के लिए अधिकारिक

20. सामान्य मॉडलिंग त्रुटियाँ

सब कुछ मॉडल करना

अधिक आरेख स्वचालित रूप से अधिक समझ नहीं देते हैं। केवल महत्वपूर्ण जोखिमों और निर्णयों का मॉडल बनाएं।

अमूर्तता स्तरों को मिला देना

व्यापार भूमिकाओं, प्रोग्रामिंग वर्गों, क्लाउड इंफ्रास्ट्रक्चर और डेटाबेस कॉलम को एक ही अविभेदित आरेख में न रखें।

अस्पष्ट नामों का उपयोग करना

“डेटा प्रोसेस करें” या “अनुरोध संभालें” जैसे नाम उद्देश्य को छिपाते हैं। ऐसे नामों को प्राथमिकता दें जो लक्ष्य, जिम्मेदारी या अर्थपूर्ण घटना को पहचानते हों।

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

केवल सफलता वाले मॉडल अवास्तविक अपेक्षाएँ पैदा करते हैं। महत्वपूर्ण अपवादों, पुनः प्रयासों, टाइमआउट और अस्वीकृत अवस्थाओं को शामिल करें।

आरेखों को स्थायी मानना

वास्तुकला विकसित होती है। एक आरेख का मालिक होना चाहिए और उसकी रखरखाव की अपेक्षा होनी चाहिए।

UML संबंधों का अत्यधिक उपयोग

एक सरल संबंध अक्सर तकनीकी रूप से सटीक लेकिन भ्रामक संबंध प्रकारों के समूह से बेहतर होता है।

आरेखों को पढ़ने में असमर्थ बनाना

एक विशाल आरेख के बजाय कई केंद्रित दृश्यों का उपयोग करें। बड़े मॉडलों को परिदृश्य, उप-प्रणाली, जीवनचक्र या विन्यास सीमा के आधार पर विभाजित करें।

डिजाइन को टूल्स द्वारा संचालित करने की अनुमति देना

एक टूल आरेखों को बनाने को आसान बना सकता है, लेकिन यह तय नहीं कर सकता कि क्या मॉडल किया जाना चाहिए या मॉडल सही है या नहीं।

21. एक व्यावहारिक मॉडलिंग कार्यप्रवाह

एक टीम किसी विशेषता या प्रणाली के लिए निम्नलिखित कार्यप्रवाह अपना सकती है।

चरण 1: सीमा निर्धारित करें

एक हल्के संदर्भ दृश्य का निर्माण करें और पहचानें:

• प्रणाली की सीमा

• प्रमुख उपयोगकर्ता

• बाहरी प्रणालियां

• मुख्य लक्ष्य

चरण 2: उपयोग के मामलों की पहचान करें

उपयोग के मामलों को एक्टर लक्ष्यों के रूप में लिखें। संबंधित कार्यों को समूहबद्ध करें और सबसे महत्वपूर्ण परिदृश्यों की पहचान करें।

चरण 3: मुख्य कार्यप्रवाह का मॉडल बनाएं

दिखाने के लिए एक क्रिया आरेख का उपयोग करें:

• सामान्य प्रवाह

• निर्णय

• जिम्मेदारियां

• समानांतर कार्य

• अपवाद

चरण 4: महत्वपूर्ण परिदृश्यों का चयन करें

महत्वपूर्ण, जटिल, जोखिम भरे या एकीकरण-प्रधान अंतःक्रियाओं के लिए क्रम आरेख बनाएं।

चरण 5: डोमेन संरचना परिभाषित करें

उन परिदृश्यों में शामिल अवधारणाओं के लिए एक अवधारणात्मक या डिजाइन-स्तरीय वर्ग आरेख बनाएं।

चरण 6: वास्तुकला की सीमाएं निर्धारित करें

दिखाने के लिए एक घटक आरेख का उपयोग करें:

• मुख्य मॉड्यूल या सेवाएं

• इंटरफेस

• निर्भरताएं

• स्वामित्व

• एकीकरण बिंदु

चरण 7: मॉडल विनिर्माण

जब बुनियादी ढांचा, सुरक्षा, स्केलिंग, उपलब्धता या संचालन महत्वपूर्ण चिंताएं हों, तो एक विनिर्माण आरेख बनाएं।

चरण 8: मॉडल जीवनचक्र

उन इकाइयों के लिए स्टेट-मशीन आरेख बनाएं जिनका व्यवहार स्थिति या अनुमत संक्रमण पर निर्भर करता है।

चरण 9: सत्यापन

मॉडल की तुलना इनके साथ करें:

• आवश्यकताएं

• विद्यमान कोड

• परीक्षण

• डेटा संरचनाएं

• बुनियादी ढांचा

• संचालन प्रतिबंध

चरण 10: रखरखाव

जब व्यवहार, इंटरफेस, स्वामित्व या विनिर्माण में परिवर्तन हो, तो प्रभावित आरेखों को अपडेट करें।

22. एक सामान्य सिस्टम के लिए न्यूनतम वितरण

एक मध्यम आकार के अनुप्रयोग के लिए, एक व्यावहारिक आधारभूत स्तर हो सकता है:

• एक सिस्टम संदर्भ या उपयोग मामला दृश्य

• महत्वपूर्ण व्यापार प्रक्रियाओं के लिए दो से पांच गतिविधि आरेख

• महत्वपूर्ण परिदृश्यों के लिए दो से पांच अनुक्रम आरेख

• एक डोमेन क्लास आरेख

• एक घटक आरेख

• एक उत्पादन विनिर्माण आरेख

• मुख्य जीवनचक्र इकाइयों के लिए स्टेट-मशीन आरेख

यह एक अनिवार्य कोटा नहीं है। कुछ सिस्टमों को कम आरेखों की आवश्यकता हो सकती है; अन्य को अधिक की आवश्यकता हो सकती है। उपयुक्त संख्या जटिलता, जोखिम, टीम का आकार, विनियमन और गलतफहमी के खर्च पर निर्भर करती है।

23. टूल चयन रणनीति

विभिन्न टूल विभिन्न मॉडलिंग आवश्यकताओं की पूर्ति करते हैं।

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

निष्कर्ष

एक व्यावहारिक UML रणनीति हर प्रकार के आरेख का उपयोग करने के बारे में नहीं है। यह उस न्यूनतम सेट के दृश्यों का चयन करने के बारे में है जो सिस्टम को समझने योग्य बनाता है।

सात-आरेख कोर व्यापक कवरेज प्रदान करता है:

• उपयोग मामला आरेख लक्ष्यों और सीमाओं को समझाते हैं।

• गतिविधि आरेख कार्यप्रवाह और जिम्मेदारियों को समझाते हैं।

• क्रम आरेख सहयोग और समय को समझाते हैं।

• वर्ग आरेख संरचना और डोमेन अवधारणाओं को समझाते हैं।

• घटक आरेख वास्तुकथा की सीमाओं को समझाते हैं।

• डिप्लॉयमेंट आरेख रनटाइम स्थान और बुनियादी ढांचे को समझाते हैं।

• स्टेट-मशीन आरेख जीवनचक्र नियमों को समझाते हैं।

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

सबसे मजबूत मॉडलिंग अभ्यास व्यापक होने के बजाय अनुशासित है:

1. महत्वपूर्ण निर्णयों, जोखिमों और व्यवहार का मॉडल बनाएं।

2. उस आरेख प्रकार का चयन करें जो प्रश्न का सबसे अच्छा उत्तर देता है।

3. प्रत्येक आरेख को एक ही अमूर्तता स्तर पर केंद्रित रखें।

4. संबंधित आरेखों को सुसंगत नाम और ट्रेसबिलिटी के माध्यम से जोड़ें।

5. मॉडल की जाँच आवश्यकताओं, कोड, परीक्षण और विन्यास के साथ करें।

6. आरेखों को बनाए रखने योग्य परियोजना आइटम के रूप में संग्रहित करें और समीक्षा करें।

7. वे आरेख हटा दें जो अब कोई मूल्य प्रदान नहीं करते हैं।

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

संदर्भ

1. VPasCode: PlantUML, Mermaid और Graphviz के साथ AI-सहायक डायग्राम-एज-कोड: VPasCode के टेक्स्ट-टू-डायग्राम इंजन, सिंटैक्स सर्वोत्तम अभ्यास और AI-सहायत संशोधन कार्यप्रवाह को कवर करने वाला आधिकारिक गाइड।
2. “ड्राइंग की जिम्मेदारियों” से “अभिव्यक्ति” तक: AI चैटबॉट का अवलोकन: यह समझाता है कि Visual Paradigm का AI चैटबॉट प्राकृतिक भाषा को मानक-अनुपालन UML और अन्य आरेखों में कैसे परिवर्तित करता है।
3. NotesKeep ज्ञान आधार के साथ Visual Paradigm AI चैटबॉट को सशक्त बनाएं: यह दिखाता है कि AI-चालित आरेख जनरेशन और आवश्यकता संश्लेषण के लिए ज्ञान स्रोत के रूप में NotesKeep रिपॉजिटरी को कैसे जोड़ा जाए।
4. Visual Paradigm के साथ अपने Mac UML मॉडलिंग में क्रांति लाएं: macOS पर Visual Paradigm के UML 2.x समर्थन, कोड इंजीनियरिंग और मॉडल ट्रेसबिलिटी का अवलोकन।
5. Visual Paradigm 18.1 में AI VPP चैटबॉट का परिचय: .vpp परियोजना फ़ाइलों को प्राकृतिक भाषा के माध्यम से क्वेरी करने की अनुमति देने वाले AI VPP चैटबॉट के लिए रिलीज घोषणा।
6. VPasCode योजनाएँ और मूल्य निर्धारण: VPasCode के निःशुल्क स्तर और Visual Paradigm Online/डेस्कटॉप संस्करणों के साथ एकीकरण के लिए मूल्य निर्धारण और विशेषताओं की तुलना।
7. Visual Paradigm VPasCode में आपका स्वागत है: डायग्राम-एज-कोड का परिवर्तन: डायग्राम-एज-कोड कार्यप्रवाह और PlantUML, Mermaid और Graphviz के लिए एकीकृत रेंडरिंग वातावरण का परिचय।
8. Visual Paradigm VPasCode में स्थानीय AI आरेख जनरेशन: यह विवरण देता है कि VPasCode का एम्बेडेड AI एडिटर के भीतर सीधे PlantUML/Mermaid/Graphviz आरेखों को कैसे जनरेट और संशोधित करता है।

यह पोस्ट Deutsch, English, Español, فارسی, Français और Bahasa Indonesia में भी उपलब्ध है।