یوزکیس دیاگرام چیست؟ | راهنمای تصویری به زبان ساده

در این مطلب به این پرسش پاسخ داده شده که یوزکیس دیاگرام چیست و با یک راهنمای تصویری به زبان ساده، به چگونگی ترسیم یوزکیس دیاگرام پرداخته شده است. همچنین، علاوه بر پاسخگویی به پرسش یوزکیس دیاگرام چیست ، تاریخچه یوزکیس دیاگرام، مزایای آن، هدف از ترسیم یوزکیس دیاگرام، کاربرد آن و اصول طراحی یوزکیس دیاگرام مورد بررسی قرار گرفته و مثال‌های گوناگونی پیرامون آن ارائه شده است. اما پیش از پرداختن به موضوع اصلی این مطلب یعنی یوزکس دیاگرام و پاسخگویی به پرسش یوزکیس دیاگرام چیست ابتدا و برای درک بهتر موضوع، توضیحاتی پیرامون زبان مدل‌سازی یکپارچه (Unified Modeling Language)، انواع نمودارهای آن و جایگاه یوزکیس دیاگرام در میان این نمودارها ارائه شده است.

زبان مدل‌سازی یکپارچه چیست ؟

زبان مدل‌سازی یکپارچه که به انگلیسی به آن Unified Modeling Language یا به طور خلاصه UML گفته می‌شود، یک زبان مدل‌سازی استاندارد است که از یک مجموعه یکپارچه از نمودارها تشکیل شده است. این زبان با این هدف توسعه پیدا کرده است تا به توسعه‌دهندگان نرم‌افزار و توسعه‌دهندگان سیستم کمک کند که آرتفیکت‌های (Artifacts) یک سیستم نرم‌افزاری را مشخصه‌سازی، بصری‌سازی، ایجاد و مستند کنند. از زبان مدل‌سازی یکپارچه یا UML برای مدل‌سازی کسب و کار و سیستم‌های غیرنرم‌افزاری نیز استفاده می‌شود.

آرتفیکت چیست؟

برای کلمه انگلیسی آرتفیکت (Artifacts) در فارسی و در حوزه‌های گوناگون معادل‌های مختلفی استفاده شده است. از جمله این معادل‌ها می‌توان به عمومی‌ترین معنای آن یعنی «مصنوعات» به معنی چیزهای ساخته دست بشر اشاره کرد. در حوزه پردازش تصویر (Image Processing)، از کلمه درست‌نما به عنوان معادلی برای آرتیفکت و برای اشاره به خطاهایی استفاده می‌شود که در کار پردازش تصویر به وقوع می‌پیونند. از جمله این خطاها می‌توان به خطای تار شدگی تصویر به دلیل فشرده‌سازی آن اشاره کرد که طی آن به نظر می‌رسد تصویر درست است اما در حقیقت به دلیل خطا تار شده است.

در زبان مدل‌سازی یکپارچه از لغت آرتفیکت (Artifact) برای اشاره به تعیین مشخصات (مشخصه‌سازی | Specification) اطلاعات محسوسی استفاده می‌شود که برای فرایند توسعه نرم‌افزار یا استقرار و عملیاتی کردن یک سیستم، تولید و یا طی این فرایندها استفاده می‌شوند. به عنوان مثال‌هایی از آرتفیکت‌ها در زبان مدل‌سازی یکپارچه می‌توان به فایل‌های مدل، منابع فایل، اسکریپت‌ها، فایل‌های قابل اجرای دودویی، یک جدول در سیستم پایگاه داده و یا یک سند پردازش متن اشاره کرد.

آرتیفکت‌ها موجودیت‌های محسوسی هستند که روی گره‌ها یعنی دستگاه‌ها و محیط اجرا، استقرار پیدا می‌کنند. دیگر عناصر زبان مدل‌سازی یکپارچه، شامل کلاس‌ها و مولفه‌ها، ابتدا در آرتفیکت‌ها تجلی پیدا می‌کنند و سپس، نمونه‌هایی از این آرتفیکت‌ها مستقر می‌شوند. آرتیفکت‌ها ممکن است ترکیبی از دیگر آرتیفکت‌ها نیز باشند. بر اساس این توضیحات شاید بتوان گفت که «دست‌ساخته» معادل مناسبی برای کلمه آرتیفکت در زبان مدل‌سازی یکپارچه است اما برای پیشگیری از هرگونه ابهام، در سرتاسر این مطلب هر جا که نیاز به اشاره به مفهوم Artifact است، عینا از کلمه آرتیفکت استفاده شده است. در تصویر زیر می‌توان اجزای یک نرم‌افزار را مشاهده کرد که در یک آرتیفکت تجلی پیدا کرده‌اند.

انواع نمودارهای زبان مدل‌سازی یکپارچه

زبان مدل‌سازی یکپارچه (UML) نمودارهای زیادی دارد که همه آن‌ها در دو دسته کلی نمودارهای ساختاری (Structural Diagrams) و نمودارهای رفتاری (Behavioral Diagrams) قرار می‌گیرند. نمودارهایی که اطلاعات ساختاری پیرامون سیستم را ارائه می‌دهند نمودارهای ساختاری نامیده می‌شوند و دسته دیگری از نمودارها که اطلاعات عمومی‌تری و کلی‌تر را ارائه می‌کنند نمودارهای رفتاری نام دارند.

نمودارهای رفتاری، خود شامل یک دسته خاص از نمودارهایی می‌شوند که جنبه‌های مختلف برهم‌کنش‌ها (Interactions) را به تصویر می‌کشند. سلسله مراتب نمودارهای UML در ادمه بیان شده و در تصویر شماره ۲ قابل مشاهده است.

• نمودارهای ساختاری
  • نمودار استقرار (Deployment Diagram)
  • نمودار ساختار مرکب (Compatible Structure Diagram)
  • نمودار شی (Object Diagram)
  • نمودار کلاس (Class Diagram)
  • نمودار نمایه (Profile Diagram | نمودار رخ‌نما)
  • نمودار مولفه (Component Diagram)
  • نمودار بسته (Package Diagram)
• نمودارهای رفتاری
  • نمودار مورد کاربرد (Use Case Diagram)
  • نمودار فعالیت (Activity Diagram)
  • نمودار حالت (State Machine Diagram | State Diagram)
  • نمودار برهم‌کنش (Interaction Diagram)
    • نمودار ارتباطات (Communication Diagram)
    • نمودار توالی (Sequence Diagram)
    • نمودار زمان‌بندی (Timing Diagram)
    • نمودار کلی برهم‌کنش (Interaction Overview Diagram)

نکاتی که باید پیرامون نمودارهای زبان مدل‌سازی یکپارچه و به طور خاص یوزکیس دیاگرام به آن‌ها توجه داشت در ادامه بیان شده‌اند.

• نمودارهای زبان مدل‌سازی یکپارچه گوناگونی وجود دارند که اهداف مختلفی برای ترسیم آن‌ها وجود دارد. این انواع در نمودار درختی بالا قابل مشاهده است. کاربر می‌تواند جزئیات یک پروژه را در انواع گوناگونی از نمودارهای UML، بسته به نوع آن پروژه، توصیف و آن‌ها را به دیگر انواع نمودارهای UML از جمله یوزکیس دیاگرام مرتبط کند.
• یوزکیس دیاگرام فقط نیازمندی‌های کارکردی سیستم را نشان می‌دهد. دیگر نیازمندی‌های سیستم مانند قوانین کسب و کار، کیفیت نیازمندی‌های سرویس و پیاده‌سازی محدودیت‌ها باید به طور جداگانه با دیگر انواع نمودارهای UML مختص آن جنس از مشخصه‌ها ارائه شوند.

در ادامه این بخش از مطلب یوزکیس دیاگرام چیست به بررسی نمودارهای ساختاری و رفتاری پرداخته شده است.

نمودارهای ساختاری

نمودارهای ساختاری جنبه‌های ایستا از یک سیستم را به تصویر می‌کشند. این نمودارها بر هر آنچه تاکید می‌کنند که باید در یک سیستم مدل شده وجود داشته باشد. از آنجا که نمودارهای ساختاری در واقع ساختار سیستم را نشان می‌دهند، از آن‌ها به طور گسترده‌ای در معماری نرم‌افزاری یک سیستم نرم‌افزاری استفاده می‌شود. برای مثال، نمودار مولفه نشان می‌دهد که یک سیستم چگونه به مولفه‌های مختلف می‌شکند و همچنین، وابستگی‌های میان این مولفه‌ها را نیز به تصویر می‌کشد.

نمودارهای رفتاری

نمودارهای رفتاری جنبه‌های پویای یک سیستم را به تصویر می‌کشند. این نمودارها بر هر آنچه تاکید دارند که در یک سیستم به وقوع می‌پیوندد. از آنجا که نمودارهای رفتاری رفتار یک سیستم را به تصویر می‌کشند، به طور گسترده‌ای برای توصیف کارکردهای سیستم مورد استفاده قرار می‌گیرند. برای مثال، نمودار فعالیت، فعالیت‌های کسب و کار و فعالیت‌های گام به گام مولفه‌ها (Components) در یک سیستم را توصیف می‌کند. نمودار مورد کاربرد یا یوزکیس دیاگرام (Use Case Diagram) نیز که موضوع اصلی بحث مطلب یوزکیس دیاگرام چیست است، از جمله نمودارهای رفتاری محسوب می‌شود که در بخش‌های بعدی به طور جامع و کامل به آن پرداخته شده است.

نمودارهای برهم‌کنش: نمودارهای برهم‌کنش یک شاخه ویژه از نمودارهای رفتاری محسوب می‌شوند که بر جریان داده‌ها و کنترل هر آنچه تاکید دارند که در میان مولفه‌های یک سیستم مدل شده وجود دارد. برای مثال، نمودار توالی نشان می‌دهد که اشیا چگونه با توجه به یک سلسله‌مراتب از پیام‌ها با یکدیگر ارتباط برقرار می‌کنند.

واژه شناسی کلمه یوزکیس دیاگرام

«نمودار مورد کاربرد» معادل فارسی برگزیده شده برای عبارت انگلیسی «Use Case Diagram» است. همچنین، «مورد استفاده» یا «مورد کاربرد» معادل‌های برگزیده شده برای عبارت انگلیسی «Use Case» هستند و از واژه «برهم‌کنش» به عنوان معادلی برای کلمه Interaction استفاده می‌شود. در سرتاسر این مطلب، نظر به آنکه بیشتر افراد با عبارات یوزکیس دیاگرام و یوزکیس مانوس هستند، بیشتر از این عبارات به جای معادل‌های فارسی آن‌ها استفاده شده است.

برای درک بهتر آنچه در ادامه این مطلب آمده است، یکی از اصطلاحات پرکاربرد در حوزه یوزکیس دیاگرام تعریف و سایر موارد در ادامه تشریح می‌شوند. در زبان مدل‌سازی یکپارچه به فردی که در کار با سیستم نقش ایفا می‌کند و در واقع کاربر سیستم است، «بازیگر» یا «Actor» گفته می‌شود. در یوزکیس دیاگرام نیز به همین صورت است و از کلمه بازیگر برای اشاره به فرد یا چیزی استفاده می‌شود که با سیستم کار می‌کند و اقداماتی را در آن راستا انجام می‌دهد. بازیگر می‌تواند یک انسان یا سیستم خارجی باشد.

یوزکیس چیست ؟

عبارت یوزکیس در مهندسی نرم‌افزار و مهندسی سیستم از جمله عبارات چند معنایی است که بر دو مفهوم کلی دلالت دارد:

• یک سناریو کاربردی برای یک نرم‌افزار را یوزکیس می‌گویند. در این شرایط، معمولا از کلمه Use Cases که حالت جمع کلمه Use Case است استفاده می‌شود.
• یک سناریو بالقوه که در آن، سیستم یک درخواست خارجی مانند ورودی کاربر را دریافت می‌کند و به آن پاسخ می‌دهد.

یوزکیس یک فهرست از اقدامات (Actions | اعمال) یا مراحل یک رویداد است که معمولا برهم‌کنش‌های بین یک بازیگر (نقش) و سیستم را برای رسیدن به یک هدف مشخص تعریف می‌کنند. چنانکه پیش‌تر نیز بیان شد، بازیگر می‌توان یک انسان یا دیگر سیستم‌های خارجی باشد. یوزکیس یا مورد کاربرد رفتارهای مورد انتظار از سیستم را تعیین می‌کند (What | چیه؟) و روش دقیق انجام آن رفتار را بیان نمی‌کند (How | چگونه؟)

در تعریفی دقیق‌تر پیرامون یوزکیس می‌توان گفت که یوزکیس روش مورد استفاده در تحلیل سیستم به منظور شناسایی، شفاف‌سازی و سازمان‌دهی نیازمندی‌های سیستم است. یوزکیس از یک مجموعه از توالی برهم‌کنش‌های ممکن بین سیستم و کاربر در یک محیط خاص تشکیل شده و به یک هدف خاص مربوط می‌شود. یوزکیس منجر به تولید سندی می‌شود که همه گام‌هایی که کاربر برای انجام یک فعالیت باید انجام بدهد را مشخص می‌کند.

یوزکیس معمولا توسط تحلیل‌گر کسب و کار نوشته می‌شود و می‌توان از آن طی مراحل مختلفی از توسعه نرم‌افزار مانند برنامه‌ریزی نیازمندی‌های سیستم، اعتبارسنجی طراحی، تست نرم‌افزار و ساخت یک چارچوب برای راهنمای کاربر از آن استفاده کرد. با استفاده از سند یوزکیس تیم توسعه می‌توانند جایی که خطا ممکن است در طول یک تراکنش به وقوع بپیوندد را بفهمند و در نتیجه، آن را اصلاح کنند.

در مهندسی سیستم، از یوزکیس ها برای اهداف به مراتب مهم‌تری نسبت به دلایل استفاده از آن‌ها در مهندسی نرم‌افزار، استفاده می‌شود. از جمله این موارد می‌توان به نمایش ماموریت یا اهداف ذینفعان اشاره کرد که از اهمیت به سزایی برخوردار هستند. چه در مهندسی نرم‌افزار و چه در مهندسی سیستم، نیازمندی‌های همراه با جزئيات پروژه بعد از تصویب نهایی یوزکیس دیاگرام ها ممکن است با زبان مدل‌سازی سیستم (Systems Modeling Language | SysML) یا اظهارات قراردادی به ثبت برسند.

