جریان رویدادها
جریان اساسی
جریان رویداد در بخش مشخصات مورد استفاده بخش عمده ای از مشخصات مورد استفاده را ارائه می دهد و توصیف می کند که بازیگر چه می کند و سیستم در پاسخ چه می کند. در قالب گفت و گوی بین بازیگر و سیستم فرموله شده است. مورد استفاده، آنچه را که در سیستم اتفاق می‌افتد، توصیف می‌کند، اما چگونگی یا چرایی آن را توصیف نمی‌کند.
همچنین باید از یک فرهنگ لغت برای حفظ تعاریف همه اصطلاحات تجاری استفاده شده در توضیحات جریان استفاده شود، این تضمین می کند که هر اصطلاح دارای یک تعریف توافق شده در همه موارد استفاده است و همچنین به ساده کردن شرح موارد استفاده کمک می کند.
عناصر طراحی خاص مانند صفحه‌های رابط کاربری یا کنترل‌ها را در توضیحات توصیف نکنید. در عوض، آن را در استوری بورد مورد استفاده توصیف کنید.
اپراتور
این مورد زمانی شروع می‌شود که بازیگر کاری برای تحریک آن انجام می‌دهد – بازیگر همیشه کسی است که موارد استفاده را آغاز می‌کند. راه‌اندازی باید به عنوان اولین مرحله در جریان رویدادهای مورد استفاده مستند شود. مثال 1. این مورد زمانی شروع می‌شود که کاربر…
مراحل
هر مرحله باید با استفاده از واژگان مورد استفاده استاندارد (درخواست ها، ارسال ها، پرس و جوها، جایی که) و سبک جمله به عنوان مثال توصیف شود.
کاری که بازیگر انجام می دهد
“درخواست های کاربر…”
آنچه سیستم در پاسخ انجام می دهد
“سیستم پیامی به و… می فرستد”.
برای بررسی قوانین تجارت
“اگه اونوقت”
در جریان رویداد، نام بازیگر به‌طور واضح در نمودار مورد استفاده نشان داده نمی‌شود، بلکه به جای آن به «کاربر» ارجاع داده می‌شود. با این حال، اگر مناسب نباشد که جریان استفاده از رویدادها به «کاربر» اشاره کند (یعنی زمانی که کنشگر زمان است یا یک سیستم خارجی)، باید از «بازیگر» استفاده شود.
هر مرحله در جریان رویداد باید به ترتیب شماره گذاری شود.
زیرنویس
برای کمک به درک و پیمایش موارد استفاده، گنجاندن سرفصل‌هایی در جریان رویداد که عملکرد مجموعه‌ای از مراحل را توصیف می‌کنند، اغلب می‌تواند مفید باشد. این عناوین در همه موارد استفاده مورد نیاز نیستند، اما به ویژه در جریان‌های مورد استفاده بزرگ و پیچیده که شامل مراحل زیادی است، مفید هستند.
مثال
- کاربر ادامه انتقال کسب و کار را انتخاب می کند.
رسیدگی به مسئولیت ناروا
- سیستم سود نماینده، تعهدات کمیسیون دریافت نشده را به عنصر سازمان نماینده برمی گرداند. سیستم سود نماینده جزئیات زیر را از بدهی های کمیسیون غیرقابل کسب عنصر سازمان نماینده ارائه می دهد:
- تعداد نمودارها
- مبلغ کل بدهی کمیسیون دریافت نشده
- این سیستم کل بدهی های کمیسیون دریافت نشده را تأیید می کند.
- اگر کل بدهی پورسانت دریافت نشده > 0 [BR48]این سیستم جزئیات بدهی کمیسیون معوقه را نمایش می دهد و به کاربر این امکان را می دهد که در قالبی مناسب برای ارسال به نماینده چاپ کند. [BR46].
انتقال تجاری
- برای هر عنصر سازمانی که برای انتقال انتخاب می شود، سیستم ثبت می کند که کار برای عنصر سازمان انتخاب شده منتقل شده است و تاریخ انتقال [BR43]
تکرار
در شرایط خاص، جریان رویدادها ممکن است نیاز به چند مرحله تکرار داشته باشد تا زمانی که یک شرط خاص برآورده شود، در این شرایط، عبارت FOR EACH…..REPEAT باید استفاده شود، برای مثال برای هر ویژگی REPEAT، مراحل 8-. 12.
بیانیه های IF
جایگزین های ساده را می توان در جریان اصلی کاربرد مورد توصیف کرد تا پردازش اختیاری غیرمعمول یا رسیدگی به استثنا را توصیف کند. اگر برای توصیف پردازش جایگزین فقط چند مرحله طول می‌کشد، این کار را مستقیماً در بخش جریان اولیه رویدادها (با استفاده از یک دستور IF) انجام دهید، نه اینکه از جریان جایگزین استفاده کنید.
دستور “if” باید یک مرحله جداگانه شماره گذاری شده باشد که در جریان اصلی قرار دارد (به بخش تودرتو در زیر مراجعه کنید). عبارت «اگر» باید در زیر یک مرحله تو در تو قرار گیرد که مسیر اصلی عمل را بیان می کند یا مراحل تودرتو را خلاصه می کند.
مثال
سیستم اطلاعات وارد شده مشتری را تایید می کند، هر گونه خطا باید قبل از ادامه کار برطرف شود، هر پیام هشداری را می توان پذیرفت و مورد استفاده ادامه می یابد:
اگر هیچ یک از فیلدهای اجباری وارد نشده باشد [BR1]سیستم یک پیغام خطا نشان می دهد که فیلدهای اجباری وارد نشده اند (پیام شماره 0001)
لانه سازی
تحت شرایط خاصی، یک مرحله در یک جریان ممکن است شامل تعدادی از مراحل همپوشانی باشد. این امر از نیاز به تقسیم مراحل همپوشانی به یک جریان جایگزین جلوگیری می کند. هنگام توصیف پردازش سیستم تودرتو، باید از شماره گذاری تودرتو استفاده شود (به عنوان مثال 4. 4.1. 4.1.1.).
با این حال، اگر چندین سطح از تودرتو در جریان استفاده شود، درک مورد استفاده می تواند بسیار دشوار شود. بنابراین، به عنوان یک قاعده کلی، بیش از دو سطح تودرتو نباید استفاده شود (یعنی 4.1.1. قابل قبول، 4.1.1.1. غیر قابل قبول).
به موارد استفاده مربوطه اشاره کنید
اگر جریان نیاز به ارجاع به یک مورد استفاده تعبیه شده دارد، فعال سازی مورد استفاده جاسازی شده را به همراه نام و شماره مرجع مورد استفاده در جریان وارد کنید. زبان استاندارد برای فعال کردن کیس کاربری داخلی برای استفاده، “INVOKE” است.
به عنوان مثال، هنگامی که یک عنصر سازمانی انتخاب می شود، سیستم گروه نمایش UC11 را فراخوانی می کند که جزئیات عنصر سازمانی انتخاب شده را نمایش می دهد.
با اشاره به رابط کاربری
ارائه یک ارجاع متقابل بین موارد استفاده و استوری‌بورد مورد استفاده برای کمک به درک اینکه کدام صفحه‌ها/صفحه‌ها در مراحل خاصی از موارد استفاده نمایش داده می‌شوند، مفید است. این رویکرد به ویژه برای طراحان و آزمایش کنندگان مفید است.
این را می توان با اختصاص یک شناسه منحصر به فرد به هر UI با استفاده از استوری برد مورد استفاده به دست آورد. شناسه منحصر به فرد رابط کاربری باید به شکل UcnnSCxx باشد. سپس می‌توان به این شناسه منحصربه‌فرد به همراه مرحله‌ای در جریان رویداد اشاره کرد که در آن ابتدا این رابط کاربری نمایش داده می‌شود.
به عنوان مثال، سیستم از کاربر می خواهد معیارهای جستجو (UC10SC01) را وارد کند.
عناصر داده
هنگامی که اطلاعات بین بازیگر و سیستم رد و بدل می شود، در مورد آنچه به عقب و جلو منتقل می شود، مشخص باشید. به عنوان مثال، گفتن اینکه کاربر «اطلاعات مشتری» را وارد می کند، چندان مفید نیست. همچنین اطلاعاتی در مورد عناصر داده در آرتیفکت در برد Use Case Story وجود دارد. از دستورالعمل‌های زیر در رابطه با میزان اطلاعاتی که باید در یک مورد استفاده در ارتباط با تبادل داده جمع‌آوری کنید، استفاده کنید.
موارد داده‌ای که روی صفحه نمایش داده می‌شوند یا بین بازیگر و سیستم ارسال می‌شوند را با جزئیات فهرست کنید، به‌عنوان مثال، نام، نام خانوادگی، خطوط آدرس 1-4، کد پستی و غیره.
در کنار هر مورد داده در فهرست، مشخص کنید که آیا فقط خواندنی/غیرفعال است یا خیر، و هر یادداشتی که برای آن مورد داده اعمال می شود.
مثال
- سیستم از کاربر می خواهد تا مشخصات مشتری را وارد کند [BR1]:
- شماره حساب بانکی (فقط خواندنی) – به طور خودکار توسط سیستم اختصاص داده می شود [BR2]
- نام مشتری
- خطوط عنوان (1-4)
- کد پستی
- تاریخ ثبت نام – با تاریخ فعلی سیستم پر شده است
یک قانون تجاری باید برای توصیف عناصر داده اجباری استفاده شود. یک قانون تجاری جداگانه باید برای هر نمونه جداگانه از تبادل داده بین یک بازیگر و سیستم برای تعریف عناصر داده اجباری برای آن تبادل استفاده شود.
هر گونه اعتبارسنجی که روی یک عنصر داده (مثلاً تاریخ بین یک محدوده معین) یا بین عناصر داده (به عنوان مثال، مقدار یک عنصر داده ممکن است بر مقادیر مجاز عنصر داده دیگری تأثیر بگذارد) نیز باید به صورت توصیف شود. یک قانون تجاری
مقادیر موجود/قابل انتخاب را برای یک آیتم داده در جریان رویداد تنها در صورتی تعریف کنید که مقدار مورد داده در مورد استفاده ارجاع داده شده باشد یا قوانین تجاری در مورد انتخاب یک مقدار خاص وجود داشته باشد.
برای وضوح، نوع داده (به عنوان مثال، عدد، تاریخ، و غیره)، قالب (به عنوان مثال، dd/mm/yyyy)، و طول باید در صفحه داستان مورد استفاده مستند شود.
پیام های خطا
هنگامی که یک خطا یا پیام هشدار به یک بازیگر گزارش می‌شود، جریان استفاده از رویدادها باید نشان دهد که در کجای جریان رویداد، پیام باید گزارش شود و نشانه‌ای از موضوع پیام ارائه کند. با این حال، متن پیام دقیق باید در یک مصنوع جداگانه ذخیره شود، که به عنوان کاتالوگ پیام نامیده می شود.
این آرتیفکت علاوه بر مصنوعات استاندارد RUP است. هر پیام در کاتالوگ پیام باید یک شناسه منحصر به فرد از فرم MSGnnnn داشته باشد و جریان استفاده از رویدادها باید به این شناسه منحصر به فرد اشاره داشته باشد، به عنوان مثال «سیستم خطایی را نشان می دهد که به کاربر اطلاع می دهد که محصول را نمی توان در مورد درخواستی عرضه کرد. تاریخ به دلیل زمان تحویل مرتبط (پیام شماره 0001)“.
جریان رویداد باید روشن کند که آیا پیام یک خطا (که در آن کاربر باید اقدام متفاوتی انجام دهد) یا یک هشدار (جایی که پردازش پس از تأیید پیام توسط کاربر ادامه می‌یابد) برای بازیگر است، به عنوان مثال.
“سیستم به کاربر هشدار می دهد که تحویل در این تاریخ نمی تواند تضمین شود.” (MSG0002)متن دقیق خطاها و هشدارها باید با ذینفعان توافق شود، سپس توسط تیم توسعه در طول ساخت اجرا شود.
پس از نمایش یک پیام خطا/اخطار، جریان رویدادها باید مشخص باشد که چه اتفاقی می افتد. برای جلوگیری از استفاده از عبارات اضافی GOTO که ممکن است پیمایش جریان رویداد را دشوار کند، توصیه می‌شود قبل از اعتبارسنجی یک عبارت ایجاد کنید که توضیح دهد در صورت بروز خطا چه اتفاقی می‌افتد و در صورت هشدار چه اتفاقی می‌افتد (نگاه کنید به مثال).
گزینه‌هایی برای کاهش میزان تکرار پیام‌ها با عمومی کردن پیام‌ها و «پارامترمحور» در دسترس هستند. یک مثال خوب از موفقیت این رویکرد، پیام هایی است که به کاربر اطلاع می دهد اطلاعات اجباری ارائه نکند.
برای اینکه این پیام عمومی و “پارامتر محور” شود، در متن پیام، پارامتر را با علامت درصد (%) و به دنبال آن یک شماره سریال (محصول در پیام) جایگزین کنید.
سپس در ستون Parameters، شماره سریال و پارامتری که با آن مرتبط است را فهرست کنید. به عنوان مثال، برای نمایش “نام فیلد “% 1 یک فیلد اجباری است – لطفا وارد کنید”، پیام زیر در ستون “پیام متن” فهرست پیام قرار می گیرد “% 1 یک فیلد اجباری است – لطفا وارد کنید” و ستون “پارامترها” “1” خواهد بود. – نام فیلد”.
توجه داشته باشید که این رویکرد برای ایجاد پیام برای همه انواع پیام کار نخواهد کرد. بسیار مهم است که پیام های ارائه شده به نماینده به جای تلاش برای عمومی کردن پیام ها در تلاش برای جلوگیری از تکراری و افزایش استفاده مجدد از پیام، معنی دار باشند.