سوال ارسالی توسط حدیث

سلام

امیدوارم ایام به کامتان باشد

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

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

دوستان جهت مشاهده بهتر دیاگرام ، تصویر را روی سیستم خود کپی کنند تا با وضوح بهتر دیاگرام را مشاهده کنند .( مدیریت )

نظر مدیریت

با سلام

به نظر مدیریت اگر شما می خواهید یوزکیس <ورود> در سیستم خود اختیار کنید باید حالت login داشته باشد . یعنی کاربر سیستم تا زمانی که وارد سیستم نشده است نباید بتواند کاری را انجام دهد . پس کاربر سیستم به واسته یوزکیس <ورود> می تواند به سایر یوزکیس ها دسترسی پیدا کند . به همین دلیل پیشنهاد من شبیه شکل زیر است . 

یوزکیس <خروج> باید شامل یک سری عملیات باشد ، که برای سیستم هنگام خروج تعریف شده باشد . مثلاً قبل از خروج BackUp گیری کند . در این مواقع وجود چنین یوزکیسی منطقی به نظر می رسد . در غیر این صورت نیازی به این یوزکیس احساس نمی شود .

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

1. باید جهت فلش به سمت یوزکیسی باشد که  کار را باید انجام دهد . مثلاً جهت فلش در دو یوزکیس <انجام محاسبات> و <محاسبه عیدی> از سمت <انجام محاسبات> به <محاسبه عیدی> باشد .
2. از ارتباط Association بین Actor و Use Case استفاده می شود .
3. از ارتباط Dependency بین Use Case استفاده می شود .
4. موقعی ما از ارتباط Generalization استفاده می کنیم که بحث ارث بری در میان باشد .

دوباره به این نکته اشاره می کنم که تجزیه و تحلیل یک امر سلیقه ای است و مطالب ذکر شده نظر شخصی مدیریت می باشد .

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

با تشکر مدیریت .

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

---------------------------------------------

سوال توسط بابک :

می خواستم بدونم Sequence Diagram رو بعد از کدام نمودار باید رسم کنیم؟
بعد از Use Case یا Class diagram

--------------------------------------------

پاسخ :

نمودار توالی (Sequence Diagram ) ، نمودار همکاری ( Collaboration Diagram ) ، نمودار فعالیت (Activity Diagram) و نمودار حالت (StateChart Diagram) همگی مربوط به UseCase Diagram می باشد . یعنی وقتی شما UseCase Diagram خود را ترسیم کردید و مشخص شد در سیستم شما چه UseCase هایی وجود دارد آنگاه می توانید برای هریک از UseCase های خود نمودارهای ذکر شده بالا را ترسیم کنید . در واقع چهار نمودار یاد شده بالا هر کدام از زاویه ای UseCase شما را تشریح می کنند تا مشخص شود UseCase ی که شما در UseCase Diagram خود قرار داده اید باید چه روند کاری را پشت سر بگذارد و دارای چه وظیفه ای است . همچنین اگر شما به آموزش نمودارهای ذکر شده توجه کنید ، متوجه خواهید شد که نمودارهای بالا را ما در قسمت UseCase Diagram به پروژه خود اضافه کرده ایم.

انشالله در درس مربوط به Class Diagram بیشتر راجع به این دیاگرام صحبت می کنیم .

نحوه انتقال State از نوار ابزار به داخل State Chart Diagram

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

 در مورد State ها آنچه باید گفت این است که می توانید روی آن دوبار کلیک نماید . منوی زیر برای شما باز می شود . در قسمت Name می توانید نام State را وارد کنید .

قسمت مهم Action ها هستند که ما می توانیم آنچه در رابطه با Entry و Do  و Exit  گفتیم مشاهده کنیم . در تب Actions می توانید کلیک راست کنید و گزینه Insert را انتخاب کنید ، ملاحظه می کنید که یک Entry اضافه شده است .

بر روی Entry می توانید دابل کلیک کنید ، در قسمت مشخص شده در شکل زیر می توانید نوع event را مشخص کنید . عملی که باید انجام شود را در قسمت Name وارد کنید .

