نحوه تعریف سناری برای یوز کیس در UML

تعریف سناریو برای use case ها در یو ام ال

توسط admin | گروه مهندسی نرم افزار | 1399/03/20

نظرات 0

سناریو در یو ام ال برای یوز کیس ها

مستند سازي جريان رخدادها (Flow of Event)

Use case در پروژه مهندسی نرم افزار و تجزیه و تحلیل سیستمهای نرم افزاری UML شروع مي كند به توضيح دادن اينكه سيستم شما چه كاري را انجام مي دهد. براي اينكه سيستم را بصورت حقيقي بسازيد، نياز به جزئيات مشخص بيشتري داريد. اين جزئيات در يك سند كه جريان رخدادها (Flow of Event) ناميده مي شود، نوشته مي شوند.
جريان رخدادها اين است كه جريان منطقي در سرتاسر use case را مستند سازي مي كند. اين سند تمام آنچه كاربر سيستم انجام مي‌دهد و آنچه كه كاربر سيستم انجام مي دهد و آنچه كه خود سيستم انجام مي‌دهد را تعريف مي كند.
جريان رخدادها هنوز از نظر اجرايي مستقل عمل مي كنند. مي‌توانيد فرض كنيد كه در حال نوشتن جرياني هستيد كه يك سيستم مكانيزه خواهد بود. به هر حال در اين حالت هم نبايد نگران اين باشيد كه سيستم در C++ساخته مي شود يا در Power Builder يا در Jvav. هدف نهايي در اينجا هم آنچه كه سيستم انجام مي دهد خواهد بود، نه اينكه سيستم چگونه آن را انجام مي دهد. جريان رخدادها داراي بخشهاي زيراست:
يك تعريف مختصر
پيش شرايط
جريانهاي رخدادهاي اصلي 
جريانهاي رخدادهاي فرعي
شرايط پسين(Postcondition)
تعريف (descripition)
هر use case بايد يك تعريف مختصر مرتبط با آنچه كه use case انجام مي دهد را داشته باشد. Use caseمربوط به انتقال وجوه در ATM ممكن است تعريفي مانند زير داشته باشد:
use case مربوط به انتقال وجوه، به مشتري يا كارمند بانك اجازه مي دهد تا وجوه را از يك حساب پس انداز يا حساب در حال بررسي به يك حساب پس انداز ديگر يا حساب در حال برررسي ديگر، منتقل كند.
تعريف بايد كوتاه ومرتبط باشد، ولي بايد تمام كاربرهاي متفاوتي كه    use case را اجرا مي كنند و نيز نتيجه نهايي كه كاربر توقع دارد توسط use case به آن برسد را دربرداشته باشد.
همچنان كه پروژه جلو مي رود(خصوصا در پروژه هاي طولاني)،
اين تعاريف use case، به تمام تيم كمك مي كند تا بخاطر آورند كه دليل قرار گرفتن هر use case در پروژه چه بوده است و قرار بوده هر use case چه كاري را انجام دهد. همچنين با مستند سازي دقيق هدف، use case به كاستن سردرگمي بين اعضاي تيم كمك مي كند.

