توصیف مورد استفاده توضیح می‌دهد که چگونه یک بازیگر با تعامل با یک سیستم به یک هدف دست می‌یابد. این توصیف، نمودار مورد استفاده را تکمیل می‌کند:

• نمودار مورد استفاده:نمایش بازیگران، دامنه سیستم و روابط.

• توصیف مورد استفاده:توضیح رفتارهای دقیق، شرایط، قوانین و نتایج.

یک نمودار نقشه را فراهم می‌کند؛ توصیف مسیر را ارائه می‌دهد.

۱. مورد استفاده چیست؟

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

مثال‌ها:

• مشتری سفارش می‌دهد

• کارمند ادعای هزینه را ارائه می‌دهد

• بیمار قرار ملاقات را تنظیم می‌کند

• مدیر یک حساب کاربری ایجاد می‌کند

• مشتری رمز عبور را بازنشانی می‌کند

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

• هدف‌محور

• ارزشمند برای یک بازیگر

• از دیدگاه کاربر توصیف شده است

• مستقل از چیدمان‌های خاص صفحه

• متمرکز بر رفتار قابل مشاهده سیستم

نام‌های ضعیف و بهبودیافته مورد استفاده

از یک عبارت کوتاه فعل–مفعول مانند ” استفاده کنیدارسال ادعای هزینه, ردیابی محموله، یا تصویب درخواست وام.

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

۲.۱ بازیگران

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

یک بازیگر می‌تواند باشد:

• یک فرد

• یک سازمان

• یک سیستم نرم‌افزاری دیگر

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

• یک محرک زمان‌بندی‌شده یا مبتنی بر زمان

مثال‌ها:

• مشتری

• نماینده پشتیبانی

• کارمند انبار

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

• خدمت ایمیل

• مدیر سیستم

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

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

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

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

مثال:

• بازیگر اصلی: مشتری

• بازیگر پشتیبان: درگاه پرداخت

• مورد استفاده: ثبت سفارش

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

۲.۲ مرز سیستم

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

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

• مرور محصولات

• افزودن محصول به سبد خرید

• ثبت سفارش

• انجام پرداخت

• پیگیری سفارش

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

• مشتری

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

• شرکت پستی

• ارائه‌دهنده ایمیل

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

۲.۳ مورد استفاده

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

برای مثال:

ثبت سفارش:یک مشتری محصولات را انتخاب می‌کند، اطلاعات تحویل را ارائه می‌دهد، برای سفارش پرداخت می‌کند و یک تأییدیه سفارش دریافت می‌کند.

«اعتبارسنجی شماره کارت اعتباری» ممکن است یک تابع سیستمی باشد، اما معمولاً آن‌قدر کوچک است که به‌عنوان یک هدف مستقل کاربر نباشد. در عوض، ممکن است بخشی از باشدثبت سفارش یا انجام پرداخت.

۲.۴ پیش‌شرط‌ها

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

مثال‌ها:

• مشتری دارای یک حساب فعال است.

• محصول برای فروش موجود است.

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

• زمان‌بندی نوبت‌دهی وجود دارد.

• سبد خرید حداقل شامل یک کالا است.

یک پیش‌شرط یک عمل نیست که توسط مورد استفاده انجام شود.

پیش‌شرط ضعیف:

مشتری وارد سیستم می‌شود.

پیش‌شرط بهتر:

مشتری احراز هویت شده است.

۲.۵ پس‌شرط‌ها

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

مثال‌ها:

• سفارش ثبت شده است.

• پرداخت تأیید شده است.

• یک ایمیل تأیید ارسال می‌شود.

• درخواست هزینه دارای وضعیت «ارسال شده» است.

• حساب کاربری به عنوان فعال علامت‌گذاری شده است.

پیش‌شرط‌های پس‌از اجرا باید نتایج را توصیف کنند، نه جزئیات پیاده‌سازی.

