راهنمای عملی UML با Visual Paradigm و VPasCode

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

این راهنما از یک سیستم خرید آنلاین به عنوان مثال پیوسته استفاده می‌کند. این راهنما انواع اصلی نمودارهای UML و یک گردش کار با استفاده ازVisual Paradigmبرای مدل‌سازی بصری وVPasCodeبرای نمودارهای مبتنی بر متن.

۱. با سوالی که نمودار شما باید به آن پاسخ دهد شروع کنید

قبل از رسم، تصمیم بگیرید که خواننده باید چه چیزی را درک کند:

• کاربران چه کارهایی می‌توانند انجام دهند؟ از نمودار مورد استفاده (Use Case) استفاده کنید.

• در طول یک سناریو چه اتفاقی می‌افتد؟ از نمودار توالی یا فعالیت استفاده کنید.

• چه مفاهیم و روابطی حوزه را تشکیل می‌دهند؟ از نمودار کلاس استفاده کنید.

• نرم‌افزار چگونه به بخش‌های قابل استقرار یا قابل تعویض تقسیم می‌شود؟ از نمودارهای مؤلفه و استقرار استفاده کنید.

• یک شی چگونه در طول زمان تغییر می‌کند؟ از نمودار ماشین حالت استفاده کنید.

نموداری که تلاش می‌کند همه سوالات را همزمان پاسخ دهد، معمولاً خواندن آن دشوار می‌شود. ترجیح دهید چند نمودار متمرکز به جای یک نمای کلی شلوغ داشته باشید.

۲. خانواده‌های نمودارهای UML

UML 2.x شامل ۱۴ نوع استاندارد نمودار است که معمولاً به نمودارهای ساختاری و رفتاری گروه‌بندی می‌شوند. نمودارهای تعاملی زیرمجموعه‌ای از نمودارهای رفتاری هستند.

شما به ندرت برای یک پروژه به هر ۱۴ مورد نیاز دارید. برای بسیاری از طراحی‌های برنامه، یک نمودار مورد استفاده، کلاس، توالی، فعالیت، مؤلفه و استقرار، یک مجموعه شروع قوی هستند.

۳. کاربردی‌ترین نمودارها، با یک مثال تجارت الکترونیک

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

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

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

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

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

1. سبد خرید و آدرس را اعتبارسنجی کنید.

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

3. یک سفارش در انتظار ایجاد کنید.

4. درخواست مجوز پرداخت را ارسال کنید.

5. اگر پرداخت موفق بود، سفارش را تأیید کنید و واحد تحویل را مطلع سازید.

6. اگر پرداخت ناموفق بود، خطا را نمایش دهید و سفارش را بدون تأیید رها کنید.

از گره‌های تصمیم‌گیری و ادغام برای شاخه‌ها، گره‌های انشعاب و پیوند برای کارهای موازی، و شناورهای مسئولیت (swimlanes) زمانی که مسئولیت بین مشتری، فروشگاه و یک ارائه‌دهنده خارجی تغییر می‌کند، استفاده کنید.

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

نمودارهای توالی شرکت‌کنندگان و پیام‌های مبادله‌شده بین آن‌ها را نشان می‌دهند. آن‌ها به‌ویژه برای شفاف‌سازی مرزهای سرویس، ترتیب فراخوانی و موارد خطا مفید هستند. مسیرهای جایگزین را برای نتایجی مانند رد پرداخت یا ناموجود شدن موجودی اضافه کنید.

@startuml
actor Customer
participant "Storefront" as UI
participant "Order Service" as Orders
participant "Inventory Service" as Inventory
participant "Payment Provider" as Payment

Customer -> UI: submit checkout
UI -> Orders: placeOrder(cart, address)
Orders -> Inventory: reserve(items)

alt items available
    Inventory --> Orders: reservation confirmed
    Orders -> Payment: authorize(total)
    alt payment approved
        Payment --> Orders: approved
        Orders --> UI: order confirmed
        UI --> Customer: show confirmation
    else payment declined
        Payment --> Orders: declined
        Orders -> Inventory: release reservation
        Orders --> UI: payment failed
        UI --> Customer: show payment error
    end
else items unavailable
    Inventory --> Orders: reservation failed
    Orders --> UI: item unavailable
    UI --> Customer: show availability error
end
@enduml

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

نمودار کلاس: ساختار دامنه

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

• مشتری

• سفارش

• خط سفارش

• محصول

• پرداخت

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

انواع رایج رابطه:

• ارتباط: یک پیوند ساختاری عمومی.

• ارث‌بری/تعمیم: یک کلاس، گونه‌ای تخصصی از کلاس دیگر است.

• تجمع: یک رابطه کل-جزء که در آن اجزا می‌توانند به‌طور مستقل وجود داشته باشند؛ با احتیاط استفاده شود.

• ترکیب: یک رابطه کل-جزء قوی که در آن چرخه عمر جزء به کل وابسته است.

• وابستگی: یک عنصر از عنصر دیگری استفاده می‌کند یا به آن وابسته است.

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

نمودار ماشین حالت: قوانین چرخه عمر

