نمودارهای کلاس UML برای مدلسازی داده با PlantUML

یک نمودار کلاس UML توصیف میکند که ساختاریک سیستم است: مواردی که مدل میکند، ویژگیهای آنها و نحوه ارتباط آنها. برای مدلسازی داده، میتواند مفاهیم حوزه و محدودیتها را قبل از تعهد به جداول یا کد برنامه نگهداری کند.

PlantUMLنمودار قابل تکرار میکند: متن مینویسید، آن را رندر میکنید، تغییرات را در کنترل نسخه بررسی میکنید و آن را هنگام تکامل مدل به روز میکنید. این امر با ساختارهای پایگاه داده، مهاجرتها و قوانین کسبوکار دقیق تکمیل میشود—نه جایگزین آنها.

1. سطح مدلسازی را انتخاب کنید

یک نمودار مدلسازی داده مفید معمولاً در هر زمان فقط بر یک سطح تمرکز میکند:

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

• منطقی:ویژگیها، شناسهها، ضرایب و قوانین، بدون اینکه مدل را به یک پایگاه داده خاص متصل کنید.

• فیزیکی:جزئیات اجرا مانند انواع ستونهای SQL، شاخصها و محدودیتهای ویژه پایگاه داده.

مثال زیر یک مدل دامنه منطقی. انواعی مانند UUID, Money, و DateTimeاین‌ها نمونه‌ای هستند؛ نمایش دقیق آن‌ها را هنگام انتخاب فناوری تعیین کنید.

2. اصول اولیه PlantUML

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

@startuml
class Customer {
  -id: UUID
  +name: String
  +email: String
  +changeEmail(newEmail: String): void
}
@enduml

نشانگرهای دیداری نشانه‌های مدل‌سازی اختیاری هستند:

• + عمومی

• - خصوصی

• # محافظت شده

• ~ دیده شدن بسته

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

3. روابط و چندگانگی

مفیدترین نمادهای رابطه برای مدل‌سازی داده‌ها عبارتند از:

برچسب‌های چندگانگی در نزدیکی انتهای ارتباط قرار دارند:

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

• 0..1 — اختیاری، حداکثر یکی

• * یا 0..* — صفر یا بیشتر

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

• 2..5 — یک محدوده محدود

برای مثال:

مشتری "1" -- "0..*" سفارش : ارسال می‌کند

برچسب‌های در هر انتهای رابطه را به دقت بخوانید: یک مشتری می‌تواند صفر یا چند سفارش ارسال کند؛ هر سفارش دقیقاً به یک مشتری مرتبط است. این برچسب‌ها رابطه را توصیف می‌کنند، نه لزوماً پیاده‌سازی کلید خارجی در یک پایگاه داده خاص.

4. مثال کاربردی: فروشگاه آنلاین

این مدل شامل مشتریان، سفارشات، آیتم‌های خطی، محصولات و ثبت‌های پرداخت است. این مدل شناسه‌ها، انواع شبیه به مقدار، یک مجموعه‌ای از مقادیر (enum)، ترکیب‌بندی و چندگانگی را نشان می‌دهد.

@startuml فضای فروشگاه
skinparam classAttributeIconSize 0
skinparam shadowing false

hide methods

class مشتری {
  +customerId: UUID
  +email: آدرسایمیل
  +displayName: رشته
}

class سفارش {
  +orderId: UUID
  +placedAt: تاریخ_زمان
  +status: وضعیت_سفارش
  +total: مبلغ
}

class خط_سفارش {
  +lineNumber: عدد صحیح
  +quantity: عددمثبت
  +unitPrice: مبلغ
}

class محصول {
  +productId: UUID
  +sku: کد_محصول
  +name: رشته
  +currentPrice: مبلغ
}

class پرداخت {
  +paymentId: UUID
  +amount: مبلغ
  +status: وضعیت_پرداخت
  +paidAt: تاریخ_زمان [0..1]
}

