کمینه مؤثر UML: راهنمای عملی مدل‌سازی سیستم‌های نرم‌افزاری

UML زمانی بیشترین کارایی را دارد که ارتباط و تصمیم‌گیری را بهبود بخشد، نه زمانی که به یک تمرین مستندسازی تبدیل شود. یک تیم به ندرت به هر نوع نمودار UML نیاز دارد. در اکثر پروژه‌ها، هفت نوع نمودار پایه‌ای محکمی را فراهم می‌کنند:

1. نمودارهای مورد استفاده

2. نمودارهای فعالیت

3. نمودارهای توالی

4. نمودارهای کلاس

5. نمودارهای مؤلفه

6. نمودارهای استقرار

7. نمودارهای ماشین حالت

این نمودارها با هم، سیستم را از دیدگاه‌های مکمل توصیف می‌کنند:

• اهداف:چه چیزی کاربران و سیستم‌های خارجی نیاز دارند

• رفتار:کار چگونه از طریق سیستم جریان می‌یابد

• تعامل:شی‌ها و خدمات چگونه با هم همکاری می‌کنند

• ساختار:چه موجودیت‌ها و روابطی وجود دارند

• معماری:بخش‌های اصلی نرم‌افزار چگونه سازماندهی شده‌اند

• عملیات:سیستم کجا اجرا می‌شود

• چرخه حیات:شی‌های مهم چگونه در طول زمان تغییر می‌کنند

هدف ایجاد یک نمودار برای هر نگرانی ممکن نیست. هدف ایجاد کوچک‌ترین مجموعه منسجم از مدل‌هاست که به سوالاتی که ذینفعان واقعاً دارند پاسخ دهد.

۱. «کمینه مؤثر UML» به چه معناست

کمینه مؤثر UML یک استراتژی مدل‌سازی مبتنی بر چهار اصل است:

• مدل‌سازی برای یک تصمیم:یک نمودار ایجاد کنید زیرا یک نیاز، انتخاب طراحی، ریسک یا جزئیات پیاده‌سازی را شفاف می‌کند.

• از ساده‌ترین نمادگذاری کافی استفاده کنید:از نمادها، تزئینات و جزئیات غیرضروری پرهیز کنید.

• ردیابی را حفظ کنید:در صورت امکان، الزامات را به رفتار، ساختار، کد، آزمایش‌ها و استقرار متصل کنید.

• نمودارها را قابل فهم نگه دارید:نموداری که همه چیز را در بر می‌گیرد، اغلب هیچ چیز را منتقل نمی‌کند.

یک مدل مفید باید به پاسخگویی به پرسش‌هایی از این دست کمک کند:

• چه کسی با سیستم تعامل دارد؟

• سیستم باید چه قابلیت‌هایی را فراهم کند؟

• چه گام‌هایی یک فرآیند کسب‌وکار را تشکیل می‌دهند؟

• کدام شیء یا سرویس مسئول هر اقدام است؟

• چه داده‌ها و مفاهیم دامنه‌ای باید نمایش داده شوند؟

• زیرسیستم‌ها چگونه تقسیم‌بندی می‌شوند؟

• کاربردها، پایگاه‌های داده و سرویس‌های خارجی در کجا استقرار می‌یابند؟

• یک موجودیت مهم چگونه از چرخه حیات خود عبور می‌کند؟

اگر یک نمودار به پاسخگویی به یکی از این پرسش‌ها کمک نکند، ممکن است ضروری نباشد.

۲. هسته هفت‌نموداری

این نمودارها مستقل نیستند. آن‌ها یک زنجیره را تشکیل می‌دهند:

نمودارهای ماشین حالت، این زنجیره را در بر می‌گیرند و چرخه حیات اشیایی را که دارای حالت‌های معنادار هستند، توصیف می‌کنند.

برای مثال، یک سفارش آنلاین ممکن است به صورت زیر نمایش داده شود:

• مورد استفاده:ثبت سفارش

• فعالیت:اعتبارسنجی سبد خرید، مجوز پرداخت، رزرو موجودی، تأیید سفارش

• ترتیب:رابط کاربری مشتری به سرویس سفارش، سرویس پرداخت و سرویس موجودی فراخوانی می‌کند.

• کلاس: سفارش, خط سفارش, پرداخت و محصول

• اجزا:وب‌اپلیکیشن، سرویس سفارش، سازگارکننده پرداخت، سرویس موجودی

• نصب و استقرار:مرورگر، خوشه برنامه، پایگاه داده، ارائه‌دهنده پرداخت

• ماشین حالت:پیش‌نویس → در انتظار پرداخت → پرداخت شده → ارسال شده → تحویل داده شده

۳. نمودارهای مورد استفاده: تعریف اهداف سیستم

یک نمودار مورد استفاده، سیستم را از بیرون نمایش می‌دهد. این نمودار بازیگرانی را که با سیستم تعامل دارند و اهدافی که دنبال می‌کنند، شناسایی می‌کند.

۳.۱ نمودار مورد استفاده چه چیزی را شامل می‌شود

عناصر اصلی عبارتند از:

• مرز سیستم:تعریف می‌کند که چه چیزی در داخل سیستم مورد مدل‌سازی قرار دارد

• نقش‌ها:افراد، سازمان‌ها، دستگاه‌ها یا سیستم‌های خارجی

• مورد استفاده:اهداف یا خدماتی که سیستم ارائه می‌دهد

• ارتباطات:ارتباطات بین نقش‌ها و موارد استفاده

• روابط شامل:رفتار قابل استفاده مجددی که توسط یک مورد استفاده دیگر نیاز است

• روابط گسترش:رفتار اختیاری یا شرطی

مثال:

@startuml
جهت چپ به راست

نقش مشتری
نقش "ارائه‌دهنده پرداخت" به عنوان PaymentProvider
نقش "سیستم انبار" به عنوان Warehouse

مستطیل "فروشگاه آنلاین" {
  usecase "مرور محصولات" به عنوان UC1
  usecase "ثبت سفارش" به عنوان UC2
  usecase "مجوز پرداخت" به عنوان UC3
  usecase "تحویل سفارش" به عنوان UC4
}

مشتری --> UC1
مشتری --> UC2
UC2 ..> UC3 : <<include>>
PaymentProvider --> UC3
Warehouse --> UC4
@enduml

۳.۲ نقش‌ها را به درستی شناسایی کنید

یک نقش لزوماً یک نقش انسانی نیست. هر چیزی خارجی است که با سیستم تعامل دارد.

نقش‌های ممکن عبارتند از:

• مشتری

• نماینده پشتیبانی

• مدیر سیستم

• درگاه پرداخت

• ارائه‌دهنده هویت

• سیستم مدیریت انبار

• وظیفه زمان‌بندی شده

• برنامه موبایل

• دستگاه اینترنت اشیاء

از نام‌گذاری نقش‌ها بر اساس جزئیات پیاده‌سازی داخلی خودداری کنید. «کنترل‌کننده REST» معمولاً یک نقش نیست. «برنامه شریک» ممکن است یک نقش باشد.

۳.۳ موارد استفاده را به عنوان اهداف نام‌گذاری کنید

نام‌های خوب مورد استفاده، نتایج را توصیف می‌کنند:

• ارسال گزارش هزینه

• تأیید درخواست خرید

• ثبت بیمار جدید

• تولید فاکتور

• بازنشانی رمز عبور

نام‌های ضعیف مکانیزم‌های پیاده‌سازی را توصیف می‌کنند:

• فراخوانی API

• اجرای کوئری SQL

• باز کردن فرم

• فراخوانی کنترل‌کننده

یک مورد استفاده باید به این سوال پاسخ دهد:

یک بازیگر چه نتیجه معناداری می‌خواهد با سیستم به دست آورد؟

