فراتر از کلاس‌های منزوی: طراحی ساختار سیستم از طریق روابط UML و PlantUML

PlantUML Edit PlantUML in VPasCode

@startuml
skinparam style strictuml
skinparam classFontSize 14
skinparam defaultFontSize 12

title 1. ارتباطات: اتصالات هم‌سطح در NexusMart

class مشتری
class رمزعبور
class ناظر
class نظریه

' جهت‌گیری یک‌طرفه (مشتری -> رمزعبور)
مشتری "1" --> "1" رمزعبور : با آن احراز هویت می‌کند

' ارتباط دوطرفه با نقش‌ها، چندگانگی و برچسب
ناظر "1" - "0..*" نظریه : می‌نویسد

note on link
  جهت خواندن UML: چپ به راست
  "1 ناظر 0..* نظریه(های) می‌نویسد"
end note

@enduml

2. تجمیع‌ها و ترکیب‌ها (سلسله مراتب کل-جزء)

وقتی روابط معنای نامتقارن «کل-جزء» را بیان کنند، UML بین تجمیع مشترک (چرخه‌زندگی مستقل) و ترکیب (مالکیت چرخه‌زندگی سخت‌گیرانه) تفاوت قائل می‌شود.

اپلیکیشن NexusMart

تجمیع مشترک: کاتالوگ حاوی محصول نمونه‌ها. حذف یک کاتالوگ منتج به حذف محصولات نمی‌شود؛ آن‌ها در پایگاه داده اصلی باقی می‌مانند.
ترکیب: سفارش مملوک مطلق آیتم سفارش نمونه‌ها. نابود کردن یک سفارش منجر به حذف همه آیتم‌های خطی آن می‌شود.

پیاده‌سازی PlantUML

PlantUML Edit PlantUML in VPasCode

@startuml
skinparam style strictuml

title 2. تجمیع‌ها در مقابل ترکیب‌ها: معانی چرخه‌زندگی

class کاتالوگ
class محصول
class سفارش
class آیتم سفارش

' تجمیع مشترک: الماس باز، چرخه‌زندگی مستقل
کاتالوگ "1" o-- "*" محصول : حاوی است

' ترکیب: الماس پر شده، ارتباط سخت‌گیرانه چرخه‌زندگی
سفارش "1" *-- "1..*" آیتم سفارش : شامل است

note right of سفارش
  ترکیب به حذف زنجیره‌ای اشاره دارد.
  آیتم سفارش بدون سفارش والد خود نمی‌تواند وجود داشته باشد.
end note

@enduml

3. کلی‌تر شدن (ارث‌بری)

کلی‌تر شدن رابطه تکسونومیک «یک نوع از» را برقرار می‌کند. زیرکلاس‌ها ساختار و رفتار از یک کلاس اصلی به ارث می‌برند و آن را از طریق ویژگی‌های اضافه شده، عملیات بازنویسی شده یا وضعیت‌های محدود شده تخصصی‌تر می‌کنند. انواع قدرتی می‌توانند زیرکلاس‌ها را بیشتر بر اساس طبقه‌بندی زمان اجرا تقسیم کنند.

اپلیکیشن NexusMart

پرداخت به عنوان یک کلاس اصلی مجازی عمل می‌کند.
پرداخت با کارت اعتباری, پرداخت پی‌پال, و پرداخت کریپتوآن را با ویژگی‌های مخصوص درگاه و منطق اعتبارسنجی تخصصی کنید.

پیاده‌سازی PlantUML

PlantUML Edit PlantUML in VPasCode

@startuml
skinparam style strictuml

title 3. تعمیم: سلسله مراتب ارث‌گیری پرداخت

کلاس مجازی Payment {
  +amount: Decimal
  +currency: String
  +process(): Boolean
}

class CreditCardPayment {
  +cardNumber: String
  +expiryDate: Date
  +cvv: String
  +validateCard(): Boolean
}

class PayPalPayment {
  +payerEmail: String
  +transactionId: String
  +verifyPayPalAccount(): Boolean
}

class CryptoPayment {
  +walletAddress: String
  +blockchainNetwork: String
  +confirmOnChain(): Boolean
}

Payment <|-- CreditCardPayment
Payment <|-- PayPalPayment
Payment <|-- CryptoPayment

@enduml

4. وابستگی‌ها (دینامیک مشتری-تامین‌کننده)

وابستگی یک رابطه جهت‌دار «استفاده» است که در آن تغییر در تامین‌کننده ممکن است باعث تغییر در مشتری شود. UML از استایل‌ها برای روشن‌سازی ماهیت وابستگی استفاده می‌کند و یک پیکان نقطه‌چین مبهم را به یک قرارداد معماری دقیق تبدیل می‌کند.

ارجاع به استایل وابستگی