class مبلغ <<شیء_مقداری>> {
  +amount: اعشاری
  +currency: کد_ارز
}

enum وضعیت_سفارش {
  پیش‌نویس
  ارسال‌شده
  پرداخت‌شده
  انجام‌شده
  لغو‌شده
}

enum وضعیت_پرداخت {
  در انتظار
  تأییدشده
  ثبت‌شده
  شکسته
  بازپرداخت‌شده
}

مشتری "1" -- "0..*" سفارش : ارسال می‌کند
سفارش "1" *-- "1..*" خط_سفارش : شامل است
خط_سفارش "0..*" --> "1" محصول : به آن ارجاع دارد
سفارش "1" -- "0..*" پرداخت : تلاش‌های پرداخت
سفارش --> وضعیت_سفارش
پرداخت --> وضعیت_پرداخت
خط_سفارش --> مبلغ : قیمت واحد
پرداخت --> مبلغ : مبلغ

note right of خط_سفارش
  مقدار باید بیشتر از صفر باشد
  unitPrice قیمتی است که هنگام ارسال سفارش ثبت می‌شود
end note

note right of محصول
  قیمت_جداگانه_محصول ممکن است تغییر کند.
  این مقدار جایگزین قیمت_واحد_خط_سفارش نمی‌شود.
end note
@enduml

چرا مدل‌سازی کنیم OrderLine به طور صریح؟ رابطه بین یک سفارش و یک محصول داده‌های خود را دارد—تعداد و قیمت در زمان خرید. این موضوع آن را به یک مفهوم حوزه‌ای تبدیل می‌کند، نه فقط یک ارتباط ساده.

چرا ترکیب از Order به سمت OrderLine? این مثال فرض می‌کند که یک خط سفارش به یک سفارش تعلق دارد و به تنهایی معنی‌دار نیست. تنها زمانی از ترکیب استفاده کنید که این قاعده مالکیت و چرخه زندگی در حوزه شما درست باشد؛ نمادهای UML آن را در پایگاه داده الزام نمی‌کنند.

چرا قیمت‌های فعلی و تاریخی را متمایز کنیم؟ قیمت یک محصول ممکن است پس از ثبت سفارش تغییر کند. نگه داشتن قیمت زمان خرید در خط سفارش، مقدار تاریخی را حفظ می‌کند.

5. تصمیمات مدل‌سازی که اهمیت دارند

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

کلاس مشتری {
  +customerId: UUID <<PK>>
  +email: EmailAddress
}

مقادیر اختیاری: از [0..1] برای یک ویژگی اختیاری زمانی که برای خوانندگان شما واضح باشد، یا قاعده را ذکر کنید. به عنوان مثال، یک پرداخت ممکن است هیچ paidAtزمان‌چین تا زمانی که موفق شود داشته باشد.

شی‌های مقداری: نوعی مانند Money یا EmailAddress می‌تواند مفهومی با اعتبارسنجی یا معنای خود را نشان دهد. تصمیم بگیرید که آیا باید به صورت کلاس جداگانه، نوع ویژگی یا ساختار پایگاه داده ظاهر شود یا خیر، بسته به مخاطب و سطح جزئیات.

انواع و مقادیر کنترل شده: از یک نوع محدود (enum) زمانی استفاده کنید که مجموعه مجاز کوچک و نسبتاً پایدار باشد. اگر مقادیر نیاز به توضیحات مستقل، چرخه زندگی یا مدیریت داشته باشند، به جای آن آنها را به عنوان یک کلاس مدل کنید.

استانداردسازی و پیاده‌سازی: یک دیاگرام کلاس مفاهیم و قوانین را انتقال می‌دهد؛ اینکه هر جزئیات رابطه‌ای را تعیین نمی‌کند. به عنوان مثال، آیاپول به دو ستون، یک جدول جداگانه یا نوع ویژه پایگاه داده تبدیل شود، این یک تصمیم پیاده‌سازی است.