۳.۴ چه زمانی از include و extend استفاده کنیم

از <<شامل>>وقتی یک رفتار به‌طور همیشگی به‌عنوان بخشی از رفتار دیگری لازم است.

برای مثال:

• «ثبت سفارش» شامل «محاسبه مجموع» است

• «ثبت حساب» شامل «اعتبارسنجی ایمیل» است

از <<گسترش>>وقتی رفتاری اختیاری یا شرطی است.

برای مثال:

• «ثبت سفارش» ممکن است توسط «اعمال تخفیف تبلیغاتی» گسترش یابد

• «ورود» ممکن است توسط «تکمیل احراز هویت چندعاملی» گسترش یابد

از این روابط صرفاً برای زیباتر کردن نمودار استفاده نکنید. اغلب، یک سناریوی کوتاه نوشتاری یا نمودار فعالیت واضح‌تر است.

۳.۵ نمودارهای مورد استفاده چه چیزی را نشان نمی‌دهند

نمودارهای مورد استفاده برای توصیف موارد زیر طراحی نشده‌اند:

• چیدمان‌های دقیق رابط کاربری

• کلاس‌های دقیق پیاده‌سازی

• جدول‌های پایگاه داده

• ترتیب پیام‌ها

• منطق الگوریتمی

• چیدمان زیرساخت

آن‌ها دامنه و اهداف را تعریف می‌کنند. نمودارهای دیگر جزئیات را ارائه می‌دهند.

۴. نمودارهای فعالیت: مدل‌سازی گردش کار و فرآیندها

نمودارهای فعالیت نشان می‌دهند که کار چگونه پیش می‌رود. آن‌ها به‌ویژه برای فرآیندهای کسب‌وکار، گردش کار، منطق انشعابی، کار موازی و مدیریت استثنا مؤثر هستند.

۴.۱ عناصر اصلی

نمودارهای فعالیت معمولاً از موارد زیر استفاده می‌کنند:

• گره‌های اولیه

• عملیات

• گره‌های تصمیم‌گیری

• گره‌های ادغام

• انشعاب‌ها و پیوندها

• ناحیه‌های شناور

• گره‌های پایانی

• شرط‌هایی مانند “[تأیید شده] یا “[رد شده]

مثال:

@startuml
|مشتری|
start
:ثبت سفارش;

|سرویس سفارش|
:اعتبارسنجی سفارش;

if (سفارش معتبر است؟) then (بله)
  :محاسبه مجموع;

  fork
    |سرویس پرداخت|
    :مجوز پرداخت;
  fork again
    |سرویس موجودی|
    :رزرو موجودی;
  end fork

  |سرویس سفارش|
  :تأیید سفارش;
  stop
else (خیر)
  :بازگرداندن خطاهای اعتبارسنجی;
  stop
endif
@enduml

۴.۲ از نواحی شناور برای نمایش مسئولیت استفاده کنید

نواحی شناور مشخص می‌کنند که هر عملیات توسط کدام نقش، سیستم یا جزء انجام می‌شود.

ناحیه‌های مفید ممکن است نشان‌دهنده موارد زیر باشند:

• مشتری

• نماینده خدمات مشتری

• خدمات سفارش

• ارائه‌دهنده پرداخت

• انبار

• برنامه‌ریز خودکار

خطوط شناور (Swimlanes) زمانی که یک فرآیند از مرزهای سازمانی یا سیستمی عبور می‌کند، به‌ویژه ارزشمند هستند.

۴.۳ تصمیم‌گیری‌ها را صریحاً مدل‌سازی کنید

یک تصمیم باید گارد (شرط) معنادار داشته باشد:

[پرداخت تأیید شد]
[پرداخت رد شد]

از برچسب‌های مبهم مانند موارد زیر پرهیز کنید:

[بله]
[خیر]

مگر اینکه سؤال تصمیم‌گیری بلافاصله واضح باشد.

۴.۴ موازی‌سازی را زمانی که اهمیت دارد، نمایش دهید

شاخه‌ها (Forks) و پیوندها (Joins) زمانی که فعالیت‌ها هم‌زمان رخ می‌دهند، مفید هستند. به‌عنوان مثال، پس از اعتبارسنجی سفارش:

• پرداخت ممکن است تأیید شود

• موجودی ممکن است رزرو شود

• ممکن است بررسی تقلب انجام شود

با این حال، موازی‌سازی را تنها زمانی مدل‌سازی کنید که بر زمان‌بندی، سازگاری، مدیریت خطا یا طراحی سیستم تأثیر بگذارد. از شاخه‌های موازی صرفاً برای پیچیده‌تر کردن نمودار استفاده نکنید.

۴.۵ نمودارهای فعالیت و الزامات

یک نمودار فعالیت می‌تواند الزامات گمشده را آشکار کند. به‌عنوان مثال، در حین مدل‌سازی یک فرآیند تأیید، تیم ممکن است با سؤالات بی‌پاسخ مواجه شود:

• اگر تأییدکننده در دسترس نباشد چه اتفاقی می‌افتد؟

• آیا یک درخواست می‌تواند رد و مجدداً ارسال شود؟

• زمان ارجاع (Escalation) چقدر است؟

• آیا دو نفر می‌توانند هم‌زمان تأیید کنند؟

• اگر سیستم پایین‌دست در دسترس نباشد چه اتفاقی می‌افتد؟

این امر نمودارهای فعالیت را پیش از آغاز پیاده‌سازی مفید می‌سازد.

۵. نمودارهای توالی: توضیح همکاری در طول زمان

نمودارهای توالی نشان می‌دهند که شرکت‌کنندگان چگونه در یک تعامل ترتیب‌یافته با زمان، پیام‌ها را مبادله می‌کنند. آن‌ها برای توصیف دقیق سناریوهای مهم ایده‌آل هستند.

۵.۱ عناصر اصلی

یک نمودار توالی معمولاً شامل موارد زیر است:

• بازیگران (Actors)

• اشیاء یا خدمات

• خطوط حیات

• پیام‌ها

• پیام‌های بازگشتی

• نوارهای فعال‌سازی

• شرایط

• حلقه‌ها

• مسیرهای جایگزین

• پیام‌های ناهمگام

مثال:

@startuml
actor Customer
boundary "Web App" as Web
control "Order Service" as Order
control "Payment Service" as Payment
database "Order DB" as DB

Customer -> Web : Submit order
Web -> Order : createOrder(cart)

Order -> DB : save(order)
DB --> Order : orderId

Order -> Payment : authorize(amount)

alt Payment approved
  Payment --> Order : approved
  Order -> DB : updateStatus(PAID)
  Order --> Web : confirmation
  Web --> Customer : Display confirmation
else Payment declined
  Payment --> Order : declined
  Order -> DB : updateStatus(PAYMENT_FAILED)
  Order --> Web : payment error
  Web --> Customer : Display error
end
@enduml

۵.۲ سناریوها را به‌صورت استراتژیک انتخاب کنید

برای هر مورد استفاده، نمودار توالی ایجاد نکنید. با سناریوهایی شروع کنید که:

• حیاتی برای کسب‌وکار

• از نظر فنی پرریسک

• پر از یکپارچه‌سازی

• حساس به امنیت

• تراکنشی

• دشوار در درک

• احتمالاً مشکلات معماری را آشکار می‌کنند

مثال‌های متداول عبارتند از:

• احراز هویت کاربر

• پردازش پرداخت

• بارگذاری فایل

• ارسال سفارش

• بازنشانی رمز عبور

• انتشار رویداد

• بازیابی خطا

• اجرای وظایف پس‌زمینه

۵.۳ تمایز بین تعاملات هم‌زمان و ناهم‌زمان

