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

UML به عنوان یک استاندارد صنعتی توسط گروه مدیریت اشیاء (OMG) مدیریت میشود و همچنین از طریق استانداردهای بینالمللی نیز پذیرفته شده است. UML مدرن معمولاً به UML 2.x اشاره دارد که مجموعهای گسترده از نمودارهای ساختاری و رفتاری را تعریف میکند. به عنوان مثال، UML 2.2، ۱۴ نوع نمودار را تعریف کرد که به طور مساوی بین مدلسازی ساختاری و رفتاری تقسیم شدهاند.
UML چیست؟
UML یک زبان مدلسازی عمومی برای سیستمهای نرمافزار-محور است. این زبان یک نمادگذاری استاندارد برای نمایش موارد زیر فراهم میکند:
-
اجزای سیستم
-
کلاسها و اشیاء
-
الزامات کاربران
-
جریانهای کاری و فرآیندهای کسبوکار
-
پیامهای مبادلهشده بین اشیاء
-
حالتها و گذارهای سیستم
-
محیطهای استقرار نرمافزار
-
وابستگیهای بین بستهها و اجزا
هدف از UML جایگزین کردن کد منبع نیست. بلکه، این استاندارد به تیمها کمک میکند تا پیش از اجرا، در حین آن و پس از آن، درباره یک سیستم فکر کرده و آن را مبادله کنند.
یک مدل UML میتواند در سطوح مختلف جزئیات ایجاد شود:
-
سطح مفهومی:مفاهیم اصلی کسبوکار را بدون جزئیات پیادهسازی توصیف میکند.
-
سطح تحلیل:نیازمندیها، مسئولیتها و رفتار سیستم را کاوش میکند.
-
سطح طراحی:کلاسها، رابطها، اجزا و تعاملات را تعریف میکند.
-
سطح پیادهسازی:جزئیاتی را نشان میدهد که بهطور نزدیک با کد منبع و زیرساخت استقرار مطابقت دارند.
چرا UML مهم است؟
UMLمفید است، زیرا سیستمهای نرمافزاری زمانی که تنها از طریق کد منبع یا اسناد مکتوب طولانی توصیف شوند، میتوانند درکناپذیر شوند.
سیستمهای پیچیده را ساده میکند
نمودارها نمای کلی بصری از سیستمهای بزرگ ارائه میدهند. به عنوان مثال، یک نمودار کلاس میتواند دهها کلاس و روابط آنها را شفافتر از چندین صفحه متن نشان دهد.
ارتباط را بهبود میبخشد
توسعهدهندگان، طراحان، معماران، آزمونکنندگان، تحلیلگران کسبوکار و مشتریان ممکن است پیشینههای فنی متفاوتی داشته باشند. UML به آنها یک زبان بصری مشترک برای بحث درباره نیازمندیهای سیستم و تصمیمات طراحی میدهد.
از برنامهریزی پشتیبانی میکند
تیمها میتوانند پیش از نوشتن کد، جریانهای کاری، کلاسها، خدمات و محیطهای استقرار را مدلسازی کنند. این کار میتواند نیازمندیهای گمشده، مسئولیتهای تکراری و مشکلات معماری را در مراحل اولیه آشکار کند.
به مستندسازی نرمافزار کمک میکند
نمودارهای UML میتوانند به عنوان مستندات فنی بلندمدت مورد استفاده قرار گیرند. آنها به توسعهدهندگان جدید کمک میکنند تا یک سیستم موجود را درک کنند و به تیمهای نگهداری در زمان نیاز به تغییرات کمک میکنند.
طراحی بهتر را تشویق میکند
ایجاد یک مدل تیم را مجبور میکند تا به پرسشهایی از این دست بپردازد:
-
کدام شیء مسئول یک وظیفه است؟
-
اجزا چگونه به هم متصل شدهاند؟
-
وقتی یک عملیات شکست میخورد چه اتفاقی میافتد؟
-
کدام کلاسها به یکدیگر وابسته هستند؟
-
سیستم چگونه به رویدادهای مختلف واکنش نشان میدهد؟
مفاهیم کلیدی UML

