دیاگرامهای Use Case

Use case diagrams موارد زیر را نشان می دهد:

• Use caseها: یک use case، ترتیب اعمالی را که چیزی از valueی قابل اندازه گیری را برای یک actor فراهم می کند، و به عنوان یک بیضی افقی رسم می شود، توصیف می کند.

Actorها: یک actor، یک شخص، سازمان، یا سیستم خارجی است که در یک یا چند تعامل با سیستم شما نقشی دارد. Actorها به صورت نمادآدمک ترسیم می شوند.

• Associationها: رابطه بین actorها و use caseها، در دیاگرام use case، توسط خطوط توپر نشان داده می شوند. هر جا که actor درگیر تعاملی است که توسط یک use case، توصیف شده است، رابطه ای وجود دارد. Associationها به صورت خطوطی که use caseها و actorها را با یک فلش (arrowhead) روی یکی از خطوط به هم وصل می کنند، مدل سازی می شوند.اغلب از سرنیزه برای نشان دادن جهت فراخوانی اولیه رابطه، یا برای نشان دادن actor ابتدایی درون use case استفاده می شود. نوک نیزه ها معمولاً با data flow اشتباه گرفته می شود.
• جهبه دربرگیرنده سیتم (اختیاری): می توان یک مستطیل دور use caseها رسم کرد، که system boundary box نامیده می شود، تا گستره سیستم شما را نشان دهد. هر چیزی درون box نشانگر عملکردی است که در دید است و هرچیزی بیرون از box اینگونه نیست. Boxهای محدوده سیستم بندرت استفاده می شوند، گرچه من در بعضی موارد از آنها جهت تشخیص اینکه کدام use caseها در هر release عمده از سیستم تحویل داده می شوند، استفاده کرده ام. شکل شماره 2، چگونگی انجام این را نشان می دهد.
• بسته ها (اختیاری): بسته ها (packages) ساختارهای UMLیی هستند که شما را قادر به طبقه بندی عناصر مدل (از قبیل use caseها) به صورت گروهایی می کند. بسته ها به صورت file folders نشان داده می شوند و می توان آنها را در هر دیاگرام UML، شامل دیاگرام use case و کلاس دیاگرام، استفاده کرد. من از بسته ها، فقط زمانی استفاده می کنم که دیاگرام های من سنگین می شوند - یعنی اینکه روی یک صفحه چاپ نمی شوند - و نمی توان یک دیاگرام بزرگ را به دیاگرام های کوچک تر طبقه بندی کرد. شکل 3، نشان می دهد چگونه می توان شکل 1 را با بسته ها صبقه بندی کرد.

در مثالی که در شکل 1 نشان داده شده است، دانش آموزان با کمک مسئولین مربوطه در حال ثبت نام هستند. استادها در حال وارد کردن نمره هایی هستند که دانش آموزان در تکالیفشان بدست آورده اند، و مسئولین ثبت نام، کارنامه های دانش آموزان را نیز توزیع می کنند. دقت کنید که چگونه بعضی از use caseها درگیر چند actor هستند. به این موضوع نیز دقت داشته باشید که چگونه بعضی از associationها دارای arrowhead هستند- هر use case association معین، یک arrowhead صفر یا یک خواهد داشت. رابطه (association) بین دانش آموز و ثبت نام در seminar (شکل 4) نشان می دهد که این use case ابتداً توسط یک دانش آموز فراخوانی می شود نه مسئول ثبت نام (actor مسئول ثبت نام نیز در این use case درگیر است). فهم اینکه associationها، جریان های اطلاعات را نشان نمی دهند مهم است؛ آنها صرفاً actorیی را نشان می دهند که تا حدودی درگیر یک use case هستند. اطلاعات بین actor و use case رد و بدل می شود، مثلاً، دانش آموزان باید نشان بدهند قصد ثبت نام در کدام seminar را دارند، و سیستم باید به دانش آموزان نشان دهد ایا آنها ثبت نام شده اند یا خیر. اما، دیاگرام های use case، این نوع اطلاعات را مدل سازی نمی کنند. جریان اطلاعات را می توان با استفاده از UML activity diagrams مدل سازی کرد. خط بین Enroll در Seminar use case وactor registrar هیچ arrowheadیی ندارد، که نشان می دهد معلوم نیست تعامل بین سیستم و مسئولین ثبت نام چگونه شروع می شود. ممکن است یک مسئول ثبت نام متوجه شود دانش آموزی نیاز به کمک دارد و او را کمک کند، در حالیکه، در مواقعی ممکن است خود دانش آموز از مسئول ثبت نام تقاضای کمک کند، اطلاعات مهمی که در توصیف use case، مستند می شود.