پیش‌شرط پس‌از اجرا ضعیف:

جدول سفارش‌ها به‌روزرسانی می‌شود.

پیش‌شرط پس‌از اجرا بهتر:

سفارش ذخیره شده و برای انجام آماده است.

۲.۶ سناریوی اصلی موفقیت

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

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

1. یک تعامل بین بازیگر و سیستم

2. یک پاسخ سیستم

3. یک عملیات کسب‌وکار معنادار

مثال:

1. مشتری محصولات را انتخاب می‌کند.

2. سیستم سبد خرید فعلی را نمایش می‌دهد.

3. مشتری اطلاعات تحویل را وارد می‌کند.

4. سیستم اطلاعات تحویل را اعتبارسنجی می‌کند.

5. مشتری سفارش را ارسال می‌کند.

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

7. درگاه پرداخت، پرداخت را مجوز می‌دهد.

8. سیستم سفارش را ثبت می‌کند.

9. سیستم تأییدیه سفارش را نمایش می‌دهد.

از جزئیات خاص رابط‌کاربری خودداری کنید، مگر اینکه برای الزام ضروری باشند.

گام ضعیف:

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

گام بهتر:

مشتری سفارش را ارسال می‌کند.

۲.۷ جریان‌های جایگزین

یک جریان جایگزین، یک تغییر معتبر از سناریوی اصلی را توصیف می‌کند.

مثال‌ها:

• مشتری تحویل در فروشگاه را به جای ارسال انتخاب می‌کند.

• مشتری با یک روش پرداخت ذخیره‌شده پرداخت می‌کند.

• مدیر یک ادعا را با شرایطی تأیید می‌کند.

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

جریان‌های جایگزین ممکن است دوباره به جریان اصلی بپیوندند.

مثال:

A1. مشتری از یک روش پرداخت ذخیره‌شده استفاده می‌کند
در گام ۶، مشتری یک روش پرداخت ذخیره‌شده را انتخاب می‌کند. سیستم با استفاده از آن روش درخواست مجوز می‌دهد، سپس در گام ۷ ادامه می‌یابد.

۲.۸ جریان‌های استثنا

یک جریان استثنا، یک وضعیت ناموفق یا غیرعادی را توصیف می‌کند.

مثال‌ها:

• پرداخت رد می‌شود.

• محصول موجود نیست.

• احراز هویت ناموفق است.

• خدمت خارجی در دسترس نیست.

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

یک جریان استثنا باید توضیح دهد:

• مشکل در کجا رخ می‌دهد

• سیستم چه کاری انجام می‌دهد

• کاراکتر چه چیزی می‌بیند

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

مثال:

E1. پرداخت رد شد
در گام ۷، درگاه پرداخت تراکنش را رد می‌کند. سیستم دلیل را نمایش می‌دهد، سفارش را به‌عنوان پرداخت‌نشده علامت‌گذاری می‌کند و به مشتری اجازه می‌دهد روش پرداخت دیگری را انتخاب کند.

۲.۹ روابط شامل و گسترش

شامل

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

مثال:

• ثبت سفارش شامل محاسبه مجموع است

• ثبت سفارش شامل احراز هویت مشتری است

• برداشت وجه شامل تأیید رمز شخصی است

رفتار شامل‌شده الزامی است.

ثبت سفارش <<شامل>> محاسبه مجموع

گسترش

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

مثال:

• ثبت سفارش ممکن است با اعمال کد تخفیف گسترش یابد

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

رفتار گسترش‌دهنده همیشه اجرا نمی‌شود.

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

یک قانون مفید:

• شامل: «این همیشه به‌عنوان بخشی از مورد استفاده رخ می‌دهد.»

• گسترش: «این ممکن است تحت شرایط خاصی رخ دهد.»

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

۲.۱۰ تعمیم

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

مثال:

• کارمند یک بازیگر عمومی است.