کلاس
یک کلاس یک الگو است که ویژگیها و عملیات مشترک بین گروهی از شیءها را تعریف میکند.
برای مثال، یک سفارشکلاس ممکن است شامل موارد زیر باشد:
-
ویژگیها:
شناسه سفارش,تاریخ سفارش، ووضعیت -
عملیات:
calculateTotal()وcancelOrder()
شیء
یک شیء، نمونهی واقعی یک کلاس است. اگر سفارش یک کلاس باشد، order1001 ممکن است یک شیء خاص باشد که از آن کلاس ایجاد شده است.
ویژگی
یک ویژگی، دادهای را که توسط یک کلاس یا شیء نگهداری میشود، نشان میدهد.
نمونهها شامل موارد زیر هستند:
-
name -
price -
emailAddress -
orderStatus
عملیات
یک عملیات، رفتاری را که توسط یک کلاس ارائه میشود، نشان میدهد. عملیاتها اغلب بهعنوان روشها در زبانهای برنامهنویسی پیادهسازی میشوند.
نمونهها شامل موارد زیر هستند:
-
addItem() -
submitPayment() -
sendNotification()
نقشگر
یک نقشگر یک نقش خارجی است که با یک سیستم تعامل دارد. یک نقشگر میتواند یک فرد، یک سیستم دیگر، یا یک دستگاه خارجی باشد.
نمونهها شامل موارد زیر هستند:
-
مشتری
-
مدیر
-
درگاه پرداخت
-
سیستم انبار
رابط
یک رابط مجموعهای از عملیات را تعریف میکند که یک کلاس یا مؤلفه متعهد به ارائه آنها میشود. رابطها به کاهش وابستگیها و پشتیبانی از پیادهسازیهای قابل تعویض کمک میکنند.
رابطه
یک رابطه توصیف میکند که عناصر UML چگونه به هم متصل شدهاند. روابط رایج شامل وابستگی، وابستگی، تعمیم، تجمیع و ترکیب هستند.
چندتایی
چندتایی مشخص میکند که چند شیء میتوانند در یک رابطه شرکت کنند.
نمونههای رایج شامل موارد زیر هستند:
-
1: دقیقاً یکی -
0..1: صفر یا یکی -
*: چندین -
1..*: یکی یا بیشتر -
0..*: صفر یا بیشتر
برای مثال، یک مشتری ممکن است صفر یا چندین سفارش ثبت کند. این را میتوان به صورت زیر نمایش داد:
مشتری ۱ -------- ۰..* سفارش
دستهبندیهای نمودارهای UML
نمودارهای UMLبه طور معمول به دو دسته اصلی تقسیم میشوند:
-
نمودارهای ساختاری
-
نمودارهای رفتاری
نمودارهای ساختاری توصیف میکنند که یک سیستم از چه اجزایی تشکیل شده است. نمودارهای رفتاری توصیف میکنند که یک سیستم چه کاری انجام میدهد و چگونه در طول زمان رفتار میکند.

نمودارهای ساختاری UML
نمودارهای ساختاری سازماندهی ثابت یک سیستم را نشان میدهند. آنها بر روی کلاسها، اشیاء، اجزا، بستهها، گرهها و روابط تمرکز دارند.
۱. نمودار کلاس

نمودار کلاس یکی از پرکاربردترین نمودارهای UML است. آن ساختار ثابت یک سیستم را با نمایش موارد زیر نشان میدهد:
-
کلاسها
-
ویژگیها
-
عملیاتها
-
رابطها
-
روابط
-
دیدهشدن
-
تکثیر
یک مدل کلاس سادهشده تجارت الکترونیک ممکن است به این شکل باشد:
مشتری
- customerId
- name
+ placeOrder()
سفارش
- orderId
- orderDate
- status
+ calculateTotal()
محصول
- productId
- name
- price
+ updatePrice()
روابط ممکن شامل موارد زیر هستند:
مشتری 1 -------- 0..* سفارش
سفارش 1 -------- 1..* محصول
در یک طراحی دقیقتر، یک OrderItem کلاس ممکن است بین سفارش و محصول.
نمودارهای کلاس برای موارد زیر مفید هستند:
-
مدلسازی دامنه
-
طراحی شیگرا
-
برنامهریزی پایگاه داده و برنامه
-
شناسایی مسئولیتها
-
توضیح وراثت و رابطها
نمودار کلاس بهطور کلی کلاسها را توصیف میکند، در حالی که نمودار شیء، نمونههای خاص آن کلاسها را نشان میدهد. Visual Paradigm نمودارهای کلاس را بهعنوان مدلهایی از کلاسها، ویژگیها، عملیات و روابط درون یک سیستم شیگرا توصیف میکند.
۲. نمودار شیء
نمودار شیء، تصویری لحظهای از یک سیستم در یک لحظه خاص را نشان میدهد. این نمودار نمونههای واقعی شیء را بهجای کلاسهای عمومی نمایش میدهد.

برای مثال:
customerA:Customer
name = "Alex"
order1001:Order
status = "Paid"
نمودار شیء زمانی مفید است که نیاز به نمایش موارد زیر دارید:
-
وضعیت شیءها در زمان اجرا
-
رابطههای نمونه دادهها
-
یک سناریوی خاص
-
نحوه اتصال نمونههای کلاسها
یک نمودار کلاس ممکن است نشان دهد که یک مشتری میتواند سفارشهای متعددی ثبت کند. یک نمودار شیء ممکن است نشان دهد که customerA در حال حاضر مالک order1001 و order1002.
۳. نمودار مؤلفه