یک فراخوانی هم‌زمان به این معنی است که فرستنده منتظر پاسخ می‌ماند. یک پیام ناهم‌زمان به فرستنده اجازه می‌دهد که ادامه دهد.

این تمایز بر موارد زیر تأثیر می‌گذارد:

• تجربه کاربر

• مرزهای تراکنش

• مدیریت خطا

• مقیاس‌پذیری

• رفتار تلاش مجدد

• قابلیت مشاهده

از نمادگذاری متفاوت به‌صورت یکسان استفاده کنید و رفتارهای مهم ناهم‌زمان را در یک یادداشت یا متن همراه توضیح دهید.

۵.۴ مدل‌سازی مسیرهای خطا

یک نمودار توالی که تنها مسیر موفق را نشان می‌دهد، می‌تواند ریسک‌های بزرگ طراحی را پنهان کند. از alt, opt، و loop برای نمایش موارد زیر استفاده کنید:

• خطای اعتبارسنجی

• خطای احراز هویت

• انقضای زمان

• تلاش مجدد

• خطای جزئی

• درخواست تکراری

• عدم در دسترس بودن سرویس

• جبران یا بازگشت

برای مثال:

@startuml
کاربر -> API : ارسال درخواست

API -> سرویس : پردازش درخواست

alt سرویس پاسخ دهد
  سرویس --> API : نتیجه
  API --> کاربر : موفق
else زمان‌بندی منقضی شد
  API -> سرویس : تلاش مجدد برای درخواست
  alt تلاش مجدد موفق
    سرویس --> API : نتیجه
    API --> کاربر : موفق
  else تلاش مجدد ناموفق
    API --> کاربر : شکست موقت
  end
end
@enduml

۵.۵ از نمودارهای توالی بیش‌ازحد جزئی‌نگر پرهیز کنید

نمودار توالی زمانی که شامل هر فراخوانی متد داخلی باشد، نگهداری آن دشوار می‌شود. بر مسئولیت‌ها و مرزهای معنادار تمرکز کنید:

• رابط کاربری

• سرویس برنامه

• شیء دامنه

• مخزن

• سرویس خارجی

• پیام‌رسان

• پایگاه داده

نمودارهای پیاده‌سازی دقیق ممکن است در هنگام اشکال‌زدایی مفید باشند، اما نباید به مستندات اصلی معماری تبدیل شوند.

۶. نمودارهای کلاس: توصیف ساختار و مفاهیم دامنه

نمودارهای کلاس ساختار ایستا را نشان می‌دهند. آن‌ها می‌توانند یکی از موارد زیر را توصیف کنند:

• یک مدل مفهومی دامنه

• یک مدل شیء در سطح طراحی

• یک ساختار کلاس متمرکز بر پیاده‌سازی

این‌ها سطوح مختلف انتزاع هستند و نباید به‌صورت بی‌دقت با هم ترکیب شوند.

۶.۱ نمودارهای کلاس مفهومی در مقابل پیاده‌سازی

یک مدل مفهومی ممکن است شامل موارد زیر باشد:

• مشتری

• سفارش

• محصول

• پرداخت

یک مدل پیاده‌سازی ممکن است شامل موارد زیر باشد:

• OrderController

• OrderApplicationService

• OrderRepository

• PaymentGatewayAdapter

هر دو معتبر هستند، اما به سوالات متفاوتی پاسخ می‌دهند.

۶.۲ روابط اصلی

روابط رایج شامل موارد زیر هستند:

• ارتباط

• تجمع

• ترکیب

• عمومی‌سازی

• وابستگی

• اجرا

با روابط با دقت استفاده کنید. در بسیاری از موارد، یک ارتباط ساده واضح‌تر از تمایز پیچیده بین تجمع و ترکیب است.

مثال:

@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

۶.۳ تعدد اهمیت دارد

تعدد بیانگر محدودیت‌ها است:

• 1 — دقیقاً یکی

• 0..1 — اختیاری

• * — چندین

• 1..* — یکی یا بیشتر

برای مثال:

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

به این معنی است که هر سفارش متعلق به یک مشتری است، در حالی که یک مشتری ممکن است صفر یا چندین سفارش داشته باشد.

۶.۴ مسئولیت‌ها را مدل کنید، نه فقط فیلدهای داده

نمودار کلاس باید به توضیح اینکه رفتارها در کجا قرار می‌گیرند کمک کند. یک شیء دامنه با عملیات معنادار، اغلب اطلاعات بیشتری نسبت به مجموعه‌ای از کلاس‌ها دارد که فقط شامل getter و setter هستند.

برای مثال:

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

عملیات دقیق به رویکرد طراحی بستگی دارد، اما اصل آن یکسان است:

مسئولیت‌های مهم کسب‌وکار را نزدیک به مفاهیمی که متعلق به آن‌ها هستند، قرار دهید.

۶.۵ از تبدیل نمودارهای کلاس به طرح‌واره‌های پایگاه داده خودداری کنید

یک نمودار کلاس به‌طور خودکار یک طرح‌واره رابطه‌ای نیست. مگر اینکه هدف به‌طور خاص طراحی پایداری باشد، هر ستون پایگاه داده را اضافه نکنید.

یک تمایز مفید عبارت است از:

• مدل دامنه:مفاهیم و قوانین کسب‌وکار

• مدل طراحی:کلاس‌ها و مسئولیت‌های نرم‌افزاری

• مدل داده:جدول‌ها، کلیدها، شاخص‌ها و محدودیت‌ها

این‌ها ممکن است مرتبط باشند، اما نباید با هم اشتباه گرفته شوند.

۷. نمودارهای مؤلفه: نشان دادن مرزهای معماری

نمودارهای مؤلفه، بخش‌های اصلی قابل تعویض یا قابل استقرار یک سیستم و رابط‌هایی را که از طریق آن‌ها با یکدیگر تعامل دارند، توصیف می‌کنند.

آن‌ها برای پاسخ به سوالات زیر مفید هستند:

• زیرسیستم‌های اصلی کدامند؟

• کدام مؤلفه مسئولیت را بر عهده دارد؟

• هر مؤلفه چه چیزی ارائه می‌دهد؟

• هر مؤلفه چه چیزی نیاز دارد؟

• مرزهای یکپارچه‌سازی کجا هستند؟

• کدام وابستگی‌ها پایدار یا پرخطر هستند؟

مثال:

@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

۷.۱ نمودارهای مؤلفه، نمودارهای بسته نیستند

یک نمودار بسته، عناصر مدل را برای سازماندهی گروه‌بندی می‌کند. یک نمودار مؤلفه، واحدهای معماری را توصیف می‌کند که کارایی را ارائه و مصرف می‌کنند.

یک مؤلفه ممکن است باشد:

• یک سرویس قابل استقرار

• یک برنامه تحت وب

• یک برنامه موبایل

• یک کتابخانه

• یک واسط پیام

• یک پلتفرم خارجی

• یک پایگاه داده

• یک یکپارچه‌سازی با طرف ثالث

سطح مناسب به معماری بستگی دارد.

۷.۲ نمایش رابط‌ها در مواردی که قراردادها را شفاف می‌کنند

رابط‌ها وابستگی‌ها را صریح‌تر می‌کنند:

@startuml
interface PaymentGateway

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

Order ..> PaymentGateway
Adapter - PaymentGateway
@enduml

این نشان می‌دهد که سرویس سفارش به یک انتزاع وابسته است، نه به یک ارائه‌دهنده خاص.

۷.۳ استفاده از نمودارهای مؤلفه برای پشتیبانی از تصمیمات معماری

یک نمودار مؤلفه زمانی ارزشمندتر می‌شود که با یادداشت‌های طراحی کوتاه همراه باشد:

• چرا این مرز وجود دارد؟

• چه کسی مالک داده‌ها است؟

