مفهوم یوزکیس

مقدمه بعید می دونم که تا به حال اسم Use Case رو نشنیده باشین. همه این واژه رو با علامت آدمک و بیضی در UML می شناسن ولی شاید کمتر با Use Case متنی آشنا باشن. در حالی که حالت متنی Use Case از دیاگرام معادلش مهمتر هست و تأثیر بیشتری در به انجام رسوندن موفقیت آمیز یک پروژه نرم افزاری داره. من حدود ۱۰سالی هست که با Use Case متنی آشنا هستم و در سالهای اخیر به عنوان تحلیل گر سیستم خروجی اصلی کار من Use Case بوده که کمک زیادی به انجام کامل پروژه ها کرده.

در ادامه چکیده تجربه های شخصی و کتابهایی که مطالعه کردم رو تقدیم می کنم، امیدوارم که مفید باشه. دوست ندارم با توضیحات اضافی و کسل کننده شما رو از ادامه خوندن مطلب منصرف کنم، فقط در حد خیلی خلاصه فلسفه وجودی و مزایای یوزکیس رو بیان میکنم، در قسمتهای بعدی هم کاربردها و اجزای یک یوزکیس و در نهایت هم مثالهای عملی. در ضمن از این به بعد برای راحتی بیشتر بجای Use Case از “یوزکیس” استفاده میکنم. یوزکیس و مزایای آن در سال ۱۹۸۶ یک مهندس نرم افزار سوئدی به نام Ivar Jacobson مفاهیم بکار گیری یوزکیس رو بصورت متنی و گرافیکی معرفی کرد، بعداً این تلاش به بخشی از UML که همه میشناسیم تبدیل شد. Jacobson یوزکیس رو به این صورت تعریف میکنه: “یک یوزکیس شامل تمام راه هایی است که یک سیستم، یک هدف [عمل] مشخص را برای یک کاربر خاص به انجام می رساند. تمام یوزکیسهای یک سیستم همه راه های استفاده از یک سیستم و ارزش آن را برای شما ترسیم می کند.” (بر گرفته از مقاله Use Case 2.0) این تعریف مثل همه تعاریف آکادمیک انتزاعی به نظر میاد فعلاً اینطور در نظر بگیرین که یوزکیس نوشته ای هستش که رفتار سیستم رو به زبان شیوای فارسی ثبت میکنه، برای مثال می نویسیم “کاربر درخواست ثبت سفارش می نماید و سیستم فرم ثبت سفارش را برای کاربر نمایش می دهد. کاربر درخواست خود را در فرم وارد می نماید. سیستم درخواست را ثبت کرده و تأییده را نمایش می دهد.” به همین راحتی! این روش مزایای متعددی داره: انعطاف و چابکی بالا: ساختار Use Case بصورتی هست که اون رو میشه در یک پاراگراف ساده نوشت و به مرور زمان تبدیل کرد به یک سند چند بخشی چندی صفحه ای. بیان طبیعی و همه فهم: Use Case بصورت متن نوشته میشه و همین انتقال جزییات رو به نسبت دیاگرامها راحت تر و قابل درک تر می کند. سازگار با روشهای مدرن: Use Case رو به راحتی میشه با روشهای Iterative و Incremental مثل RUP، Scrum و… استفاده کرد. به این معنی که به مرور پیشرفت پروژه جزییات بیشتری به Use Case اضافه کرد. ارتباط مؤثر با دیگر محصولات پروژه (“چیز”هایی که در پروژه تولید میشه): Use Case به راحتی از مصاحبه های اولیه با کاربر قابل تهیه هستش و براساس اون میشه از کلاسهای سیستم تا Test Case تا بانک اطلاعاتی رو استخراج کرد. نگهداری راحت: استفاده از یوزکیس نیاز به ابزار خاصی نداره و میشه با notepad هم یوزکیس نوشت. درک بهتر نیازمندیهای نرم افزار ابزاری برای درک بهتر یوزکیس در پروژه چه کاربردی دارد؟ بصورت خلاصه یوزکیس در حوزه نیازمندیهای عملیاتی (Functional Requirement) نیاز اکثر پروژه ها رو تأمین میکنه، یعنی اینکه شما تقریباً همه کارهایی که کاربر از شما می خواد که سیستم انجام بده رو می تونین با یوزکیس توصیف کنین. گفتم تقریباً چون بعضی چیزها سلیقه ای هستش. فرض کنین نرم افزار شما باید خروجیهای مختلف مثل XML و XLS داشته باشه، اینجا با یک لیست ساده هم میشه این قابلیت رو ثبت کرد و نیازی به ساختار یوزکیس نیست. مهم نیست پروژه یک سیستم بزرگ MIS هستش یا یک سیستم حسابداری یا یک بازی کامپیوتری یا هرچی، شما می تونین از یوزکیس استفاده کنین. از طرف دیگه همونطور که در قبلاً گفتم محتوای یوزکیس انقدر غنی هستش که خوراک بیشتر “چیزهای” که برای طراحی و پیاده سازی نرم افزار نیاز دارین رو تأمین میکنه. برای مثال کلاسهای برنامه و اکثر دیاگرامرهای UML، بانک اطلاعاتی، تست کیسها و خیلی چیزهای دیگه به یوزکیسها وابسته هستن. برای روشن تر شدن اینکه کاربر یوزکیس به چه صورته یک مثال ساده [و شاید ساده لوحانه] میزنم: همه زیر و بم کارهایی که یک سیستم مدیریت پروژه ساده رو میشه با نوشتن ۳ تا یوزکیس به نامهای فرضی “ثبت پروژه”، “اخذ گزارش” و “مدیریت کاربران” ثبت کرد. این همه گفتم ولی حواستون باشه که برای ثبت کردن تمام زوایای یک پروژه به اسناد و ابزارهای دیگه ای هم نیاز دارین مثلاً یوزکیس نیازمندیهای کیفی شما رو جواب نمیده، یعنی شما توی یوزکیس در مورد اینکه جستجو نباید بیشتر از ۳ ثانیه طول بکشه یا سیستم عامل سرور لینوکس هستش حرفی نمی زنین.

 