• مدیر یک بازیگر تخصصی است که رفتار کارمند را به ارث می‌برد.

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

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

۳. الگوی استاندارد توصیف مورد استفاده

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

شناسه مورد استفاده:
نام مورد استفاده:
هدف:
حوزه:
سطح:
بازیگر اصلی:
بازیگران پشتیبان:
ذینفعان و منافع:

محرک:

شرایط پیش‌نیاز:

ضمانت‌های حداقلی:

ضمانت‌های موفقیت:

سناریوی اصلی موفقیت:
۱.
۲.
۳.

جریان‌های جایگزین:
الف۱.
الف۲.

جریان‌های استثنا:
الف۱.
الف۲.

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

قوانین کسب‌وکار:

الزامات داده:

فرکانس و حجم:

فرضیات:

سؤالات باز:

مورد استفاده مرتبط:

توضیح فیلدها

۴. مثال: ثبت سفارش

UC-001 — ثبت سفارش

هدف:
اجازه دادن به مشتری برای خرید یک یا چند محصول.

دامنه:
فروشگاه آنلاین

سطح:
هدف کاربر

بازیگر اصلی:
مشتری

بازیگران پشتیبان:

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

• خدمات موجودی

• خدمات ایمیل

• خدمات تحویل

ذینفعان و منافع:

• مشتری:می‌خواهد محصولات را با موفقیت خریداری کند و تأییدیه دریافت کند.

• فروشگاه:می‌خواهد یک سفارش معتبر را ثبت کند و پرداخت را دریافت کند.

• انبار:به اطلاعات دقیق انجام سفارش نیاز دارد.

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

• خدمات تحویل:به یک آدرس تحویل کامل نیاز دارد.

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

پیش‌نیازها:

• مشتری حداقل یک کالا در سبد خرید دارد.

• محصولات برای سفارش در دسترس هستند.

• مشتری یک آدرس تحویل معتبر ارائه می‌دهد.

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

تضمین‌های حداقلی:

• هیچ سفارش پرداخت‌نشده‌ای به عنوان تأییدشده در نظر گرفته نمی‌شود.

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

• اگر پرداخت شکست بخورد، موجودی رزرو شده آزاد می‌شود.

ضمانت‌های موفقیت:

• پرداخت تأیید شده است.

• سفارش ثبت شده است.

• موجودی رزرو شده است.

• مشتری تأییدیه را دریافت می‌کند.

• اطلاعات انجام سفارش در اختیار انبار قرار می‌گیرد.

سناریوی اصلی موفقیت

1. مشتری سبد خرید را بررسی می‌کند.

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

3. مشتری اطلاعات تحویل را ارائه می‌دهد.

4. سیستم اطلاعات تحویل را اعتبارسنجی می‌کند.

5. مشتری روش پرداخت را انتخاب می‌کند.

6. مشتری سفارش را ارسال می‌کند.

7. سیستم موجودی محصولات را بررسی می‌کند.

8. سیستم درخواست تأیید پرداخت را از درگاه پرداخت ارسال می‌کند.

9. درگاه پرداخت پرداخت را تأیید می‌کند.

10. سیستم سفارش را ایجاد می‌کند.

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

12. سیستم تأییدیه سفارش را برای مشتری ارسال می‌کند.

13. سیستم شماره سفارش و تاریخ تخمینی تحویل را نمایش می‌دهد.

جریان‌های جایگزین

A1. مشتری از آدرس ذخیره‌شده استفاده می‌کند

در گام ۳، مشتری آدرس ذخیره‌شده قبلی را انتخاب می‌کند. سیستم آدرس را نمایش داده و در گام ۴ ادامه می‌دهد.

A2. مشتری از روش پرداخت ذخیره‌شده استفاده می‌کند

در گام ۵، مشتری روش پرداخت ذخیره‌شده را انتخاب می‌کند. سیستم از آن روش استفاده کرده و در گام ۶ ادامه می‌دهد.