در ادامه مطلب یوزکیس دیاگرام چیست و در بخشی که چگونگی ترسیم یوزکیس دیاگرام بیان شده، به طور دقیق‌تر به یوزکیس پرداخته شده است. هدف از بیان مفهوم یوزکیس در این بخش از مطلب یوزکیس دیاگرام چیست آن است که کاربر مفهوم یوزکیس دیاگرام و یوزکیس را اشتباه نگیرد، آن‌ها را معادل یکدیگر نداند و از این موضوع آگاه باشد که یوزکیس دیاگرام حالت مصور و نموداری شده یوزکیس است.

مدل‌سازی بصری یوزکیس و ساخت یوزکیس دیاگرام

یوزکیس ها فقط به صورت متنی نیستند و در صورت لزوم امکان ترسیم نمودارهای اختصاصی نیز برای آن‌ها وجود دارد که در واقع همان یوزکیس دیاگرام است. در زبان مدل‌سازی یکپارچه (UML)، رابطه بین یوزکیس‌ها و بازیگران در یوزکیس دیاگرام اساسا بر مبنای روش نشانه‌گذاری آبجکتوری (Objectory) ایوار جاکوبسن (Ivar Jacobson) ترسیم و ارائه می‌شود. SysML از نشانه‌گذاری مشابهی در سطح بلوک سیستم استفاده می‌کند. علاوه بر آن، دیگر نمودارهای رفتاری UML مانند نمودار فعالیت (Activity Diagrams)، نمودار توالی (Sequence Diagrams)، نمودار ارتباطات (Communication Diagrams) و نمودار حالت ماشین (Machine State Diagram) برای بصری‌سازی یوزکیس قابل استفاده هستند. به طور خاص، نمودار توالی سیستم (System Sequence Diagram) معمولا برای نمایش تعاملات بین بازیگران خارجی و سیستم تحت طراحی (SuD)، معمولا برای بصری‌سازی یک سناریو مشخص از یوزکیس، مورد استفاده قرار می‌گیرد.

تحلیل یوزکیس معمولا با ترسیم نمودار مورد کاربرد یا یوزکیس دیاگرام آغاز می‌شود. به منظور انجام توسعه چابک، یک مدل خواسته‌ها (Requirement Model | مدل نیازمندی‌ها) برای بسیاری از نمودارهای UML، یوزکیس‌ها را همراه با توصیفات متنی به تصویر می‌کشد. یادداشت‌ها یا چکیده‌های یوزکیس بسیار سبک وزن خواهند بود و فقط برای پروژه‌های کوچک یا ساده مورد نیاز هستند. به عنوان مکمل خوبی برای استفاده در کنار یوزکیس های متنی، ارائه نمودارهای بصری از یوزکیس ها یا همان یوزکیس دیاگرام نقش ابزاری تسهیل کننده و موثری را برای درک بهتر ارتباطات و طراحی نیازهای رفتاری یک سیستم پیچیده دارد.

یوزکیس دیاگرام چیست ؟

یوزکیس دیاگرام در ساده‌ترین تعریف، نموداری است که برهم‌کنش‌های بین کاربر یک سیستم و آن سیستم را به تصویر می‌کشد. این برهم‌کنش‌ها به منظور رسیدن به هدف خاصی در آن سیستم انجام می‌شوند. یوزکیس دیاگرام با استفاده از چند شکل مشخص شامل آدمک، دایره و جهت‌نما ترسیم می‌شود.

به بیان دقیق‌تر، در مهندسی نرم‌افزار و مهندسی سیستم، یوزکیس دیاگرام نموداری است که اعمال یا مراحلی را نمایش می‌دهد که برای رسیدن به یک هدف خاص طی تعامل بین یک بازیگر با یک سیستم انجام می‌شوند. در واقع، یوزکیس دیاگرام ارائه‌ای بصری از تعاملات کاربر با سیستم است که رابطه بین کاربر و یوزکیس‌های گوناگون را ضمن کار با یک سیستم نشان می‌دهد. یک نمودار مورد کاربرد یا یوزکیس دیاگرام می‌تواند انواع گوناگونی از کاربران یک سیستم یا همان بازیگران و یوزکیس‌های گوناگون را به تصویر بکشد. یوزکیس دیاگرام معمولا با استفاده از چند شکل خاص شامل دایره یا بیضی و جهت‌نما ترسیم می‌شود.

پرسش یوزکیس دیاگرام چیست از جمله پرسش‌های متداول مهندسان نرم‌افزار و مهندسان سیستم است و افراد گوناگون این پرسش را به اشکال مختلفی مطرح می‌کنند. علاوه بر آنکه برخی از توسعه‌دهندگان نرم‌افزار یا مدیران پروژه نمی‌دانند که یوزکیس دیاگرام چیست ، بخش زیادی از آن‌ها نیز مزایای ترسیم یوزکیس دیاگرام برای توسعه یک محصول نرم‌افزاری خوب را دستکم می‌گیرند. اما آیا واقعا به یوزکیس دیاگرام بی‌توجهی شده و اهمیت آن نادیده گرفته شده است؟ در ادامه این مطلب، پاسخ این پرسش‌ها داده شده است.

یوزکیس دیاگرام شکل اولیه از خواسته‌ها از یک سیستم (نیازمندی‌ها) برای توسعه یک محصول نرم‌افزاری جدید است. هنگامی که یوزکیس ها تعریف شدند، می‌توان آن‌ها را به صورت متنی و بصری ارائه کرد که حالت بصری همان یوزکیس دیاگرام است که نسبت به حالت متنی از محبوبیت بیشتری نیز برخوردار است. یک نکته کلیدی و مزیت مدل‌سازی یوزکیس آن است که این کار به افراد درگیر در پروژه کمک می‌کند تا یک سیستم را از چشم‌انداز کاربر نهایی متصور شوند و بسازند. طراحی و ترسیم یوزکیس دیاگرام روشی موثر برای بیان رفتار سیستم به زبان قابل درک برای افراد گوناگون است که طی آن همه رفتارهای خارجی سیستم یعنی رفتارهایی از سیستم که نمود بیرونی دارند تعیین می‌شوند. از جمله ویژگی‌های برجسته یوزکیس دیاگرام می‌توان به موارد زیر اشاره کرد:

• یک یوزکیس دیاگرام معمولا ساده است. یوزکیس دیاگرام جزئیات زیادی پیرامون یوزکیس‌ها را نمایش نمی‌دهد.
• یوزکیس دیاگرام تنها برخی از روابط بین یوزکیس ها، بازیگران و سیستم‌ها را نمایش می‌دهد.
• یوزکیس دیاگرام ترتیب انجام مراحلی که توسط بازیگر برای رسیدن هدف انجام می‌شود را نشان نمی‌دهد.

چنانکه پیش‌تر بیان شد، یک نمودار یوزکیس باید ساده و حاوی تعداد اَشکال کمی باشد. اگر یوزکیس دیاگرام حاوی بیش از ۲۰ یوزکیس دیگر باشد، احتمالا فرد جایی در طراحی یوزکیس دیاگرام اشتباه کرده است. یعنی در واقع، یوزکیس بعضا مستقل از هم را در یک یوزکیس دیاگرام آورده است، در حالی که می‌توانست هر یک را به طور جداگانه ترسیم کند و از ترسیم یک یوزکیس دیاگرام شلوغ و پیچیده اجتناب بورزد.

تاریخچه یوزکیس دیاگرام

در سال ۱۹۸۷، «ایوار جاکوبسن» (Ivar Jacobson) اولین مقاله خود را پیرامون یوزکیس در کنفرانس OOPSLA'87 ارائه کرد. او در این مقاله توضیح داده بود که روش یوزکیس چطور در شرکت اریکسون برای ثبت و تعیین نیازمندی‌های یک سیستم با استفاده از روش‌های مدل‌سازی متنی، ساختاری و بصری مورد استفاده قرار گرفته است تا تحلیل و طراحی شی‌گرا را ارائه کند. او در مقاله انگلیسی خود از اصطلاحات Usage Scenario (سناریو کاربرد) و Use Case (مورد کاربرد) برای اشاره به مفهومی استفاده کرد بود که ترجمه انگلیسی اصطلاح سوئدی آن یعنی «användningsfall» است.

در سال ۱۹۹۲، او در تدوین کتابی با نام «مهندسی کامپیوتر شی‌گرا - یک رویکرد مورد کاربرد محور» (Object Oriented Software Engineering - A Use Case Driven Approach) مشارکت کرد. در این کتاب، مبانی مهندسی سیستم شی‌گرا را بیان کرد و به عمومی‌سازی یوزکیس ها برای ثبت خواسته‌های عملیاتی (نیازهای کارکردی) به ویژه در توسعه نرم‌افزار کمک کرد. در سال ۱۹۹۴، او کتابی را پیرامون یوزکیس و روش‌های شی‌گرای اعمال شده بر مدل‌های کسب و کار و مهندسی فرایندهای کسب و کار منتشر کرد.

هم‌زمان با انتشار کتاب مذکور، «گریدی بوچ» (Grady Booch) و «جیمز رامبا» (James Rumbaugh) روی یکپارچه‌سازی روش‌های تحلیل و طراحی شی‌گرا و همچنین، «روش بوچ» (Booch Method) و «روش‌های مدل‌سازی شی» (Object Modelling Technique | OMT) کار می‌کردند. در سال ۱۹۹۵، ایوار جاکوبسن به آن‌ها پیوست و اعضای این تیم در کنار هم، «زبان مدل‌سازی یکپارچه» (Unified Modelling Language | UML) را ارائه کردند که شامل مدل‌سازی یوزکیس می‌شد. زبان مدل‌سازی یکپارچه توسط «گروه مدیریت شی» (Object Management Group | OMG) در سال ۱۹۹۷ استانداردسازی شد. جاکوبسن، بوچ و رامبا روی اصلاح فرایند توسعه نرم‌افزار آبجکتوری (Objectory Software Development Process) کار کردند. فرایند یکپارچه شده حاصل، در سال ۱۹۹۹ منتشر شد و رویکرد یوزکیس محور را ترویج کرد.

از آن زمان تاکنون، نویسندگان زیادی در توسعه این روش مشارکت داشته‌اند که از جمله آن‌ها می‌توان به تلاش‌های «لری کانستنتاین» (Larry Constantine) در سال ۱۹۹۵ در زمینه «طراحی کاربرد محور» (Usage-Centered Design) اشاره کرد که به نمودارهای آن «یوزکیس اساسی» (Essential Use Cases) گفته می‌شود. هدف یوزکیس اساسی توصیف اهداف کاربر به جای یک توالی از اقدامات یا سناریوها است که ممکن است طراحی رابط کاربری را دچار محدودیت یا سوگیری کنند. «آلیستر کوکبرن» (Alistair Cockburn) در سال ۲۰۲۰ یک یوزکیس هدف محور را بر مبنای روایت متنی و مشخصه‌های جدول ارائه کرد.

«کرت بیتنر» (Kurt Bittner) و «ایان اسپنس» (Ian Spence) روش‌های پیشرفته برای تحلیل نیازهای کارکردی با یوزکیس را در سال ۲۰۰۲ توسعه دادند. در عین حال، «دین لفینگول» (Dean Leffingwell) و «دن ویدریگ» (Don Widrig) پیشنهاد اعمال یوزکیس را برای تغییر فعالیت‌های ارتباطی مدیریتی و ذینفعان دادند. «گانر اورگارد» (Gunnar Overgaard) در سال ۲۰۰۴ پیشنهاد گسترش اصول الگوی طراحی (Design Patterns) را برای یوزکیس را داد.

در سال ۲۰۱۱، جاکوبسن، ایان اسپنس و کرت بیتنر، کتابی الکترونیکی با عنوان «یوزکیس ۲.۰» (Use Case 2.0) را ارائه کردند. این نسخه از یوزکیس برای سازگار کردن روش یوزکیس با زمینه چابک، غنی‌سازی آن با قطعه‌های افزایشی یوزکیس (Incremental Use Case Slices) و ارتقای کاربردهای آن در سرتاسر چرخه حیات توسعه کامل ارائه شده بود. آن‌ها انتشار این کتاب را پس از ارائه رویکرد تازه خود یه یوزکیس و در کنفرانس سالانه آی‌بی‌ام انجام دادند.

کاربرد یوزکیس دیاگرام

در حالی که یوزکیس ممکن است جزئیات زیادی را پیرامون هر احتمالی در سیستم به همراه داشته باشد، یوزکیس دیاگرام می‌تواند به فراهم کردن سطح بالاتری از جزئیات پیرامون هر احتمال کمک کند. یوزکیس دیاگرام علاوه بر آنکه می‌تواند سطح بالایی از جزئیات را پیرامون هر احتمال در سیستم فراهم کند، می‌تواند نمایش سطح بالاتری از یک سیستم را ارائه دهد. البته، باید توجه داشت که یوزکیس کلیه جزئیات لازم پیرامون یک سیستم را به همراه ندارد. یوزکیس دیاگرام در واقع یک نقشه ساخت (بلو پرینت | Blueprint) از سیستم است. یوزکیس دیاگرام ها یک ارائه ساده شده و گرافیکی از کاری را فراهم می‌کنند که سیستم انجام می‌دهد.

نظر به ماهیت ساده این نوع از نمودارها، یوزکیس دیاگرام می‌تواند ابزار خوبی برای ارتباط با ذینفعان یک پروژه نرم‌افزاری باشد. یوزکیس دیاگرام در واقع نموداری است که تلاش می‌کند دنیای واقعی را تقلید و نمایی برای ذینفعان به منظور درک چگونگی طراحی سیستم فراهم کند. سیائو (Siau) و «لی» (Lee) پژوهشی را به منظور بررسی آن انجام دادند که آیا یوزکیس دیاگرام ها ضروری و مورد نیاز محسوب می‌شوند و یا اقلامی غیر ضروری هستند. نتیجه این پژوهش حاکی از آن است که یوزکیس دیاگرام هدف سیستم را به بیانی ساده‌تر به ذینفعان سیستم منتقل می‌کند و قابلیت تفسیر شدن یوزکیس دیاگرام به مراتب از نمودارهای کلاس بیشتر است.

هدف یوزکیس دیاگرام