بخش‌های مختلف یوزکیس

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

نکته‌: یک یوزکیس معمولاً یک سند الکترونیکی مثل فایل Word هستش و هر بخشی که در ادامه میگم یک بخش از این فایل متنی هستش. نا گفته نمونه یوزکیس قابلیت اتصال به ابزارهای CASE مثل RequisitePro رو هم داره که الان بهش کاری ندارم.

عنوان

نام یوزکیس که توصیه میشه با فعل شروع بشه. برای مثال “صدور فاکتور” یا “ثبت پروژه” یا “شوت کردن توپ”!

توضیح کلی

فکر بدی نیست که یک توضیح کلی برای خواننده بدین که آمادگی ذهنی پیاده کنه. برای مثال “این یوزکیس برای توصیف روشهای صدور فاکتور سیستم فلان نوشته شده و به دلیل اهمیت پارامترهای امنیتی در سند بهمان بخش جدایی برای آن در نظر گرفته شده است….”

پیش فرضها

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

سناریوی اصلی

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

“مسئول فروش در هنگام فروش کالا به يک طرف حساب، مشخصات کالاي خريداري شده را در فاکتور فروش ثبت مي نمايد . مسئول فروش مي تواند مبلغ نهايي را از طرف حساب به صورت نقدي يا چک بگيرد.”

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

سناریوهای جانبی

بزرگترین بخش یوزکیس از نظر حجمی همین بخش هستش و ممکنه تا ۸۰ درصد کل یوزکیس (توصیه میشه یوزکیس از ۳یاچهار صفحه کاغذ A4 بزرگتر نشه) رو به خودش اختصاص بده.

مباحث باز

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

انواع یوزکیس چیست؟

بخشهای یوزکیس رو گفتیم، حالا میرسیم به انواع یوزکیس. شما بسته به فاز پروژه به انواع مختلفی از یوزکیس نیاز پیدا می‌کنین، مبنای این تقسیم بندی میزان جزییاتی هستش که یوزکیس دربر می‌گیره یا به بیان دیگه تقسیم بندی “ساختاری” هستش. این تقسیم بندی بر مبنای نظریات Alistair Cockburn، شاگرد Jacobson صورت گرفته، برای اطلاعات بیشتر به کتاب Writing Effective Usecases رجوع کنین:

ابتدایی

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

غیررسمی‌(Casual)

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

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

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

کامل (Fully Dressed)

من از لفظ کامل استفاده کردم ولی اصراری ندارم انتخاب درستی بوده، منظورم این بود که از نظر ساختار کاملترین هستش ولی از نظر محتوی یک یوزکیس ممکنه به این زودیها کامل نشه. مثال یوزکیس کامل رو در انتهای پروژه نمونه خواهید دید.

بکارگیری انواع یوزکیس

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

 

ادامه دارد…

 

منبع