• آیا تعامل همگام یا ناهمگام است؟

• وقتی وابستگی شکست می‌خورد چه اتفاقی می‌افتد؟

• آیا مؤلفه به‌طور مستقل قابل استقرار است؟

• چه مرز امنیتی را نمایندگی می‌کند؟

• چه تضمین‌های یکپارچگی وجود دارد؟

نمودار نباید نیاز به داشتن هر پاسخ داشته باشد، اما باید توجه را به موارد مهم هدایت کند.

۸. نمودارهای استقرار: اتصال نرم‌افزار به زیرساخت

نمودارهای استقرار محیط فیزیکی یا مجازی را نشان می‌دهند که در آن آثار نرم‌افزار اجرا می‌شوند.

آن‌ها به پاسخ دادن به موارد زیر کمک می‌کنند:

• هر برنامه در کجا اجرا می‌شود؟

• کدام گره‌ها با یکدیگر ارتباط برقرار می‌کنند؟

• پایگاه‌های داده در کجا قرار دارند؟

• کدام خدمات از بیرون قابل دسترسی هستند؟

• چه مرزهای شبکه‌ای وجود دارند؟

• سیستم چگونه توزیع شده است؟

• کدام انتخاب‌های زیرساخت بر قابلیت اطمینان یا عملکرد تأثیر می‌گذارند؟

مثال:

@startuml
node "دستگاه کاربر" به عنوان Device {
  artifact "مرورگر" به عنوان Browser
}

node "منطقه ابری" به عنوان Cloud {
  node "لایه وب" به عنوان WebTier {
    artifact "وب‌اپلیکیشن" به عنوان WebApp
  }

  node "لایه برنامه" به عنوان AppTier {
    artifact "سرویس سفارش" به عنوان OrderSvc
    artifact "مبدل پرداخت" به عنوان PaymentSvc
  }

  database "پایگاه داده سفارش" به عنوان DB
}

cloud "ارائه‌دهنده پرداخت" به عنوان Provider

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

۸.۱ تمایز بین گره‌ها، آثار و محیط‌ها

• یک گره یک محیط اجرایی است، مانند سرور، کانتینر، دستگاه، ماشین مجازی یا پلتفرم مدیریت‌شده.

• یک آثار یک واحد نرم‌افزاری قابل استقرار است، مانند باینری، تصویر کانتینر، بسته یا برنامه.

• یک محیط ممکن است نمایانگر توسعه، آزمایش، پیش‌تولید یا تولید باشد.

۸.۲ شامل جزئیات مهم عملیاتی

بسته به هدف، نمودارهای استقرار ممکن است نشان دهند:

• تعادل‌دهنده‌های بار

• دیوارهای آتش

• منطقه‌های شبکه

• خوشه‌های کانتینری

• منطقه‌های در دسترس

• پایگاه‌های داده و نسخه‌های تکراری

• کش‌ها

• پیام‌رسان‌ها

• ذخیره‌سازی اشیاء

• خدمات خارجی

• سیستم‌های پایش و ثبت‌رویداد

جزئیات زیرساختی که بر تصمیم مستندشده تأثیری ندارند، اضافه نکنید.

۸.۳ از نمودارهای استقرار برای تحلیل ریسک استفاده کنید

مدل‌سازی استقرار می‌تواند موارد زیر را آشکار کند:

• نقطه شکست واحد

• پایگاه داده‌ی نمایان

• مرز شبکه‌ی ناموجود

• ترافیک بیش‌ازحد بین‌منطقه‌ای

• وابستگی بدون استراتژی جایگزینی

• جداسازی ناکافی بین محیط‌ها

• اتصال رمزنگاری‌نشده

• فرض مقیاس‌پذیری غیرواقعی

۹. نمودارهای ماشین حالت: مدل‌سازی چرخه‌های حیات

نمودارهای ماشین حالت توصیف می‌کنند که یک موجود چگونه با حرکت بین حالت‌ها به رویدادها واکنش نشان می‌دهد.

آن‌ها زمانی ارزشمند هستند که رفتار یک شیء به شدت به حالت فعلی آن وابسته باشد.

نمونه‌های رایج شامل موارد زیر هستند:

• سفارش

• پرداخت

• ارسال

• تیکت پشتیبانی

• حساب کاربری

• درخواست گردش کار

• اشتراک

• سند

• دستگاه

• اجرای وظیفه

مثال:

@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

۹.۱ حالت‌ها را با دقت تعریف کنید

یک حالت باید یک وضعیت معنادار را نشان دهد، نه صرفاً یک عمل.

حالت‌های خوب:

• در انتظار تأیید

• تأیید شده

• رد شده

• پرداخت ناموفق

• ارسال شده

حالت‌های ضعیف:

• کلیک کردن روی دکمه

• فراخوانی سرویس

• اجرای روش

عمل‌ها رویدادها یا گذارها هستند. حالت‌ها شرایطی هستند که پایدار می‌مانند.

۹.۲ قواعد گذار را شامل کنید

یک گذار می‌تواند شامل موارد زیر باشد:

• رویداد

• شرط نگهبان

• عمل

برای مثال:

در انتظار تأیید -- approve [مدیر مجاز است] / recordApproval --> تأیید شده

این کار قواعد کسب‌وکار را قابل مشاهده و قابل آزمایش می‌کند.

۹.۳ از ماشین‌های حالت برای استخراج تست‌ها استفاده کنید

هر گذار موارد تست را پیشنهاد می‌دهد:

• گذار معتبر

• گذار نامعتبر

• خطای گارد

• رویداد تکراری

• انقضای زمان

• تلاش مجدد

• لغو

• بازیابی

برای چرخه حیات سفارش، آزمایش‌ها ممکن است موارد زیر را تأیید کنند:

• سفارش پیش‌نویس قابل ارسال است

• سفارش تحویل‌داده‌شده قابل لغو نیست

• خطای پرداخت اجازه تلاش مجدد می‌دهد

• سفارش لغوشده نمی‌تواند به وضعیت پرداخت‌شده بازگردد

۱۰. هفت نمودار چگونه با هم کار می‌کنند

نمودارها باید یک مدل یکپارچه را تشکیل دهند، نه هفت تصویر جداگانه.

قابلیت «ارسال گزارش هزینه» را در نظر بگیرید.

مورد استفاده

• کارمند گزارش هزینه را ارسال می‌کند

• مدیر گزارش هزینه را تأیید می‌کند

• کارمند مالی بازپرداخت را پردازش می‌کند

فعالیت

• وارد کردن هزینه‌ها

• پیوست کردن رسیدها

• اعتبارسنجی داده‌ها

• ارسال گزارش

• مسیریابی به مدیر

• تأیید یا رد

• ارسال به واحد مالی

ترتیب

• رابط کاربری کارمند به سرویس هزینه فراخوانی می‌دهد

• سرویس هزینه گزارش را اعتبارسنجی می‌کند

• سرویس رسید پیوست‌ها را ذخیره می‌کند

• خدمات گردش کار مدیر را تعیین می‌کند

• خدمات اعلان‌ها هشدارها را ارسال می‌کند

کلاس

• کارمند

• گزارش هزینه

• قلم هزینه

• رسید

• تاییدیه

• بازپرداخت

اجزا

• برنامه تحت وب

• خدمات هزینه

• ذخیره‌سازی رسید

• خدمات گردش کار

• خدمات اعلان‌ها

• یکپارچه‌سازی مالی

پیاده‌سازی

• مرورگر

• لایه وب

• خوشه برنامه

• ذخیره‌سازی شیء

• پایگاه داده رابطه‌ای

• پلتفرم مالی

ماشین حالت

پیش‌نویس → ارسال شده → در حال بررسی → تایید شده → بازپرداخت شده
                         ↓
                      رد شده