پيش شرايط (Precondition)
پيش شرايط يك use case، ليستي از شرايطي هستند كه قبل از شروع كار use case بايد بررسي شوند. به طور مثال، يك پيش شرط مي تواند اين باشد كه يك use case ديگر اجرا شده است و يا كاربر حق دستيابي مستقيم براي اجراي use case جاري را دارد.تمام use case ها داراي پيش شرط نيستند.
توضيحاتي كه در بالا داده شدند در واقع اين نكته پروژه مهندسی نرم افزار را متذكر مي‌شوند كه نمودارهاي use case، نشاندهنده ترتيبي كه بايد use caseها اجرا شوند، نيستند. پيش شرايط، مي توانند براي مستندسازي برخي اطلاعات اين چنيني مي باشند: به طور مثال، ممكن است پيش شرايط يك use case اين باشد كه يك use case ديگر اجرا شده باشد.
جريان رخداد اصلي وفرعي
مشخصات كامل use case در جريان رخداد اصلي وفرعي تعريف شده است.جريان رخدادها، آنچه را كه در اجراي عمليات در use case پيش خواهد آمد را مرحله به مرحله توصيف مي كند. جريان رخدادها بر آنچه سيستم انجام خواهد داد متمركز مي شود ولي به چگونگي انجام آن كاري ندارد زيرا جريان رخداد از ديد كاربر نوشته مي شود.جريان رخدادهاي اصلي و فرعي شامل موارد زير است:
چگونگي شروع كار use case
مسيرهاي متنوع منتهي به use case
جريان رخداد معمولي يا اوليه منتهي به use case
در طول use case هر گونه انحرافي از جريان رخداد اصلي به عنوان روند فرعي شناخته مي شوند.
هر روند خطا
چگونه use caseبه پايان مي رسد.
به طور مثال،جريان رخداد براي use case مربوط به برداشت پول از حساب ممكن است به اين شكل باشد:
جريان اوليه
1. use case وقتي شروع مي شود كه مشتري بانك كارتش را درون ATM قرار دهد.
2. ATM يك پيغام خوش آمدگويي به مشتري مي دهد و به او اجازه مي دهد كه شماره مشخصات فردي (PIN) خويش را وارد نمايد.
3. مشتري بانك PIN خود را وارد مي كند.
4. ATM صحت و اعتبار PIN را بررسي مي كند. اگرPIN معتبر نباشد، روند فرعيA1 انجام خواهد شد .
5. ATM گزينه هاي زير را آماده مي كند:
وجوه واريز شده
برداشت نقدي
انتقال وجوه
6. كاربر گزينه برداشت از حساب را انتخاب مي كند.
7. ATM اجازه برداشت مي دهد.
8. كاربر مقداري كه مي خواهد برداشت كند را وارد مي نمايد.
9. ATM بررسي مي كند كه آيا در حساب به اندازه مورد نياز پول موجود است يا خير. اگر به اندازه كافي پول موجود بود، جريان رخداد فرعي A2انجام خواهد شد.
اگر در يافتن مقدار وجوه خواسته شده اشكالي ظاهر شود، روند خطايE1انجام خواهد شد.
10. ATM مقدار وجوه برداشت شده ازحساب مشتري را كم مي كند.
11. ATMوجه خواسته شده را به مشتري پرداخت مي نمايد.
12. ATM يك رسيد براي مشتري چاپ مي كند.
13. ATM، كارت مشتري را از دستگاه بيرون مي فرستد.
14. use case به پايان مي رسد.
جريان رخداد فرعي A1 :PIN وارد شده نا معتبر 
1. ATM به مشتري اخطار مي دهد كه به مقدار كافي پول در حساب او موجود نيست .
2. ATMكارت مشتري را بيرون مي فرستد .
3. Use case  به پايان مي رسد.
روند خطاي E1  : خطا در صحت وجوه درخواستي 
1. ATM يك پيغام خطا را به مشتري مبني بر اينكه خطايي در شناسايي وجوه پيش آمده است ، مي دهد و شماره تلفن مركز خدمات بانكي را به مشتري ارائه مي كند.
2. ATM، خطاي پيش آمده را در ركورد خطاها ثبت مي كند.ركورد مربوطه داراي نام مشتري و شماره حساب، تاريخ و ساعت وقوع خطا و كد خطا، خواهد بود.
3. ATM كارت مشتري را بيرون مي فرستد.
4. use case به پايان مي رسد.
زمان مستند سازي جريان رخدادها، مي توانيد مانند مثال بالا از ليست‌هاي شماره دار، و يا متون پاراگراف بندي شده، ليست هاي bullet شده و يا حتي فلوچارت استفاده كنيد.
روند جريان بايد با نيازهاي جمع آوري شده، هماهنگي داشته باشد. هنگامي كه تصميم مي گيريد يك جريان را مستندسازي كنيد، بازديدكنندگان از سند را بخاطر بسپاريد. مشتريان اين سند را وارسي مي‌كنند تا ببينند كه آيا عملكرد آن، توقعات ونيازهاي آنها را برطرف مي‌سازد يا نه.
تحليلگر(Analyst) براي اطمينان از اينكه آيا سند با نيازها هماهنگي دارد يا خير، آن را بررسي مي كند.مديرپروژه آن را بررسي مي كند تا بتواند تصويربهتري، از آنچه قرار است ساخته شود را بدست آورد.
چنانچه بخواهد، بتواند برآوردهاي هزينه مربوط به پروژه را اصلاح كند.هنگامي كه درحال نوشتن جريان هستيد، از جزئيات چگونگي كار دوري كنيد. به فكر نوشتن دستورالعمل باشيد. يك دستورالعمل مي‌واند به اين شكل باشد« دوتخم مرغ اضافه كن‌» هرگز نبايد بگوييد «به سمت يخچال برو. تخم مرغ را از آنجا بردار. اولين تخم مرغ را در دست بگير. آن را به كنار كاسه بزن...» در جريان رخداد ممكن است بگوييد اعتبارIDكاربررا بررسي كن». ولي مشخص نخواهيد كرد كه اين عمل با نگاه كردن به كدام جدول مربوطه در جدول بانكي صورت
خواهد گرفت. توجهتان بايد بر روي اطلاعات رد وبدل شده بين كاربر و سيستم باشد و نه بر روي اينكه سيستم چگونه كار خود را انجام  مي دهد.