هدف از نمودارهای یوزکیس ثبت جنبه‌های پویای سیستم است. در کنار یوزکیس دیاگرام از دیگر نمودارها و مستندسازی‌ها می‌توان برای فراهم آوردن یک نمای عملیاتی و فنی از سیستم استفاده کرد. یوزکیس دیاگرام ارائه ساده شده و گرافیکی از آنچه را فراهم می‌کند که سیستم واقعا انجام می‌دهد. یوزکیس دیاگرام ها معمولا در مراحل اولیه توسعه نرم‌افزار توسعه پیدا می‌کنند و افراد معمولا از مدل‌سازی یوزکیس با اهداف زیر استفاده می‌کنند.

• تعیین زمینه کاری یک سیستم
• ثبت خواسته‌ها از یک سیستم (نیازمندی‌ها)
• اعتبارسنجی معماری یک سیستم
• پیاده‌سازی و تولید نمونه‌های تست
• توسعه پیدا کردن سیستم با حضور تحلیلگران دارای دانش دامنه

در ادامه مطلب یوزکیس دیاگرام چیست به بیان مزایا و معایب یوزکیس دیاگرام پرداخته شده است.

مزایای یوزکیس دیاگرام

از آغاز گرایش مدیران و مهندسان پروژه‌ها به روش‌های چابک (Agile)، روش داستان کاربر (َUser Scenario) از «برنامه‌نویسی مفرط» (Extreme Programming)، محبوبیت بسزایی کسب کرد و بسیاری از افراد بر این باور بوده و هستند که این راهکار، بهترین راه برای نمایش خواسته‌های (Requirement | نیازمندی‌ها) چابک یک پروژه است.

آلیستار کاکبورن (Alistair Cockburn)، دانشمند کامپیوتری، پنج دلیل خود را برای اینکه چرا همچنان از یوزکیس در توسعه چابک استفاده می‌کند فهرست کرده است. پنج دلیل کاکبورن، در ادامه آمده‌اند.

1. یوزکیس دیاگرام لیستی از عناوین اهداف را فراهم می‌آورد که کوتاه‌ترین خلاصه از آنچه سیستم ارائه می‌کند را دربر دارد (حتی از داستان‌های کاربر نیز خلاصه‌تر است). همچنین، یک اسکلت برای برنامه‌ریزی پروژه فراهم می‌کند تا برای ساخت اولویت‌های اولیه، تخمین‌ها، تخصیص تیم و زمان‌بندی مورد استفاده قرار بگیرد.
2. سناریو موفقیت اصلی هر یوزکیس، برای کلیه افراد درگیر در یک توافق این دید را فراهم می‌کند که سیستم چه کاری انجام می‌دهد و چه کاری انجام نمی‌دهد. این مورد، زمینه را برای هر یک از خواسته‌ها از سیستم (نیازمندی‌های سیستم) فراهم می‌کند (داستان‌های به خوبی دانه‌بندی شده کاربر)، زمینه‌ای که به دست آوردن آن به هر روش دیگری بسیار سخت خواهد بود.
3. بسط شرایط هر یوزکیس چارچوبی را برای تحقیق پیرامون همه عناوینی فراهم می‌کند که گاهی بحث پیرامون آن‌ها، ۸۰ درصد از زمان و بودجه توسعه پروژه را از آن خود می‌کند. یوزکیس، یک مکانیزم رو به جلو فراهم می‌کند؛ بنابراین، ذینفعان می‌توانند مسائلی که امکان آن وجود دارد که پاسخ دادن به آن‌ها مدت زمان زیادی به طول بینجامد را مشخص کنند. با مشخص شدن این پرسش‌ها، تیم توسعه هنگامی که برای پرداختن به آن‌ها آماده است و زمان کافی دارد، می‌تواند آن‌ها را مورد بررسی قرار دهد.
4. قطعه‌بندی سناریو یوزکیس، پاسخ‌هایی را با جزئیات بسیار زیاد فراهم می‌کند؛ حتی گاهی برای پرسش‌های نادیده گرفته شده و نکته‌بینانه کسب و کار مانند پرسش «چه کسی باید این کیس را انجام دهد؟» نیز پاسخی دربردارد. یوزکیس یک چارچوب فکر کردن/مستندسازی است که با عبارت if...then...else تطابق دارد و کمک می‌کند تا برنامه‌نویسان به مسائل بپردازند. البته باید توجه داشت که پرداختن به مسائل گوناگون در زمان تحقیق و بررسی انجام می‌شود، نه در زمان برنامه‌نویسی.

به طور خلاصه، تعیین نیازمندی‌های سیستم در یوزکیس، دارای مزایایی در مقایسه با رویکردهای سنتی یا دیگر رویکردها است. این مزایا، در ادامه و به طور مشروحی مورد بررسی قرار گرفته‌اند.

تمرکز کاربر

یوزکیس دیاگرام یک ابزار قدرتمند و کاربر محور برای فرایند مشخصه‌سازی خواسته‌های نرم‌افزار (Software Requirement Specification) است. مدل‌سازی یوزکیس معمولا از شناسایی نقش‌های ذینفعان اصلی (بازیگران) آغاز می‌شود  که با سیستم تعامل می‌کنند. همچنین، اهداف یا مقاصدی از بازیگران که در کار با سیستم باید تامین شوند (یک چشم‌انداز خارجی) نیز مشخص می‌شود.

این اهداف کاربر، بعدا به یک کاندیدای ایده‌آل برای اسامی یا عناوین یوزکیس مبدل می‌شوند که ویژگی‌های کارکردی مطلوب یا سرویس‌های فراهم شده توسط سیستم را ارائه می‌کنند. ارتباطات بهتر در رویکرد کاربر محور موجب حصول اطمینان از این موضوع می‌شود که آنچه برای کسب و کار واقعا ارزش دارد و کاربر می‌خواهد، توسعه پیدا کرده است و فقط کارکردهای بدیهی که توسط توسعه‌دهنده حدس زده شده‌اند و یا از چشم‌انداز (درونی) سیستم هستند توسعه پیدا نکرده‌اند. تالیف یوزکیس سال‌ها است که یک ابزار مهم و ارزشمند در دامنه «طراحی کاربر محور» (User Centered Design | UCD) محسوب می‌شود.

ارتباطات بهتر

یوزکیس ها معمولا به زبان طبیعی با الگوهای ساختاریافته نوشته می‌شوند. این فرم متن روایت (داستان‌های نیازمندی‌های قابل خواندن)، تقریبا توسط همه قابل خواندن است و به وسیله نمودارهای بصری زبان برنامه‌نویسی یکپارچه (UML)، ارتباطات بهتر و عمیق‌تر را در میان ذینفعان شامل مشتریان، کاربران نهایی، توسعه‌دهندگان، تست‌کنندگان و مدیران برقرار می‌کند و پرورش می‌دهد. ارتباطات بهتر منجر به درک بهتر خواسته‌ها از سیستم و به طور خاص خواسته‌های کیفی می‌شود و بنابراین، سیستم‌های با کیفیتی به عنوان خروجی پروژه آماده و در نهایت تحویل مشتری می‌شوند.

خواسته‌های کیفی با اکتشاف ساختاری

یکی از برجسته‌ترین موضوعات پیرامون یوزکیس مربوط به قالب‌های الگوهای یوزکیس به ویژه سناریو موفقیت اصلی (جریان اصلی) و بخش‌بندی سناریو می‌شود. تحلیل گام به گام یک یوزکیس از پیش‌شرط‌ها تا پس‌شرط‌ها با اکتشاف و تحقیق و پژوهش پیرامون هر گام از اقدامات از جریان یوزکیس مقدماتی به بسط‌یافته انجام می‌شود. این کار برای شناسایی نیازمندی‌های جزئی که به طور طبیعی پنهان و نادیده گرفته شده‌اند و ظاهرا بدیهی به نظر می‌رسند اما در حقیقت نیازمندی‌های پر هزینه‌ای هستند (چنانکه کاکبورن پیش‌تر به آن اشاره کرده بود) انجام می‌شود.

یوزکیس یک راهکار ساختار یافته و سودمند برای گردآوری نیازمند‌های کیفی به صورت پایدار، شفاف و سیستماتیک ارائه می‌کند. کمینه کردن و بهینه‌سازی گام‌های اقدامات در یوزکیس در تامین اهداف کاربر در طراحی تعاملی و ارائه یک تجربه کاربری بهتر از سیستم، نقش دارد.

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

با بهره‌گیری از محتوای مبتنی بر یک اقدام (عمل) یا ساختار جریان رویداد، یک مدل از یک یوزکیس به خوبی نوشته شده نیز به عنوان یک کار پایه‌ای و راهنمای ارزشمند برای طراحی تست کیس‌ها و راهنماهای کاربر از سیستم یا محصول محسوب می‌شود و یک سرمایه گذاری ارزشمند را در پی دارد. ارتباط واضحی بین مسیرهای جریان از یوزکیس و تست کیس‌های آن وجود دارد. مشتق کردن کیس‌های تست کارکردی از یک یوزکیس در سناریو آن، کاری فاقد پیچیدگی است.

معایب یوزکیس دیاگرام و محدودیت‌های آن

معایب یوزکیس دیاگرام و در واقع، محدودیت‌های آن، در ادامه بیان شده است.

• یوزکیس‌ها به خوبی برای ثبت خواسته‌هایی (نیازمندی‌هایی) از سیستم که مبتنی بر برهم‌کنش‌ها نیستند (مانند الگوریتم‌ها یا خواسته‌های ریاضیاتی) و یا خواسته‌های غیرعملیاتی () (مانند پلتفرم، کارایی، زمان‌بندی یا جنبه‌های امنیتی حیاتی) مناسب‌سازی نشده‌اند. این موارد، بهتر است به طور شفاف در جای دیگر اعلان شوند.
• با توجه به آنکه هیچ تعریف کاملا استانداردی از یوزکیس ها وجود ندارد، در هر پروژه‌ای باید تفسیرهای خاص آن پروژه شکل بگیرد.
• برخی از روابط یوزکیس مانند Extends در هنگام تفسیر شدن دچار ابهام می‌شوند و برای ذینفعان دشوار است که آن‌ها را درک کنند. به این مورد پیش‌تر توسط کاکبورن اشاره شده بود.
• توسعه‌دهندگان یوزکیس معمولا تعیین سطح وابستگی‌های رابط کاربری را برای ادغام در یوزکیس کاری دشوار می‌دانند. این در حالی است که در نظریه یوزکیس بیان شده که رابط کاربری نباید در یوزکیس منعکس شود؛ زیرا انتزاعی کردن این بخش از طراحی، نامناسب خواهد بود و بصری‌سازی یوزکیس ها را دشوار می‌سازد. در مهندسی نرم‌افزار، این دشواری‌ها با اعمال «قابلیت ردیابی نیازمندی‌ها» (Requirements Traceability) حل می‌شود؛ برای مثال، با استفاده از یک «ماتریس ردیابی» (Traceability Matrix) این کار قابل انجام است. دیگر رویکرد موجود برای تخصیص عناصر رابط کاربری در یوزکیس، ضمیمه کردن طراحی رابط کاربری به هر گام در یوزکیس است. به این مورد، استوری‌بورد یوزکیس (Use Case Storyboard) گفته می‌شود.
• یوزکیس ها ممکن است بیش از اندازه مورد تاکید قرار بگیرند و در واقع، بیش از آنچه باید، در طراحی پروژه و ارتباط با ذینفعان به آن‌ها استناد شود. «برتراند میر» (Bertrand Meyer) مسائلی مانند انجام طراحی سیستم صرفا بر اساس یوزکیس‌ها و استفاده از یوزکیس برای اجتناب کردن از استفاده از دیگر روش‌های ارزشمند تحلیل خواسته‌ها را از جمله معایب یوزکیس می‌داند.
• یوزکیس ها نقطه شروعی برای طراحی تست هستند؛ اما از آنجا که هر تستی نیازمند معیارهای موفقیت خودش است، یوزکیس‌ها ممکن است نیاز به ویرایش شدن برای فراهم کردن شرایط پسین جداگانه برای هر مسیر داشته باشند.
• اگرچه یوزکیس‌ها شامل اهداف و زمینه‌های پروژه هستند، این اهداف و انگیزه‌های پشت اهداف (نگرانی‌های ذینفعان و ارزیابی‌های آن‌ها شامل موارد غیر تعاملی) با دیگر اهداف سیستم دچار ناسازگاری می‌شوند یا به طور مثبت/منفی آن‌ها را تحت تاثیر قرار می‌دهند و بدین شکل، موضوع روش‌های مدل‌سازی خواسته‌های به صورت هدف‌محور مطرح می‌شود.

معرفی مجموعه آموزش‌های مهندسی کامپیوتر - نرم‌افزار فرادرس

طراحی یوزکیس دیاگرام یکی از مباحث مهم در مهندسی نرم‌افزار محسوب می‌شود که در دانشگاه و در رشته مهندسی کامپیوتر گرایش نرم‌افزار، در دروس مهندس نرم‌افزار ۱ و ۲ تدریس می‌شود. در عین حال، فراگیری روش طراحی یوزکیس دیاگرام برای کلیه مهندسان و مدیران پروژه‌های نرم‌افزاری، برنامه‌نویس‌ها، مهندس‌های سیستم و دیگر افرادی که در صدد طراحی سیستم‌های جدید هستند بسیار مهم و حائز اهمیت است. در ادامه این بخش از مطلب یوزکیس دیاگرام چیست «مجموعه آموزش‌های مهندسی کامپیوتر - نرم‌افزار» فرادرس به صورت اجمالی معرفی شده‌اند که برای فراگیری مباحث مختلف حوزه مهندسی کامپیوتر از جمله اصول مهندسی نرم‌افزار شامل طراحی یوزکیس دیاگرام می‌توان از آن‌ها استفاده کرد.