یک نمودار مؤلفه، سازماندهی و وابستگیهای مؤلفههای نرمافزاری قابل تعویض را نشان میدهد.
یک نمودار مؤلفه تجارت الکترونیک ممکن است شامل موارد زیر باشد:
-
وباپلیکیشن
-
خدمت سفارش
-
خدمت محصول
-
خدمت پرداخت
-
خدمت اطلاعرسانی
-
پایگاه داده
مثال:
وباپلیکیشن --> خدمت سفارش
خدمت سفارش --> خدمت پرداخت
خدمت سفارش --> خدمت اطلاعرسانی
خدمت سفارش --> پایگاه داده سفارش
نمودارهای مؤلفه بهویژه برای موارد زیر مفید هستند:
-
معماریهای میکروسرویس
-
سیستمهای مبتنی بر سرویس
-
طراحی API
-
معماری برنامه
-
نمایش مرزهای سرویس و وابستگیها
۴. نمودار استقرار

یک نمودار استقرار، محیط فیزیکی یا مجازی را که نرمافزار در آن اجرا میشود، نشان میدهد.
ممکن است نشان دهد:
-
دستگاههای کلاینت
-
سرورهای وب
-
سرورهای برنامه
-
سرورهای پایگاه داده
-
گرههای ابری
-
کانتینرها
-
اتصالات شبکه
-
قطعات نرمافزاری استقرار یافته
مثال:
دستگاه مشتری
|
v
سرور وب
|
v
سرور برنامه
|
v
سرور پایگاه داده
نمودارهای استقرار به معماران کمک میکنند تا بفهمند نرمافزار کجا اجرا میشود و اجزای زیرساخت چگونه با یکدیگر ارتباط برقرار میکنند.
۵. نمودار بستهها

یک نمودار بستهها، عناصر مدل مرتبط را در بستهها سازماندهی کرده و وابستگیها بین آن بستهها را نشان میدهد.
یک پروژه ممکن است شامل بستههایی مانند باشد:
-
کاربر -
فهرست -
سفارش -
پرداخت -
اعلان
مثال:
سفارش --> کاربر
سفارش --> کاتالوگ
سفارش --> پرداخت
پرداخت --> اعلان
نمودارهای بسته برای موارد زیر مفید هستند:
-
سازماندهی مدلهای بزرگ
-
نمایش وابستگیهای ماژولها
-
شناسایی لایههای معماری
-
جلوگیری از جفتشدگی ناخواسته
۶. نمودار ساختار ترکیبی

یک نمودار ساختار ترکیبی، ساختار داخلی یک کلاس، جزء یا طبقهبندیسازنده دیگر را نشان میدهد.
این نمودار میتواند موارد زیر را نمایش دهد:
-
اجزای داخلی
-
پورتها
-
اتصالات
-
همکاریهای داخلی
-
روابط بین عناصر داخلی
برای مثال، یک OrderControllerممکن است شامل یا متصل به موارد زیر باشد:
-
OrderService -
OrderRepository -
PaymentService -
NotificationService
برخلاف نمودار مؤلفه که معمولاً بر مؤلفههای سطح بالا تمرکز دارد، نمودار ساختار ترکیبی بر سازماندهی داخلی یک طبقهبندیکننده تمرکز میکند.
۷. نمودار پروفایل
نمودار پروفایل، UML را برای یک حوزه یا فناوری خاص گسترش میدهد. این نمودار عناصر مدلسازی تخصصی را از طریق استریوتایپها، مقادیر برچسبگذاریشده و قیود تعریف میکند.

برای مثال، یک پروفایل ممکن است استریوتایپهایی مانند موارد زیر را معرفی کند:
<<entity>>
<<controller>>
<<service>>
<<microservice>>
نمودارهای پروفایل زمانی مفید هستند که نیاز باشد نمادگذاری استاندارد UML برای موارد زیر سازگار شود:
-
وباپلیکیشنها
-
معماری سازمانی
-
سیستمهای بلادرنگ
-
سیستمهای نهفته
-
چارچوبهای برنامهنویسی خاص
-
مدلسازی خاص صنعت
نمودار پروفایل اغلب از فهرستهای مقدماتی حذف میشود، اما در میان انواع استاندارد نمودارهای UML 2.x گنجانده شده است. UML 2.x معمولاً به عنوان دارای هفت نوع نمودار ساختاری و هفت نوع نمودار رفتاری توصیف میشود.
نمودارهای رفتاری UML
نمودارهای رفتاری رفتار پویای یک سیستم را توصیف میکنند. آنها گردشکارها، رویدادها، تعاملات، تغییرات وضعیت و پاسخها را نشان میدهند.
۱. نمودار مورد استفاده