A3. مشتری تحویل از فروشگاه را انتخاب می‌کند

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

جریان‌های استثنا

E1. محصول در دسترس نیست

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

E2. پرداخت رد شد

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

E3. درگاه پرداخت در دسترس نیست

در گام ۸، درگاه پرداخت در مهلت زمانی تنظیم‌شده پاسخ نمی‌دهد. سیستم تلاش پرداخت را به عنوان «در انتظار» علامت‌گذاری می‌کند، مشتری را مطلع می‌سازد و از ارسال تکراری سفارش جلوگیری می‌کند.

قوانین کسب‌وکار

• یک سفارش باید حداقل شامل یک محصول باشد.

• تعداد محصول باید بزرگتر از صفر باشد.

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

• پرداخت باید پیش از تأیید سفارش، مجاز شود.

• قیمت‌ها و مالیات‌ها بر اساس قوانین قیمت‌گذاری فعلی محاسبه می‌شوند.

• مشتری تنها پیش از آغاز عملیات تحویل، می‌تواند سفارش را لغو کند.

نیازمندی‌های ویژه

• خلاصه سفارش باید تحت بار عادی در مدت دو ثانیه نمایش داده شود.

• اطلاعات پرداخت نباید به صورت متن ساده ذخیره شوند.

• ارسال‌های تکراری نباید منجر به ایجاد سفارش‌های تکراری شوند.

• سیستم باید ردپای حسابرسی (Audit Trail) را برای تغییرات وضعیت پرداخت و سفارش ثبت کند.

۵. سطوح سناریوهای استفاده

توضیحات سناریوهای استفاده می‌توانند در سطوح مختلف جزئیات نوشته شوند.

سناریوی استفاده در سطح خلاصه

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

مثال:

تحویل سفارش مشتری

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

• دریافت سفارش

• انتخاب محصولات

• بسته‌بندی سفارش

• ارسال سفارش

سناریوی استفاده در سطح هدف کاربر

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

مثال:

ثبت سفارش

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

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

این یک رفتار کوچک و قابل استفاده مجدد سیستم را توصیف می‌کند.

مثال‌ها:

• محاسبه مجموع سفارش

• اعتبارسنجی پرداخت

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

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

۶. نوشتن توصیف‌های باکیفیت سناریوی استفاده

از زبان مبتنی بر بازیگر استفاده کنید

از دیدگاه بازیگر بنویسید:

مشتری سفارشی را ثبت می‌کند.

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

OrderController سرویس سفارش را فراخوانی می‌کند.

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

هر گام را اتمی نگه دارید

از ترکیب بیش از حد عملیات پرهیز کنید:

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

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

1. مشتری اطلاعات تحویل را وارد می‌کند.

2. سیستم اطلاعات را اعتبارسنجی می‌کند.

3. مشتری یک روش پرداخت را انتخاب می‌کند.

4. مشتری سفارش را تأیید می‌کند.

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

رفتار قابل مشاهده را توصیف کنید

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

ضعیف:

سیستم درخواست را پردازش می‌کند.

قوی‌تر:

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

از طراحی زودهنگام رابط کاربری خودداری کنید.

استفاده از:

مشتری اطلاعات تحویل را ارائه می‌دهد.

به جای:

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

نسخه دوم به‌طور غیرضروری رابط کاربری را محدود می‌کند.

مسیر اصلی را موفق نگه دارید.

مسیر اصلی را با هر خطای ممکن پر نکنید. خطاها را در جریان‌های استثنا قرار دهید.

قوانین کسب‌وکار را به‌طور جداگانه شناسایی کنید.

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

رفتار شکست را صریح بیان کنید.

برای هر شکست مهم، مشخص کنید:

• آیا داده‌ها ذخیره می‌شوند یا خیر.

• آیا تراکنش برگشت داده می‌شود یا خیر.