• فیلم آموزش مدل‌سازی UML با نرم‌افزار Rational Rose (مدرس دوره: مهندس سمیه توکلی، طول مدت دوره: سه ساعت و سی و پنج دقیقه): برای مشاهده فیلم آموزش مدل‌سازی UML با نرم‌افزار Rational Rose + کلیک کنید.
• فیلم آموزش توسعه نرم‌افزار با متد ICONIX و زبان مدل‌سازی UML (مدرس دوره: مهندس سعید مصطفایی، طول مدت دوره: سه ساعت و پنجاه و شش دقیقه): برای مشاهده فیلم آموزش توسعه نرم‌افزار با متد ICONIX و زبان مدل‌سازی UML + کلیک کنید.
• فیلم آموزش نرم افزار RAPTOR برای ترسیم فلوچارت (مدرس دوره: مهندس محمد جباری، طول مدت دوره: پنجاه و سه دقیقه): برای مشاهده فیلم آموزش نرم افزار RAPTOR برای ترسیم فلوچارت + کلیک کنید.
• فیلم آموزش آموزش تبدیل فلوچارت به کد با Flowgorithm (مدرس دوره: مهندس وحید باقی، طول مدت دوره: یک ساعت و بیست و سه دقیقه): برای مشاهده فیلم آموزش آموزش تبدیل فلوچارت به کد با Flowgorithm + کلیک کنید.
• فیلم آموزش الگوریتم موازی و پردازش موازی (مدرس دوره: منوچهر بابایی، طول مدت دوره: سیزده ساعت و دو دقیقه): برای مشاهده فیلم آموزش الگوریتم موازی و پردازش موازی + کلیک کنید.
• فیلم آموزش تخمین تلاش لازم برای توسعه نرم افزارها‎ با متلب (مدرس دوره: دکتر عمید خطیبی بردسیری، طول مدت دوره: سه ساعت و بیست و پنج دقیقه): برای مشاهده فیلم آموزش تخمین تلاش لازم برای توسعه نرم‌افزارها‎ با متلب + کلیک کنید.
• فیلم آموزش مبانی توسعه نرم افزاری Agile (چابک) (مدرس دوره: مهندس عباس نیک‌نفس، طول مدت دوره: دو ساعت و سی و پنج دقیقه): برای مشاهده فیلم آموزش مبانی توسعه نرم‌افزاری Agile (چابک) + کلیک کنید.

باورهای غلط پیرامون یوزکیس

باورهای غلط متداولی پیرامون یوزکیس وجود دارند که در ادامه مورد بررسی قرار گرفته‌اند.

چابکی داستان‌های کاربر و عدم چابکی یوزکیس‌ها

باور غلط: «داستان‌های کاربر چابک هستند؛ یوزکیس‌ها چابک نیستند». مدل‌های توسعه نرم‌افزار چابک و اسکرام (Scrum) از جهت روش‌های مورد نیاز، بی‌طرف و خنثی عمل می‌کنند. چنانکه در «اسکرام پرایمر» (Scrum Primer) چنین بیان شده است:

 اقلام (Items) موجود در لیست ویژگی‌های محصول به شکلی بیان شده‌اند که شفاف و پایدار هستند. بر خلاف باور غلط عمومی، بک‌لوگ محصول حاوی «داستان‌های کاربر» نیست؛ بلکه حاوی اقلام (Items) است. این اقلام را می‌توان به عنوان داستان‌های کاربر، یوزکیس ها یا دیگر انواع رویکردهای مربوط به مهندسی خواسته‌ها بیان کرد که تیم پروژه آن‌ها را مفید می‌پندارد. اما رویکرد هر آنچه که باشد، اغلب اقلام باید روی تحویل ارزش به مشتری کار کنند.

باید توجه داشت که روش‌های یوزکیس برای آنکه رویکرد چابک داشته باشند تکامل یافته‌اند.

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

باور غلط: «یوزکیس ها اساسا نمودار هستند». «کریگ لارمن» (Craig Larman) در رابطه با یوزکیس‌ها چنین بیان می‌کند که «یوزکیس ها نمودار نیستند، متن هستند». نمودار در واقع یوزکیس دیاگرام ترسیم شده بر اساس یوزکیس است.

وجود محتوای مرتبط با کاربر در یوزکیس

باور غلط: «یوزکیس ها دارای مقدار زیادی محتوای مرتبط با رابط کاربری هستند». یکی از باورهای غلط پیرامون یوزکیس ها آن است که یوزکیس ها معمولا حاوی سطحی از جزئیات (نام‌گذاری، برچسب‌ها و دکمه‌ها) هستند که موجب می‌شود این یوزکیس‌ها به خوبی برای ثبت خواسته‌های سیستم جدید به طور کامل و از صفر تا صد، مناسب باشند. این یکی از باورهای غلط رایج در حوزه یوزکیس است. هر یک از یوزکیس‌های به خوبی نوشته شده باید اهداف و مقاصد بازیگر را نشان دهند (ماهیت نیازمندی‌های کارکردی) و به طور طبیعی، نباید حاوی جزئیاتی پیرامون رابط کاربری باشد.

برای مثال، یوزکیس نباید حاوی جزئیاتی پیرامون برچسب‌ها و کلیدها، عملیات رابط کاربری و دیگر موارد این چنینی باشد. زیرا این موارد، جزئیات غیر لازمی هستند که بر پیچیدگی کار می افزایند و پیاده‌سازی آن را محدود و با مشکل مواجه می‌کنند. برای ثبت نیازمندی‌ها برای یک سیستم جدید از پایه، نمودارهای یوزکیس به همراه جزئيات مختصری پیرامون یوزکیس معمولا به عنوان ابزارهای ارزشمند و کاربردی مورد استفاده قرار می‌گیرند که دستکم به اندازه داستان‌های کاربر سبک‌وزن هستند.

زمان‌بر بودن نوشتن یوزکیس برای سیستم‌های بزرگ

باور غلط: «نوشتن یوزکیس برای سیستم‌های بزرگ کاری خسته کننده و اتلاف زمان است». برخی پیرامون نوشتن یوزکیس برای سیستم‌های بزرگ چنین می‌گویند:

«قالب یوزکیس موجب می‌شود تا توصیف یک سیستم بزرگ توسط آن در کمتر از چند صد صفحه به کاری دشوار مبدل شود (برای مثال و از این جمله، می‌توان به سیستم مدیریت ارتباط با مشتریان اشاره کرد). این کار بسیار زمان‌بر است و کاربر خود را در حالی پیدا می‌کند که حجم زیادی از کارهایی را انجام می‌دهد که غیرلازم هستند.»

هزینه کردن زمان زیاد، برای نوشتن یوزکیس های خسته‌کننده‌ای که هیچ ارزشی ندارند و یا ارزش زیادی را به همراه ندارند منجر به تلاش مجدد می‌شود و حاکی از آن است که نویسندگان آن یوزکیس افراد مسلط و متخصصی نبوده‌اند و با چگونگی نوشتن یوزکیس های با کیفیتی که موثر و کارآمد باشند آشنایی ندارند. یوزکیس را باید به شیوه تکرار شونده، افزایشی و تکاملی (به صورت چابک) ترسیم کرد.

اعمال الگوهای یوزکیس بدین معنا نیست که همه فیلدهای الگوی یوزکیس باید به طور جامع مورد استفاده قرار بگیرند و از بالا به پایین تکمیل شوند. در حقیقت، فرمت یوزکیس به وسیله استایل‌های قالب محبوب و پرکاربرد، فرموله شده است. برای مثال، RUP و کاکبورن این کار را انجام داده‌اند و در عمل اثبات کرده‌اند که یوزکیس ابزار مفید و کمک کننده‌ای برای ثبت، تحلیل و مستندسازی (مدل) است و نباید بر اساس گستردگی و یا صرفا بر اساس سایز آن مورد قضاوت قرار بگیرد.

این امکان وجود دارد که یک یوزکیس با کیفیت و جامع از یک سیستم بزرگ در نهایت در صدها صفحه وجود داشته باشد؛ اما اساسا دلیل این موضوع پیچیدگی ذاتی مسئله مورد بررسی است و نه مهارت های ضعیف نوشتن مولفان یوزکیس یا ناتوانی یوزکیس در به تصویر کشیدن سیستم‌های بزرگ.

اصول عمومی یوزکیس

یوزکیس روشی برای ثبت، مدل‌سازی و تعیین خواسته‌ها از سیستم (نیازمندی‌های سیستم) است. یوزکیس با مجموعه‌ای از رفتارهایی متناظر است که سیستم امکان دارد در تعامل با بازیگران انجام دهد و نتایج قابل مشاهده‌ای را تولید می‌کند که در اهداف اثرگذار هستند. بازیگران نقشی را بازی می‌کنند که کاربران انسانی یا دیگر سیستم‌ها در برهم‌کنش‌ها با سیستم ایفا می‌کنند. در تحلیل خواسته‌ها، در مرحله شناسایی نیازها، نمودار یوزکیس مطابق با اهداف کاربری خاص نام‌گذاری می‌شود که برای بازیگر اولیه تعیین می‌شود. یوزکیس بعدا با توضیحات متنی یا دیگر مدل‌های گرافیکی، جزئیات بیشتری دریافت می‌کند که توالی عمومی از فعالیت‌ها و رویدادها را شامل مواردی مانند شرایط خاص، استثناها یا شرایط خطا توصیف می‌کند.

مطابق با آنچه در کتاب «بدنه دانش مهندسی نرم‌افزار» (Software Engineering Body of Knowledge | SWEBOK) آمده است، یوزکیس در زمره روش‌های استخراج نیازمندی‌های سناریومحور و همچنین، روش‌های تحلیل مبتنی بر مدل قرار دارد. اما در عین حال، یوزکیس ها از تحصیل خواسته‌های مبتنی بر روایت، تحصیل خواسته‌های افزایشی، مستندسازی سیستم و تست پذیرش (Acceptance Test) نیز پشتیبانی می‌کنند.

انواع یوزکیس

انواع گوناگونی از یوزکیس ها و تنوع در روش‌های ترسیم آن‌ها وجود دارد که در ادامه مطلب یوزکیس دیاگرام چیست مورد بررسی قرار گرفته‌اند. یوزکیس های سیستم، نیازهای سیستمی که قرار است توسعه پیدا کند را تعیین می‌کنند. آن‌ها در توصیفات همراه با جزئیات خود، نه فقط برهم‌کنش‌ها با بازیگران، بلکه سایر موجودیت‌هایی که در این فرایند دخیل هستند را نیز تعیین می‌کنند. یوزکیس ها در واقع نقاط آغازین برای مدل‌های تحلیلی بیشتر و انجام طراحی‌ها هستند.

یوزکیس های تجاری به جای آنکه روی یک سیستم نرم‌افزاری متمرکز شوند، روی سازمان تجاری تمرکز می‌کنند. این یوزکیس ها برای تعیین مدل‌های کسب و کار و نیازمندی‌های فرایند کسب و کار در زمینه نوآوری‌های بازمهندسی فرایند کسب و کار مورد استفاده قرار می‌گیرند.

یوزکیس های اساسی (Essential Use Cases) که به آن‌ها یوزکیس های انتزاعی (Abstract Use Cases) نیز گفته می‌شود، اهداف دقیق بازیگران و چگونگی واکنش سیستم به آن‌ها را بدون تعیین هرگونه توالی یا توصیف یک سناریو، تعیین می‌کنند. این عمل با هدف پشتیبانی از طراحی کاربر محور و اجتناب از تحریک سوگیری پیرامون رابط کاربری در مراحل اولیه مشخصه‌سازی سیستم (System Specification) انجام می‌شود.

یوزکیس ۲.۰ با روش توسعه چابک تطبیق پیدا کرده است. این روش، گردآوری خواسته‌ها را با پشتیبانی از روایت داستان کاربر انجام می‌دهدت. همچنین، «قطعه‌ها» (Slices) یوزکیس هایی را فراهم می‌کنند که تحصیل خواسته‌های افزایشی را تسهیل کرده و امکان پیاده‌سازی افزایشی را فراهم می‌کند.

دامنه

دامنه یک یوزکیس را می‌توان بر اساس موضوع و هدف  پروژه تعیین کرد. این موارد در ادامه تشریح شده‌اند.

• موضوع یوزکیس: موضوع یک یوزکیس، سیستم، زیرسیستم یا مولفه‌هایی را تعریف می‌کند که برهم‌کنش‌ها را تعیین می‌کنند.
• اهداف یوزکیس: اهداف یوزکیس به صورت سلسله‌مراتبی قابل ساختاردهی هستند و سطح علاقه‌مندی سازمانی (سازمان، دپارتمان، کاربر) را برای رسیدن به هدف و تجزیه اهداف کاربر به زیراهداف نشان می‌دهند. تجزیه هدف از نقطه نظر کاربر و به طور مستقل از سیستم انجام می‌شود که از تجزیه عملیات سنتی متمایز است.

کاربرد

یوزکیس ها به دلیل کاربردهایی که در حوزه‌های زیر دارند، بسیار شناخته شده هستند.

• مهندسی نرم‌افزار شی‌گرا (Object Oriented Software Engineering | OOSE) به عنوان یک مولفه پیشران
• زبان مدل‌سازی یکپارچه (Unified Modeling Language | UML) به عنوان یک ابزار مدل‌سازی رفتاری
• فرایند توسعه نرم‌افزار یکپارچه شده (Unified Software Development Process | UP) و پیشران آن، «فرایند یکپارچه گویا» (Rational Unified Process | RUP)
• مستندات مشخصه‌سازی نیازمندی‌های نرم‌افزار (Software Requirement Specification | SRS)، به عنوان یک ساختار جایگزین برای نیازمندی‌های کارکردی
• استنباط طراحی از نیازمندی‌ها با استفاده از رویکرد مرز کنترل موجودیت (Entity Control Boundary)
• توسعه چابک

اشیای نمودار یوزکیس

نمودار یوزکیس شامل ۴ شی است. این چهار شی در ادامه بیان شده‌اند.

• بازیگر
• یوزکیس
• سیستم
• بسته

هر یک از این اشیا در ادامه شرح داده شده‌اند.

بازیگر

بازیگر در نمودار یوزکیس، هر موجودیتی است که نقشی را در سیستم داده شده ایفا می‌کند. بازیگر می‌تواند یک فرد، سازمان یا سیستم خارجی باشد. بازیگر معمولا به صورت شکل زیر در یوزکیس ترسیم می‌شود.

یوزکیس

یوزکیس یا مورد کاربرد، عمل (کارکرد) یا اقدامی را درون سیستم نشان می‌دهد. یوزکیس را با استفاده از یک بیضی نشان می‌دهند و نام گذاری آن با توجه به فعل انجام شده، صورت می‌گیرد.

سیستم

سیستم برای تعریف دامنه یوزکیس مورد استفاده قرار می‌گیرد و با استفاده از یک مستطیل ترسیم می‌شود. سیستم یک مولفه اختیاری در یوزکیس دیاگرام، ولیکن بسیار مفید است. این مورد، به طور خاص هنگام بصری‌سازی سیستم‌های بزرگ بسیار مفید واقع می‌شود. برای مثال، می‌توان همه یوزکیس‌ها را ساخت و سپس، شی سیستم را برای تعریف دامنه پوشش داده شده توسط پروژه مورد استفاده قرار داد.

