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

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

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

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

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

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

• بازیگران — کاربران خارجی، سازمان‌ها، دستگاه‌ها یا سیستم‌هایی که با آن تعامل دارند.

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

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

• روابط بین موارد استفاده — مانند «<<شامل>> و «<<گسترش>>.

• عمومی‌سازی — وراثت بین بازیگران یا موارد استفاده.

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

• مراحل الگوریتم

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

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

• روندکارهای داخلی

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

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

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

۲. مفاهیم کلیدی

مرز سیستم

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

برای مثال، در یک سیستم خرید آنلاین:

+--------------------------------------+
|        سیستم خرید آنلاین            |
|                                      |
|  (مرور محصولات)                      |
|  (ثبت سفارش)                         |
|  (انجام پرداخت)                      |
+--------------------------------------+

نقش‌ها در خارج از مرز باقی می‌مانند زیرا آن‌ها خارجی به سیستم هستند.

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

نقش‌ها

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

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

• کاربران انسانی

• برنامه‌های خارجی

• دستگاه‌های سخت‌افزاری

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

• زمان یا رویدادهای برنامه‌ریزی‌شده، هنگامی که به عنوان محرک‌های خارجی مدل‌سازی می‌شوند

مثال‌ها:

• مشتری

• کتابدار

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

• مدیر سیستم

• سرویس ایمیل

یک نقش نماینده‌ی نقش، لزوماً یک شخص خاص نیست. برای مثال، «مشتری» معمولاً بهتر از «الکس» است.

نقش‌ها می‌توانند باشند:

• نقش‌های اصلی — تعاملات را برای دستیابی به یک هدف آغاز می‌کنند.

• نقش‌های پشتیبان — خدماتی را به سیستم ارائه می‌دهند.

برای مثال، یک مشتری ممکن است «ثبت سفارش» را آغاز کند، در حالی که یک درگاه پرداخت، «پردازش پرداخت» را پشتیبانی می‌کند.

مورد استفاده

یک مورد استفادهنماینده یک هدف معنادار یا خدماتی است که توسط سیستم ارائه می‌شود.

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

فعل + مفعول

مثال‌ها:

• ثبت حساب

• جستجوی کاتالوگ

• ارسال درخواست

• تولید گزارش

• لغو رزرو

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

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

ترجیح دهید:

ثبت سفارش

به جای:

اعتبارسنجی شیء سفارش

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

ارتباطات

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

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

مشتری ---- (ثبت سفارش)

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

۳. روابط بین موارد استفاده

<<شامل>>

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

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

(ثبت سفارش) ..> (احراز هویت مشتری) : <<شامل>>

مورد استفاده پایه به مورد استفاده شامل وابسته است.

از شاملوقتی:

• رفتار اجباری است.

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

• استخراج رفتار، وضوح را بهبود می‌بخشد.

مثال:

(برداشت وجه) ..> (احراز هویت کارت) : <<شامل>>
(بررسی موجودی) ..> (احراز هویت کارت) : <<شامل>>

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

<<گسترش>>

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

(اعمال تخفیف) ..> (ثبت سفارش) : <<گسترش>>

رفتار تخفیف تنها زمانی رخ می‌دهد که شرایط واجد شرایط بودن برآورده شوند.

از گسترشوقتی:

• رفتار اختیاری است.

• این تنها در صورتی رخ می‌دهد که یک شرط برقرار باشد.

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

مثال‌ها:

• «افزودن بسته‌بندی هدیه» گسترش‌دهنده «ثبت سفارش» است.

• «درخواست بازپرداخت» گسترش‌دهنده «لغو اشتراک» است.

• «ارسال ایمیل تبلیغاتی» گسترش‌دهنده «تکمیل ثبت‌نام» است.

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

عمومی‌سازی

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

برای مثال:

مشتری ویژه --|> مشتری

مشتری ویژه نوعی از مشتری است و تعاملات مشتری را به ارث می‌برد.

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

مدیر --|> کارمند
کتابدار --|> کارمند

از عمومی‌سازی به‌صورت محدود استفاده کنید. اگر رابطه صرفاً «استفاده می‌کند» یا «در آن مشارکت دارد»، معمولاً یک ارتباط (association) مناسب‌تر است.

۴. بازیگران اصلی و پشتیبان

یک سناریوی پرداخت آنلاین را در نظر بگیرید:

• «مشتری» بازیگر اصلی است، زیرا خرید را آغاز می‌کند.

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

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

مشتری ---- (ثبت سفارش)
(ثبت سفارش) ---- درگاه پرداخت

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

۵. چگونه موارد استفاده را شناسایی کنیم

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

1. چه کسی از سیستم استفاده می‌کند؟

2. هر بازیگر چه هدفی را می‌خواهد محقق کند؟