• آیا بازیکن می‌تواند تلاش مجدد کند یا خیر.

• آیا مدیر مطلع می‌شود یا خیر.

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

۷. از الزامات تا موارد استفاده

یک جریان کاری عملی عبارت است از:

1. سیستم مورد مدل‌سازی را شناسایی کنید.

2. بازیگران خارجی را فهرست کنید.

3. بپرسید هر بازیگر چه هدفی را می‌خواهد محقق کند.

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

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

6. سناریوی اصلی موفقیت را بنویسید.

7. جریان‌های جایگزین و استثنا را اضافه کنید.

8. قوانین کسب‌وکار و الزامات ویژه را اضافه کنید.

9. نمودار مورد استفاده را رسم کنید.

10. مدل را با ذینفعان بازبینی کنید.

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

تحلیل نقش-هدف

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

این نقش به چه نتیجه‌ای کسب‌وکاری از سیستم نیاز دارد؟

۸. نمادگذاری نمودار کاربرد

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

• نقش:نقش خارجی

• کاربرد: قابلیت سیستم یا هدف بازیگر

• مرز سیستم: دامنه سیستم

• ارتباط: بازیگر در یک مورد استفاده مشارکت دارد

• شامل: رفتار مورد نیاز و قابل استفاده مجدد

• گسترش: رفتار اختیاری یا شرطی

• تعمیم: بازیگر یا مورد استفاده تخصصی

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

• هر مرحله از گردش کار

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

• ویژگی‌های کلاس

• قوانین کسب‌وکار دقیق

• چیدمان‌های صفحه

• الگوریتم‌های داخلی

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

۹. مثال نمودار PlantUML

مثال زیر مدل‌سازی ثبت سفارش مورد استفاده و رفتار مرتبط را انجام می‌دهد.

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

skinparam packageStyle rectangle
skinparam shadowing false
skinparam usecase {
    BackgroundColor #F8FBFF
    BorderColor #2F5597
    ArrowColor #555555
}

actor Customer
actor "Payment Gateway" as Payment
actor "Inventory Service" as Inventory
actor "Email Service" as Email
actor "Delivery Service" as Delivery

rectangle "Online Store" {
    usecase "Browse Products" as Browse
    usecase "Manage Cart" as Cart
    usecase "Place Order" as PlaceOrder
    usecase "Calculate Order Total" as CalculateTotal
    usecase "Check Product Availability" as CheckStock
    usecase "Authorize Payment" as AuthorizePayment
    usecase "Reserve Inventory" as ReserveInventory
    usecase "Send Order Confirmation" as SendConfirmation
    usecase "Track Order" as TrackOrder
    usecase "Apply Discount Code" as ApplyDiscount
}

Customer --> Browse
Customer --> Cart
Customer --> PlaceOrder
Customer --> TrackOrder

Payment --> AuthorizePayment
Inventory --> CheckStock
Inventory --> ReserveInventory
Email --> SendConfirmation
Delivery --> TrackOrder

PlaceOrder ..> CalculateTotal : <<include>>
PlaceOrder ..> CheckStock : <<include>>
PlaceOrder ..> AuthorizePayment : <<include>>
PlaceOrder ..> ReserveInventory : <<include>>
PlaceOrder ..> SendConfirmation : <<include>>

ApplyDiscount ..> PlaceOrder : <<extend>>

@enduml

تفسیر

• مشتری آغاز می‌کند ثبت سفارش.

• ثبت سفارش همواره شامل محاسبه، بررسی موجودی، مجوز پرداخت، رزرو موجودی و تأیید است.

• اعمال کد تخفیف اختیاری است، بنابراین آن را گسترش می‌دهد ثبت سفارش.

• خدمات خارجی در رفتارهای خاص سیستم مشارکت دارند.

• مرز سیستم عبارت است از فروشگاه آنلاین مستطیل.

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

