یوزکیس ها Use Cases در uml یو ام ال
وقتی شما اولین گروه اکتورهای سیستم را لیست کردید حالا میتوانید مشخص کنید که آن Actor ها قراره با چه چیزی در تعامل باشند و اسمبل assemble کردن مدل سیستم رو اینطوری شروع کنید. مرحله بعدی مشخص کردن کیس ها و شرایطی cases هست که سیستم از اونها قراره با هم استفاده کنه تا کاری رو به انجام برسونند. در واقع use case ها از نیازمندی های نرم افزار استخراج میشوند. اینجا دقیقا جایی است که این نیازمندی های که در سند اولیه توسط کارفرما بصورت مبهم ارائه شده بود، الان باید بصورت تقسیم بندی شده در قالب یوزکیس use case ها مشخص و شفاف بشوند.
دقت کنید، در uml وقتی میگیم usecase ها نیازمندی های نرم افزار هستند پس باید حالت موفقیت و شکست pass/fail criteria مشخصی داشته باشند. یعنی باید دقیقا قابل تشخیص باشه که این یوزکیس حالت موفقش چیه و حالت شکستش چیه و این حالت های موفقیت و شکست باید برای همه ذینفعان پروژه، کارفرما، برنامه نویسا، تستر ها و همه مشخص و واضح باشه که براساس اون بشه در نهایت گفت این یوزکیس درست کار میکنه یا خیر؟
در مدل یو ام الی ما یه یوز کیس یا اسم دیگه ش job میتونه یه کار خیلی ساده مثل لاگین کردن باشه تا یه کار خیلی پیچیده مثل بارگزاری اطلاعات روی چند تا دیتابیس باشه. نکته مهم اینجاست که هر یوزکیسی از نظر کاربر بیرونی به منزله انجام یک کار job و اتمام اون کار باید باشه، مثلا تعریف یک متغیر یک یوزکیس نیست ولی لاگین کردن داخل سیستم چون از نظر کاربر بیرونی و اون آدم واقعی یک کار مشخص هست یک usecase محسوب میشه و خروجی هر use case یک چیز مشخصی باید باشد. مثلا توی مثال سیستم مدیریت محتوا، ایجاد یک اکانت برای یک بلاگر یک یوزکیس میتونه باشه. در uml یوزکیس ها بصورت یک بیضی Oval ترسیم میشن.شاید وقتی دونستین یوزکیس چقدر مهمه به این فکر کنید که این همه اهمیت فقط یک بیضی؟ درسته این بیضی خیلی وقتها به اشتباه میندازه که ازش غافل بشن ولی یادتون باشه usecase به تنهایی مهمترین عنصر و پایه مدلسازی در uml هست که این یوزکیس ها در نهایت در uml مشخص میکنند که این سیستم نرم افزار نهایی قراره چی باشه.
تعریف یوزکیس use case: اگه بخوام یه تعریف از یوزکیس داشته باشم میتونم بگم usecase یک چیزی است که یک نتیجه قابل اندازه گیری برای یوزر بیرونی سیستم actor میتونه ایجاد کنه. هر بخشی از رفتار سیستم که این تست و شرایطی که گفتیم رو داشته باشه میتونه کاندیدای خوبی به عنون use case شدن در مدل uml داشته باشه.
خطوط ارتباطی Communicatio Line در uml
خوب تا اینجای کار ما فهمیدیم اکتور چیه و use case چی هست. ولی چطوری میتونیم نشون بدیم که مثلا اکتوری مثل administrator میتونه تو یوزکیسی به اسم "ایجاد یک بلاگ" حضور داشته باشه و با اون usecase در تعامل باشه؟ پاسخ این سوال با حطور ارتباطی communication line در مدلسازی یو ام ال داده میشه.
خطوط ارتباطی communication line ها یک اکتور actor را به یک یوزکیس use case وصل میکنند، تا نشون بدند این اکتور در این یوزکیس شرکت participate داره.
در مثال ساده بالا یک اکتور به یک یوزکیس وصل شده است و نشان میدهد که ادمینیستریتور در یوزکیس ایجاد بلاگ مشارکت دارد.این امکان طبیعتا وجود دارد که چندین اکتور در یک یوزکیس شرکت کنند.از لحاظ تئوری محدودیتی برای تعداد این اکتورها وجود ندارد.
برای اینکه نشون بدیم چندین اکتور در یک use case در uml مشارکت دارند کافیست از هرکدام یک خط ارتباطی به یوزکیس بکشیم.
بعضی جاها میبینیم بجای یک خط مستقیم خطی از اکتور به یوزکیس وصل میکنند که سرش یه فلش داره و یه arrow هست. این فلش نشون دهنده مسیر جریان و حرکت داده ها data flow و یا میتونه نشون بده کی یوزکیسو شروع میکنه، ولی در کل این روش استاندارد و درستی برای خطوط ارتباطی نیست و بهتره خطوط ارتباطی طبق همین شکلی که هست ترسیم بشوند، بدون فلش و چیز دیگه ای. هدف این خطوط ارتباطی communication line ها اینه که نشون بده یک اکتور در یک یوزکیس حضور داره یا مشارکت داره، نه اینکه بگه دیتاها چجوری حرکت میکنند بین اینها یا اینکه کدوم اکتوری یوزکیس را شروع میکنه و ... اگر میخوایم اطلاعات بیشتری از این ارتباط بدیم میتونیم از توضیحات و نوت و description استفاده کنیم و استفاده از Navigate در خط ارتباطی اشتباه است.
مرز سیستم System Boundaries
درسته که مرزبندی مشخصی بین اکتور actor ها (عناصر بیرونی سیستم external to system) و یوزکیس usecase ها (عناصر درونی سیستم internal to system) وجود داره و مرز اینها یعنی internal ها و external ها از هم جداست، ولی uml عنصری را برای این تفکیک مشخص کرده است که باعث میشود مدل یو ام الی شما به شدت مشخص و واضح باشد. برای اینکار یک باکس یا مربع اطراف همه یوزکیس هایتان بکشید و مطمئن شوید اکتورها بیرون از اون باکس های مربعی قرار میگیرند. و بهتر هم هست این باکس ها رو نامگذاری کنید که مشخص باشه اسم سیستم شما چی هست، مثلا content management system مثال اینجا بود.
توضیحات یوز کیس ها Usecase Description در UML
خوب دیاگرامی که تا اینجا ارتباط بین اکتورها و یوزکیس ها رو به شما نشون داد، میتونه نقطه شروع خوبی برای مدلسازی در uml باشه ولی کافی نیست. با این دیاگرام، طراحان سیستم شما اطلاعات کافی از اینکه چجوری قراره این یوزکیس ها نیازهای نرم افزار رو براورده کنه، ندارند. از کجا بفهمند مثلا شروع کننده یوزکیس کدوم actor هست یا اینکه مهمترین اکتور هر usecase کیه؟ بهترین راه برای بیان این موضوعات استفاده از توضیحات یوز کیس use case description ها است که شما برای هر یوزکیس یک توضیح یا Description قرار میدین. قوانین مشخص و سفت و سختی برای این دیسکریپشن ها وجود نداره ولی معمولا موضوعات زیر را میتوانید در use case description بنویسید:
- نیازمندی های مربوطه به یوزکیس Reated Requirement: یعنی بنویسیم که این یوزکیس کدام یک از نیازمندی های سیستم رو قراره رفع بکنه؟
- هدف در سیستم Goal in Context: این یوز کیس کجای سیستم قرار داره و قراره چه هدفی داشته باشه؟
- پیش شرط ها Preconditions: این یوزکیس برای انجام شدنش چه نیازمندی هایی هست و مثلا کدوم یوزکیس ها قبلش باید انجام بشن؟
- شرط موفقیت پایانی Successfull End Condition: وقتی این یوزکیس انجام بشه وضعیت بعدی سیستم چه خواهد شد؟
- شرط شکست پایانی Failed End Condition: وقتی یوزکیس نتونه انجام بشه، وضعیت بعدی سیستم چه خواهد بود؟
- اکتور اولیه Primary Actors: اینکه اولین اکتوری که با این یوزکیس در ارتباط خواهد بود و در این usecase شرکت خواهد کرد کدومه؟
- اکتورهای ثانویه Secondary Actors: اکتورهایی که در این یوزکیس مشارکت دارند ولی اولی نیستند کدومان؟
- تریگر Trigger: اون اکتور اولیه قراره چیکار کنه در قدم اول که یوزکیس شروع بشه؟
- فلوی اصلی Main Flow: مراحلی که یوزکیس در حالت نرمالش طی میکنه چیاست؟ Step های رفتار یوزکیس؟
- اکستنشنها Extensions: یعنی مراحلی که هر کدوم از مراحل فلوی اصلی لازمه کامل کنند چیاست؟مثلا اگر در main flow ما بگیم استپ های 1 تا 10 داریم در اینجا میگیم استپ 1-1و 1-2 , ... چیاست؟
یادمون باشه use case description یک موضوع دلخواه و یک توضیح اضافی نیست و باید حتما در مدل ما وجود داشته باشه، بدون توضیحات یوزکیس در uml این یوزکیس ها خیلی چیزای مفیدی نخواهند بود.
یک نکته مهمی در نوشتن این توضیحات هست: هرچقدر شما جزییات بیشتری در مدلسازی uml بنویسید، باعث میشه بعدا بیشتر برگردید و این توضیحاتو اصلاح کنید. این اساس برنامه نویسی تکرار پذیر iterative development هست و از این جهت که شما با بازگشت بیشتر به refinement بیشتری میرسید کمک میکنه.
اینکه در مدلسازی UML تعداد یوزکیس های شما چقدر باید باشه، قانون خاصی نداره. در واقع تعداد یوزکیس ها در یو ام الی بستگی به تعداد JOB هایی داره که سیستم شما قراره پاسخ بده و به نیازمندی های نرم افزار بستگی داره. این یعنی برای یک سیستم شما ممکنه 2 تا یوزکیس داشته باشید ولی واسه سه سیستم دیگه ممکنه صدها یوزکیس در مدل uml ای لازم باشه. خیلی نگران تعداد یوزکیس ها و استاندارد بودنش نباشید، مهم اینکه یوزکیس های صحیحی داشته باشید. برای این انتخاب و صحیح بودن یوزکیس ها باید تجربه کنید و به مرور زمان و پروژه های مختلف دستتون میاد که کدوم یوزکیس میتونه صحیح باشه.
ارتباطات یوزکیس ها Use Case Relationships
یوزکیس ها بیان میکنند سیستم و مدل شما در uml چگونه نیازمندی های پروژه را رفع خواهد کرد. وقتی شما دارید usecase description را مینویسید متوجه میشوید که مراحل شبیه به همی در تعداد بوزکیس وجود دارد و در موقع نوشتن description این مراحل بین یوزکیس های مختلف تکرار میشن.همچنین متوجه میشید که بعضی یوزکیس ها در چند جا استفاده میشن تا نیازمندی های نرم افزار رو هندل کنند، با اینکه یک یوزکیس یه جای دیگه سیستم با یه اکتور دیگه در ارتباطه و در نهایت شما متوجه میشید که یک یوزکیس در چندین flow باید وجود داشته باشه تا نیازمندی های نرم افزار محقق بشه. خوب بهتر نیست راهی باشه که از این تکرار توضیحات یوزکیس ها Use Case Description Repetition ها خلاص بشیم؟ پاسخ بله البته هست. شما میتونید رفتار های قابل استفاده مجدد Reusable، اختیاری Opetional و حتی ویژه Specialized در یوزکیس ها داشته باشید.
ارتباط اینکلود Include Relationship
تا اینجا دیدین که یوزکیس ها با اکتورهای Actors کار میکنند تا نیازمندی های را در uml مدل سازی کنند. ارتباط یوزکیس ها در مورد افزودن چیزی جدید به سیستم نیست، بلکه مربوط به شکستن سیستم به اجزای کوچکتر است. هدف از Use Case Relationship اینه که سیستم را به اجزای کوچکتر بشکنید تا طراحان و برنامه نویسان سیستم هم متوجه بشن که چطوری باید سیستم رو به اجزای کوچکتر بخش بندی کنند تا مدیریت نرم افزار راحت تر باشه و پشتیبانی و توسعه نرم افزار نیز بهتر باشه.
هر نیازمندی جدیدی در سیستم در واقع یک use case جدید محسوب میشه،البته همیشه نمیشه گفت این ارتباط یک به یک هست ولی در کل میتونه اینطوری باشه. فرض کنید در سیستم دو تا یوزکیس داریم که هر دو یوزکیس در توضیحاتشون میگن که باید لاگین بودن کاربر چک بشه، مثلا یک یوزکیس برای درج پست جدید و یک یوزکیس دیگه برای ویرایش اطلاعات پروفایل، طبیعتا هر دوی این یوزکیس ها نیاز دارند اول لاگین بودن کاربر چک بشه و در واقع credential کاربر رو بررسی کنند. در این مواقع بهتره که یه یوزکیس جدیدی داشته باشیم که اینکارو انجام میده و این یوزکیس جدید توسط دو تا یوزکیس قبلی استفاده بشه.
همانطورکه در شکل بالا میبینید، دو تا یوزکیس دارند از یک یوزکیس استفاده میکنند و خود اون یوزکیس include شده هم با یک اکتور در ارتباط است و طبیعتا همه use case description این یوزکیس اینکلود شده در اون دو تای دیگه هم معنا پیدا میکنه. همچنین در شکل بالا میبینید اکتوری که این یوزکیس ازش استفاده میکنه یک شخص و person نیست و یک دیتابیس بیرونی هست.
Special Cases اسپشیال کیس ها:
بعضی وقتها وقتی شما دارید یه یوزکیس را تعریف میکنید متوجه میشید که این یوزکیس خیلی شبیه یکی یا چند تا یوزکیس دیگه ست، ولی باهاشون تفاوت های خیلی ریزی داره. برعکس unclude ها که یک یوزکیس دقیقا در دل یک usecase دیگه باید استفاده بشه اینجا اینطوری نیست و یک یوزکیس شبیه یه یوزکیس دیگه هست لی با تفاوت های خیلی کم. از این مدل یوزکیس ها در طراحی شی گرا،زیاد پیش میاد.یعنی خیلی case ها و حالت های خاص و specialized از یک یوزکیس general را خواهیم دید. مثلا وقتی شما قراره یک بتونید در سیستم چندین نوع اکانت ایجاد کنید، این فرآیند ایجاد اکانت کلی هست و فقط برای انواع مختلف اکانت ممکنه یه تفاوت های خیلی ریزی داشته باشند.
دقیقا مانند قسمت پاینی از شکل بالا که دو مدل create new blog از حالت کلی ایجاد reate new blog دارند specific میشن و ما به این ارتباط بین یوزکیس ها special case میگیم.در واقع این طراحی داره در مورد use case Inhertance و ارث بری یوزکیس ها و ارث بری نیازمندی ها و Case ها و حالت ها عمل میکنه. ارث بری یکی از مهمترین ویژگی های طراحی Object Oriented Design است. در واقع در Use case Inheritance ما میگیم یوزکیس های ارث بری شده، دقیقا همه مراحل use case والد را دارند ولی یه سری مراحلی را اضافه تر خواهند داشت. یعنی اون قابلیت های عمومی رو در یوزکیس والد تعریف میکنیم و child ها باید ارث بری کنند و هر کدوم یه چیزهایی اضافه کنند به خودشون. اینجا به یوزکیس والد General Use case و به یوزکیس های فرزند Specialized Use case گفته میشه. همچنین دقت کنید که همه ارتباطاتی که یوزکیس General با actor ها در Uml داره،منطقا این ارتباطات به یوزکیس specialized هم میرسه. یعنی هم خود usecase والد و ارتباطاتش و هم توضیحات اون یوزکیس همه در یوزکیس های specialized وجود خواهند داشت و به ارث برده میشن. یعنی هر چیزی که در genaral داریم به ارث میره و عینا در فرزندها وجود دارد.به این فرآیند Generalization گفته میشه.
ارتباط اسکتند Extend بین یوزکیس ها در Uml
پیچیده ترین و سخت ترین مفهوم ارتباط یوزکیس ها همین نوع ارتباط extend هست که خیلی هم میتونه باعث اشتباه بشه. این کلمه extend در برنامه نویسی java و c# دقیقا مثل همون ارث بری میمونه که شما یک کلاس پایه base class تعریف میکنید و میگین که یه کلاس دیگه از این کلاس ارث بری باید بکنه. این کلاس فرزند رو بهش کلاس extend شده میگیم. پس در واقع شما هرجا در مدلسازی با uml از ارتباط extend استفاده کنید برای برنامه نویس به این معنی هست که اینجا باید Inheritance اتفاق بیفته.درسته؟ خوب اینجا یه موضوعی هست. شما در بخش قبلی دیدین که با انجام Generalization ما داشتیم Inheritance رو پیاده سازی میکردیم. پس الان چی شد؟اون ارث بری هست یا این؟ خوب باید بگم که این دو تا ارتباط یه کمی با هم فرق دارند. تفاوت اینجاست که در حالت ارث بری قبلی دقیقا هر چیزی که کلاس پایه داشت در کلاس فرزند اتفاق میفتاد ولی اینجا این که کلاس فرزند چیارو به ارث ببره یا نبره کاملا اختیاری و Optional هست.
همانطور که در شکل بالا میبینید یوزکیس Record Application Failure اسکتند شده از اون دو تا یوزکیس و این نشون میده که این یوزکیس ممکنه در هر کدام از حالت های اون دو تا گاها پیس بیاد. مثلا فرض کنید موقع ایجاد یک پست جدید سیستم failure داشته باشیم و این system failure ممکنه توی ایجاد پست جدید پیش بیاد یا ممکنه موقع ایجاد کاربر جدید پیش بیاد، یعنی همیشه پیش نمیاد،ممکنه پیش بیاد. بطور ساده میتونم بگم generalization یعنی ارث بری، ارتباط اکستند یعنی حالت خاص و اینکلود هم نیازمندی مشترک را میتوان در نظر گرفت.
خوب تا اینجا شما تونستید Usecase Overview Diagram رو فهمیدید و باید در چند مرحله نیازمندی های سیستم رو به یوزکیس تبدیل کنید:
- تعریف نیازمندی های نرم افزار به عنوان یوزکیس
- تعریف اکتورهایی که با این نیازمندی های باید کار کنند مانند ادمین یا کاربر یا مشتری یا سیستم های بیرونی و غیر person ها
- تعریف stereotype های ارتباط بین یوزکیس ها با 3 حالت اینکلود، special case و genaralization و ارتباط Extend که ترکیب اینها میشه دیاگرام یوزکیس نرم افزار.
تفاوت کلیدی include و extend در ارتباطات بین یوزکیس ها
Include و extend جزو stereotypeها هستند و فرقشون با مثال توضیح میدم:
فرض کنید یوزکیس A به تنهایی معنا داره و میتونه به تنهایی کار کنه و یک یوزکیس مجزا هست، و وقتی برای انجام یک کاری در یک یوزکیس دیگه به اسم یوزکیس B لازم باشه حتما این یوزکیس A فراخوانی باشه و انجام بشه تا یوزکیس B بتونه انجام شده تلقی بشه، اینجا باید از Include استفاده کرد و میگیم A اینکلود میشه برای B و در دیاگرام UML ای یک خطی با برچسب include از B به A میکشیم. استفاده از اینلکود زمانیه که ما در نمودارمون و سیستم نرم افزاری یوزکیس ها رو به یوزکیس های کوچکتر و قابل استفاده در یکدیگر تکه میکنیم ولی همه این یوزکیس ها به تنهایی مفهوم دارند و یک نیازمندی از سیستم هستند.
در مورد اکستند، یوزکیس A به تنهایی به درد نمیخوره و اصلا نیازی نیست که در سیستم باشه ولی برای انجام کاری در یوزکیس B باید این یوزکیس A انجام بشه،یعنی یوزکیس A یکسری مراحل هست که باید در یوزکیس B باشد و انجام بشه ولی چون ممکنه تو یوزکیس های غیر B هم به درد بخوره، اومدیم یه یوزکیس جدا کردیمش و البته اختیاری هست و ضروری نیست که حتما همچین A ای تعریف بشه. دقت کنید یوزکیس هایی که جزو extend هستند، به تنهایی مفهومی ندارند. از لحاظ نموداری برای نمایش ارتباط extend بین دو تا یوزکیسمون یک فلش خطچین با لیبل extend از اون یوزکیس اختیاری A به یوزکیس B میکشیم.
در واقع یادمون باشه اکستند یوزکیسی هست که به تنهایی تو سیستم ما معنا نداره، مثل Deelete Verification ولی اینکلود یوزکیسی هست که به تنهایی معنا داره مثل login کاربر و تفاوت بعدی اینکه بدون اتفاق افتادن یوزکیس include شده یوزکیس اول نمیتونه انجام بشه، مثلا بدون لاگین کاربر نمیتونه پروفایلشو ببینه ولی یوزکیس extend یه چیز اختیاریه و اجباری نیست و یوزکیس مبدا بدون این هم کارش میتونه انجام شه، مثلا رکورد میتونه حذف بشه و حتما برای حذف رکورد نیازی نیست وریفیکیشن اتفاق بیفته
ارتباطات بین یوزکیس ها از نوع Precedes
ارتباط از نوع precedes در واقع حالت کلی دو تا ارتباط include و extend هستش. یعنی حالت های اینکلود و اسکتند یه زیرمجموعه ای از همین preced هستند و بطور کلی معنیش هم اینه که قبل اینکه یوزکیس B انجام بشه و تموم بشه، یوزکیس A حتما باید انجام شده باشه
ارتباط یوزکیس ها از نوع Invokes
ارتباط نوع اینوک در یوزکیس ها به این معنی هست که هر موقع یوزکیس A انجام میشه، حتما یوزکیس B هم ناخوداگاه اتفاق میفته