هر نمودون دیدگاهی متفاوت را بدون تکرار تمام موارد دیگر اضافه می‌کند.

۱۱. انتخاب نمودارهایی که باید ایجاد شوند

یک فرآیند انتخاب عملی این است که بپرسیم تیم چه نوع عدم قطعیتی دارد.

شما برای هر ویژگی به هر نموداری نیاز ندارید.

یک قانون تصمیم‌گیری سبک

یک نمودار ایجاد کنید اگر حداقل یکی از موارد زیر صادق باشد:

• ذینفعان مختلف نیازمندی را به صورت متفاوت تفسیر می‌کنند.

• یک فرآیند دارای رفتارهای شاخه‌ای یا موازی مهم است.

• یک سناریو از چندین مرز سیستم عبور می‌کند.

• یک شیء حوزه دارای قوانین غیربدیهی است.

• یک تصمیم معماری نیاز به ابلاغ دارد.

• توپولوژی پیاده‌سازی بر قابلیت اطمینان، امنیت یا عملکرد تأثیر می‌گذارد.

• قوانین چرخه عمر توضیح در قالب متن دشوار است.

• این نمودار برای پیاده‌سازی، بازبینی، آزمایش یا عملیات بازنشانی خواهد شد.

از ایجاد نمودار صرفاً به این دلیل که یک قالب انتظار آن را دارد، خودداری کنید.

۱۲. سطوح جزئیات

یک رویکرد مدل‌سازی قوی از سطوح مختلف انتزاع استفاده می‌کند.

سطح زمینه

سیستم و بازیگران یا سیستم‌های خارجی اصلی را نشان می‌دهد.

کاربردی برای:

• حوزه

• ارتباط با ذینفعان

• مرزهای سیستم

سطح کانتینر یا زیرسیستم

نمایش برنامه‌ها، سرویس‌ها، پایگاه‌های داده و یکپارچه‌سازی‌های اصلی.

کاربردی برای:

• معماری

• مالکیت

• برنامه‌ریزی استقرار

سطح مؤلفه

نمایش بخش‌های داخلی معماری و رابط‌ها.

کاربردی برای:

• طراحی دقیق

• بازبینی وابستگی‌ها

• مرزهای تیم

سطح کد

نمایش کلاس‌ها، روش‌ها و وابستگی‌های پیاده‌سازی.

کاربردی برای:

• کار توسعه‌دهنده

• بازساخت

• عیب‌یابی

همه سطوح را در یک نمودار قرار ندهید. یک نمودار زمینه نباید شامل همه کلاس‌ها باشد و یک نمودار کلاس نباید تلاش کند کل شبکه تولید را نمایش دهد.

۱۳. Visual Paradigm UML

Visual Paradigm برای تیم‌هایی که مدل‌سازی گرافیکی و مستندات یکپارچه را ترجیح می‌دهند، بسیار مناسب است.

می‌تواند برای موارد زیر مفید باشد:

• ترسیم نمودارهای UML به صورت تعاملی

• نگهداری مخزن مدل

• پیوند نمودارها به الزامات

• ایجاد روابط ردیابی

• تولید مستندات

• همکاری از طریق یک محیط مدل‌سازی مشترک

• تولید یا مهندسی معکوس آثار انتخاب‌شده

• مدیریت مدل‌های بزرگ‌تر با ویژگی‌های پیمایش و سازماندهی

۱۳.۱ نقاط قوت

ابزارهای گرافیکی UML به‌ویژه زمانی مفید هستند که:

• تحلیل‌گران و غیرتوسعه‌دهندگان نیاز به ویرایش نمودارها دارند

• ذینفعان دستکاری بصری را ترجیح می‌دهند

• یک پروژه نیاز به سازماندهی رسمی مدل دارد

• ردیابی مهم است

• تیم یک مخزن مرکزی را نگهداری می‌کند

• مستندات باید به‌صورت یکسان تولید شوند

۱۳.۲ استفاده توصیه‌شده

از Visual Paradigm برای نمای‌های مدل استفاده کنید که از موارد زیر بهره می‌برند:

• چیدمان تعاملی

• یادداشت‌های غنی

• پیمایش بین‌نموداری

• مدیریت رسمی مخزن

• ردیابی

• کارگاه‌های ذینفعان

اجازه ندهید ابزار استراتژی مدل‌سازی را تعیین کند. ابتدا تصمیم بگیرید:

• کدام تصمیم توسط نمودار پشتیبانی می‌شود

• چه کسی آن را خواهد خواند

• چه سطحی از جزئیات مناسب است

• چگونه نگهداری خواهد شد

• آیا مدل نیاز به اتصال به الزامات یا کد دارد

۱۳.۳ انضباط مخزن

یک مخزن مدل مشترک از همان شیوه‌های کنترل نسخه بهره می‌برد:

• قراردادهای نام‌گذاری را تعیین کنید

• مالکیت بخش‌های اصلی مدل را تعیین کنید

• بررسی تغییرات مهم

• از نمودارهای تکراری غیرضروری پرهیز کنید

• نمای منسوخ را بایگانی کنید

• هدف نمودارهای مهم را ثبت کنید

• نام‌گذاری عناصر مدل را یکسان و یکدست نگه دارید

۱۴. VPasCode و مدل‌سازی مبتنی بر متن

VPasCode از رویکردی مبتنی بر متن برای مدل‌سازی در اکوسیستم Visual Paradigm پشتیبانی می‌کند. این سبک برای تیم‌هایی مفید است که می‌خواهند نمودارها بیشتر مانند آثار منبع (source artifacts) رفتار کنند.

نمودارهای مبتنی بر متن می‌توانند موارد زیر را ارائه دهند:

• سازگاری با سیستم کنترل نسخه

• بازبینی کد

• شاخه‌بندی و ادغام

• تولید خودکار

• ساخت‌های تکرارپذیر

• به‌روزرسانی‌های دسته‌ای آسان‌تر

• نزدیکی به کد منبع و مستندات

یک مدل مبتنی بر متن ممکن است به شکل زیر باشد:

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

دستورالعمل دقیق به ابزار و جریان کاری بستگی دارد، اما مزیت کلی این است که نمودار به صورت متن قابل ویرایش نمایش داده می‌شود، نه صرفاً به عنوان یک فایل گرافیکی.

۱۴.۱ چه زمانی مدل‌سازی مبتنی بر متن به خوبی کار می‌کند

از نمودارهای مبتنی بر متن در موارد زیر استفاده کنید:

• توسعه‌دهندگان مدل‌ها را نگهداری می‌کنند

• نمودارها به‌طور مکرر تغییر می‌کنند

• تیم از Git یا یک سیستم کنترل نسخه دیگر استفاده می‌کند

• بازبینی‌کنندگان می‌خواهند تغییرات متنی را بررسی کنند

• نمودارها به عنوان بخشی از مستندات تولید می‌شوند

• چندین شاخه نیاز دارند که به‌طور مستقل تکامل یابند

۱۴.۲ محدودیت‌های احتمالی

مدل‌سازی مبتنی بر متن ممکن است در موارد زیر کمتر مناسب باشد:

• ذینفعان کسب‌وکار نیاز دارند که نمودارها را مستقیماً ویرایش کنند

• چیدمان باید به‌صورت دستی بهینه‌سازی شود

• مدل دارای توضیحات بصری غنی است

• تیم با نحو نمودارها آشنا نیست

• یک مخزن نیازمند پیمایش بصری پیشرفته است

یک رویکرد ترکیبی اغلب مؤثر است: از نمودارهای مبتنی بر متن برای معماری متمرکز بر کد و از ابزارهای گرافیکی برای تحلیل‌های رو به ذینفعان استفاده کنید.