بسته

بسته (Package) دیگر مولفه دلخواهی است که در یوزکیس دیاگرام های پیچیده بسیار مفید واقع می‌شود. بسته‌ها برای گروه‌بندی کردن یوزکیس ها مورد استفاده قرار می‌گیرند. بسته‌ها در یوزکیس دیاگرام به صورتی که در تصویر زیر نشان داده شده ترسیم می‌شوند.

راهنمای طراحی یوزکیس دیاگرام

اگرچه از یوزکیس دیاگرام ها می‌توان برای اهداف گوناگونی استفاده کرد، ولی اصول و راهنمایی‌هایی وجود دارد که باید در هنگام ترسیم یوزکیس دیاگرام از آن‌ها تبعیت کرد. این راهنمایی‌ها شامل استانداردهای نام‌گذاری، جهت پیکان‌ها، محل قرارگیری یوزکیس ها، استفاده از جعبه‌های سیستم و همچنین، استفاده صحیح از روابط می‌شود. در ادامه، این اصول مورد بررسی قرار گرفته‌اند.

هنگامی که بحث از تحلیل نیازمندی‌های سیستم می‌شود، یوزکیس دیاگرام معمولا همیشه گزینه اول است. یوزکیس دیاگرام ، بصری و معمولا درک آن بسیار ساده است. راهنمایی‌هایی که در ادامه آمده به ترسیم بهتر یوزکیس‌ها کمک می‌کند. یک یوزکیس دیاگرام معمولا شامل بازیگران، یوزکیس ها و روابط بین آن‌ها است. نمودارهای بزرگ‌تر حاوی سیستم و مرزها نیز هستند. در ادامه، اصول طراحی یوزکیس بر اساس شی مورد استفاده در دیاگرام تشریح می‌شوند. باید به خاطر داشت که مواردی که در ادامه بیان می‌شوند صرفا راهنمایی‌هایی برای طراحی یوزکیس هستند و قوانین طراحی آن محسوب نمی‌شوند.

بازیگران

در هنگام ترسیم یوزکیس دیاگرام در نظر داشتن راهنمایی‌های زیر برای ترسیم بازیگران بسیار مفید است.

• برای بازیگران، اسامی معنادار و مرتبط با کسب و کار انتخاب شود. برای مثال، اگر یوزکیس با یک سازمان خارجی تعامل دارد، بهتر است که نام‌گذاری آن با توجه به کارکرد انجام شود؛ نه با استفاده از نام سازمان (مثلا: نام‌گذاری با شرکت هواپیمایی بهتر از آن است که مثلا از نام ماهان یا تورک‌ار استفاده شود.).
• بازیگران اولیه باید در سمت چپ نمودار باشند. این کار، طراح یوزکیس دیاگرام را قادر به آن می‌سازد که نقش‌های مهم در سیستم را به سرعت تشخیص دهد.
• بازیگران نقش‌ها را مدل می‌کنند (نه جایگاه‌ها را)؛ در یک هتل، هم سرپرست دفتر و هم سرپرست شیفت می‌توانند کار رزرو را انجام دهند. بنابراین بهتر است چیزی مانند «مسئول رزرو» (Reservation Agent) برای نام بازیگر انتخاب شود تا نقش آن را مشخص و برجسته کند.
• سیستم‌های خارجی از بازیگران سیستم هستند. برای مثال اگر یوزکیس مربوط به ارسال ایمیل است و در آن نرم‌افزار مدیریت ایمیل وجود دارد، پس نرم‌افزار یک بازیگر برای یک یوزکیس بیان شده است.
• بازیگران با دیگر بازیگران برهم‌کنش ندارند. در کیس‌هایی که بازیگران در سیستم با یکدیگر برهم‌کنش دارند، نیاز به ساخت یک نمودار یوزکیس جدید با سیستم موجود در نمودار پیشین است که در آن، سیستم موجود در نمودار پیشین به عنوان یک بازیگر خواهد بود.
• قرار دادن بازیگران ارث‌بری شده در زیر بازیگر والد قابل انجام است. این کار برای قابل خواندن‌تر کردن و برجسته کردن سریع مشخصه‌های یوزکیس برای بازیگر انجام می‌شود.

نکات کلی که برای رسم بازیگر در یوزکیس دیاگرام باید به خاطر داشت:

• شخصی است که با یوزکیس برهم‌کنش دارد (کارکرد سیستم).
• نام‌گذاری با اسامی انجام می‌شود.
• بازیگر نقشی در کسب و کار ایفا می‌کند.
• مشابه با مفهوم کاربر است، اما یک کاربر می‌تواند نقش‌های متفاوتی داشته باشد؛ برای مثال: یک استاد دانشگاه می‌تواند معلم و در عین حال پژوهشگر باشد.
• دو نقش با دو سیستم بازی می‌کند.
• بازیگر، محرک یوزکیس (ها) است.
• بازیگر مسئولیتی پیرامون سیستم (ورودی‌ها) دارد و در عین حال، انتظاراتی نیز از سیستم دارد (خروجی‌ها).

یوزکیس ها

در هنگام ترسیم یوزکیس دیاگرام در نظر داشتن راهنمایی‌های زیر برای ترسیم یوزکیس ها بسیار مفید است.

• نام یوزکیس‌ها باید با یک فعل شروع شود. یک یوزکیس یک اقدام را مدل‌سازی می‌کند؛ بنابراین نام باید با یک فعل شروع شود.
• نام یوزکیس را باید توصیفی گذاشت. دلیل این امر آن است که اطلاعات بیشتری برای افرادی ارائه شود که به یوزکیس دیاگرام نگاه می‌کنند. برای مثال، «چاپ فاکتور» (Print Invoice) بهتر از «چاپ» (Print) است.
• ترتیب منطقی باید برجسته شود. برای مثال، اگر یک مشتری موردتحلیل است، یک یوزکیس دیاگرام معمول شامل حساب بانکی فعال، واریز و برداشت می‌شود. نشان دادن این موارد در یک ترتیب منطقی، معنادارتر است.
• قرار دادن یوزکیس‌های Include شده در سمت راست یوزکیس موجود به افزایش خوانایی و افزایش شفافیت، کمک می‌کند.
• قرار دادن یوزکیس ارث‌بری شده زیر یوزکیس والد به افزایش خوانایی نمودار کمک می‌کند.

نکات کلی که برای رسم یوزکیس در یوزکیس دیاگرام باید به خاطر داشت:

• کارکرد سیستم (فرایند-خودکار شده یا دستی)
• نام‌گذاری شده با افعال (یا عبارات اسمی)
• انجام دادن کاری
• هر بازیگر باید به یک یوزکیس متصل شود؛ در حالی که برخی از یوزکیس ها ممکن است به بازیگرها متصل نشده باشند.

روابط

در هنگام ترسیم یوزکیس دیاگرام در نظر داشتن راهنمایی‌های زیر برای ترسیم روابط بسیار مفید است.

• پیکان در هنگام استفاده از <<extend>> به یوزکیس مبنا اشاره داشته باشد.
• <<extend>> می‌تواند شرایط بسط اختیاری داشته باشد.
• هنگام استفاده از <<include>>، پیکان به یوزکیس include شده اشاره داشته باشد.
• هم <<extend>> و هم <<include>> به صورت پیکان‌های خط‌چین نمایش داده شوند.
• رابطه بازیگر و یوزکیس، جهت‌نماها را نشان نمی‌دهد.

نکات کلی که برای رسم روابط در یوزکیس دیاگرام باید به خاطر داشت:

• مشارکت یک بازیگر در یوزکیس با اتصال یک بازیگر به یک یوزکیس با یک اتصال سخت نمایش داده می‌شود.
• بازیگران ممکن است با تخصیص اتصالاتی به یوزکیس مرتبط شوند که ارتباط بین یوزکیس و بازیگر را با یکدیگر با پیام ها نمایش می‌دهد.

سیستم‌ها/بسته‌ها

در هنگام ترسیم یوزکیس دیاگرام در نظر داشتن راهنمایی‌های زیر برای ترسیم سیستم‌ها/بسته‌ها بسیار مفید است.

• به ندرت و تنها در صورت لزوم از آن‌ها استفاده شود.
• اسامی معنادار و توصیفی به این اشیا داده شود.

نکات کلی که برای رسم سیستم در یوزکیس دیاگرام باید به خاطر داشت:

• مرزهای سیستم به طور بالقوه کل سیستم هستند و در سند نیازمندی‌ها تعریف شده است.
• برای سیستم‌های بزرگ و پیچیده، هر ماژولی ممکن است مرزهای سیستم باشد. برای مثال، در یک سیستم مدیریت منابع سازمانی (Enterprise Resource Planning | ERP) یک سازمان، هر ماژول مانند پرسنل، حقوق و دستمزد، حسابداری و دیگر موارد هر یک مرزهای سیستم هستند.
• می‌توان مرزهای سیستم را برای مشخصه یوزکیس برای هر یک از این کارکردهای کسب و کار شکل داد.
• کل سیستم می‌تواند همه این ماژول‌ها را گسترش دهد و مرزهای کلی سیستم را به تصویر بکشد.

سایر اصول و راهنمایی‌ها برای طراحی یوزکیس

در این بخش از مطلب یوزکیس دیاگرام چیست برخی از مهم‌ترین و متداول‌ترین اصول و راهنمایی‌ها برای ترسیم یوزکیس دیاگرام بیان شد. این در حالی است که در کنار این اصول عمومی، هر سازمانی متناسب با شرایط خود می‌تواند اصول، استانداردها و حتی قوانینی برای ترسیم یوزکیس دیاگرام داشته باشد که به تسهیل فعالیت‌های مرتبط در آن سازمان کمک کند.

آموزش ترسیم یوزکیس دیاگرام

تا این لحظه،‌ مفههوم شی، رابطه و اصولی که هنگام ترسیم یوزکیس به آن‌ها نیاز است مورد بررسی قرار گرفتند. در ادامه، فرایندهای گوناگون با استفاده از مثال سیستم بانکی، بیان خواهد شد.

شناسایی بازیگران

بازیگران، موجودیت‌های خارجی هستند که با سیستم تعامل دارند. بازیگر می‌تواند یک فرد، سیستم دیگر یا سازمان باشد. در سیستم بانکداری، واضح‌ترین بازیگر مشتری بانک است. دیگر بازیگران می‌توانند کارکنان بانک یا صندوق‌دارها، بسته به نقشی (Role) باشند که قصد نمایش آن در یوزکیس وجود دارد. مثالی از یک سازمان خارجی می‌تواند اداره امور مالیاتی یا بانک مرکزی باشد. پردازشگر وام بانکی مثال خوبی از یک سیستم خارجی است که مانند یک بازیگر به سیستم تخصیص یافته است.

اغلب، افراد شروع فرآیند تحصیل خواسته‌ها با شناسایی بازیگران را کاری ساده می‌پندارند. پرسش‌های زیر می‌تواند به افراد در پیدا کردن بازیگران سیستم کمک کند. این لیست را اشنایدر (Schneider) و وینترز (Winters) در سال ۱۹۹۸ ارائه کرده‌اند که همچنان بسیار کاربردی است.

• چه کسی از سیستم استفاده می‌کند؟
• چه کسی سیستم را نصب می‌کند؟
• چه کسی سیستم را راه‌اندازی می‌کند؟
• چه کسی سیستم را نگهداری می‌کند؟
• چه کسی سیستم را خاموش می‌کند؟
• چه سیستم‌های دیگری از این سیستم استفاده می‌کند؟
• چه کسی از سیستم اطلاعات دریافت می‌کند؟
• چه کسی برای سیستم اطلاعات فراهم می‌کند؟
• آیا چیزی به صورت خودکار در زمان حال حاضر به وقوع می‌پیوندد؟

شناسایی یوزکیس‌ها

اکنون زمان شناسایی یوزکیس ها رسیده است. یک راهکار خوب برای انجام این کار شناسایی آن است که بازیگر چه خواسته‌ای از سیستم دارد. در سیستم بانکی، مشتری نیاز به باز کردن حساب، واریز یا برداشت وجه، درخواست دسته چک و دیگر کارکردهای مشابه را دارد.

یوزکیس های سطح بالا باید همیشه یک کارکرد کامل را فراهم کنند که توسط کاربر مورد نیاز است. می‌توان یوزکیس ها را بسته به پیچیدگی سیستم گسترش داد و یا include کرد. هنگامی که طراح یوزکیس دیاگرام، بازیگران و یوزکیس سطح بالا را شناسایی می‌کند، دیدگاهی اولیه از چیستی سیستم به دست می‌آورد. اکنون، می‌توان یوزکیس دیاگرام را به خوبی تنظیم کرد و لایه‌های دیگری از جزئیات را به آن افزود.

جستجو برای عملیات متداول برای استفاده از Include

طراح یوزکیس دیاگرام باید به جستجو برای عملیات (کارکردهای) متداولی بپردازد که در سرتاسر سیستم مورد استفاده قرار می‌گیرند. اگر دو یا تعداد بیشتری یوزکیس پیدا شود که کارکردهای مشابهی دارند، می‌توان کارکردهای مشابه را استخراج و آن‌ها را به یک یوزکیس مجزا اضافه کرد. سپس، می‌توان آن را با include کردن رابطه متصل کرد تا مشخص شود که این یوزکیس همیشه هنگامی فراخوانی می‌شود که یوزکیس اصلی اجرا شده است.

وجود امکان تعمیم بازیگران و یوزکیس ها

نمونه‌هایی وجود دارد که در آن بازیگران گوناگون با یوزکیس مشابهی مرتبط هستند و در عین حال، برخی از آن‌ها یوزکیس‌هایی را فراخوانی می‌کنند که تنها به خود آن‌ها مرتبط هستند. می‌توان کار مشابهی را برای یوزکیس ها نیز انجام داد. یکی از بهترین مثال‌ها در این رابطه، یوزکیس «Make Payment» در سیستم پرداخت است. می‌توان این یوزکیس را بعدا به Pay by Credit Card ،Pay by Cash ،Pay by Check و دیگر موارد تعمیم داد. همه این‌ها دارای خصیصه‌ها و کارکردهای پرداخت با سناریوهای اختصاصی خود هستند.

