پروژه مهندسی نرم افزار UML انبارداری بخش نهم
نکاتی راجع به نوشتن سناریو برای Use Case ها
معمولا سناریویی که برای هر Use Case نوشته می شود برای رعایت نظم درون جدولی مانند شکل زیر نوشته می شود. این جدول به صورت استاندارد دارای بخشهایی است که معمولا در هنگان نوشتن سناریوهای مختلف برای برخی از قسمتهای آن را نمی توان تعریفی نوشت. به عنوان مثال در برخی از سناریوها قیود Use Case ذکر می شوند و در برخی سناریو ها قیودی وجود ندارد که نوشته شود.
|
محل درج شماره سناریو
|
محمل درج نام سیستم یا زیر سیستم
|
محل درج نام Use Case و نام Actor
|
|
Scenario Description: در این بخش شرح مختصری از سناریو نوشته می شود.
|
|
Assumption: در این بخش تعریفی از اکتور بیان می شود و شرح داده می شود که وظیفه Actor مورد نظر در این Use Case چیست.
|
|
Include: در این بخش نوع ارتباط با Use case های دیگر در صورت وجود مشخص می شود.
|
Extended: در این بخش نوع ارتباط با Use case های دیگر در صورت وجود مشخص می شود.
|
|
(Pre-Condition): در این بخش معمولا شرط یا شروطی نوشته می شوند که قبل از اتفاق افتادن Use Case باید برقرار باشند. یا به عبارتی شرایطی که باید اتفاق بیفتند تا Use Case فعال شود.
|
|
مراحل: ( یا Main Flow) جریان اصلی کار به صورت جزء به جزء شرح داده می شود.
|
Actor
|
System
|
|
در این بخش عملیاتی که اکتور درخواست می دهد به صورت مرحله به مرحله نوشته می شود.
|
در این بخش عملیاتی که سیستم انجام می دهد به صورت مرحله به مرحله نوشته می شود.
|
|
Constraints: در این بخش قیودی که در هنگام انجام Use Case باید اعمال شوند نوشته می شوند.
|
|
Post-Condition: شرایطی که بعد از اتمام کار Use Case ایجاد می شود را Post-Condition می گویند.
|
|
Alternative Flow: جریان فرعی Use Case در این بخش شرح داده می شود. مانند خطاها و Exception ها.
|
|
Goal: در این بخش هدف اصلی که باید به آن رسیده شود نوشته می شود.
|
| |
|
|
|
|
|
در ادامه به ارائه سناریو برای هر یک از Use Case ها خواهیم پرداخت.
سناریوی Boss Mailbox Use Case
|
سناریوی شماره 1
|
سیستم انبار شيشه
|
نام: صندوق پستي
Actor: مدیر انبار
|
|
شرح سناریو: در این سناریو ، مدیر انبار پس ازورود به سیستم ، وارد صندوق پستي خود می شود و نسبت به ارسال پیامها و بررسی پیامهای رسیده اقدام می نماید.
|
|
Assumption: منظور از مدیر انبار در این Use Case در حقیقت فردی است که تمامی امور انبار زير نظر اين شخص انجام مي شود و بالاترین شخص از نظر سطوح دسترسی به اطلاعات می باشد و می تواند هر گونه ویرایشی در اطلاعات درج شده انجام دهد.
|
|
Communicate: مدیر انبار
|
Extended: صفحه اصلی نرم افزار
|
|
(Pre-Condition): پس از بروز رسانی ، از طریق ارسال پیغام به صندوق پستي ساير كاربران ، به آنها اطلاعات داده می شود. در صورتی که پيام جدیدی در صندوق موجود باشد به آن پاسخ داده خواهد شد.
|
|
مراحل:
|
Actor
|
System
|
|
1- مدیر بر روی کلید ورود به صندوق پستي کلیک می نماید.
|
2- سیستم صفحه مربوط به صندوق پستي را نمایش می دهد.
|
|
|
3- سیستم در صورت وجود ، پيامهاي های رسیده جدید را نمایش می دهد.
|
|
4- مدیر انبار پيام های مورد نظر را ارسال می نماید.
|
5- سیستم فهرست تائید ارسال نامه های ارسالی را نمایش می دهد.
|
|
|
6- سیستم پيامها ی خوانده شده ، خوانده نشده و جواب داده شده را به تفکیک نمایش می دهد.
|
|
Constraints: نحوه پاسخ به پيامها توسط مدير انبار مشخص می گردد.
|
|
Post-Condition: پس از ارسال پيام به کاربران ، کاربران ثبت نامی باید بتوانند به اطلاعات موجودي جدید انبار دسترسی داشته باشند. کاربران به گونه ای باید از دریافت پيام در صندوق پستي خود در هنگام استفاده از سایر بخشهاي نرم افزار انبار آگاه شوند.
|
|
Alternative Flow: درصورتی که پيام به هر دلیلی ارسال نشد باید از طرف سیستم پیغام مناسبی صادر شود.
|
| |
|
|
|
|
|