خواهید دید که event انتخابی شما به همراه عملی که باید انجام شود به نمودار شما اضافه شده است . در شکل زیر event انتخابی Do می باشد .

برای Transition ها نیز ابتدا آن را انتخاب کرده و سپس از مبدا به مقصد آن را می کشیم . در مورد Transition ها باید گفت آنچه مهم است event است که منجر به چنین Transition شده است .

نوع event را در قسمت Event و آرگومانهایی که به همراه event ارسال می شوند را در قسمت Arguments می توانید مشخص کنید . آنچه در شکل می بینید event است که باعث ورود به State 1 شده است .

برای انتقال سایر اشیاء به صفحه همانند گذشته عمل می کنیم . ابتدا آن را انتخاب کرده سپس در صفحه کلیک می کنیم .

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

فایل PDF درس دوازدهم

این ورژن رشنال دارای فایل کرک است . برای دانلودفایل کرک بر روی لینک زیر کلیک کنید .

یکی از کاربران سایت سوالی در رابطه با ترسیم Use Case دیاگرام ، به شرح زیر برای ما ارسال نموده اند . لذا دوستان می توانند نظرات خود را در این رابطه بیان کنند . نظرات بیان شده به ادامه همین مطلب افزوده می شود .

من دارم یک پرو‍زه مربوط به یک سایت خرید و فروش رو تحلیل و طراحی میکنم

در قسمتی از این سایت مدیر سایت میتواند اعمالی مانند بلاک کردن کاربرو پاک کردن کاربر و... را انجام دهد.به نظر شما آیا من برای هرکدام از این اعمال می بایست یک جدا در نظر بگیرم و یا نه بیام و همه  این اعمال رو درون یک Use Case  فرضا به نام User control  قرار بدم

البته نظر خودم اینه که بیام و فرضا یکUse Case  به نام User control   داشته باشم که یک Associassion با Actor مدیر داشته باشه و بعد چند  Use Case با نام های فرضا Block user  و Delete user  بگذارم که این Use Case ها فقط با User control   از طریق رابطه extended  یا include رابطه برقرار کنند ( یعنی با Actor رابطه نداشته باشند .)

نظر مدیریت

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

در رابطه با موردی که شما اشاره کرده اید نظر من این است که شما یک Use Case به نام < ورود به سیستم کنترل > داشته باشید که از آنجا بتوانید به Use Case های بلوکه کردن و حذف کردن و سایر موارد کنترلی دسترسی داشته باشید . نظر من چیزی شبیه شکل زیر می باشد .

البته این مطلب را دوباره یادآور می شوم که تجزیه و تحلیل یک امر سلیقه ای است . امکان دارد نظر یکی دیگر از دوستان ، غیر از نظر من باشد لذا نمی توان گفت که نظر نفر اول کاملاً صحیح است یا نظر نفر دوم .

اگر دوستان در این رابطه نظر دیگری دارند بیان نمایند تا دوست عزیزمان به جمع بندی بهتری برسد .

 نظر دهنده : آقای احسان محمودی

سلام
این امر باعث نمیشه که تعداد Use case ها خیلی افزایش پیدا کنه ؟
مطمئنا هرچه تعداد use case ها افزایش پیدا کنه Complexity زیادتر  میشه
یا در این حالت  Use case ها خیلی کوچک می شوند

------------------------------------------------------

پاسخ مدیریت

دوست عزیز از لطف شما بسیار سپاسگذارم .

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

نظر دهنده : حدیث

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

------------------------------------------------------

پاسخ مدیر

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

خانم محترم Use Case دیاگرام شما را هم به زودی آماده و برای بررسی بیشتر در وبلاگ قرار می دهم . آنجا بیشتر در مورد پروژه شما بحث می کنیم .

موفق باشید

فرا رسیدن ماه مبارک رمضان ، ماه رحمت و مغفرت ، ما بهار قرآن بر تمامی مسلمین به خصوص هم میهنان عزیز مبارک باد
التماس دعا