۱۵. 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

۱۵.۱ مزایا

PlantUML ارزشمند است زیرا نمودارها می‌توانند:

• در کنار کد منبع ذخیره شوند

• در درخواست‌های کشش (Pull Requests) بررسی شوند

• به صورت خودکار تولید شوند

• با ویرایش‌های ساده متنی به‌روزرسانی شوند

• در پایپ‌لاین‌های Markdown یا مستندسازی گنجانده شوند

• به صورت یکسان در محیط‌های مختلف تولید شوند

۱۵.۲ سازماندهی فایل‌های PlantUML

یک ساختار عملیاتی برای مخزن ممکن است به این صورت باشد:

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

از نام‌های توصیفی استفاده کنید و نمودارها را بر اساس هدف سازماندهی کنید، نه بر اساس ابزار.

۱۵.۳ تصاویر تولیدشده را از منبع حقیقت (Source of Truth) خارج نگه دارید

هنگام امکان‌پذیر بودن:

• ذخیره‌سازی .pumlفایل‌ها به عنوان منبع معتبر

• فایل‌های PNG، SVG یا PDF را در حین ساخت مستندات تولید کنید

• از ویرایش دستی تصاویر تولیدشده خودداری کنید

• بررسی کنید که نمودارها در اتوماسیون با موفقیت رندر شوند

۱۵.۴ از سبک‌بندی یکسان استفاده کنید

یک واژگان بصری کوچک تعریف کنید:

• یک رنگ برای سیستم‌های خارجی

• یک رنگ برای سرویس‌های داخلی

• یک رنگ برای پایگاه‌های داده

• یک نماد برای پیام‌رسانی ناهمگام

• یک قرارداد نام‌گذاری برای رابط‌ها

• یک روش برای نمایش مرزهای امنیتی

یکپارچگی ارزشمندتر از تزئینات است.

۱۶. مدل‌سازی UML با کمک هوش مصنوعی

هوش مصنوعی می‌تواند مدل‌سازی را تسریع کند، اما باید به عنوان یک دستیار مدل‌سازی در نظر گرفته شود، نه به عنوان یک مرجع.

هوش مصنوعی برای موارد زیر مفید است:

• تبدیل الزامات به موارد استفاده کاندید

• استخراج بازیگران و اهداف

• پیشنهاد جریان‌های فعالیت

• تولید PlantUML

• پیشنهاد شرکت‌کنندگان توالی

• شناسایی موجودیت‌های دامنه

• تشخیص مسیرهای جایگزین گمشده

• بررسی یکپارچگی نمودار

• تولید مستندات از روی نمودارها

• ترجمه بین نمایش‌های گرافیکی و متنی

• تولید ایده‌های تست از گذارهای وضعیت

۱۶.۱ یک گردش کار بهره‌ور هوش مصنوعی

یک گردش کار قابل اعتماد به این صورت است:

1. الزامات، محدودیت‌ها و زمینه سیستم را ارائه دهید.

2. از هوش مصنوعی بخواهید فرضیات و ابهامات را شناسایی کند.

3. یک نمودار کاندید تولید کنید.

4. نمودار را در برابر الزامات واقعی بررسی کنید.

5. آن را با پیاده‌سازی و زیرساخت مقایسه کنید.

6. جزئیات نادرست یا اختراعی را اصلاح کنید.

7. نتیجه را به صورت بصری رندر کرده و بازرسی کنید.

8. بازبینی را از ذینفعان مربوطه دریافت کنید.

9. مدل تأییدشده را در مخزن پروژه ذخیره کنید.

10. هنگامی که سیستم تغییر می‌کند، آن را به‌روزرسانی کنید.

۱۶.۲ درخواست از هوش مصنوعی با قیود

درخواست ضعیف:

یک نمودار UML برای یک سیستم سفارش‌دهی ایجاد کنید.

درخواست قوی‌تر:

یک نمودار توالی PlantUML برای ثبت سفارش ایجاد کنید.

شرکت‌کنندگان:
- مشتری
- برنامه تحت وب
- سرویس سفارش
- ارائه‌دهنده پرداخت
- سرویس موجودی
- پایگاه داده سفارش

قیود:
- پرداخت باید پیش از تأیید سفارش، مجاز شود.
- رزرو موجودی ممکن است همزمان با مجوزپرداخت انجام شود.
- پرداخت ردشده باید سفارش را در وضعیت PaymentFailed باقی بگذارد.
- زمان‌بندی (timeout) باید یک بار تلاش مجدد شود.
- مسیرهای موفق، ردشده و زمان‌بندی را نمایش دهید.
- سرویس‌هایی که در اینجا فهرست نشده‌اند، اختراع نکنید.

هرچه قیود به وضوح بیشتری بیان شوند، احتمال اینکه خروجی شامل معماری‌های پشتیبانی‌نشده باشد، کمتر است.

۱۶.۳ از هوش مصنوعی برای نقد و بررسی بخواهید، نه فقط تولید

درخواست‌های بازبینی مفید شامل موارد زیر هستند:

• چه الزاماتی نمایان نشده‌اند؟

• کدام شاخه‌ها گم شده‌اند؟

• آیا این نمودار توالی با ماشین حالت در تضاد است؟

• آیا وابستگی‌های بدون توضیح وجود دارند؟

• آیا مسئولیت‌هایی به مؤلفه نادرست واگذار شده‌اند؟

• آیا مدل استقرار، الزام در دسترس بودن را پشتیبانی می‌کند؟

• کدام گذارها باید به موارد تست تبدیل شوند؟

• کدام فرضیات نیاز به تأیید دارند؟

۱۶.۴ شکست‌های رایج مدل‌سازی با هوش مصنوعی

مدل‌های تولیدشده توسط هوش مصنوعی ممکن است:

• بازیگران یا سرویس‌هایی اختراع کنند

• نقش‌های کسب‌وکار را با مؤلفه‌های فنی اشتباه بگیرند

• جدول‌های پایگاه داده پشتیبانی‌نشده اضافه کنند

• ارتباط همگام را فرض کنند

• مسیرهای شکست را حذف کنند

• مالکیت را به‌درستی نشان ندهند

• استفاده نادرست از روابط UML

• تولید نمودارهایی که از نظر دستوری معتبر اما از نظر معنایی نادرست هستند

• ترکیب سطوح انتزاعی

• فرضیه‌ها را به عنوان الزامات در نظر گرفتن

اصل کلیدی این است:

هوش مصنوعی می‌تواند به سرعت یک پیش‌نویس تولید کند، اما تنها بررسی‌های تخصصی حوزه و فنی می‌توانند تعیین کنند که آیا پیش‌نویس صحیح است یا خیر.

۱۷. اعتبارسنجی UML در برابر واقعیت

یک نمودار تنها زمانی ارزشمند است که با سیستم همسو باقی بماند.

۱۷.۱ اعتبارسنجی بر اساس الزامات

بررسی کنید:

• آیا هر الزام مهم در یک یا چند مدل ظاهر شده است؟

• آیا بازیگران و اهداف صحیح هستند؟

• آیا قوانین کسب‌وکار نمایان شده‌اند؟

• آیا استثناها گنجانده شده‌اند؟

• آیا الزامات غیرعملکردی در موارد مرتبط منعکس شده‌اند؟

۱۷.۲ اعتبارسنجی بر اساس پیاده‌سازی

بررسی کنید:

• آیا مرزهای کامپوننت‌ها با کد مطابقت دارند؟

• آیا شرکت‌کنندگان توالی وجود دارند؟

• آیا رابط‌ها و پیام‌ها دقیق هستند؟

• آیا مسئولیت‌های کلاس‌ها واقع‌بینانه هستند؟

• آیا عملیات ناهمگام به درستی نمایش داده شده‌اند؟