نمودار مورد استفاده، الزامات عملکردی یک سیستم را از دیدگاه بازیگران خارجی ارائه میدهد.
یک سیستم خرید آنلاین معمولی ممکن است شامل این بازیگران باشد:
-
مشتری
-
مدیر سیستم
-
درگاه پرداخت
-
خدمات تحویل
کاربردهای ممکن عبارتند از:
-
ثبت حساب کاربری
-
ورود به سیستم
-
مرور محصولات
-
افزودن محصول به سبد خرید
-
ثبت سفارش
-
انجام پرداخت
-
پیگیری تحویل
-
مدیریت محصولات
نمودار مورد استفاده، دیدگاهی کلی از عملکرد سیستم ارائه میدهد بدون اینکه جزئیات پیادهسازی را توصیف کند.
رابطههای مهم عبارتند از:
-
ارتباط:یک بازیگر را به یک مورد استفاده متصل میکند.
-
شامل:رفتاری را نشان میدهد که همواره توسط یک مورد استفاده دیگر بازنشانی میشود.
-
گسترش: رفتارهای اختیاری یا شرطی را نشان میدهد.
-
تعمیم:تخصصگرایی بین بازیگران یا موارد استفاده را نشان میدهد.
برای مثال، ثبت سفارشممکن است شامل انجام پرداخت، در حالی که اعمال تخفیفممکن است گسترش یابد ثبت سفارش.
۲. نمودار فعالیت

نمودار فعالیت، جریان کنترل را در یک فرآیند یا مورد استفاده نشان میدهد. این نمودار برای مدلسازی گردشکارهای متوالی و موازی مفید است.
مثال: ثبت سفارش
شروع
|
جستجوی محصولات
|
افزودن محصول به سبد
|
رفتن به مرحله پرداخت
|
وارد کردن جزئیات پرداخت
|
آیا پرداخت موفق بود؟
/
خیر بله
| |
نمایش خطا ایجاد سفارش
|
ارسال تأییدیه
|
پایان
نمودارهای فعالیت میتوانند موارد زیر را نشان دهند:
-
عملکردها
-
تصمیمها
-
ادغامها
-
حلقهها
-
فعالیتهای موازی
-
گرههای شروع و پایان
-
ناوهای مسئولیتها
ناوها میتوانند نشان دهند که هر اقدام توسط کدام بازیگر یا جزء سیستم انجام میشود. به عنوان مثال، یک ناه ممکن است نماینده مشتری، ناه دیگر نماینده سرویس سفارش، و ناه دیگر نماینده دروازه پرداخت باشد.
۳. نمودار توالی

یک نمودار توالی نشان میدهد که اشیاء یا اجزا چگونه به ترتیب زمانی با یکدیگر ارتباط برقرار میکنند.
مثال: ثبت سفارش
مشتری -> WebApp: ارسال سفارش
WebApp -> OrderService: createOrder()
OrderService -> PaymentService: authorizePayment()
PaymentService --> OrderService: paymentApproved
OrderService -> NotificationService: sendConfirmation()
OrderService --> WebApp: orderCreated
WebApp --> مشتری: نمایش تأییدیه
نمودارهای توالی شامل موارد زیر هستند:
-
شرکتکنندگان
-
خطوط حیات
-
پیامها
-
نوارهای فعالسازی
-
پیامهای بازگشتی
-
شرایط
-
حلقهها
-
گزینههای جایگزین
-
تعاملات موازی
آنها بهویژه برای توضیح فراخوانیهای API، تعاملات سرویس، جریانهای احراز هویت و مدیریت خطاها مفید هستند.
۴. نمودار ارتباطی

یک نمودار ارتباطی که در نسخههای قدیمیتر UML بهطور تاریخی به عنوان نمودار همکاری نامیده میشد، بر روابط بین اشیاء و پیامهای مبادلهشده بین آنها تأکید دارد.
بهجای تمرکز اصلی بر یک خط زمانی عمودی مانند نمودار توالی، بر موارد زیر تمرکز دارد:
-
اشیاء
-
پیوندها بین اشیاء
-
پیامهای شمارهگذاریشده
-
ساختار همکاری
مثال:
۱: submitOrder()
کاربر ----------------> وباپلیکیشن
۲: createOrder()
وباپلیکیشن ------------------> سرویس سفارش
۳: authorizePayment()
سرویس سفارش -------------> سرویس پرداخت
نمودارهای ارتباطی زمانی مفید هستند که ساختار همکاری اشیاء مهمتر از خط زمانی دقیق بصری باشد.
۵. نمودار ماشین حالت

یک نمودار ماشین حالت نشان میدهد که چگونه یک شیء یا سیستم در پاسخ به رویدادها حالت خود را تغییر میدهد.
یک سفارش ممکن است از حالتهای زیر عبور کند:
جدید -> در انتظار پرداخت -> پرداختشده -> ارسالشده -> تحویلشده
|
v
لغوشده
یک گذار میتواند با یک رویداد یا شرط برچسبگذاری شود:
در انتظار پرداخت -- پرداختتاییدشده --> پرداختشده
در انتظار پرداخت -- پرداختناموفق --> پرداختناموفق
نمودارهای ماشین حالت برای موارد زیر مفید هستند:
-
چرخههای عمر سفارش
-
حالتهای حساب کاربری
-
وضعیت گردش کار
-
رفتار دستگاه
-
حالتهای اتصال شبکه
-
فرآیندهای تأیید
آنها زمانی که رفتار یک شیء به شدت به وضعیت فعلی آن وابسته است، بهویژه ارزشمند هستند.
۶. نمودار زمانبندی