استایل	هدف / توضیحات
`«استفاده»`	مشتری نیاز دارد تامین‌کننده توابع داخلی را اجرا کند.
`«ایجاد»`	عملیات مشتری اشیاء کلاس تامین‌کننده را ایجاد می‌کنند.
`«ایجاد نمونه»`	مسیر مشخص ایجاد نمونه در طول عمر اجرایی.
`«استنتاج»`	مقدار هدف به صورت محاسباتی از یک عنصر منبع استخراج می‌شود.
`«انجام دادن»`	مشتری مشخصات رفتاری تعریف‌شده توسط تامین‌کننده را پیاده‌سازی می‌کند.
`«جزئی‌سازی»`	مشتری یک فرمول‌بندی سطح پایین‌تر و دقیق‌تر از تامین‌کننده را نمایش می‌دهد.
`«ردیابی»`	تکامل تاریخی یا مفهومی را در سطوح مختلف انتزاع ردیابی می‌کند.
`«اجازه دادن»`	تامین‌کننده دسترسی ویژه به اجزای خصوصی خود را برای مشتری اعطا می‌کند.
`«جایگزین»`	مشتری در زمان اجرا شرایط قرارداد اجرایی مورد انتظار از تأمین‌کننده را برآورده می‌کند.

اپلیکیشن نکسوس مارت

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

پیاده‌سازی PlantUML

PlantUML Edit PlantUML in VPasCode

@startuml
skinparam style strictuml

title 4. وابستگی‌ها: قراردادهای مشتری-تأمین‌کننده

class سرویس_سفارش
class مشتری_موجودی
class سفارش
class فاکتور
class داشبورد_تحلیلی

سرویس_سفارش .--> مشتری_موجودی : «از»
سفارش .--> فاکتور : «ایجاد»
داشبورد_تحلیلی .--> سفارش : «استخراج»

note bottom of سرویس_سفارش
  وابستگی‌ها اتصالات ساختاری موقت هستند.
  این امر مالکیت یا بسته‌بندی چرخه عمر را نشان نمی‌دهد.
end note

@enduml

5. کلاس‌های ارتباطی

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

اپلیکیشن نکسوس مارت

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

پیاده‌سازی PlantUML

PlantUML Edit PlantUML in VPasCode

@startuml
skinparam style strictuml

title 5. کلاس ارتباطی: استانداردسازی ارتباطات چند به چند

class مشتری
class محصول

' ارتباط پایه چند به چند
مشتری "*" - "*" محصول

' کلاس ارتباطی که متادیتا مخصوص ارتباط را ثبت می‌کند
class ثبت خرید {
  +تاریخ خرید: تاریخ و زمان
  +قیمت واحد: اعشاری
  +مقدار: عدد صحیح
  +محاسبه مجموع جزئی: اعشاری
}

' خط نقطه‌ای که کلاس ارتباطی را به رابطه متصل می‌کند
(مشتری، محصول) .. ثبت خرید

note right of ثبت خرید
  کلاس‌های ارتباطی پیچیدگی M:N را با
  ارتقاء ارتباط به موجودیتی اولیه حل می‌کنند.
end note

@enduml

6. دستورالعمل‌ها، نکات و جزئیات تدریجی

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

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

گروه‌بندی بر اساس زمینه دامنه: کلاس‌ها را در اطراف زمینه‌های محدود (مثلاً سفارش‌دهی, کاتالوگ, پرداخت‌ها) برای کاهش بار شناختی و جلوگیری از چیدمان‌های پیچیده و بی‌نظم
حذف ارتباطات خام M:N: ارتباطات بدون محدودیت * به * را در مراحل اولیه تحلیل به کلاس‌های ارتباطی تبدیل کنید. این کار مدل را برای نقشه‌برداری رابطه‌ای و طراحی مبتنی بر دامنه آماده می‌کند.
تکمیل تدریجی بر اساس فاز:
- دامنه (نیازمندی‌ها): نام کلاس‌ها + ارتباطات کلی. بدون ویژگی‌ها/عملیات.
- تحلیل: محدودیت‌ها، نقش‌ها و ویژگی‌های کلیدی را اضافه کنید. روش‌ها را به تعویق بیندازید.
- طراحی: امضاها، محدودکننده‌های دیداری (+, -, #), استایل‌های پیاده‌سازی، و قراردادهای وابستگی.
کنترل‌های چیدمان PlantUML: از نشانه‌های جهتی (-چپ->, -پایین->, -راست->, -بالا->) برای اجبار به چیدمان تمیز و جلوگیری از تقاطع خطوط در نمودارهای پرجمعیت.

مثال چیدمان و جزئیات تدریجی PlantUML

PlantUML Edit PlantUML in VPasCode

@startuml
skinparam style strictuml
skinparam linetype ortho

title 6. کنترل چیدمان و جزئیات تدریجی (مرحله طراحی)

package "زمینه سفارش‌دهی" {
  class Order {
    -orderId: UUID
    -status: OrderStatus
    +submit(): void
    +cancel(): void
  }
  class OrderItem {
    -quantity: int
    -price: Decimal
    +getLineTotal(): Decimal
  }
}

package "زمینه پرداخت" {
  abstract class Payment {
    +process(): boolean
  }
  class CreditCardPayment {
    -cardToken: String
    +validate(): boolean
  }
}

' چیدمان جهت‌دار اجباری برای خوانایی
Order "1" *-- "1..*" OrderItem : شامل >
Order -راست-> Payment : پرداخت از طریق >
Payment <|-- CreditCardPayment

note as N1
  مدل مرحله طراحی شامل:
  - محدودکننده‌های دیداری (+, -)
  - امضا عملیات
  - مسیریابی خطوط عمودی
  - بسته‌بندی مبتنی بر زمینه
end note

@enduml