از ماشین حالت استفاده کنید وقتی گذرهای مجاز یک شیء اهمیت دارند. یک سفارش ممکن است از مراحل زیر عبور کند:

در انتظار → در انتظار پرداخت → تأییدشده → انجام‌شده

همچنین ممکن است به لغو‌شده یا پرداخت ناموفق گذرها را با رویدادهای محرک یا گاردها برچسب‌گذاری کنید، مانند تأیید پرداخت یا [موجودی موجود]. این نمودار می‌تواند گذارهای نامعتبر را آشکار کند—برای مثال، آیا یک سفارش تکمیل‌شده قابل لغو است یا خیر.

نمودارهای مؤلفه و استقرار: نرم‌افزار و زمان اجرا

یک نمودار مؤلفهمسئولیت‌ها و وابستگی‌های نرم‌افزاری را نشان می‌دهد، مانند ویترین فروشگاه، سرویس سفارش، سرویس موجودی و سازگار پرداخت. این نمودار برای بحث درباره ماژولاریته و مرزهای یکپارچه‌سازی مفید است.

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

۴. مدل‌سازی خوب: قراردادهای عملی

• به هر نمودار یک عنوان واضح و یک هدف واحد بدهید.

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

• نمودارها را به اندازه‌ای نگه دارید که در اندازه مورد نظر قابل خواندن باشند.

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

• ارتباطات مهم و جریان‌های پیام را برچسب‌گذاری کنید.

• وقتی قوانین تعداد اهمیت دارند، به ارتباطات ضریب (چندتایی) اضافه کنید.

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

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

• تفاوت بین آنچه تأیید شده و آنچه پیشنهاد شده یا هنوز ناشناخته است را مشخص کنید.

• نمودارها را هنگام تغییر تصمیمات مهم طراحی یا رفتار به‌روز کنید.

UML را به عنوان یک ابزار ارتباطی در نظر بگیرید. یک نمودار می‌تواند از نظر دستوری معتبر باشد و همچنان گمراه‌کننده باشد اگر برچسب‌ها، فرضیات یا دامنه آن واضح نباشند.

۵. استفاده از Visual Paradigm

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

یک جریان کاری عملی:

1. یک پروژه ایجاد کنیدبرای سیستم یا حوزه محدودی که در حال مدل‌سازی آن هستید.

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

3. یک نمودار مورد استفاده ایجاد کنیدتا مرز و تعاملات اصلی را تعیین کنید.

4. نمودارهای رفتار را اضافه کنیدبرای سناریوهایی که بیشترین ریسک یا ابهام را دارند.

5. مدل کلاس را بسازیداطراف مفاهیم دامنه و قوانین آن‌ها.

6. نمای کامپوننت و استقرار را اضافه کنیداگر معماری یا محل استقرار در زمان اجرا نیاز به بحث دارد.

7. با ذینفعان بازبینی کنید.نام‌ها، دامنه، جریان‌های جایگزین و کاردری‌ها را بررسی کنید.

8. نمودارها را صادر یا به اشتراک بگذاریددر قالب‌های مناسب برای بازبینی و مستندسازی.

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

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

۶. استفاده از VPasCode

VPasCode یک ویرایشگر نمودار-به-کد مبتنی بر مرورگر از Visual Paradigm است. اطلاعات محصول آن از پشتیبانی از قالب‌های نمودار مبتنی بر متن از جمله PlantUML و Mermaid با رندر زنده صحبت می‌کند؛ همچنین صادراتی مانند SVG و PNG را نیز توصیف می‌کند.

یک گردش کار ساده:

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

2. یک اسکریپت نمودار بنویسید یا پیست کنید.

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

4. نام‌ها، روابط، چیدمان و مسیرهای خطا را اصلاح کنید.

5. یک تصویر برای سند یا بازبینی صادر کنید.

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

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

۷. یک گردش کار کامل و کاربردی

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

1. مورد استفاده:تعریف کنید چه کسی می‌تواند سفارش دهد و کدام سیستم‌های خارجی مشارکت دارند.

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

3. توالی: تعاملات را برای مسیرهای موفقیت، شکست پرداخت و ناموجود بودن موجودی با جزئیات بیان کنید.

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

5. ماشین حالت: چرخه حیات معتبر سفارش را مشخص کنید.

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

7. پیاده‌سازی: اگر تصمیمات زیرساخت مرتبط هستند، محل‌گذاری زمان اجرا را مستند کنید.

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

۸. اشتباهات رایج

• تلاش برای ترسیم کل سیستم به‌صورت یکجا: آن را بر اساس دغدغه یا سناریو تقسیم‌بندی کنید.

• اشتباه گرفتن فعالیت‌ها با توالی‌ها: فعالیت‌ها بر جریان کار تأکید دارند؛ توالی‌ها بر پیام‌ها در طول زمان تأکید می‌کنند.

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

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

• ترک کردن مسیرهای جایگزین: شکست‌ها و لغوها اغلب نیازمندی‌های مهمی را آشکار می‌کنند.

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

• اجازه کهنه شدن نمودارها: یک نمودار قدیمی می‌تواند بدتر از نداشتن هیچ نموداری باشد، زیرا خوانندگان ممکن است به آن اعتماد کنند.

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

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