۱۰. ایجاد نمودار در Visual Paradigm VPasCode

VPasCode یک پلتفرم مبتنی بر مرورگر برای تبدیل متن به نمودار است که از PlantUML، Mermaid، Graphviz و سایر فرمت‌های نمودار پشتیبانی می‌کند. این پلتفرم ویرایش سورس و رندرینگ زنده را فراهم می‌کند و اجازه می‌دهد نمودار با تغییر کد به‌روزرسانی شود.

روند کاری پایه

1. ویرایشگر VPasCode را باز کنید.

2. یک نمودار PlantUML جدید ایجاد کنید.

3. منبع PlantUML را پیست کنید.

4. تأیید کنید که ویرایشگر نحو PlantUML را تشخیص می‌دهد.

5. پیش‌نمایش زنده را بررسی کنید.

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

7. نمودار رندر شده را صادر یا کپی کنید.

8. نمودار را به مستندات پروژه اضافه کنید.

VPasCode از نمودارهای مورد استفاده PlantUML پشتیبانی می‌کند و رندرینگ بلادرنگ در مرورگر را ارائه می‌دهد. همچنین نمونه‌ها و گزینه‌های سبک‌بندی برای نمودارهای PlantUML را فراهم می‌کند.

نمونه دستور برای تولید با کمک هوش مصنوعی

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

یک نمودار مورد استفاده PlantUML برای یک فروشگاه آنلاین ایجاد کنید.

بازیگر اصلی:
- مشتری

بازیگران پشتیبان:
- درگاه پرداخت
- سرویس موجودی
- سرویس ایمیل
- سرویس تحویل

موارد استفاده اصلی:
- جستجوی محصولات
- مدیریت سبد خرید
- ثبت سفارش
- ردیابی سفارش

ثبت سفارش باید شامل موارد زیر باشد:
- محاسبه مجموع سفارش
- بررسی موجودی محصول
- مجوز پرداخت
- رزرو موجودی
- ارسال تأییدیه سفارش

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

از یک مرز سیستم با نام «فروشگاه آنلاین» استفاده کنید.

کد تولید شده را به عنوان نقطه شروع در نظر بگیرید. بررسی کنید که آیا:

• نقش‌ها واقعاً بیرونی هستند

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

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

• مرز سیستم دقیق است

• روابط رفتار واقعی کسب‌وکار را منعکس می‌کنند

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

۱۱. نگهداری نمودارهای مورد استفاده PlantUML

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

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

usecase "Place Order" as PlaceOrder
Customer --> PlaceOrder

افزودن نظرات

' Core customer transaction
usecase "Place Order" as PlaceOrder

نظرات به سایر اعضای تیم کمک می‌کنند تا منبع را درک کرده و نمودار را نگهداری کنند.

نمودار را متمرکز نگه دارید

اگر یک نمودار حاوی تعداد زیادی مورد استفاده است:

• یک نمودار زمینه ایجاد کنید

• نمودارهای جداگانه بر اساس حوزه کسب‌وکار ایجاد کنید

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

• نمودارهای مرتبط را از طریق مستندات به هم پیوند دهید

• از نمایش هر زیرعملکردی در بالاترین سطح خودداری کنید

از نام‌گذاری یکسان استفاده کنید

یک قرارداد را انتخاب کرده و آن را به‌طور مداوم اعمال کنید:

• ثبت سفارش

• لغو سفارش

• پیگیری سفارش

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

• ثبت سفارش

• OrderCancellation

• tracking_function

منبع را همراه با پروژه ذخیره کنید

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

docs/
  use-cases/
    UC-001-place-order.md
    UC-002-track-order.md
  diagrams/
    online-store-use-cases.puml

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

۱۲. ردیابی‌پذیری

یک فرآیند بلوغ‌یافته نیازمندی‌ها، موارد استفاده را به سایر آثار پروژه متصل می‌کند.