Actorها همیشه با حداقل یک use case درگیر هستند، و همیشه روی لبه های بیرونی دیاگرام use case رسم می شوند.

شکل شماره 1: سیستم دیاگرام use case

شکل شماره 2: استفاده از System boundary boxes جهت نشان دادن releaseها

شکل شماره 3: اعمال packageها جهت ساده کردن دیاگرامهای use case

ایجاد دیاگرام های use case

دوست دارم تا آنجا که ممکن است، actorهای زیادی را معرفی کنم. شما باید بپرسید actorها چگونه با سیستم در تعامل است تا مجموعه ای از use caseهای ابتدایی را معرفی کند. سپس، روی دیاگرام، actorها را به use caseهایی که با آنها درگیر هستند، متصل می کنید. اگر یک actor اطلاعاتی را فراهم کند، use case را راه بیاندازد، یا اطلاعاتی رابه عنوان خروجی use case دریافت کند، آنگاه باید ارتباطی بین آنها وجود داشته باشد. من معمولاً arrowheadها را وارد خطوط ارتباط (association lines) نمی کنم زیرا تجربه من نشان می دهد که افراد آنها را با نشانه های جریان اطلاعات (information flow) اشتباه می گیرند، نه با فراخوانی اولیه.

پاراگراف قبلی، سبکی را که من معمولاً برای مدل سازی use case استفاده می کنم توصیف می کند، یعنی روش " ابتدا actorها". دیگران دوست دارند با معرفی یک actor و use caseهایی که با ابتدا با آن درگیر هستن شروع کنند و مدل را از آنجا تکمیل کنند. هر دو روش جواب می دهد. نکته مهم این است که افراد مختلف، از روش های مختلف استفاده می کنند، پس باید وقتی که از روش Model With Others تبعیت می کنید، انعطاف پذیر باشید.

فرصتهای استفاده مجدد

شکل چهار، سه نوع ربطه (extendها، includeها، و inheritance) بین use caseها را نشان می دهد. من دوست دارم روابط extend را معادل یک "hardware interrupt" در نطر بگیرم زیرا شما نمی دانید کی یا آیا extending use case، فراخوانده خواهد شد؛ و روابط Include را معادا یک "فرآیند فراخوانی" در نظر بگیرم؛ Inheritance، به همان روش UML class diagrams اعمال می شود. این مقاله، Reuse in Use Case Models، این سه رابطه را با جزییات بیشتر توضیح می د هد.

شکل 4: استفاده مجد د از use case.

Agile باقیمانده

چگونه می توان use case modeling agile را نگه داشت؟ ابتدا، سعی کنید تا آنجا که ممکن است آنرا ساده نگه دارید. از ابزارهای ساده و انعطاف پذیر برای مدل سازی با آن استفاده کنید. من معمولاً دیاگرامهای use case را روی یک وایت برد ایجاد می کنم، همانطور که در شکل 5 می بینید. شکل 5، مثالی از یک دیاگرام ابتدایی است که من با stakeholderهای پروژه ام رسم کرده ام. AM به ما می گوید که محتوا مهم تر از ظاهر (representation) است، پس رسم کردن دیاگرام با دست، مسئله بزرگی نیست. در ضمن، مهم نیست که دیاگرام کامل نیست، زیرا یک دانشگاه دارای بخشهای بیشتری است که در اینجا نشان داده شده، و همیشه می توان در صورت نیاز، دیاگرام را تغییر داد.

شکل 5: طرح وایت برد

همزمان با ایجاد طرح، من شرح مختصری از هر use case روی یک وایت برد نیز می نویسم. هدف من ثبت اطلاعات کافی در مورد use case است،؛ به طوری که کلاً متوجه شویم درباره چیست. اگر به جزییات بیشتری نیاز داشته باشیم، همیشه می توانیم بعداً آنها را اضافه کنیم، چه به صورت یک essential/business use case یا یک system use case.