• آیا گذارهای حالت توسط پیاده‌سازی اعمال می‌شوند؟

۱۷.۳ اعتبارسنجی بر اساس عملیات

بررسی کنید:

• آیا نمودار استقرار واقعاً قابل استقرار است؟

• آیا اتصالات شبکه واقع‌بینانه هستند؟

• آیا سیستم‌های خارجی نمایان شده‌اند؟

• آیا پایگاه‌های داده، صف‌ها، حافظه‌های پنهان (کش) و ذخیره‌سازی در موارد مهم گنجانده شده‌اند؟

• آیا فرضیه‌های مربوط به شکست و مقیاس‌پذیری معقول هستند؟

۱۷.۴ اعتبارسنجی در سراسر نمودارها

به دنبال تناقض‌هایی مانند موارد زیر بگردید:

• یک مورد استفاده، یک نقش را نام می‌برد که در زمینه سیستم وجود ندارد

• یک نمودار توالی، یک مؤلفه را فراخوانی می‌کند که در معماری نمایش داده نشده است

• یک ماشین حالت، یک گذر را مجاز می‌داند که توسط قوانین کسب‌وکار پشتیبانی نمی‌شود

• یک نمودار کلاس، رابطه یک‌به‌چند را نشان می‌دهد در حالی که پایگاه داده، رابطه یک‌به‌یک را اعمال می‌کند

• یک نمودار استقرار، یک سرویس مورد نیاز توسط نمودارهای توالی را نادیده می‌گیرد

• یک نمودار فعالیت، عملیات موازی را نشان می‌دهد در حالی که پیاده‌سازی به‌طور کاملاً توالی است

سازگاری در سراسر نمودارها اغلب از کیفیت هنری هر نمودار فردی مهم‌تر است.

۱۸. ردیابی‌پذیری

ردیابی‌پذیری مدل‌ها را به الزامات، کد، آزمایش‌ها و آثار عملیاتی پیوند می‌دهد.

یک زنجیره ردیابی ساده ممکن است به این صورت باشد:

الزام
  → مورد استفاده
    → جریان فعالیت
      → سناریوی توالی
        → مؤلفه
          → پیاده‌سازی
            → آزمایش خودکار

برای یک شیء دامنه دارای حالت:

قانون کسب‌وکار
  → گذر حالت
    → شرط نگهبان
      → مورد آزمایش

ردیابی‌پذیری نیازمند اتصال هر عنصر به همه عناصر دیگر نیست. بر روابط با ارزش بالا تمرکز کنید:

• رفتارهای حیاتی ایمنی

• الزامات قانونی

• کنترل‌های امنیتی

• یکپارچه‌سازی‌های مهم

• قوانین کسب‌وکار پیچیده

• تصمیمات معماری با ریسک بالا

۱۹. کنترل نسخه و نگهداری مدل

یک نمودار مستند است و مستندات زمانی که نگهداری نمی‌شوند، غیرقابل اعتماد می‌شوند.

۱۹.۱ مدل‌ها را در نزدیکی کاری که توصیف می‌کنند ذخیره کنید

رویکردهای ممکن شامل موارد زیر هستند:

• فایل‌های UML در مخزن منبع

• مخزن‌های مستندات معماری

• یک مخزن مدل‌سازی مشترک

• نمودارهای تولیدشده که همراه با مستندات فنی منتشر می‌شوند

• ارتباطات بین الزامات و عناصر مدل

۱۹.۲ بازبینی نمودارها همراه با کد

برای تغییرات معماری یا رفتار، در صورت امکان، به‌روزرسانی نمودار مربوطه را در همان تغییر همراه با پیاده‌سازی گنجانده شود.

بازبینی‌کنندگان سپس می‌توانند ارزیابی کنند:

• آیا پیاده‌سازی با طراحی مورد نظر مطابقت دارد

• آیا تغییر طراحی تکمیل شده است

• آیا وابستگی‌ها تغییر کرده‌اند

• آیا مسیرهای شکست جدیدی وجود دارد

• آیا پیامدهای استقرار در نظر گرفته شده‌اند

۱۹.۳ ترجیح دادن تعداد کمتر از نمودارهای مرجع

چندین نمودار متناقض بدتر از یک نمودار ناقص است. مشخص کنید کدام نمودار برای هر نگرانی مرجع است.

برای مثال:

• نمودار مؤلفه: مرجع برای مرزهای اصلی سرویس

• نمودار استقرار: مرجع برای توپولوژی تولید

• ماشین حالت: مرجع برای چرخه حیات سفارش

• نمودار کلاس: مرجع برای روابط دامنه

۲۰. اشتباهات رایج در مدل‌سازی

مدل‌سازی همه چیز

نمودارهای بیشتر به‌طور خودکار به درک بیشتر منجر نمی‌شوند. ریسک‌ها و تصمیمات مهم را مدل کنید.

ترکیب سطوح انتزاعی

نقش‌های کسب‌وکار، کلاس‌های برنامه‌نویسی، زیرساخت ابری و ستون‌های پایگاه داده را در یک نمودار بدون تمایز قرار ندهید.

استفاده از نام‌های مبهم

نام‌هایی مانند «پردازش داده» یا «مدیریت درخواست» قصد را پنهان می‌کنند. نام‌هایی را ترجیح دهید که هدف، مسئولیت یا رویداد معناداری را شناسایی کنند.

حذف رفتار شکست

مدل‌های فقط موفقیت، انتظارات غیرواقعی ایجاد می‌کنند. استثناهای مهم، تلاش‌های مجدد، زمان‌بندی‌های منقضی‌شده و حالت‌های رد شده را شامل کنید.

در نظر گرفتن نمودارها به‌عنوان دائمی

معماری تکامل می‌یابد. یک نمودار باید صاحب و انتظارات نگهداری داشته باشد.

استفاده بیش‌ازحد از روابط UML

یک ارتباط ساده اغلب بهتر از مجموعه‌ای دقیق از نظر فنی اما گیج‌کننده از انواع روابط است.

غیرقابل‌خواندن کردن نمودارها

به جای یک نمودار عظیم، از چندین نمای متمرکز استفاده کنید. مدل‌های بزرگ را بر اساس سناریو، زیرسیستم، چرخه حیات یا مرز استقرار تقسیم‌بندی کنید.

اجازه دادن به ابزارها برای هدایت طراحی

یک ابزار می‌تواند ترسیم نمودارها را آسان‌تر کند، اما نمی‌تواند تصمیم بگیرد چه چیزی باید مدل‌سازی شود یا آیا مدل صحیح است یا خیر.

۲۱. یک فرآیند مدل‌سازی عملی

یک تیم می‌تواند فرآیند زیر را برای یک ویژگی یا سیستم اتخاذ کند.

گام ۱: تعیین محدوده

یک نمای زمینه سبک ایجاد کنید و موارد زیر را شناسایی کنید:

• مرز سیستم

• کاربران اصلی

• سیستم‌های خارجی

• اهداف اصلی

گام ۲: شناسایی موارد استفاده

موارد استفاده را به عنوان اهداف بازیگر بنویسید. عملکرد مرتبط را گروه‌بندی کنید و مهم‌ترین سناریوها را شناسایی کنید.

گام ۳: مدل‌سازی جریان کاری اصلی

از یک نمودار فعالیت برای نمایش موارد زیر استفاده کنید:

• جریان عادی

• تصمیم‌ها

• مسئولیت‌ها

• کار موازی

• استثناها

گام ۴: انتخاب سناریوهای حیاتی

برای تعاملاتی که مهم، پیچیده، پرریسک یا وابسته به یکپارچه‌سازی هستند، نمودارهای توالی ایجاد کنید.

گام ۵: تعریف ساختار دامنه