Post Conditions (شرايط پسين)
Postcoditionها شرطهايي هستند كه بايد بعداز پايان اجراي use case، داراي مقدار tnue باشند، به طور مثال، ممكن است بعد از كامل‌دن يك use case ، يك flag را تنظيم كرده باشيد. اينچنين اطلاعاتي شرايط پسين (Postconditions) ناميده مي شوند. مانند پيش شرايط، شرايط هاي پسين هم مي توانند براي افزودن اطلاعاتي درباره جرياني كه use caseها در آن اجرا مي شوند، به كار گرفته شوند. به طور مثال، اگر يك use case هميشه بايد بعد از يك use case ديگر اجرا شود، مي توانيد آن را در يك شرايط پسين مستندسازي كنيد. همه use caseها داراي شرايط پسين نيستند.
كار كردن با عامل ها (Actor)
هر كس يا هر چيزي كه با سيستم موجود برهم كنش دارد، عامل (actor) ناميده مي شود.use caseها هر چيز موجود درمحدوده سيستم را توصيف مي كنند، در حالي كه عامل ها در خارج از محدوده سيستم قرار دارند. در UML، عامل ها با آدمك هايي به شكل زير نشان داده مي شوند:


Actor 1
سه نوع اصلي از عامل ها وجود دارند: كاربران سيستم، سيستم هاي ديگري كه باسيستم موجود درارتباط هستند وزمان.
اولين نوع عامل يك انسان فيزيكي و يا به عبارت ديگر كاربر است. اينها بيشترين عامل مورد استفاده هستند و تقريبا در تمام سيستمها وجود دارند. درمثال ATM، برخي از كاربران ممكن است مشتريان ATM يا، فرد پشتيبان ATM باشند. براي نامگذاري اين عامل ها ترجيحا به جاي استفاده از نام موقعيت، از نام نقشها استفاده كنيد.يك نام منحصر به فرد مزاياي مهمي دارد. ممكن است يك روز صبح John Doe مسئول پشتيباني ATM باشد، يعني بازيگر نقش پشتيبان ATM. ممكن است از او بخواهد در اواسط روز مقداري پول ازحساب خود براي خريد غذاي ظهر برداشت نمايد. 
پس در اينجا او نقش مشتري ATM را خواهد داشت.استفاده از نام نقشها به جاي استفاده از نام موقعيت، تصوير پايدارتري از عامل ها را به شما ارائه خواهد داد. نام موقعيت براي يك عامل ممكن است تغيير كند و رابطه ها و مسئوليت ها ازيك موقعيت به يك موقعيت ديگر انتقال يابد. بااستفاده از نقشها، با افزايش يا تغيير يك موقعيت، نيازي به بروز رساني مدل نخواهيد داشت.
دومين نوع عامل، سيستم ديگر است.به طور مثال، ممكن است بگوييد كه بانك ما داراي يك سيستم اعتباري است كه براي پشتيباني از اطلاعات اعتبار حساب هر مشتري استفاده مي شود. سيستم ATM، ما بايد قابليت محاوره(ارتباط) با اين سيستم اعتباري را داشته باشد. 
در اين مورد، سيستم اعتباري داراي نقش عامل خواهد بود. دقت كنيد كه با دادن نقش عامل به اين سيستم، فرض ما براين است كه سيستم اعتباري به هيچ وجه تغيير نمي كند. به خاطر داشته باشيد كه عامل ها در بيرون از محدوده سيستمي كه ما مي سازيم قرار دارند و درنتيجه كاملا خارج از كنترل ما مي باشند. اگر بخواهيم در سيستم اعتباري تغييرات مهمي ايجاد كنيم، اين سيستم بايد درون محدوده پروژه باشد و داراي نقش عامل نباشد.
سومين نوع عامل كه زياد استفاده مي شود، زمان است. هنگامي كه زمان تبديل به يك عامل مي شود كه زمان در حال گذر باعث ايجاد رخدادي در سيستم گردد. به طور مثال ممكن است سيستم ATM هر نيمه شب يك پردازش تطبيق سيستم انجام دهد. چون زمان خارج از كنترل ما است، يك عامل مي باشد.
ساخت يك عامل Abstract
يك عامل Abstract، عاملي است كه هيچ مصداق واقعي ندارد. به عبارت ديگر، كادريناليتي عامل، دقيقا صفر است. به طور مثال، ممكن است چندين عامل داشته باشيد: كارمند ساعتي، كارمند ثابت و كارمند موقتي . تمامي اينها نوعي از عامل چهارم هستند كه عامل كارمند مي باشد. باوجود اين، هيچ كس در شركت فقط يك كارمند نيست- هر كس يا كارمند ساعتي است، يا كارمند ثابت است يا موقتي. دليل وجود عاملي با نام كارمند اين است كه رابطه معمول استخدام ساعتي، استخدام با حقوق ثابت و استخدام موقتي، نشان داده شود.هيچ مرحله و مصداق واقعي براي عامل كارمند وجود ندارد، پس آن يك، عامل Abstract خواهد بود.
روش ايجاد يك عاملAbstract:
1. در مرورگرو يا نمودار use case، عاملي را ايجاد نماييد.
2. در مرورگر و يا نمودارuse case، بر روي عامل كليك راست كنيد.
3. از منوي باز شده Open Specification را انتخاب نماييد.
4. برگه Detail را باز كنيد.
5. كادر انتخاب Abstract را علامت گذاري نماييد.
 