یک نمودار زمانبندی نشان میدهد که وضعیت یا مقدار یک یا چند عنصر چگونه در طول زمان تغییر میکند.
آن اغلب برای موارد زیر استفاده میشود:
-
سیستمهای بلادرنگ
-
سیستمهای نهفته
-
پروتکلهای ارتباطی
-
هماهنگی سختافزار و نرمافزار
-
تعاملات حساس به عملکرد
برای مثال، یک نمودار زمانبندی میتواند رابطه بین موارد زیر را نشان دهد:
-
یک سیگنال دستگاه
-
یک وضعیت کنترلکننده
-
یک مقدار سنسور
-
یک پاسخ در طول یک بازه زمانی مشخص
۷. نمودار نمای کلی تعامل

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

ارتباط
یک ارتباط نشاندهنده یک اتصال ساختاری بین دو عنصر است.
مشتری -------- سفارش
این نشان میدهد که مشتریان و سفارشها با هم مرتبط هستند.
ارتباط جهتدار
یک ارتباط جهتدار قابلیت پیمایش را در یک جهت نشان میدهد.
سفارش ------> پرداخت
این نشان میدهد که یک سفارش درباره یک شیء پرداخت آگاه است یا از آن استفاده میکند، در حالی که برعکس آن ممکن است صادق نباشد.
عمومیسازی
عمومیسازی نمایانگر وراثت یا تخصصیسازی است.
کاربر
/
مشتری مدیر
در اینجا، مشتری و مدیر انواع تخصصیشدهی کاربر.
وابستگی
وابستگی نشان میدهد که یک عنصر بهطور موقت از عنصر دیگری استفاده میکند یا به آن متکی است.
OrderService - - - -> PaymentGateway
تغییری در درگاه پرداخت ممکن است بر سرویس سفارش تأثیر بگذارد.
تجمع
تجمع نمایانگر رابطهی کل-جزء است که در آن اجزا میتوانند بهطور مستقل وجود داشته باشند.
تیم ◇------ بازیکن
یک بازیکن ممکن است حتی اگر تیم منحل شود، همچنان وجود داشته باشد.
ترکیب
ترکیب نشاندهنده یک رابطه قوی کل-جزء است. اجزا بهطور کلی برای چرخه حیات خود به کل وابسته هستند.
سفارش ◆------ آیتم سفارش
یک آیتم سفارشمیتواند بهعنوان بخشی از یک سفارش در نظر گرفته شود و ممکن است در خارج از آن سفارش معنایی نداشته باشد.
اجرا
اجرا نشان میدهد که یک کلاس یا مؤلفه یک رابط را پیادهسازی میکند.
PaymentService - - -|> PaymentProcessor
خدمات پرداخترفتار تعریفشده توسط پردازشگر پرداخت رابط را فراهم میکند.
مثال UML: سیستم خرید آنلاین
به یک برنامه خرید آنلاین توجه کنید.
نقشهای اصلی
-
مشتری
-
مدیر
-
درگاه پرداخت
-
خدمات تحویل
کاربردهای اصلی
-
ایجاد حساب کاربری
-
مرور محصولات
-
افزودن اقلام به سبد خرید
-
ثبت سفارش
-
انجام پرداخت
-
ردیابی ارسال
-
مدیریت موجودی
کلاسهای ممکن
مشتری
محصول
سبد خرید
اقلام سبد خرید
سفارش
اقلام سفارش
پرداخت
ارسال
اجزای سرویس ممکن
سرویس کاربر
سرویس کاتالوگ
سرویس سبد خرید
سرویس سفارش
سرویس پرداخت
سرویس حملونقل
سرویس اطلاعرسانی
مثال تعامل
وقتی مشتری سفارشی ثبت میکند:
-
مشتری سبد خرید را ارسال میکند.
-
وباپلیکیشن درخواست را به سرویس سفارش ارسال میکند.
-
سرویس سفارش اقلام را اعتبارسنجی میکند.
-
سرویس پرداخت، پرداخت را تأیید میکند.
-
سفارش ذخیره میشود.
-
سرویس حملونقل مطلع میشود.
-
سرویس اعلان، یک ایمیل تأیید ارسال میکند.
این فرآیند کسبوکار واحد ممکن است از طریق چندین نمودار UML نمایش داده شود:
-
نمودار مورد استفاده: نشان میدهد که مشتری میتواند سفارش دهد.
-
نمودار فعالیت: گردش کار و نقاط تصمیمگیری را نشان میدهد.
-
نمودار توالی: پیامها بین سرویسها را نشان میدهد.
-
نمودار کلاس: نشان میدهد
مشتری,سفارش,محصولو کلاسهای مرتبط. -
نمودار مؤلفه: سرویسهای درگیر را نشان میدهد.
-
نمودار استقرار: محل اجرای آن سرویسها را نشان میدهد.
چگونه نمودار مناسب UML را انتخاب کنیم
| هدف مدلسازی | نمودار UML پیشنهادی |
|---|---|
| نمایش کلاسها و روابط آنها | نمودار کلاس |
| نمایش نمونههای واقعی اشیاء | نمودار شیء |
| توضیح عملکرد سیستم | نمودار مورد استفاده |
| مدلسازی گردش کار کسبوکار یا سیستم | نمودار فعالیت |
| نمایش پیامهای مبادلهشده در طول زمان | نمودار توالی |
| نمایش همکاری شیء | نمودار ارتباطی |
| نمایش چرخه حیات و تغییرات وضعیت | نمودار ماشین وضعیت |
| نمایش ماژولها یا خدمات نرمافزاری | نمودار مؤلفه |
| نمایش استقرار فیزیکی | نمودار استقرار |
| سازماندهی عناصر مدل | نمودار بسته |
| نمایش اجزای داخلی یک طبقهبند | نمودار ساختار ترکیبی |
| نمایش تغییرات در طول زمان | نمودار زمانبندی |
| خلاصهای از چندین تعامل | نمودار نمای کلی تعامل |
| گسترش UML برای یک حوزه تخصصی | نمودار پروفایل |
یک رویکرد خوب در مدلسازی این است که تنها نمودارهایی را انتخاب کنید که به یک سوال خاص پاسخ میدهند. ایجاد تمام نمودارهای ممکن UML میتواند مستندات را بهصورت غیرضروری پیچیده کند.
UML و چرخه حیات توسعه نرمافزار
UML میتواند از بسیاری از مراحل توسعه نرمافزار پشتیبانی کند.
تحلیل نیازمندیها
نمودارهای مورد استفاده به شناسایی بازیگران و عملکرد سیستم کمک میکنند. نمودارهای فعالیت میتوانند فرآیندهای کسبوکار و گردش کارها را شفاف کنند.
تحلیل سیستم
نمودارهای کلاس میتوانند مفاهیم حوزه را نمایش دهند. نمودارهای توالی میتوانند به تحلیلگران کمک کنند تا درک کنند که چگونه مورد استفادهها محقق میشوند.
طراحی معماری
نمودارهای مؤلفه، بسته و استقرار به تعریف ساختار برنامه و زیرساخت آن کمک میکنند.
طراحی دقیق
نمودارهای کلاس، نمودارهای توالی، نمودارهای ماشین حالت و نمودارهای ساختار ترکیبی میتوانند مسئولیتهای پیادهسازی و تعاملات شیء را توصیف کنند.
توسعه
توسعهدهندگان میتوانند از مدلها بهعنوان مرجع در حین پیادهسازی کلاسها، سرویسها، APIها و ساختارهای پایگاه داده استفاده کنند.
آزمون
آزمونکنندگان میتوانند سناریوها را از مورد استفادهها، نمودارهای فعالیت و نمودارهای توالی استخراج کنند. نمودارهای ماشین حالت میتوانند به شناسایی گذارهای حالت معتبر و نامعتبر کمک کنند.
نگهداری
نمودارهای UML مستندات سیستمهای موجود را فراهم میکنند و به تیمها کمک میکنند تا تأثیر تغییرات پیشنهادی را ارزیابی کنند.
ایجاد نمودارهای UML با استفاده از Visual Paradigm
Visual Paradigm یک پلتفرم مدلسازی بصری و طراحی نرمافزار است که پشتیبانی از ایجاد نمودارهای UML را همراه با سایر فعالیتهای مدلسازی و توسعه فراهم میکند. قابلیتهای UML آن شامل نمودارهایی مانند کلاس، توالی، مورد استفاده، فعالیت، جزء، استقرار، ماشین حالت، بسته، شیء و ساختار ترکیبی است.
شروع یک پروژه UML
یک جریان کاری عملی در Visual Paradigm به شرح زیر است:
-
یک پروژه جدید ایجاد کنید.
-
مدل را در بستههایی مانند ” سازماندهی کنید:
نیازمندیها,مدل دامنه,خدمات” و “استقرار. -
یک نمودار مورد استفاده ایجاد کنید تا عملکرد سیستم را ثبت کنید.
-
یک نمودار فعالیت یا توالی برای جریانهای کاری مهم اضافه کنید.
-
یک نمودار کلاس برای مدل دامنه ایجاد کنید.
-
نمودارهای جزء و استقرار را برای معماری اضافه کنید.
-
نمودارها را با ذینفعان بازبینی کنید.
-
مدل را با پیشرفت سیستم بهروزرسانی کنید.
-
در صورت نیاز، نمودارها را صادر کنید یا مستندات تولید نمایید.
ایجاد نمودار کلاس
برای ایجاد یک نمودار کلاس:
-
یک نمودار کلاس جدید ایجاد کنید.
-
کلاسهای اصلی دامنه را اضافه کنید.
-
ویژگیها و عملیات را اضافه کنید.
-
کلاسها را با استفاده از روابط مناسب به هم متصل کنید.
-
چندگانگیها را اضافه کنید.
-
در صورت نیاز، وراثت و رابطها را مشخص کنید.
-
نمودار را طوری بچینید که کلاسهای مرتبط به راحتی قابل پیگیری باشند.
-
مدل را در برابر الزامات اعتبارسنجی کنید.
برای مثال، یک نمودار کلاس برای یک فروشگاه آنلاین ممکن است شامل مشتری, سفارش, محصول, پرداخت، و ارسال.
ایجاد نمودار مورد استفاده
یک نمودار مورد استفاده میتواند با روشهای زیر ایجاد شود:
-
شناسایی بازیگران خارجی.
-
فهرستکردن توابع اصلی سیستم.
-
اضافه کردن مرز سیستم.
-
قرار دادن موارد استفاده درون مرز.
-
اتصال بازیگران به موارد استفادهای که در آنها مشارکت دارند.
-
اضافه کردن روابط شامل یا گسترش فقط زمانی که بازن استفاده یا رفتارهای اختیاری را شفاف میکنند.
ایجاد نمودار توالی
هنگام ایجاد نمودار توالی:
-
سناریوی مورد مدلسازی را شناسایی کنید.
-
بازیگر یا مؤلفه آغازگر را اضافه کنید.
-
اشیاء یا خدمات مشارکتکننده را اضافه کنید.
-
آنها را از چپ به راست مرتب کنید.
-
پیامها را به ترتیب زمانی اضافه کنید.
-
گزینهها، حلقهها و شرایط خطا را مدلسازی کنید.
-
بررسی کنید که هر پیام با یک مسئولیت واقعبینانه مطابقت داشته باشد.
همکاری و مستندسازی
Visual Paradigm قابلیتهای مدلسازی بصری، ویژگیهای همکاری تیمی، پشتیبانی از مستندسازی و یکپارچهسازیهایی را ارائه میدهد که برای اتصال مدلسازی به فعالیتهای گستردهتر توسعه نرمافزار طراحی شدهاند. پلتفرم آن همچنین از بازبینی و نظردهی مشارکتی روی نمودارها پشتیبانی میکند.
برخی نسخهها و گردشهای کاری ممکن است ویژگیهایی مانند مهندسی کد، مدلسازی پایگاه داده، سازماندهی مدل، صادرات نمودار و تولید مستندات را نیز ارائه دهند. این قابلیتها باید بر اساس نیازهای پروژه انتخاب شوند، نه اینکه بهطور خودکار به هر مدلی اضافه شوند.
بهترین روشها برای مدلسازی مؤثر UML
با هدف مدلسازی کنید
هر نمودار باید به یک سوال مشخص پاسخ دهد. برای مثال:
-
مشتری چگونه سفارش خود را ثبت میکند؟
-
کدام خدمات به خدمات پرداخت وابسته هستند؟
-
سفارش میتواند در چه حالتهایی قرار گیرد؟
-
کدام کلاسها به حوزه سفارش تعلق دارند؟
نمودارها را متمرکز نگه دارید
از قرار دادن کل سیستم در یک نمودار خودداری کنید. مدلهای بزرگ را به نمایهای کوچکتری برای الزامات، ساختار حوزه، رفتار، معماری و استقرار تقسیم کنید.
از نامهای یکسان استفاده کنید
از نامهای یکسان در سراسر نمودارها استفاده کنید. اگر یک نمودار یک مؤلفه را “OrderService" صدا میزند،دیگری نباید آن را “OrderManager" صدا بزند،مگر اینکه واقعاً عناصر متفاوتی باشند.
سطح مناسبی از جزئیات را انتخاب کنید
یک نمودار مخاطبمحور (مخصوص ذینفعان) معمولاً باید جزئیات فنی کمتری نسبت به یک نمودار پیادهسازی داشته باشد. مگر اینکه برای مخاطبان مرتبط باشند، امضای متدها، فیلدهای پایگاه داده یا جزئیات خاص چارچوب را اضافه نکنید.
از روابط غیرضروری پرهیز کنید.
اضافه کردن تمام وابستگیهای ممکن میتواند خواندن نمودار را دشوار کند. روابطی را شامل کنید که اطلاعات طراحی معنادار را منتقل میکنند.
تعداد (Multiplicity) را در مواردی که اهمیت دارد، نمایش دهید.
تعداد به شفافسازی قوانین کسبوکار و روابط دادهها کمک میکند. به عنوان مثال، نشان دادن اینکه یک سفارش شامل یک یا چند قلم سفارش است، اطلاعاتیتر از صرفاً اتصال دو کلاس به یکدیگر است.
نمودارها را در برابر الزامات اعتبارسنجی کنید.
یک مدل تنها زمانی مفید است که بهطور دقیق سیستم را نمایندگی کند. نمودارها را با الزامات، سناریوهای تست، کد منبع و بازخورد ذینفعان مقایسه کنید.
از نمودارها بهعنوان مستندات زنده استفاده کنید.
هنگامی که تصمیمات طراحی بزرگ تغییر میکنند، نمودارهای UML را بهروزرسانی کنید. نمودارهای منسوخ میتوانند گیجکنندهتر از نداشتن هیچ نموداری باشند.
نمودارهای مکمل را ترکیب کنید.
هیچ نمودار UML واحدی نمیتواند هر جنبهای از یک سیستم را توضیح دهد. یک نمودار کلاس ممکن است ساختار را نشان دهد، در حالی که یک نمودار توالی توضیح میدهد که آن ساختار در یک سناریوی خاص چگونه رفتار میکند.
اشتباهات رایجی که باید از آنها پرهیز کرد
-
مورد قرار دادن UML بهعنوان کد منبع
-
ایجاد نمودارها بدون هدف مشخص
-
ترکیب جزئیات مفهومی و پیادهسازی بدون توضیح
-
استفاده از وراثت در مواردی که ترکیب (Composition) مناسبتر است
-
حذف تعداد از روابط مهم
-
اضافه کردن بیش از حد عناصر به یک نمودار
-
استفاده از روابط include و extend نادرست
-
عدم مدلسازی جریانهای خطا و جایگزین
-
اجازه دادن به استفاده از نامهای ناسازگار در نمودارهای مختلف
-
فرض کردن اینکه یک نمودار صحیح است صرفاً به این دلیل که از نظر بصری مرتب به نظر میرسد
UML 2.x و تعداد نمودارها
نسخههای اولیه UML معمولاً انواع نمودارهای کمتری را توصیف میکردند.UML 2.xزبان را گسترش داد و نمودارهای اضافی را معرفی یا رسمی کرد، از جمله:
-
نمودار ساخت ترکیبی
-
نمودار ارتباطی
-
نمودار نمای کلی تعامل
-
نمودار زمانبندی
همچنین نمودارهای نمودار حالت را به نمودار ماشین حالت تغییر نام داد. یک طبقهبندی رایج در UML 2.x شامل ۱۴ نمودار است: هفت نمودار ساختاری و هفت نمودار رفتاری. گروه رفتاری شامل نمودارهای مورد استفاده، فعالیت، ماشین حالت، توالی، ارتباطی، نمای کلی تعامل و زمانبندی است. گروه ساختاری شامل نمودارهای کلاس، شیء، مؤلفه، ساخت ترکیبی، استقرار، بسته و پروفایل است.
بنابراین، فهرستهایی که UML 2.x را دارای تنها ۱۳ نمودار توصیف میکنند، در طبقهبندی رایج ۱۴-نموداری ناقص هستند.
نتیجهگیری
UML یک زبان بصری کاربردی برای درک، طراحی و مستندسازی سیستمهای نرمافزاری فراهم میکند. این زبان به تیمها کمک میکند تا نیازمندیها را مبادله کنند، معماری را کاوش کنند، روابط شیء را مدلسازی کنند، گردشهای کاری را توصیف کنند و رفتار زمان اجرا را توضیح دهند.
معمولاً پرکاربردترین نمودارها عبارتند از:
-
نمودارهای مورد استفاده برای نیازمندیهای عملکردی
-
نمودارهای کلاس برای ساختار ایستا
-
نمودارهای فعالیت برای گردشهای کاری
-
نمودارهای توالی برای تعاملات
-
نمودارهای مؤلفه برای معماری
-
نمودارهای استقرار برای زیرساخت
-
نمودارهای ماشین حالت برای رفتار چرخه عمر
Visual Paradigm میتواند این فرآیند مدلسازی را با ارائه ابزارهایی برای پشتیبانی کندایجاد نمودارهای UML، سازماندهی مدلها، همکاری با اعضای تیم و تولید مستندات فنی. مؤثرترین رویکرد این نیست که از هر نمودار UML بهصورت بیرویه استفاده شود، بلکه نمودارهایی را انتخاب کنیم که سوالات مهم طراحی را شفاف سازند.
وقتی بهصورت یکپارچه استفاده شود و با سیستم واقعی همسو نگه داشته شود، UML فراتر از مجموعهای از نمادها میشود: به یک زبان طراحی مشترک تبدیل میشود که نیازهای کسبوکار، معماری نرمافزار، پیادهسازی، تست و نگهداری بلندمدت را به هم متصل میکند.
This post is also available in Deutsch, English, Español, Français, Bahasa Indonesia, 日本語, Polski, Portuguese, Ру́сский, Việt Nam, 简体中文 and 繁體中文.