یک نمودار کلاس مفهومی یا در سطح طراحی برای مفاهیم درگیر در آن سناریوها ایجاد کنید.

گام ۶: تعیین مرزهای معماری

از یک نمودار کامپوننت برای نمایش موارد زیر استفاده کنید:

• ماژول‌ها یا سرویس‌های اصلی

• رابط‌ها

• وابستگی‌ها

• مالکیت

• نقاط یکپارچه‌سازی

گام ۷: استقرار مدل

زمانی که زیرساخت، امنیت، مقیاس‌پذیری، در دسترس بودن یا عملیات نگرانی‌های مهمی هستند، یک نمودار استقرار ایجاد کنید.

گام ۸: چرخه‌های حیات مدل

برای موجودیت‌هایی که رفتار آن‌ها به وضعیت یا گذارهای مجاز وابسته است، نمودارهای ماشین حالت ایجاد کنید.

گام ۹: اعتبارسنجی

مدل‌ها را با موارد زیر مقایسه کنید:

• نیازمندی‌ها

• کد موجود

• آزمون‌ها

• ساختارهای داده

• زیرساخت

• محدودیت‌های عملیاتی

گام ۱۰: نگهداری

زمانی که رفتار، رابط‌ها، مالکیت یا استقرار تغییر می‌کند، نمودارهای متأثر را به‌روزرسانی کنید.

۲۲. حداقل تحویل‌دادنی برای یک سیستم معمولی

برای یک برنامه با اندازه متوسط، یک مبنای عملی ممکن است شامل موارد زیر باشد:

• یک نمای زمینه سیستم یا نمای مورد استفاده

• دو تا پنج نمودار فعالیت برای فرآیندهای کسب‌وکار مهم

• دو تا پنج نمودار توالی برای سناریوهای حیاتی

• یک نمودار کلاس دامنه

• یک نمودار مؤلفه

• یک نمودار استقرار تولید

• نمودارهای ماشین حالت برای موجودیت‌های کلیدی چرخه حیات

این یک سهمیه اجباری نیست. برخی سیستم‌ها ممکن است به نمودارهای کمتری نیاز داشته باشند؛ برخی دیگر ممکن است به نمودارهای بیشتری نیاز داشته باشند. تعداد مناسب به پیچیدگی، ریسک، اندازه تیم، مقررات و هزینه سوءتفاهم بستگی دارد.

۲۳. استراتژی انتخاب ابزار

ابزارهای مختلف نیازهای مدل‌سازی متفاوتی را برآورده می‌کنند.

یک تیم نیازی ندارد برای هر موقعیتی یک ابزار انتخاب کند. یک رویکرد ترکیبی می‌تواند به خوبی کار کند اگر منبع حقیقت و مسئولیت‌های نگهداری مشخص باشند.

نتیجه‌گیری

یک استراتژی عملیاتی UML درباره استفاده از هر نوع نمودار نیست. بلکه درباره انتخاب کوچک‌ترین مجموعه‌ای از دیدگاه‌هاست که سیستم را قابل درک می‌کند.

هسته هفت‌نموداری پوشش گسترده‌ای ارائه می‌دهد:

• نمودارهای مورد استفاده اهداف و دامنه را توضیح می‌دهند.

• نمودارهای فعالیت گردش کارها و مسئولیت‌ها را توضیح می‌دهند.

• نمودارهای توالی همکاری و زمان‌بندی را توضیح می‌دهند.

• نمودارهای کلاس ساختار و مفاهیم دامنه را توضیح می‌دهند.

• نمودارهای مؤلفه مرزهای معماری را توضیح می‌دهند.

• نمودارهای استقرار محل اجرا و زیرساخت را توضیح می‌دهند.

• نمودارهای ماشین حالت قوانین چرخه عمر را توضیح می‌دهند.

Visual Paradigm می‌تواند از مدل‌سازی گرافیکی، ردیابی و همکاری مبتنی بر مخزن پشتیبانی کند. VPasCode و PlantUML نمودارها را برای نسخه‌بندی، بررسی، تولید و نگهداری با کد منبع آسان‌تر می‌کنند. هوش مصنوعی می‌تواند پیش‌نویس، تبدیل و بررسی را تسریع کند، اما خروجی آن باید با الزامات واقعی، پیاده‌سازی واقعی و محدودیت‌های عملیاتی مقایسه شود.

قوی‌ترین تمرین مدل‌سازی انضباطی است، نه جامع:

1. تصمیمات، ریسک‌ها و رفتارهای مهم را مدل کنید.

2. نوع نموداری را انتخاب کنید که بهترین پاسخ را به سوال می‌دهد.

3. هر نمودار را بر روی یک سطح انتزاعی متمرکز نگه دارید.

4. نمودارهای مرتبط را از طریق نام‌های یکسان و قابلیت ردیابی به هم متصل کنید.

5. مدل‌ها را در برابر الزامات، کد، تست‌ها و استقرار اعتبارسنجی کنید.

6. نمودارها را به عنوان آثار قابل نگهداری پروژه ذخیره و بازبینی کنید.

7. نمودارهایی که دیگر ارزشی ارائه نمی‌دهند را حذف کنید.

UML کارآمد با تعداد نمودارهای تولید شده سنجیده نمی‌شود. بلکه با این سنجیده می‌شود که آیا مدل‌ها به افراد کمک می‌کنند تا با اطمینان بیشتری سیستم را بسازند، تست کنند، عملیاتی کنند و تغییر دهند.

منبع

1. VPasCode: نمودار-به-کد با کمک هوش مصنوعی با استفاده از PlantUML، Mermaid و Graphviz: راهنمای رسمی که موتور متن-به-نمودار VPasCode، بهترین شیوه‌های نحو و جریان‌های کاری اصلاح با کمک هوش مصنوعی را پوشش می‌دهد.
2. از «کارهای نقاشی» به «بیان»: مروری بر چت‌بات هوش مصنوعی: توضیح می‌دهد که چت‌بات هوش مصنوعی Visual Paradigm چگونه زبان طبیعی را به UML و سایر نمودارهای مطابق با استانداردها تبدیل می‌کند.
3. توانمندسازی چت‌بات هوش مصنوعی Visual Paradigm با پایگاه دانش NotesKeep: نشان می‌دهد که چگونه مخازن NotesKeep را به عنوان منبع دانش برای تولید نمودارهای هدایت‌شده توسط هوش مصنوعی و ترکیب الزامات متصل کنید.
4. انقلاب در مدل‌سازی UML مک خود با Visual Paradigm: مروری بر پشتیبانی Visual Paradigm از UML 2.x، مهندسی کد و ردیابی مدل در macOS.
5. معرفی چت‌بات هوش مصنوعی VPP در Visual Paradigm 18.1: اعلامیه انتشار چت‌بات هوش مصنوعی VPP که به کاربران اجازه می‌دهد فایل‌های پروژه .vpp را از طریق زبان طبیعی جستجو کنند.
6. طرح‌ها و قیمت‌گذاری VPasCode: مقایسه قیمت و ویژگی‌ها برای لایه رایگان VPasCode و یکپارچه‌سازی با نسخه‌های آنلاین/دسکتاپ Visual Paradigm.
7. به VPasCode Visual Paradigm خوش آمدید: تحول نمودار-به-کد: معرفی جریان کاری نمودار-به-کد و محیط رندر یکپارچه برای PlantUML، Mermaid و Graphviz.
8. تولید نمودار هوش مصنوعی بومی در Visual Paradigm VPasCode: جزئیات هوش مصنوعی تعبیه‌شده VPasCode که نمودارهای PlantUML/Mermaid/Graphviz را مستقیماً درون ویرایشگر تولید و اصلاح می‌کند.

This post is also available in Deutsch, English, Español and Français.