چگونگي كار با رابطه ها
UML از انواع متعددي از رابطه ها براي use caseها و عامل ها پشتيباني مي كند. اين شامل رابطه هاي Communiccation، رابطه‌هاي extend و رابطه هاي generalization براي عامل مي باشد.
رابطه هاي uses و extend، رابطه هاي بين use caseها را تعريف مي كنند. رابطه هاي Actor generalization، رابطه بين عامل‌ها را تعريف مي كند.
رابطه Communiccation
به رابطه بين use case و عامل، رابطه Communiccationمي گويند. در UML، رابطه هاي اطلاعاتي با استفاده از فلش به حالت نمودار درمي آيند. 
 
ابتداي فلش نشان دهنده كسي است كه ارتباط از آنجا شروع مي شود. در مثال زير، عامل مشتري، آغازگر ارتباط با سيستم براي برداشت پول از حساب مي باشد. يك use case هم مي تواند آغازگر ارتباط با يك عامل باشد. 
 
در اين مثال، use case آغازگر ارتباط با عامل سيستم اعتباري است. در زماني كه use case مربوط به پرداخت پول دراجرا است، سيستم ATM ارتباط با سيستم اعتباري را براي كامل كردن محاوره شروع مي كند. 
تبادل اطلاعات در هر دو جهت انجام مي شود. از سيستم ATM به سيستم اعتباري و به عكس، و فلش تنها نشان دهنده آغازگر اين ارتباط خواهد بود.
نمودارهاي Interaction
يك نمودار Interaction روندي در يك use case را مرحله به مرحله نشان مي دهد. در مثال ATM، ما چندين روند مناسب را درuse case مربوط به برداشت پول از حساب داشتيم(Withdraw Money). چندين نمودار Interaction براي اين use case خواهيم داشت. يكي از آنها نمودار Interaction با نام happy day است كه نشان مي دهد وقتي همه چيز به خوبي درحال انجام است چه اتفاقي مي افتد. 
نمودارهاي اضافي ديگري را خواهيم داشت كه نشان دهنده اين است كه چه اتفاقي براي رخدادهاي متناوب مي افتد. وقتي كسي PIN را اشتباه وارد مي كند چه رخ خواهد داد، وقتي پول كافي هنگام برداشت از حساب وجود نداشته باشد چه رخ خواهد داد و غيره.
 
مطالعه ادامه مقاله در فایل WORD DOC   زیر ،  تعداد صفحه 102 می باشد. لطفا پس از دانلود مقاله ، یک فاتحه رفتگان مرا میهمان نمایید . . . 
 

 

0 نظر

نظر محترم شما در مورد مقاله های وب سایت برنامه نویسی و پایگاه داده

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

حرف 500 حداکثر