fa azb fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa en fa fa fa fa fa fa en fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa en fa fa fa fa fa fa fa fa en fa fa fa fa fa fa fa fa fa ar fa fa fa fa fa fa fa fa fa ar fa fa fa fa fa fa fa fa fa fa fa
بعید می دونم که تا به حال اسم 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، بانک اطلاعاتی، تست کیسها و خیلی چیزهای دیگه به یوزکیسها وابسته هستن.
برای روشن تر شدن اینکه کاربر یوزکیس به چه صورته یک مثال ساده [و شاید ساده لوحانه] میزنم: همه زیر و بم کارهایی که یک سیستم مدیریت پروژه ساده رو میشه با نوشتن ۳ تا یوزکیس به نامهای فرضی “ثبت پروژه”، “اخذ گزارش” و “مدیریت کاربران” ثبت کرد.
این همه گفتم ولی حواستون باشه که برای ثبت کردن تمام زوایای یک پروژه به اسناد و ابزارهای دیگه ای هم نیاز دارین مثلاً یوزکیس نیازمندیهای کیفی شما رو جواب نمیده، یعنی شما توی یوزکیس در مورد اینکه جستجو نباید بیشتر از ۳ ثانیه طول بکشه یا سیستم عامل سرور لینوکس هستش حرفی نمی زنین.
در بخش بعدی به ساختار یوزکیس می رسیم و آماده می شیم برای مثال عملی.
نگاهی متفاوت به یوزکیس (قسمت دوم) | امین رشیدی
10 اکتبر 2014 در 12:42 ب.ظ - پاسخ
[…] قسمت قبلدر مورد تعریف یوزکیس و کلیات کاربردش در پروژه صحبت […]
کارگاه عملی استخراج نیازمندیها (یوزکیس) – قسمت اول | امین رشیدی
11 نوامبر 2014 در 12:35 ب.ظ - پاسخ
[…] با یوزکیس، قسمت اولیوزکیس متنی رو معرفی کردم و در قسمت دوم اجزای یک یوزکس رو شرح دادم. حالا میخوایم یک پروژه فرضی […]
کارگاه عملی استخراج نیازمندیها (یوزکیس) – قسمت اول | Amin Rashidi
5 می 2017 در 4:12 ب.ظ - پاسخ
[…] با یوزکیس، قسمت اول یوزکیس متنی رو معرفی کردم و در قسمت دوم اجزای یک یوزکس رو شرح دادم. حالا میخوایم یک پروژه فرضی […]
10 اکتبر 2014 در 7:08 ق.ظ - پاسخ
مطلب جالبی بود با اینکه من سه سالی هست از UML فاصله گرفتم ولی هنوز خوندن این مطالب برام جالبه
لطفا رنگ متن ها را یک کمی تیره تر کنید تا راحتتر بشه متن و خوند اینجوری چشم خسته میشه
10 اکتبر 2014 در 12:11 ب.ظ - پاسخ
خوشحالم که مطلب براتون مفید بوده و چشم، مورد رنگ رو در اولین فرصت برطرف میکنم.
10 اکتبر 2014 در 7:26 ق.ظ - پاسخ
یاد دوران کاردانی و کارشناسی‌ام افتادم و پروژه‌هاش 🙂
10 اکتبر 2014 در 12:12 ب.ظ - پاسخ
چقدر خوب. اگر تجربه ای در این مورد دارین ممنون می شم به اشتراک بذارین.
10 اکتبر 2014 در 1:26 ق.ظ - پاسخ
بسیار مفید و آموزنده بود جناب رشیدی
3 مارس 2015 در 12:28 ب.ظ - پاسخ
از اینکه این مطالب رو به زبان فارسی در دنیای مجازی با این شیوایی کلام انتشار دادید تشکر میکنم .
اینکه بتونیم یوزکیس ها رو با نگاهی تازه پیدا کنیم بسیار جالب هست… من دانشجویی هستم که تازه با درس تحلیل و طراحی سیستم اشنا شدم …خوشبختانه استاد درس مربوطمون یک مسیر زیبایی رو مشخص کردند که همه مطالب در ذهن ما جا گرفت و راحت تر تونستیم با اون ها ارتباط برقرار کنیم …
در قدم اول ما نیازمندی های عملیاتی و غیر عملیاتی (functional va non-functional) را پیدا کردیم که در قدم اول بفهمیم چه نیاز های اصلی و کم ارزشی تو سیستممون هست که این خودش خیلی کمک می کنه که به use case ها برسیم ولی یک موردی رو که همیشه بهمون گوش زد میکردند این بود که حواستون به اکتور ها باشه چون اون ها هستند که میخواهند از سیستم شما استفاده کنند نیاز های اونها پلی هست برای شناسایی یوزکیس هاتون….
ممنون ببخشید از اینکه پر حرفی کردم ….
3 مارس 2015 در 12:56 ب.ظ - پاسخ
ممنون از لطف شما و اینکه نظر خودتون رو با من به اشتراک گذاشتین.
در تأیید صحبتهای شما باید بگم که محور اصلی یوزکیس و در کل فرآیند شناسایی نیازمندیهای سیستم آکتورها هستن و بی توجه به اونها عامل اصلی شکست خوردن پروژه های نرم افزاری هستش.