دیاگرام‌ها قابل خواندن باشند: یک حوزه بزرگ را به دیاگرام‌های متمرکز—مانند سفارش‌دهی، موجودی و هویت—تقسیم کنید و از بسته‌ها برای گروه‌بندی کلاس‌های مرتبط استفاده کنید. فقط ویژگی‌های مرتبط با سؤالی که دیاگرام قصد پاسخگویی به آن دارد را نشان دهید.

۶. مدل‌سازی از طریق نیازمندی‌ها

1. مفاهیم پیشنهادی را استخراج کنید از زبان حوزه: اسم‌ها اغلب نشان‌دهنده کلاس‌ها هستند؛ فعل‌ها اغلب نشان‌دهنده روابط یا رفتارها هستند.

2. قوانین را روشن کنید با سؤالات دقیق: آیا سفارشی بدون مشتری وجود دارد؟ آیا می‌تواند صفر خط داشته باشد؟ آیا پرداخت می‌تواند دوباره تلاش شود؟

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

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

5. محدودیت‌های تعداد را تنظیم کنید از قوانین کسب‌وکار، و بررسی هر دو انتهای هر رابطه.

6. موارد لبه‌ای را بررسی کنید: حذف، سوابق تاریخی، فیلدهای اختیاری، تلاش‌های مکرر، و تغییر مقادیر.

7. نمایش و بررسی این نمودار را با متخصصان حوزه و اجرایی‌ها بررسی کنید. آن را به عنوان یک مدل برای تأیید، نه فقط یک تصویر برای تأیید، در نظر بگیرید.

۷. از VPasCode و Visual Paradigm استفاده کنید

VPasCode یک ابزار مبتنی بر مرورگر است ویرایشگر متن به نمودار با پشتیبانی از PlantUML و پیش‌نمایش زنده. توضیحات ویژگی‌های آن همچنین شامل تولید و ویرایش هوش مصنوعی کد نمودار، و کمک به سینتکس است. یک روش عملی به شرح زیر است:

1. VPasCode را باز کنید و PlantUML را انتخاب یا وارد کنید.

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

3. بر روی منبع PlantUML تکرار و بهبود اعمال کنید؛ متن را به عنوان مدرک قابل نسخه‌برداری حفظ کنید.

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

5. هر کلاس، رابطه، چندگانگی و قانون کسب‌وکار تولید شده را خودتان تأیید کنید.

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

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

یک نمودار کلاس منطقی UML برای یک فروشگاه آنلاین ایجاد کنید. مشتریان سفارشات می‌دهند. هر سفارش شامل یک یا چند خط سفارش است. هر خط سفارش به یک محصول اشاره دارد و مقدار و قیمت واحد در زمان خرید را ذخیره می‌کند. سفارشات می‌توانند چندین تلاش پرداخت داشته باشند. شناسه‌ها، چندگانگی‌ها و مجموعه‌های وضعیت سفارش و پرداخت را شامل شود. فقط کد PlantUML خروجی دهید.

سپس قبل از پذیرش آن، خروجی را در برابر الزامات بررسی کنید. برای نتایج بهتر، فرضیات را به صورت صریح مشخص کنید—برای مثال، آیا سفارشات می‌توانند پیش‌نویس با خطوطی نداشته باشند، و آیا پرداخت‌ها قابل بازپرداخت هستند یا خیر.

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

8. یک لیست بررسی فشرده

قبل از به اشتراک گذاشتن یا اجرا کردن یک نمودار کلاس، بررسی کنید:

• آیا هر کلاس یک مفهوم معنادار در حوزه کاری را نشان می‌دهد؟

• آیا شناسه‌ها و ویژگی‌های مهم واضح هستند؟

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

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

• آیا اطلاعات تاریخی در جاهایی که مقادیر فعلی می‌توانند تغییر کنند حفظ شده‌اند؟

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

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

• آیا محتوای تولیدشده در برابر نیازهای واقعی بررسی شده است؟

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

This post is also available in Deutsch, English, Español, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文.