شناسایی یوزکیس و سپس، فرایند استخراج خواسته‌های مبتنی بر سناریو با پرسیدن اینکه چه چیزی به صورت خارجی قابل مشاهده است و مقادیر قابل مشاهده‌ای انجام می‌شود که هر بازیگر آن را می‌خواهد. هنگامی که بازیگران شناسایی شدند، پرسش‌های زیر برای شناسایی یوزکیس ها مورد استفاده قرار می‌گیرد. این لیست از پرسش‌ها را نیز اشنایدر و ویتنرز در سال ۱۹۹۸ ارائه کرده‌اند.

• بازیگر از سیستم چه کارکردی را می‌خواهد؟
• آیا سیستم اطلاعات را ذخیره می‌کند؟ بازیگران چه چیزهایی را می‌سازند، می‌خوانند، به روز رسانی و یا حذف می‌کنند؟
• آیا سیستم نیاز به آگاه کردن یک بازیگر از تغییرات داخلی سیستم دارد؟
• آیا رویدادهای خارجی وجود دارند که سیستم باید پیرامون آن‌ها اطلاعی داشته باشد؟ کدام بازیگر، سیستم را از این رویدادها آگاه می‌کند؟

شناسایی روابط

پنج نوع از روابط در یوزکیس دیاگرام وجود دارد. این روابط عبارتند از:

• ارتباط بین یک بازیگر و یوزکیس
• تعمیم یک بازیگر
• گسترش (Extend) رابطه بین دو یوزکیس
• رابطه شمول (Include) بین دو یوزکیس
• تعمیم یک یوزکیس

کارکردهای اختیاری یا کارکردهای افزوده

کارکردهایی وجود دارد که به صورت اختیاری راه‌اندازی می‌شوند. در این شرایط، می‌توان رابطه را گسترش داد و یک قاعده Extend را به آن ضمیمه کرد. در مثال سیستم بانکداری، محاسبه سود اختیاری است و تنها زمانی انجام می‌شود که شرایط خاصی برآورده شده باشد.

البته، این بدین معنا نیست که Extend همیشه اختیاری است. گاهی یوزکیس متصل شده با استفاده از (Extend) می‌تواند مکمل یوزکیس مبنا باشد. چیزی که باید به خاطر داشت این است که یوزکیس مبنا باید قادر باشد تا یک کارکرد را به خودی خود انجام دهد؛ حتی اگر یوزکیس بسط پیدا کرده فراخوانی نشود. یک شکل استاندارد از یوزکیس دیاگرام در زبان مدل‌سازی یکپارچه (UML) به صورتی است که در یوزکیس دیاگرام زیر وجود دارد.

روابط در نمودار یوزکیس

هنگامی که صحبت از ترسیم یوزکیس دیاگرام می‌شود، یک حوزه که ممکن است محل بحث باشد، نمایش روابط در نمودار یوزکیس است. یوزکیس ها اشکال مختلفی از روابط را به اشتراک می‌گذارند. تعریف روابط بین دو یوزکیس تصمیم تحلیل‌گر سیستم از نمودار یوزکیس است. رابطه بین دو یوزکیس اساسا مدل‌سازی وابستگی بین دو یوزکیس است. استفاده از یک یوزکیس موجود با استفاده از انواع گوناگونی از روابط، تلاش کلی مورد نیاز برای توسعه سیستم را کاهش می‌دهد.

در حقیقت، بسیاری از افراد سه نوع رابطه <<extend>> ،<<include>> و تعمیم (Generalization) را با یکدیگر اشتباه می‌گیرند. در این مقاله نگاهی به انواع نمودارهای یوزکیس همراه با جزئیات انداخته شده است و انواع روابط همراه با مثال‌هایی تشریح شده‌اند. پنج نوع رابطه در نمودارهای یوزکیس قابل نمایش است.

• انجمن بین بازیگر و یوزکیس
• تعمیم یک بازیگر
• گسترش رابطه بین دو یوزکیس
• Include بین دو یوزکیس
• تعمیم یک یوزکیس

در ادامه، هر یک از این نوع روابط همراه با جزئیات تشریح خواهند شد.

پیوند بین بازیگر و یوزکیس

پیوند بین بازیگر و یوزکیس (Association Link) یک نوع رابطه بسیار ساده است و در هر یوزکیس دیاگرامی می‌توان آن را مشاهده کرد. برخی از مواردی که پیرامون این نوع رابطه در یوزکیس دیاگرام می‌توان اشاره کرد در ادامه بیان شده‌اند.

• یک بازیگر باید با حداقل یک یوزکیس انجمن داشته باشد.
• یک بازیگر را می‌تواند با چند یوزکیس انجمن کرد.
• چندین بازیگر را می‌توان با یک یوزکیس تنها انجمن کرد.

 

تعمیم یک بازیگر

تعمیم بازیگر (Generalization of an Actor) بدان معنا است که یک بازیگر می‌تواند نقش دیگر بازیگران را به ارث ببرد. نوادگان، همه یوزکیس‌های اجداد خود را به ارث می‌برند. نوادگان یک یا تعداد بیشتری یوزکیس دارند که برای آن نقش مشخصه‌سازی شده است. اکنون می‌توان یوزکیس دیاگرام را برای نمایش تعمیم یک بازیگر ساخت.

گسترش رابطه بین دو یوزکیس

بسیاری از افراد پیرامون نوع رابطه extend در یوزکیس ها دچار سردرگمی می‌شوند. چنانکه از نام این یوزکیس مشخص است، این یوزکیس موجب گسترش یوزکیس مبنا می‌شود و کارکردهای بیشتری را به سیستم اضافه می‌کند.

در ادامه نکاتی بیان شده‌اند که باید هنگام استفاده از رابطه <<extend>> در نظر داشت.

• extend یوزکیس بستگی به یوزکیس بسط یافته (Extended) دارد. در نمودار زیر، یوزکیس «Calculate Bonus» بدون یوزکیس «Deposit Funds» فاقد معنا است.
• یوزکیس گسترش یافته معمولا اختیاری است و می‌توان آن را بسته به شرایط راه‌اندازی کرد. در نمودار، می‌توان مشاهده کرد که یوزکیس بسط یافته تنها برای سپرده‌های بیش از 10,000 یا سن بالاتر از ۵۵ است.
• یوزکیس بسط یافته باید به تنهایی معنادار باشد. این یعنی یوزکیس بسط یافته باید مستقل باشد و نباید به رفتار یوزکیسی که بسط پیدا کرده است وابسته باشد.

در یوزکیس دیاگرام زیر، مثال کنونی برای <<extend>> رابطه نمایش داده شده است.

اگرچه، بسط یوزکیس یک کار دلخواه است، اما معمولا نباید این کار را انجام داد. یک یوزکیس بسط یافته می‌تواند رفتار غیراختیاری داشته باشد. این مورد معمولا هنگام مدل‌سازی رفتارهای پیچیده به وقوع می‌پیوندد. برای مثال، در یک سیستم حسابداری، یک یوزکیس ممکن است «Add Account Ledger Entry» باشد. یوزکیس مذکور ممکن است یک یوزکیس بسط یافته «Add Tax Ledger Entry» و «Add Payment Ledger Entry» داشته باشد. این موارد اختیاری نیستند، اما بستگی به ورودی دفتر حساب (Account Ledger Entry) دارند. همچنین، آن‌ها رفتار خاص خود را دارند که به عنوان یک یوزکیس جدا مدل‌سازی می‌شود. شایان توجه است که استریوتایپ <<extends>> نشانگر یک رابطه extend است.

رابطه Include بین دو یوزکیس

رابطه Include نشان می‌دهد که رفتار یوزکیس include شده بخشی از یوزکیس including (مبنا) است. دلیل اصلی این موضوع استفاده مجدد از عملیات متداول (تکراری) در سرتاسر یوزکیس‌ها استفاده شود. در برخی از موارد، این کار برای ساده کردن رفتارهای پیچیده مورد استفاده قرار می‌گیرد. تنها چند نکته وجود دارد که هنگام استفاده از رابطه <<include>> در یوزکیس دیاگرام باید در نظر داشت. این موارد در ادامه بیان شده‌اند.

• یوزکیس مبنا ناقص و بدون یوزکیس include شده است.
• یوزکیس include شده اجباری است و اختیاری محسوب نمی‌شود.

در ادامه، دیاگرام سیستم بانکداری برای نمایش رابطه Include نمایش داده شده است.

نکاتی که باید به صورت کلی پیرامون رابطه include در یوزکیس دیاگرام در نظر داشت در ادامه بیان شده است.

• هنگامی که یک یوزکیس به عنوان استفاده از کارکرد دیگر یوزکیس به تصویر کشیده شد، رابطه بین یوزکیس ها با عنوان include یا رابطه شمول نام‌گذاری می‌شود.
• یک یوزکیس شامل کارکرد توصیف شده در دیگر یوزکیس به عنوان بخشی از جریان فرایند کسب و کار آن است.
• یک رابطه استفاده شده از یوزکیس مبنا به یوزکیس فرزند نشان می‌دهد که یک نمونه از یوزکیس مبنا شامل رفتار به صورت تعیین شده در یوزکیس فرزند است.
• یک رابطه Include با یک جهت‌نمای مستقیم به تصویر کشیده می‌شود که دارای خط‌چین است. نوک پیکان جهت‌نما به یوزکیس فرزند اشاره دارد و یوزکیس والد به مبنای جهت‌نما متصل است.
• استریوتایپ <<include>> رابطه را به صورت یک رابطه include تعریف می‌کند.

تعمیم یوزکیس

این کار مشابه با تعمیم یک بازیگر است. رفتار اجداد یک بازیگر توسط نوادگان به ارث برده می‌شود. این مورد هنگامی استفاده می‌شود که یک رفتار متداول بین دو یوزکیس وجود داشته باشد و همچنین، رفتار ویژه‌ای وجود داشته باشد که به هر یوزکیس اختصاص دارد.

برای نمونه در مثال بانکداری پیشین، یک یوزکیس وجود دارد که به آن «Pay Bills» گفته می‌شود. این مورد را می‌توان به «Pay by Credit Card» و «Pay by Bank Balance» تعمیم داد. نکاتی که باید به صورت کلی پیرامون تعمیم در یوزکیس دیاگرام در نظر داشت در ادامه بیان شده است.

• یک رابطه تعمیم، یک رابطه والد-فرزند بین یوزکیس ها است.
• یوزکیس فرزند، یک نسخه بهبود و ارتقا یافته از والد است.
• عمومی‌سازی به صورت یک جهت‌نمای مستقیم که پیکان آن یک مثلث تو خالی است انجام می‌شود.
• یوزکیس فرزند در مبنای جهت‌نما متصل می‌شود. نوک پیکان جهت‌نما به یوزکیس والد متصل است.

ابزارهای موجود برای ترسیم یوزکیس

ویرایشگرها و یا پردازشگرهای متن دارای پشتیبانی از الگوهای یوزکیس، اغلب برای نوشتن یوزکیس مورد استفاده قرار می‌گیرند. برای خواسته‌های یک سیستم بزرگ و پیچیده، ابزارهای اختصاصی طراحی یوزکیس دیاگرام گزینه‌های مناسبی محسوب می‌شوند. برخی از ابزارهای طراحی یوزکیس محبوب و شناخته شده در ادامه بیان شده اند.