3. سیستم چه خدماتی ارائه می‌دهد؟

4. چه رویدادهایی رفتار سیستم را فعال می‌کنند؟

5. سیستم باید با چه سیستم‌های خارجی تعامل داشته باشد؟

6. چه رفتاری همواره الزامی است؟

7. چه رفتاری اختیاری یا مشروط است؟

برای هر بازیگر، اهداف آن‌ها را فهرست کنید:

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

۶. راهنمای نام‌گذاری

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

مثال‌های خوب:

• ایجاد حساب کاربری

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

• ارسال ادعا

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

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

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

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

• پردازش سیستم

• مدیریت داده‌ها

• عملکرد کاربر

• اجرای عملیات

از جزئیات فنی بیش از حد پرهیز کنید:

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

• فراخوانی نقطه پایانی REST

• ایجاد سرویس پرداخت

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

۷. مثال: سیستم مدیریت کتابخانه

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

• جستجوی کتاب توسط اعضا

• قرض گرفتن کتاب توسط اعضا

• بازگرداندن کتاب توسط اعضا

• مدیریت کاتالوگ توسط کتابداران

• اعلامیه‌های اخطار مهلت

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

کاراکترهای ممکن:

• عضو

• کتابدار

• سرویس اطلاع‌رسانی

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

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

• جستجوی کاتالوگ

• قرض گرفتن کتاب

• بازگرداندن کتاب

• محاسبه جریمه

• پرداخت جریمه

• مدیریت کاتالوگ

• ارسال اعلان تأخیر

روابط:

• قرض گرفتن کتاب شامل بررسی عضویت است.

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

• بازگرداندن کتاب شامل محاسبه جریمه است.

• پرداخت جریمه با سرویس پرداخت تعامل دارد.

• ارسال اعلان تأخیر با سرویس اعلان تعامل دارد.

۸. مثال PlantUML

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

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

عنوان: سیستم مدیریت کتابخانه - نمودار مورد استفاده

نقش: عضو
نقش: کتابدار
نقش "سرویس اعلان" به عنوان Notification
نقش "سرویس پرداخت" به عنوان Payment

مستطیل "سیستم مدیریت کتابخانه" {

  usecase "جستجوی کاتالوگ" به عنوان UC_Search
  usecase "قرض گرفتن کتاب" به عنوان UC_Borrow
  usecase "بازگرداندن کتاب" به عنوان UC_Return
  usecase "بررسی عضویت" به عنوان UC_CheckMember
  usecase "بررسی موجودی کتاب" به عنوان UC_CheckAvailability
  usecase "محاسبه جریمه" به عنوان UC_CalculateFine
  usecase "پرداخت جریمه" به عنوان UC_PayFine
  usecase "مدیریت کاتالوگ" به عنوان UC_ManageCatalog
  usecase "ارسال اعلان تأخیر" به عنوان UC_Notify
}

Member --> UC_Search
Member --> UC_Borrow
Member --> UC_Return
Member --> UC_PayFine

Librarian --> UC_ManageCatalog
Librarian --> UC_Borrow
Librarian --> UC_Return

Payment --> UC_PayFine
Notification --> UC_Notify

UC_Borrow ..> UC_CheckMember : <<شامل>>
UC_Borrow ..> UC_CheckAvailability : <<شامل>>
UC_Return ..> UC_CalculateFine : <<شامل>>

UC_Notify ..> UC_Return : <<گسترش>>

@enduml

۹. توضیح مثال

نقش‌ها

نقش عضو
نقش کتابدار
نقش "سرویس اعلان" به عنوان Notification
نقش "سرویس پرداخت" به عنوان Payment

این نمودار دو نقش انسانی و دو سرویس خارجی را مدل‌سازی می‌کند.

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

مرز سیستم

مستطیل «سیستم مدیریت کتابخانه» {
    ...
}

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

ارتباطات بازیگر

عضو --> UC_جستجو
عضو --> UC_قرض

این ارتباطات نشان می‌دهند که یک عضو می‌تواند در کاتالوگ جستجو کند و کتاب‌ها را قرض بگیرد.

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

روابط شامل

UC_قرض ..> UC_بررسی_عضو : <<شامل>>
UC_قرض ..> UC_بررسی_در دسترس بودن : <<شامل>>

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

روابط گسترش

UC_اعلام ..> UC_بازگرداندن : <<گسترش>>

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

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

۱۰. مشخصات دقیق‌تر مورد استفاده

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

مورد استفاده: قرض گرفتن کتاب

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

۱۱. مرجع دستوری PlantUML

اعلام نقش‌ها

actor Customer
actor "Payment Gateway" as Gateway

اعلام موارد استفاده

usecase "Place Order" as PlaceOrder
usecase "Process Payment" as ProcessPayment

ایجاد مرز سیستم