ردیابی به پاسخ به این سوالات کمک می‌کند:

• کدام الزامات پوشش داده شده‌اند؟

• کدام موارد استفاده تست نشده‌اند؟

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

• اگر یک الزام تغییر کند، چه چیزی تحت تأثیر قرار می‌گیرد؟

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

مدل‌سازی اجزای داخلی به عنوان بازیگران

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

یک بازیگر باید خارج از سیستم مورد مدل‌سازی باشد.

در نظر گرفتن صفحات به عنوان موارد استفاده

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

استفاده از:

ارسال ادعای هزینه

به جای:

صفحه ادعای هزینه

استفاده از شاملبرای هر مرحله مشترک

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

استفاده از گسترشبرای مراحل عادی

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

نوشتن جزئیات پیاده‌سازی

از ارجاع به موارد زیر خودداری کنید:

• کنترل‌کننده‌ها

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

• نقاط پایانی API

• کلاس‌ها

• روش‌های داخلی

مگر اینکه سند به‌طور خاص یک طراحی فنی باشد.

نادیده گرفتن رفتار شکست

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

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

«مدیریت کل کسب‌وکار» قابل اجرا نیست. اهداف گسترده را به موارد استفاده در سطح هدف کاربر تقسیم کنید.

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

«اعتبارسنجی فیلد» و «نمایش پیام» معمولاً گام‌های سیستم هستند، نه اهداف مستقل بازیگر.

۱۴. چک‌لیست بازبینی

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

حوزه و بازیگران

• آیا مرز سیستم واضح است؟

• آیا تمام بازیگران خارجی شناسایی شده‌اند؟

• آیا بازیگران نقش‌ها هستند و نه نام‌های فردی؟

• آیا سیستم‌های پشتیبان تنها زمانی مدل‌سازی می‌شوند که خارجی باشند؟

کیفیت هدف

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

• آیا نام یک عبارت فعل-اسم واضح است؟

• آیا مورد استفاده در سطح مناسبی قرار دارد؟

کیفیت جریان

• آیا سناریوی اصلی یک نتیجه موفق را توصیف می‌کند؟

• آیا هر گام اتمی و قابل مشاهده است؟

• آیا مسیرهای جایگزین مستند شده‌اند؟

• آیا مسیرهای استثنا مستند شده‌اند؟

• آیا رفتار بازیابی واضح است؟

شرایط و نتایج

• آیا پیش‌شرط‌ها قابل آزمایش هستند؟

• آیا تضمین‌های موفقیت صریح هستند؟

• آیا تضمین‌های حداقلی تعریف شده‌اند؟

• آیا قوانین کسب‌وکار از مراحل رویه‌ای جدا شده‌اند؟

کیفیت نمودار

• آیا تمام موارد استفاده درون مرز صحیح قرار دارند؟

• آیا ارتباطات بازیگر معنادار هستند؟

• آیا «شامل» اجباری هستند؟

• آیا «گسترش» اختیاری یا مشروط هستند؟

• آیا نمودار بدون جزئیات بیش‌ازحد قابل خواندن است؟

کیفیت الزامات

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

• آیا الزامات غیرعملکردی گنجانده شده‌اند؟

• آیا سوالات حل‌نشده ثبت شده‌اند؟

• آیا مورد استفاده به الزامات و موارد آزمایش پیوند خورده است؟

۱۵. ساختار پیشنهادی تحویل‌ها

برای یک بسته پروژه کامل، از ساختار زیر استفاده کنید:

۱. زمینه سیستم
۲. کاتالوگ بازیگران
۳. نمودار مورد استفاده
۴. کاتالوگ مورد استفاده
۵. توضیحات دقیق مورد استفاده
۶. قوانین کسب‌وکار
۷. الزامات غیرعملکردی
۸. ماتریس ردیابی
۹. سوالات باز و فرضیات
۱۰. فایل‌های منبع PlantUML

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

منبع

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