• کیس کامپلکس (Case Complex)
• انترپرایز آرکیتکت (Enterprise Architect)
• مجیک دراو (MagicDraw)
• نرم‌افزارهای رشنال پرکوئست‌پرو (PrequistiePro) (یکی از از ابزارهای اولیه و شناخته شده برای مدیریت نیازها و یوزکیس در دهه ۱۹۹۰)
• مدل‌ساز ایده‌های نرم‌افزاری (Rational Software's RequisitePro)

اغلب ابزارهای زبان مدل‌سازی یکپارچه (UML)، هم از نوشتن متن و هم از مدل‌سازی بصری یوزکیس ها پشتیبانی می‌کنند.

یوزکیس در کسب و کار

به روش مشابهی که یوزکیس یک مجموعه از رویدادها و تعاملات بین کاربر و سیستم یا دیگر بازیگران را توصیف می‌کند، به منظور تولید نتیجه یک ارزش (هدف)، یک یوزکیس کسب و کار، تعامل عمومی‌تری بین یک سیستم کسب و کار و کاربر/بازیگر آن سیستم را برای تولید نتایج یک مقدار ارائه می‌کند. تفاوت اولیه آن است که سیستم در نظر گرفته شده در یک مدل یوزکیس کسب و کار، ممکن است علاوه بر سیستم‌های تکنولوژیکی شامل افرادی از کسب و کار نیز باشد. افراد درون سیستم را کارکنان کسب و کار می‌گویند.

در مثال یک رستوران، تصمیمی که باید گرفته شود آن است که با هر فرد به عنوان یک بازیگر برخورد شود (بدین ترتیب بیرون از سیستم) یا یکی از کارکنان کسب و کار (درون سیستم) است. اگر یک پیش‌خدمت به عنوان یک بازیگر در نظر گرفته شود، چنانکه در مثال زیر نمایش داده شده است، سیستم رستوران شامل پیش‌خدمت نمی‌شود و مدل، تعامل بین پیش‌خدمت و رستوران را نمایش می‌دهد. یک جایگزین آن است که پیش‌خدمت به عنوان بخشی از سیستم رستوران در نظر گرفته شود (یکی از کارکنان کسب و کار)، در حالی که مشتری به عنوان فردی خارج از سیستم در نظر گرفته می‌شود (یک بازیگر).

نکاتی پیرامون یوزکیس دیاگرام

در ادامه، نکاتی پیرامون چگونگی اعمال یوزکیس به طور موثر روی پروژه‌های نرم‌افزاری بیان شده است.

• همیشه باید ساختاردهی و سازمان‌دهی نمودار یوزکیس از چشم‌انداز کاربران انجام شود.
• یوزکیس‌ها باید به سادگی آغاز به کار کنند و بالاترین نما ممکن باشد. تنها در این حالت است که آن‌ها پالایش می‌شوند و جزئیات بیشتری به آن‌ها اضافه می‌شود.
• نمودارهای یوزکیس بر مبنای کارکرد هستند و باید روی «What» متمرکز باشند، نه روی How.

سطوح جزئیات یوزکیس

دانه‌بندی یوزکیس به روشی اشاره دارد که در آن اطلاعات در مشخصه‌سازی سیستم سازمان‌دهی شده‌اند و در برخی از موارد، به سطح جزئیاتی اشاره دارد که آن‌ها نوشته شده‌اند. دست‌یابی به سطح درستی از دانه‌بندی یوزکیس، ارتباط بین ذینفعان و توسعه‌دهندگان را تسهیل می‌کند و برنامه‌ریزی پروژه را ارتقا می‌دهد. آلیستر کاکبورن در کتاب «نوشتن یوزکیس‌های موثر» (Writing Effective Use Cases) یک راهکار ساده برای بصری‌سازی سطوح گوناگون یوزکیس از سطح هدف را با فکر کردن به اصطلاحات دریا به دست می‌دهد. این اصطلاحات به همراه سمبل بصری آن‌ها در جدول زیر آورده شده است.

در راستای آنچه پیرامون سطوح جزئیات در یوزکیس دیاگرام بیان شد، باید به نکات زیر نیز توجه داشت.

• هنگامی که یک یوزکیس به جزئیات بسیار زیاد و هر احتمالی می‌پردازد، یک نمودار یوزکیس برای سطح بالاتری از سیستم و به صورت یک بلوپرینت استفاده می‌شود.
• نوشتن یوزکیس‌ها در سطح بالاتر از دانه‌بندی همراه با جزئیات کمتر در صورتی که نیاز به جزئیات نباشد، سودمند است.

قالب‌های گوناگون ترسیم یوزکیس

راهکارهای زیادی برای نوشتن یک یوزکیس، از متن (Text) گرفته تا چکیده یوزکیس (Use Case Brief)، تکه تکه (Casual)، رئوس مطالب (Outline) تا نسخه کامل (Fully Dressed)، با تمپلیت‌های متنوع وجود دارد. نوشتن یوزکیس در قالب‌ها توسط فروشندگان یا کارشناسان متعدد یک فعالیت متداول صنعتی برای تحصیل نیازمندی‌های سیستمی با کیفیت بالا است.

استایل کاکبورن

قالب Cockburn توسط آلیستر کاکبورن در کتاب او با نام «نوشتن بررسی‌های موردی موثر» (Writing Effective Use Cases) معرفی شده و یکی از پر استفاده‌ترین استایل‌های یوزکیس است.

دامنه‌های طراحی

کاکبورن پیشنهاد می‌کند که حاشیه‌نویسی برای هر یوزکیس با سمبل‌هایی برای نمایش «دامنه طراحی» (Design Scope) انجام شود که ممکن است یک جعبه سیاه (جزئیات داخلی پنهان باشند) یا یک جعبه سفید باشد (جزئیات داخلی نمایش داده شوند). پنج نماد برای این کار وجود دارند که در جدول زیر نمایش داده شده‌اند.

دیگر مولفان گاهی به یوزکیس های در سطح سازمانی (Organization Level)، یوزکیس در سطح کسب و کار (Business Use Cases) می‌گویند.

سطح هدف

کاکبورن پیشنهاد می‌کند که حاشیه‌نویسی هر مورد کاربرد با یک سمبل برای نمایش «سطح هدف» انجام شود. سطح ترجیح داده شده، «User Goal» است که به آن «سطح دریا» (Sea Level) نیز گفته می‌شود. گاهی در نگارش متن، نام یک یوزکیس با یک متن جایگزین دنبال می‌شود (! ،+، - و دیگر موارد) که راهی دقیق‌تر و راحت‌تر برای نمایش سطوح است. این موارد در جدول زیر ارائه شده است.

کاملا پوشش‌دهی شده

کاکبورن یک ساختار همراه با جزئیات بیشتر را برای یوزکیس توصیف می‌کند، اما اجازه می‌دهد که هنگامی که جزئیات کمتری مورد نیاز است ساده شود.

تمپلیت یوزکیس کاملا پوشش‌دهی شده، فیلدهای زیر را لیست می‌کند.

• عنوان: یک عبارت هدف فعل-فاعل که هدف از بازیگر اصلی را نام‌گذاری می‌کند.
• بازیگر اصلی
• هدف در زمینه
• دامنه
• سطح
• ذینفعان و علاقه‌مندی‌ها
• پیش‌شرط
• ضمانت مینیمال
• ضمانت موفقیت
• تریگر (راه‌انداز | محرک)
• سناریو موفقیت اصلی
• افزونه‌ها
• فناوری و لیست تنوع داده

علاوه بر آن، کاکبورن استفاده از دو دستگاه را برای نشان دادن ماهیت هر یوزکیس پیشنهاد می‌کند: آیکون‌ها برای طراحی دامنه و سطح هدف. رویکرد کاکبورن دیگر مولفان را تحت تاثیر قرار می‌دهد. برای مثال، الکساندر (Alexander) و بئوس دوکیک (Beus-Dukic) قالب یوزکیس کاملا پوشش‌دهی شده کاکبورن را از نرم‌افزار به سیستم‌هایی از هر نوع، تعمیم داده‌اند. فیلدهای متفاوت این قالب با قالب کاکبورن در ادامه بیان شده‌اند.

• سناریوهای تنوع (ممکن است از سناریو اصلی منشعب شده باشد و ممکن است به سناریو اصلی بازگردد)
• استثناها (برای مثال، رویدادها و سناریوهای مدیریت استثناهای آن‌ها)

کژوال

کاکبورن تشخیص داده است که ممکن است پروژه‌ها همیشه یوزکیس‌هایی با جزئیات «کاملا پوشش‌دهی شده» نداشته باشند. از این رو، او یک یوزکیس کژوال با فیلدهای زیر را توصیف می‌کند.

• عنوان (هدف)
• بازیگر اصلی
• دامنه
• سطح
• داستان: بدنه یوزکیس به سادگی یک پاراگراف یا دو خط متن است که به طور غیر رسمی، آنچه به وقوع می‌پیوندد را توصیف می‌کند.

 استایل فولر

مارتین فولر (Martin Fowler) چنین بیان می‌کند که «هیچ استانداردی برای نوشتن محتوای یک یوزکیس وجود ندارد و فرمت‌های گوناگون در کیس‌های گوناگون عملکرد خوبی دارند». او یک استایل متداول را برای استفاده به صورت زیر توصیف می‌کند:

• عنوان: هدف یوزکیس که سعی در ارضای آن وجود دارد.
• سناریو موفقیت اصلی: لیست شماره‌گذاری شده مراحل
  • گام: یک دستور ساده از برهم‌کنش بین بازیگر و یک سیستم
• افزونه‌ها: لیست‌های به طور جداگانه شماره‌گذاری شده، یکی به ازای هر افزونه
  • افزونه: شرایطی که منجر به نتایج مختلف از سناریوهای موفقیت گوناگون می‌شود. یک افزونه از گام اصلی ۳ که به صورت 3A شماره‌گذاری شده است.

استایل فولر را می‌توان به عنوان یک نوع ساده شده از الگوی کاکبورن دید.

مثال‌هایی از یوزکیس

در ادامه مثال‌هایی پیرامون یوزکیس دیاگرام ارائه شده است. این یوزکیس دیاگرام ها از متداول‌ترین انواع یوزکیس دیاگرام ها هستند که در مسائل مورد بررسی قرار می‌گیرند.

یوزکیس دیاگرام ویرایش مقاله

آنچه در ادامه آمده است، یک یوزکیس نمونه و بسیار ساده برای ویرایش مقاله توسط کاربر است. این یوزکیس دیاگرام ویرایش مقاله با نسخه به شدت ویرایش شده از الگوی کاکبورن استایل ترسیم شده است. شایان توجه است که هیچ دکمه، کنترل، فرم و یا دیگر عناصر رابط کاربری در این یوزکیس دیاگرام وجود ندارد. در یوزکیس دیاگرام ویرایش مقاله زیر تنها اهداف و زیراهداف کاربر در هر گام از افزونه یا جریان پایه‌ای وجود دارد. این اقدامات مشخصه‌سازی خواسته‌ها را شفاف‌تر می‌کند و انعطاف‌پذیری طراحی و پیاده‌سازی را حداکثری می‌سازد.

یوزکیس: ویرایش یک مقاله

• بازیگر اصلی: عضو (یک عضو ثبت شده)
• دامنه: یک سیستم ویکی
• سطح: ! (هدف کاربر یا سطح دریا)
• چکیده:  (برابر با داستان کاربر یا یک روایت)
  • عضو هر بخشی از مقاله‌ای را که مطالعه می‌کند، ویرایش می‌کند (کل مقاله یا تنها یک بخش). مقایسه پیش‌نمایش و تغییرات در طول ویرایش امکان‌پذیر است.
• ذینفعان: ...
• شرایط ثانویه
  • ضمانت کمینه:
  • ضمانت موفقیت:
    • مقاله ذخیره می‌شود و نمایش به‌روزرسانی شده به تصویر کشیده می‌شود.
    • یک رکورد ویرایش برای مقاله توسط سیستم ساخته می‌شود. بنابراین، مشاهده کنندگان مقاله بعدا از به‌روزرسانی‌ها با خبر خواهند شد.
• پیش‌شرط‌ها
  • مقاله با قابلیت فعال ویرایش به اعضا نمایش داده می‌شود.
• پیش‌ران‌ها
  • عضو درخواست ویرایش مقاله را (برای کل مقاله یا تنها یک بخش از آن) می‌کند.
• جریان پایه‌ای
  1. سیستم یک ناحیه/جعبه ویرایشگر جدید را فراهم می‌کند که با محتوای همه مقالات مرتبط و با یک خلاصه اطلاعاتی برای ویرایش توسط کاربر، تکمیل شده است. اگر عضو تنها قصد ویرایش یک بخش از مقاله را داشته باشد، تنها محتوای اصلی از آن بخش نمایش داده می‌شود. در عین حال، عنوان بخش به طور خودکار در خلاصه ویرایش تکمیل شده است.
  2. عضو، محتوای مقاله را تا هنگامی که رضایت داشته باشد ویرایش می‌کند.
  3. عضو، خلاصه ویرایش را تکمیل می‌کند و به سیستم می‌گوید که آیا کاربر می‌خواهد این مقاله را بخواند و ویرایش‌ها را اعمال کند.
  4. عضو، محتوای مقاله را تا هنگامی که رضایت داشته باشد ویرایش می‌کند.
  5. عضو، خلاصه ویرایش را تکمیل می‌کند و به سیستم می‌گوید.
  6. عضو، محتوای مقاله را تا هنگام رضایت‌مندی تکمیل می‌کند.
  7. سیستم، مقاله را ذخیره می‌کند، رویداد ویرایش را در سوابق ثبت می‌کند و هر ویرایش مطلب لازمی را به پایان می‌رساند.
  8. سیستم، مقاله را ذخیره، سوابق رویداد ویرایش را ثبت و هر فرایند لازمی برای مطلب را به پایان می‌رساند.
  9. سیستم، نمایش به روز رسانی شده از مقاله را برای عضو به نمایش می‌گذارد.
• افزونه‌ها‌
  • به تصویر کشیدن پیش‌نمایش

1. 1. 1. عضو، گزینه پیش‌نمایش را انتخاب می‌کند که موجب اعمال محتوای ویرایش شده می‌شود.
      2. سیستم، گام ۱ را با افزودن محتوای رندر شده به‌روزرسانی شده برای پیش‌نمایش، بازاجرا می‌کند و به عضو اطلاع می‌دهد که ویرایش‌های او تاکنون ذخیره نشده است و سپس ادامه می‌دهد.

• • نمایش تغییرات

1. 1. 1. عضو، نمایش تغییرات را انتخاب می‌کند که محتوای ویرایش شده را اعمال می‌کند.
      2. سیستم، گام ۱ را با افزودن نمایش نتایج مقایسه تفاوت‌ها بین ویرایش کنونی توسط کاربر و نسخه اخیر چاپ شده توسط کاربر دوباره اجرا می‌کند و سپس، ادامه می‌دهد.

• • لغو کردن ویرایش

1. 1. 1. عضو گزینه لغو ویرایش را انتخاب می‌کند (Cancel).
      2. سیستم هر نوع تغییری را که کاربر انجام داده لغو می‌کند و سپس به گام پنجم می‌رود.

• زمان به پایان می‌رسد.

یوزکیس دیاگرام انتشار کتاب

این نمودار یوزکیس یک ارائه بصری از فرایند مورد نیاز برای نوشتن و انتشار یک کتاب است. صرف‌نظر از اینکه فرد یک مولف، یک عامل یا یک فروشنده کتاب است، قرار دادن این نمودار در سناریو یوزکیس می‌تواند به تیم در انتشار کتاب بعدی کمک کند.

یوزکیس دیاگرام رزرو قطار

می‌توان از این تمپلیت برای هر فرایندی استفاده کرد که طی آن خرید خدمات توسط یک مشتری به وقوع می‌پیونند. با شماهای رنگی جذاب، متنی که خواندن و نوشتن آن آسان است و یک طیف گسترده از کتابخانه اشکال UML که در نرم‌افزارهای مختلف موجود است، می‌توان به راحتی نمودار یوزکیس را بسط داد.

یوزکیس دیاگرام وب‌سایت

نمودار زیر، یوزکیس دیاگرام وب‌سایت را نشان می‌دهد.

یوزکیس دیاگرام فروشگاه آنلاین

نمودار زیر، یوزکیس دیاگرام فروشگاه آنلاین را نشان می‌دهد.

یوزکیس دیاگرام لاگین شدن دانش‌آموز

نمودار زیر، یوزکیس دیاگرام لاگین شدن دانش‌آموز را نشان می‌دهد.

یوزکیس دیاگرام رستوران

نمودار زیر، یوزکیس دیاگرام رستوران را نشان می‌دهد.

یوزکیس دیاگرام دستگاه خودپرداز

در نمودار زیر، یوزکیس دیاگرام دستگاه خودپرداز آمده است.

یوزکیس دیاگرام فرودگاه

نمودار زیر یک نمونه یوزکیس دیاگرام فرودگاه را نمایش می‌دهد. همانطور که می‌توان مشاهده کرد. در این یوزکیس دیاگرام از extend و include نیز استفاده شده است.

یوزکیس دیاگرام بیمارستان

در نمودار زیر، یوزکیس دیاگرام بیمارستان آمده است.

معرفی فیلم آموزش مهندسی نرم‌افزار فرادرس

در این بخش از مطلب یوزکیس دیاگرام چیست فیلم آموزش مهندسی نرم‌افزار، مدل‌سازی و ترسیم مدل با نمودار، ارائه شده است.

فیلم آموزش مهندسی نرم افزار ۱

طول مدت این دوره آموزشی یازده ساعت و چهل دقیقه است و مدرس آن، مهندس فرشید شیرافکن هستند. این آموزش برای کلیه دانشجویان مهندسی کامپیوتر کلیه گرایش‌ها و علاقه‌مندان به علوم و مهندسی کامپیوتر، دانشجویان رشته‌های حوزه فناوری اطلاعات، دانشجویان صنایع، برنامه‌نویسان، مهندس‌های سیستم و سایر علاقه‌مندان و افرادی مناسب است که نیاز به فراگیری مباحث مهندسی نرم‌افزار دارند. از جمله مباحث مورد بررسی در فیلم آموزش مهندسی نرم افزار ۱ می‌توان به ارائه تعریف نرم‌افزار و مهندسی نرم‌افزار، مدل‌های فرایند، توسعه چابک، اصول راهنما در مهندسی نرم‌افزار، شناخت و مهندسی خواسته‌ها، مدل‌سازی خواسته‌ها (سناریوها)، مدل‌سازی خواسته‌ها و مفاهیم طراحی اشاره کرد. شایان توجه است که در این آموزش به مبحث تحلیل خواسته‌ها، مدل‌سازی مبتنی بر سناریو، مدل‌های UML، مدل‌سازی مبتنی بر کلاس، مدل‌سازی جریان‌گرا و دیگر مباحث مرتبط به طور کامل پرداخته شده است.

• برای دیدن فیلم آموزش مهندسی نرم افزار ۱ + اینجا کلیک کنید.

فیلم آموزش توسعه نرم افزار با متد ICONIX و زبان مدل سازی UML

طول مدت این دوره آموزشی سه ساعت و پنجاه و شش دقیقه است و مدرس آن، مهندس سعید مصطفایی هستند. این آموزش برای کلیه دانشجویان مهندسی کامپیوتر کلیه گرایش‌ها و علاقه‌مندان به علوم و مهندسی کامپیوتر، دانشجویان رشته‌های حوزه فناوری اطلاعات، دانشجویان صنایع، برنامه‌نویسان، مهندس‌های سیستم و سایر علاقه‌مندان و افرادی مناسب است که نیاز به فراگیری مباحث مهندسی نرم‌افزار، روش توسعه نرم‌افزار با متد ICONIX و زبان مدل‌سازی UML دارند. از جمله مباحث مورد بررسی در فیلم آموزشی می‌توان به معرفی نرم‌افزار و انواع فرایندهای توسعه نرم‌افزار، مفاهیم شی‌گرایی، یوزکیس دیاگرام ، تحلیل استحکام (Robustness Analysis)، نمودار توالی، نمودار کلاس و دیگر مباحث مرتبط اشاره کرد. شایان توجه است که در این آموزش به طور کامل به بحث یوزکیس دیاگرام شامل تعریف نیازمندی‌های کارکردی و غیرکارکردی سیستم، تعریف یوزکیس، سناریوی یوزکیس، روابط بین یوزکیس‌ها، ارتباط بین یوزکیس دیاگرام و مدل دامنه، روش ترسیم یوزیس دیاگرام ، ارتباط بین سناریوی یوزکیس‌ها، روش به‌روزرسانی یوزکیس دیاگرام هنگام نوشتن سناریو و ترسیم یوزکیس دیاگرام برای پروژه کلاسی با استفاده از نرم‌افزار Enterprise Architect اشاره کرد.

• برای دیدن فیلم آموزش توسعه نرم افزار با متد ICONIX و زبان مدل‌سازی UML + اینجا کلیک کنید.

فیلم آموزش مدل‌سازی UML با نرم‌افزار Rational Rose

طول مدت این دوره آموزشی سه ساعت و سی و پنج دقیقه است و مدرس آن، مهندس سمیه توکلی هستند. این آموزش برای کلیه دانشجویان مهندسی کامپیوتر کلیه گرایش‌ها و علاقه‌مندان به علوم و مهندسی کامپیوتر، دانشجویان رشته‌های حوزه فناوری اطلاعات، دانشجویان صنایع، برنامه‌نویسان، مهندس‌های سیستم و سایر علاقه‌مندان و افرادی مناسب است که نیاز به فراگیری مباحث مهندسی نرم‌افزار، زبان مدل‌سازی UML و مدل‌سازی UML با استفاده از نرم‌افزار Rational Rose دارند. از جمله مباحث مورد بررسی در فیلم آموزش مدل‌سازی UML با نرم‌افزار Rational Rose می‌توان به بیان مفهوم UML، آشنایی با محیط نرم‌افزار Rational Rose، مفاهیم پایه‌ای در Rational Rose، رسم یوزکیس دیاگرام ، نمودارهای تعاملی (برهم‌کنش‌ها)، انواع رابطه در Rational Rose، کلاس‌ها و عملیات روی آن‌ها، نمودار حالت (State Diagram)، نمودار مولفه (Component Diagram)، تولید کد و دیگر مباحث مرتبط اشاره کرد. شایان توجه است که در این آموزش به طور کامل به بحث رسم یوزکیس دیاگرام شامل مراحل رسم نمودارهای UML، رسم نمودار Use Case، تعیین رابطه در یوزکیس دیاگرام و دیگر موارد مرتبط پرداخته شده است.

• برای دیدن فیلم آموزش مدل سازی UML با نرم افزار Rational Rose + اینجا کلیک کنید.

فیلم آموزش نرم‌افزار Microsoft Visio (مایکروسافت ویزیو) برای طراحی انواع نمودار و دیاگرام - مقدماتی

طول مدت این دوره آموزشی یک ساعت و سی دقیقه است و مدرس آن، مهندس حسین خاکپور هستند. این آموزش برای کلیه دانشجویان مهندسی کامپیوتر کلیه گرایش‌ها و علاقه‌مندان به علوم و مهندسی کامپیوتر، دانشجویان رشته‌های حوزه فناوری اطلاعات، دانشجویان صنایع، برنامه‌نویسان، مهندس‌های سیستم و سایر علاقه‌مندان و افرادی مناسب است که نیاز به فراگیری مباحث ترسیم نمودار و ابزار محبوب و شناخته شده این حوزه یعنی مایکروسافت ویزیو دارند. از جمله مباحث مورد بررسی در فیلم آموزش نرم‌افزار Microsoft Visio (مایکروسافت ویزیو) برای طراحی انواع نمودار و دیاگرام - مقدماتی می‌توان به معرفی نرم‌افزار مایکروسافت ویزیو و روش رسم فلوچارت در آن، روش ترسیم چارت‌های سازمانی، ترسیم دیاگرام منحنی جریان و دیگر مباحث مرتبط اشاره کرد.

• برای دیدن فیلم آموزش نرم‌افزار Microsoft Visio (مایکروسافت ویزیو) برای طراحی انواع نمودار و دیاگرام - مقدماتی + اینجا کلیک کنید.

فیلم آموزش نرم‌افزار Microsoft Visio برای طراحی انواع نمودار و دیاگرام - تکمیلی

طول مدت این دوره آموزشی پنجاه و هفت دقیقه است و مدرس آن، دکتر مجید حسینی هستند. این آموزش برای کلیه دانشجویان مهندسی کامپیوتر کلیه گرایش‌ها و علاقه‌مندان به علوم و مهندسی کامپیوتر، دانشجویان رشته‌های حوزه فناوری اطلاعات، دانشجویان صنایع، برنامه‌نویسان، مهندس‌های سیستم و سایر علاقه‌مندان و افرادی مناسب است که نیاز به فراگیری مباحث ترسیم نمودار و ابزار محبوب و شناخته شده این حوزه یعنی مایکروسافت ویزیو دارند. شایان توجه است که آشنایی با مباحث مقدماتی ویزیو پیش‌نیاز مشاهده این آموزش است. از جمله مباحث مورد بررسی در فیلم آموزش نرم‌افزار Microsoft Visio (مایکروسافت ویزیو) برای طراحی انواع نمودار و دیاگرام - تکمیلی می‌توان به معرفی ویزیو و روش شخصی سازی آن، ساختار سازمانی و ساختار اطلاعاتی آن در ویزیو، مدل‌سازی فرایندهای کسب و کار در ویزیو، طوفان فکری و حل مسئله در ویزیو و دیگر مباحث مرتبط اشاره کرد.

• برای دیدن فیلم آموزش نرم‌افزار Microsoft Visio برای طراحی انواع نمودار و دیاگرام - تکمیلی + اینجا کلیک کنید.

فیلم آموزش مبانی توسعه نرم افزاری Agile (چابک)

طول مدت این دوره آموزشی دو ساعت و سی و پنج دقیقه است و مدرس آن، دکتر عباس نیک‌نفس هستند. این آموزش برای کلیه دانشجویان مهندسی کامپیوتر کلیه گرایش‌ها و علاقه‌مندان به علوم و مهندسی کامپیوتر، دانشجویان رشته‌های حوزه فناوری اطلاعات، برنامه‌نویسان، مهندس‌های سیستم و سایر علاقه‌مندان و افرادی مناسب است که نیاز به فراگیری مفاهیم چابکی و روش توسعه نرم‌افزاری چابک دارند. از جمله مباحث مورد بررسی در فیلم آموزش مبانی توسعه نرم افزاری Agile (چابک) می‌توان به مقدمه‌ای بر Agile، تاریخچه پیداش Agile، ارزش‌ها و اصول اساسی Agile، مزایای چابکی، برنامه‌نویسی Extreme، کانبان، اسکرام‌بان و اسکرام، داستان کاربر، حل تمرین‌های Agile و دیگر مباحث مرتبط اشاره کرد.

• برای دیدن فیلم آموزش مبانی توسعه نرم افزاری Agile (چابک) + اینجا کلیک کنید.

طول مدت این دوره آموزشی دو ساعت و سی و دو دقیقه است و مدرس آن، مهندس سعید مصطفایی هستند. این آموزش برای کلیه دانشجویان مهندسی کامپیوتر کلیه گرایش‌ها و علاقه‌مندان به علوم و مهندسی کامپیوتر، دانشجویان رشته‌های حوزه فناوری اطلاعات، برنامه‌نویسان، مهندس‌های سیستم و سایر علاقه‌مندان و افرادی مناسب است که نیاز به فراگیری مفاهیم چابکی، روش توسعه نرم‌افزاری چابک و مدیریت چابک پروژه‌ها به طور خاص با نرم‌افزار MSP دارند. از جمله مباحث مورد بررسی در فیلم آموزش مدیریت Agile (چابک) پروژه ها با نرم افزار MSP می‌توان به برنامه‌ریزی و کنترل پروژه‌های Agile با نرم‌افزار MSP، تنظیم محیط MSP برای مدیریت پروژه چابک، ساخت لیست فعالیت Agile، پیگیری فرایند چابک و دیگر مباحث مرتبط اشاره کرد.

• برای دیدن فیلم آموزش مدیریت Agile (چابک) پروژه ها با نرم افزار MSP + اینجا کلیک کنید.

فیلم آموزش تجزیه و تحلیل و طراحی سیستم‌ها

طول مدت این دوره آموزشی هشت ساعت و نه دقیقه است و مدرس آن، دکتر نازنین تیموری هستند. این آموزش برای کلیه دانشجویان مهندسی کامپیوتر کلیه گرایش‌ها و علاقه‌مندان به علوم و مهندسی کامپیوتر، دانشجویان رشته‌های حوزه فناوری اطلاعات، دانشجویان صنایع، برنامه‌نویس‌ها، مهندس‌های سیستم و سایر علاقه‌مندان و افرادی مناسب است که نیاز به فراگیری مباحث نگرش سیستمی، فرایندگرایی و کلی‌نگری، افزایش شناخت از نقاط ضعف و قوت یک سیستم و روش طراحی سیستم‌های جدید دارند. از جمله مباحث مورد بررسی در فیلم آموزش تجزیه و تحلیل و طراحی سیستم‌ها می‌توان به بررسی کلی سیستم‌ها، مبانی سیستم، روابط و ویژگی‌ها در سیستم، علم کنترل و ارتباطات، شناخت خرده سیستم‌ها و ساده‌سازی الگوی تعاملی آن‌ها، ساز و کار تداوم حیات سازمان‌ها در محیط‌های پویا، روش تجزیه و تحلیل و طراحی نظام‌یافته سیستم، شناخت بافت سازمانی، فنون نظام یافته تجزیه و تحلیل و طراحی سیستم، طراحی و برنامه‌ریزی سیستم، طراحی مفهومی سیستم جدید، طراحی تفصیلی سیستم جدید، استقرار، ارزیابی و نگهداری سیستم و دیگر مباحث مرتبط اشاره کرد.

• برای دیدن فیلم آموزش تجزیه و تحلیل و طراحی سیستم‌ها  + اینجا کلیک کنید.

فیلم آموزش پیشرفته نرم‌افزار Arena برای شبیه‌سازی و مدل‌سازی سیستم‌ها

طول مدت این دوره آموزشی سه ساعت و سی و هفت دقیقه است و مدرس آن، مهندس مهدی عرفانیان هستند. این آموزش برای کلیه دانشجویان مهندسی کامپیوتر کلیه گرایش‌ها و علاقه‌مندان به علوم و مهندسی کامپیوتر، دانشجویان رشته‌های حوزه فناوری اطلاعات، برنامه‌نویسان، مهندس‌های سیستم و سایر علاقه‌مندان و افرادی مناسب است که نیاز به فراگیری مباحث شبیه‌سازی و مدل‌سازی سیستم‌ها به طور خاص با نرم‌افزار پیشرفته Arena دارند. از جمله مباحث مورد بررسی در فیلم آموزش پیشرفته نرم‌افزار Arena برای شبیه‌سازی و مدل‌سازی سیستم‌ها می‌توان به بررسی ماژول‌های Basic Process و Advanced Process، مدل‌سازی سیستم‌های حمل و نقل پیشرفته، رویکرد شبیه‌سازی پیوسته و مدل‌سازی با ماژول FlowProcess، شبیه‌سازی سیستم‌های High Speed و High Volume، آموزش ماژول‌های Packaging، ارائه مثال کاربردی پیرامون یک زنجیره تامین، معرفی قابلیت Visual Designer و دیگر مباحث مرتبط اشاره کرد.

• برای دیدن فیلم آموزش پیشرفته نرم‌افزار Arena برای شبیه‌سازی و مدل‌سازی سیستم‌ها + اینجا کلیک کنید.