rectangle "فروشگاه آنلاین" {
    usecase "مرور محصولات" as Browse
    usecase "ثبت سفارش" as Order
}

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

Customer --> Browse
Customer --> Order

شامل

Order ..> ProcessPayment : <<شامل>>

گسترش

ApplyCoupon ..> Order : <<گسترش>>

عمومی‌سازی بازیگران

PremiumCustomer --|> Customer

گروه‌بندی بسته‌ها

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

rectangle "سیستم بانکی" {
  package "مدیریت حساب" {
    usecase "باز کردن حساب" as OpenAccount
    usecase "بستن حساب" as CloseAccount
  }

  package "پرداخت‌ها" {
    usecase "انتقال وجه" as TransferFunds
    usecase "پرداخت صورت‌حساب" as PayBill
  }
}

یادداشت‌ها

note right of PlaceOrder
  مشتری باید احراز هویت شود
  قبل از ثبت سفارش.
end note

۱۲. بهبود چیدمان نمودار

PlantUML به‌طور خودکار نمودارها را چیدمان می‌کند، اما چندین تکنیک خوانایی را بهبود می‌بخشد.

کنترل جهت

جهت چپ به راست

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

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

جهت بالا به پایین

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

به‌جای تکرار نام‌های طولانی:

usecase "بررسی هویت مشتری" به‌عنوان VerifyIdentity

سپس ارجاع دهید:

RegisterAccount ..> VerifyIdentity : <<include>>

گروه‌بندی موارد استفاده مرتبط

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

package "مدیریت سفارش" {
    usecase "ایجاد سفارش" as CreateOrder
    usecase "لغو سفارش" as CancelOrder
}

از تقاطع‌های بیش از حد پرهیز کنید

وقتی تعداد زیادی از خطوط همدیگر را قطع می‌کنند، نمودار خواندن دشواری پیدا می‌کند. می‌توانید آن را با موارد زیر بهبود بخشید:

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

• گروه‌بندی موارد استفاده در بسته‌ها

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

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

• پرهیز از روابط غیرضروری

۱۳. اشتباهات رایج

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

این معمولاً بیش از حد فنی است:

اعتبارسنجی اتصال پایگاه داده
تبدیل درخواست به رشته
فراخوانی API پرداخت

اهداف معنادار از دیدگاه خارجی را ترجیح دهید:

انجام پرداخت
ارسال درخواست
تولید گزارش

در نظر گرفتن هر بازیگر به عنوان یک شخص

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

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

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

• سیستم انبار

• اسکنر بارکد

• خدمات اطلاع‌رسانی

استفاده از includeبرای رفتارهای اختیاری

اگر رفتار اختیاری است، از گسترش به جای شامل.

نادرست:

ثبت سفارش ..> اعمال کد تخفیف : <<شامل>>

اگر اعمال کد تخفیف اختیاری است، از این استفاده کنید:

اعمال کد تخفیف ..> ثبت سفارش : <<گسترش>>

استفاده از گسترش برای رفتارهای اجباری

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

ثبت سفارش ..> احراز هویت مشتری : <<شامل>>

اتصال مستقیم موارد استفاده بدون معنای منطقی

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

ایجاد یک نمودار عظیم واحد

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

نمایش ترتیب

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

۱۴. چه زمانی از سایر نمودارهای UML استفاده کنیم

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

۱۵. فرآیند مدل‌سازی پیشنهادی

1. مرز سیستم را تعریف کنید.

2. همه بازیگران خارجی را شناسایی کنید.

3. اهداف هر بازیگر را شناسایی کنید.

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

5. بازیگران را به موارد استفاده‌ای که در آن‌ها مشارکت دارند متصل کنید.

6. رفتارهای اجباری قابل استفاده مجدد را شناسایی کرده و آن را با مدل‌سازی کنید <<شامل>>.

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

8. عمومی‌سازی را فقط در مواردی که رابطه واقعی «یک نوع از» وجود دارد، اضافه کنید.

9. نمودار را با ذینفعان بازبینی کنید.

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

11. اگر نمودار شلوغ شد، آن را تقسیم کنید.

۱۶. قالب فشرده PlantUML

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

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

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

بازیگر کاربر
بازیگر "سیستم خارجی" به عنوان ExternalSystem

مستطیل "نام سیستم" {
  usecase "هدف اصلی کاربر" به عنوان MainGoal
  usecase "رفتار مشترک مورد نیاز" به عنوان RequiredBehavior
  usecase "رفتار اختیاری" به عنوان OptionalBehavior
}

کاربر --> MainGoal
ExternalSystem --> MainGoal

MainGoal ..> RequiredBehavior : <<شامل>>
OptionalBehavior ..> MainGoal : <<گسترش>>

@enduml

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

منبع

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