یک UML Use Case Diagram (UCD) چیست، و کی باید از آن استفاده کرد؟
دیاگرام های UML Use Case را می توان جهت توصیف عملکرد یک سیستم به صورت افقی استفاده کرد. این بدین معناست که غیر از صرفاً نمایش ویژگیهای ویژه سیستم شما، می توان از UCDها جهت نشان دادن همه عملکردهایی که در دسترس است، استفاده کرد. تذکر این نکته مهم است که UCDها اساساً با sequence diagramها یا flow chartها فرق دارند، زیرا آنها تلاشی برای نشان دادن ترتیب یا تعداد دفعاتی که systems actionها و sub-actionها باید اجرا شوند، نمی کنند. تعدادی مثال گرافیکی در این مقاله وجود دارد؛ شاید بخواهید نگاهی به آنها بیاندازید تا با ظاهرشان آشنا شوید.
UCDها دارای فقط 4 عنصر اصلی هستند: actorها، که سیستمی که شما توصیف می کنید، با آن ارتباط متقابل دارد، خود سیستم، use caseها، یا سرویسها، که سیستم می داند چگونه اجرا کند، و خطوطی که نشانگر رابطه بین این عناصر هستند.
شما باید از UCD برای نمایش عملکردهای سیستم تان به صورت top-down استفاده کنید (یعنی از نگاهی که عملکرد سیستم واضح است، اما توصیفها در سطح بالایی هستند. جزییات بیشتر را می توان به دیاگرام ، جهت توضیح دادن نکات جالب در رفتار سیستم، اضافه کرد).
مثال: یک UCD، به خوبی با task توصیف همه چیزهایی که می توان با یک database، توسط تمامی افرادی که می توانند انرا ببینند، انجام داد، سازگار شود.
شما نباید از UCDها برای نمایش رفتارهای استثناء (هنگام روی دادن error) استفاده کنید، یا تلاش کنید ترتیب مراحلی را که باید به منظور تکمیل یک task اجرا شوند، نشان دهید. برای این کار از دیاگرام Sequence استفاده کنید.
مثال: یک UCD، به طور بد وضعیفی با توصیف پروتکل شبکه ای TCP/IP سازگار می شود، زیرا موارد استثناء (exception cases)، رفتارهای شاخه ای (branching behaviors)، و عملکردهای شرطی (conditional functionality) زیادی وجود دارد.
چگونه بفهمیم actorهای یک UCD چه کسانی هستند؟
وقتی با یک جدول Action/Response کار می کنید، شناسایی actor آسان است: موجودیت هایی که رفتارشان در ستون "Actor's Actions" ظاهر می شود، actor هستند؛ و موجودیت هایی که رفتارشان در ستون "System's Response" ظاهر می شود، componentهای سیستم هستند.
اگر در حال کار کردن با نسخه ای قدیمی، یک دیاگرام sequence، یا توصیف یک سناریو هستید، actorها معمولاً موجودیت هایی هستند که نمی توان رفتارشان را کنترل کرد یا تغییر داد (مثلاً agentهایی که قسمتی از سیستمی نیستند که شما می سازید یا توصیف می کنید). بارزترین کاندیدها برای actorها، نقشهای سیستم هستند، مگر در موارد نادری که سیستمی که شما توصیف می کنید، واقعاً یک فرآیند انسانی است (از قبیل متد معینی برای رابطه با مشتری هایی که باید توسط کارمندان پیگیری شوند). نقشهایی که باید با ان ارتباط متقابل برقرار کرد،همگی actor هستند. اگر سیستم شما با سیستمهای دیگر (ازقبیل databaseها، و سرورهایی که توسط افراد دیگر یا legacy system نگه داری می شوند) ارتباط متقابل دارد، بهتر است با آنها مثل actorها برخورد کنید.
مثال: هنگام افزودن یک database جدید به سیستم، جهت مدیریت امور مالی شرکت، احتمالاً سیستم شما مجبور به ایجاد رابطه با نرم افزار موجود برای مدیریت انبار خواهد بود. از آنجاییکه شما آن نرم افزار را ننوشته اید، آن را جایگزین نکنید، و ففط از سرویسهایی که در اختیارتان می گذارد استفاده کنید، actor بودن برای آن سیستم، معنادار خواهد بود.
از کجا بفهمیم در "System" box چه چیزی بگذاریم؟
system box فقط در دیاگرام های سطح بالا ظاهر می شود (به یاد داشته باشید که توصیف یک UML Use Case معمولی، از دیاگرام ها و زیردیاگرام های زیادی تشکیل خواهد شد)، و باید نمادهای Use case را دربربگیرد، یکی برای هر سرویس سطح بالایی که سیستم شما برای actorهایش فراهم می کند. هر نوع رفتار داخلی، که سیستم شما ممکن است داشته باشد و فقط توسط بخشهای دیگر سیستم استفاده می شوند، نباید در system box ظاهر شود. یک راه مفید برای استفاده از این سرویسهای سطح بالا، به ترتیب زیر است:
اگر یک use case، یک سرویس سطح بالا را ارایه می کند، آن سرویس باید برای actorهایی که با آن در ارتباط متقابل هستند تا فقط آن سرویس را در یک session از سیستم شما تقاضا کنند، معنی دار باشد.
مثال: در دیاگرام زیر، قصد داریم use case را برای یک دوربین نمایش دهیم. فرض کنید ما "Open Shutter"، "Flash"، و "Close Shutter" را به عنوان use caseهای سطح بالا انتخاب می کنیم. مسلماً، تمامی اینها رفتارهایی هستند که یک دوربین دارد، اما هیچ عکاسی دوربینش را برنمی دارد، سپس shutter را باز کند، و آن را پایین بگذارد، وآن روز از عکس برداریش راضی باشد. چیز مهمی که باید بفهمیم این است که این رفتارها به تنهایی انجام نمی شوند، اما نسبتاً بخشی از یک use case سطح بالاتر، یعنی "take picture" است. (به یاد داشته باشید که یک بار عکس گرفتن با دوربین برای عکاسان بی معنی است.)
actorها در دیاگرام من ارتباط های متقابل دارند. چگونه انها را نشان دهم؟
اگر ارتباط های متقابلی بین actorها در سیستم تان وجود داشته باشد، شما نمی توانید آنها را روی همان دیاگرام سیستم تان نمایش دهید. کاری که در عوض می توانید بکنید، ترسیم یک UCD مجزا است، که با یکی از actorها به تنهایی مانند یک سیستم رفتار می کند، وبا سیستم دیجیتال تان مانند actorهایی در این دیاگرام جدید.
مثال: فرض کنید می خواهید ارتباط های متقابل بین یک کاربر، مرورگر وب، و سروری را که با آن در تماس است، را به صورت دیاگرام نشان دهید. از آنجاییکه می توانید فقط یک سیستم روی دیاگرام داشته باشید، باید یکی از سیستمهای بارز، از قبیل سرور را انتخاب کنید. سپس شاید وسوسه شوید خطوط ارتباط متقابلی بین actorها رسم کنید، اما این یک مشکل است، زیرا مشخص نیست منظور از ارتباط متقابل چیست.، پس نشان دادن آن در اینجا فایده ای ندارد. یک راه حل مفید تر، ترسیم در دیاگرام است، که همه ارتباط های متقابل را، مانند شکل زیر، نشان دهد:
می خواهم ترتیبی از اعمالی را که سیستم اجرا می کند، نشان دهم. چگونه این کار را بکنم؟
با استفاد ه از یک UML Use Case Diagram نمی توانید این کار را انجام دهید. UCDها باید توصیفی از بالا به پایین (top-down) و افقی از عملکرد باشد، نه توصیفی جزء به جزء از رفتار. در بیشتر اوقات، تلاش برای نمایش ترتیبی از اعمال با دیاگرام های use case، ایده خوبی نیست. در عوض شما باید از دیاگرام sequence یا یک flow chart سنتی استفاده کنید. (همانطور که در زیر توضیح داده شده، نمایش شرایط شاخه ای ساده (simple branching conditions) با یک UCD، امکان پذیر است، اما از این تکنیک باید کمتر استفاده کنید زیرا ممکن است یک دیاگرام را غیر فابل خواندن بکند).
تفاوت یک UML Use Case Diagram با flow chart سنتی چیست؟
همانطور که در بالا اشاره شد، UCDها، عملکرد را به صورت از بالا به پایین نمایش می دهند، در حالیکه flow chartها، رفتار را به صورت خطی و زمان محور نشان می دهند. همچنین، روش develop کردن آنها نیز متفاوت است.
مثال: (این متن مربوط به دیاگرام زیر است). هنگام ساختن یک UCD، مرحله اول، شناخت تمامی رفتارهای سطح بالا است. وقتب این کار را انجام دادید، از قبل باید ، همه کارهایی را که سیستم شما می داند چگونه انجام دهد، حداقل به روشی سطح بالا، توصیف کرده باشید. سپس با تجزیه کردن use caseتان به use caseهای بیشترکه توسط use case سطح بالا استفاده می شوند، می توانید به اضافه کردن جزییات ادامه دهید. در هر مرحله از از نصب، UCD شما، شرح کاملی از عملکرد سیستم است: شاید فاقد جزییات باشد، اما فاقد عناصر feature set نخواهد بود. و اگر عملکرد یا رفتار در طول حیات پروژه تان اضافه یا حذف شود، محدوده تغییراتی که باید اعمال کنید، وابسته به محدوده تغییرات در خود سسیستم، و کامل بودن مدلتان است. این، مفید است؛ زیرا بدین معناست که وقتی مدلتان خیلی ناقص است، ایجاد تغییدات گسترده در سیستم، مستلزم کنارگذاشتن کارهای دیگر نیست. اما یک flow chart، تا وقتی که ترسیم آن را تمام نکرده اید، به طور صحیح سیستم را توصیف نمی کند، حتی تغییرات کوچک در سیستم منجر به بازنویسی flow chartهای تان خواهد شد. عموماً، UCها، فرایند تحلیل و طراحی را خیلی بهتر از flow chartها ساپورت می کنند.
کی از uses arrow استفاده کنم؟
extends arrow یا (extends edge)، از یک use case X به یک use case Y کشیده می شوند تا نشان دهند که فرآیند X، یک رفتار موردی از همان نوع فرآیند عمومی تر Y است. شما در شرایطی از این استفاده می کنید که سیستم تان تعدادی فرآیند use case دارد که همگی دارای تعدادی subtaskهای مشترک هستند، اما هر کدام چیز متفاوتی دارد که دسته بندی همه آنها به یک use case را برای شما غیر ممکن می کند.
مثال: فرض کنید می خواهید جزییاتی را به دیاگرامی که در زیر نشان داده شده، بیافزایید که یک سیستم رزرو بلیط هواپیما را نشان می دهد. چیزی که شما می خواهید نشان دهید این است که همه صندلی های هواپیما دقیقاً شبیه هم نیستند (بعضی ها کنار پنجره و بعضی ها کنار راهرو هستند)، و بعضی اوقات مسافران یکی از این نوع صندلی ها را ترجیح می دهند، البته همیشه نمی توان این انتخاب آنان را سریعاً برآورده کرد، زیرا ممکن است صندلی ای که آنها می خواهند، در دسترس نباشد. بنابراین، فرآیند تخصیص دادن یک صندلی کنار پنجره، مستلزم چک کردن "دردسترس بودن" صندلی های کنار پنجره است، در حالیکه، فرآیند تخصیص دادن یک صندلی کنار راهرو، مستلزم چک کردن "دردسترس بودن" صندلی های کنار راهرو است. اما گرچه این فرآیندها متفاوت هستند، اما از جهاتی نیز شبیه هم هستند، پس نادیده گرفتن شباهت هایشان، بی معنی است. خوشبختانه، UML، اجازه داشتن هر دو را به ما می دهد: می نویسیم که تخصیص این دو نوع صندلی، فرآیندهای متفاوتی هستند، اما در both processes extend a common, more general process (تخصیص صندلی ها)، شبیه هم هستند.
فرق بین useها و extendها چیست؟
احتمالاً بهترین راه فکر کردن درمورد عناصر دیاگرام به ترتیب زیر است:
-"X uses Y" نشان می دهد که تسک "X"، دارای یک زیر تسک "Y" است، بدین معنی که در فرآیند تکمیل تسک "X"، تسک "Y" حداقل یکبار تکمیل می شود.
-"X extends Y" نشان می دهد که "X"، یک تسک از همان نوع "Y" است، اما "X"، یک مورد ویژه و معین تر برای انجام "Y" است. بدین معنی که، انجام دادن X بسیار شبیه انجام دادن Y است، اما X دارای فرآیندهای کمی اضافی تر است که فراتر از چیزهایی است که باید جهت تکمیل Y انجام داد.
مثال نشان می دهد که به منظور انجام موفقیت آمیز "Check-in"، شما باید "Weigh luggage" و "Assign a seat" رلا چندین بار انجام دهید. گرچه کلید این کار این است که همه UCDهایی که توسط یک use case استفاده می شود، باید قبل از اینکه آن use case تکمیل شود، انجام شوند. وقتی متوجه شوید که چندین نوع تخصیص صندلی وجود دارد، شاید وسوسه شوید یک دیاگرام با استفاده لبه های uses، مانند نمونه بالایی، ترسیم کنید، اما این کار بی معنی است. این دیاگرام می گوید که به منظور تخصیص دادن یک صندلی، شما باید هم یک صندلی کنار پنجره و هم یک صندلی کنار راهرو به مسافر تخصیص دهید. اما اصلاً نترسید، رابطه extends، به خوبی این موقعیت را منترل می کند. با استفاده از رابطه extends، (همانگونه که در دیاگرام زیر نشان داده شده)، می توان گفت که دو راه برای تخصیص یک صندلی وجود دارد: تخصیص یک صندلی کنار پنجره، و تخصیص یک یک صندلی کنار راهرو، اما در فرآیند تخصیص مسافر یا صندلی، فقط یکی باید تکمیل شود.
سناریویی که من می خواهم توصیف کنم، به چند حالت ممکن تقسیم می شود، یا چندین error دارد. چگونه می توانم آن را با Use Case Diagrams نشان دهم؟
نشان دادن عدم موفقیت و حالت های مختلف، اغلب با یک دیاگرام Sequence یا flow chart، بهتر انجام می شود، اما موارد grey-area وجود دارد که معلوم نیست آیا یک Use Case Diagram مناسب است یا خیر. یک قانون: اگر در نمایش اعمال branching در Use Case Diagram، مجبور به استفاده از نمادهای use case بیشتری شوید، و دیاگرام بدست آمده نامشخص یا گیج کننده باشد، از یک سبک diagramming دیگر استفاده کنید.
با توجه به گفته بالا، نشان دادن رفتار ساده branching با UCDها امکان پذیر است، گرچه دوباره تاکید می کنم که UCDها، FLOW CHART نیستند. این کار از طریق تشخیص اینکه آیا use case، یا فرآیندی که سعی می کنید نمایش دهید، می تواند دو حالت مختلف داشته باشد (مثلاً شکست یا موفقیت)، آنگاه بدین معنی خواهد بود که شما واقعاً در use case متفاوت دارید: یکی که در آن، فرآیند موفقیت آمیز است، و دیگری که در آن، فرآیند شکست می خورد. البته، این دو use case، در اینکه هر دو extensionهای Use case اصلی هستند، مرتبط هستند، در نتیجه، شما use case اصلی را با Branching که از آن extend شده، ترسیم می کنید.من این را تقریباً سواستفاده از معنی لبه extends می دانم، زیرا واقعاً د ر اینجا برای نمایش طبقه بندی use case استفاده نمی شود (که هدفش است). دوباره می گویم، از این تکنیک به ندرت استفاده کنید، زیر ا خیلی زود می تواند یک دیاگرام را غیرقابل خواندن بکند.
مثال: فرض کنید می خواهید use case یک CD Player نرمال را نمایش دهید. وقتی همه چیز خوب است، CD player، سینی را که CD روی آن قرار می گیرد را به داخل می کشد، آن را می خواند، و پخش CD را شروع می کند (use case رفتار، د رزیر نشان داده شده). متاسفانه، برخی کاربران، هنگامی که هیچ CD در سینی وجود ندارد، فرمان play به سیستم می دهند. بنابراین، فرمان انجام نمی شود، و سیستم مجبور است کار دیگری غیر از play کردن CD انجام دهد (مثلاً به کاربر بگوید یک CD قراردهد). برای نشان دادن این، ما دیاگرام نرمال را با چند use case اضافی تغییر می دهیم، که در آن وجود CD تایید می شود. رفتار play کردن CD، رفتار تایید اینکه وجود CD را extend می کند. مورد مخصوص دیگر تایید وجود CD، این است که این کار انجام می شود در حالی که CD وجود ندارد، پس به کاربر گفته می شود تا یک CD قرار دهد.
اشتراک