سوالی و جوابی که کلید مشکلات است(در مورد دیاگرام کلاس)

[mahdikoochooloo]

به نام خدا
سلام رفقا

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

کسی نظری داره؟

[mahin_n]

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

به نظر منم این موضوعی که فرموده شد کاملا درسته . مهم ترین و کاربردی ترین دیاگرام همون class diagram هستش که توی مراحل آنالیز و طراحی به کار می آد من حتی برای کشیدن دیاگرام کلاس مجبور شدم تا dfd سیستم رو هم بکشم تا اون رو متوجه بشم . فقط یه اشتباهی که کردم این بود که هیچ توجهی به این موضوع نکردم که میخوام با پایگاه داده رابطه ای توی مرحله پیاده سازی کار کنم و کلاسهامو و به خصوص attribute های کلاسها روجوری طراحی کنم که توی اون مرحله مشکلی پیش نیاد و دوباره مجبور شدم بعضی کلاسهامو تغییر بدم.

[mahdikoochooloo]

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

ممنون

[mahin_n]

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

تو دیاگرام کلاس پایگاه داده اضافه نمیشه بلکه براساس تفکر پایگاه داده ای رسم میشه.
ببینید من تو مثال پایین که برای سیستم فروشم کشیده بودم کد کالا را بعنوان attribute برای درخواست فروش در نظر گرفته بودم درحالیکه نیازی به این att نیست و اینجا نباید بیارمش بلکه تو همون table هایی که تو پایگاه داده ام برای کلاسها میکشم باید کد کالا را بعنوان foreign key برای این جدول در نطر بگیرم . در واقع منظورم اینکه تو کلاسهای دیاگرامم باید متدها و ویژگی های همون کلاس رو در نطر بگیرم بعد تو جدول هام بیام براساس روابطم att های جدیدی رو اضافه کنم. امید وارم منظورم رو متوجه شده باشید

73409

[Neo2011]

همتون اشتباه کردین. چون اولین مرحله تحلیل سیستم، شناخت سیستم هست. شما تا زمانی که نتونین سیستم رو بشناسین و روابط بین اجزای سیستم رو مشخص کنین، چطور مینونین برای اونها کلاس طراحی کنین؟ یک سیستم آموزشی رو در نظر بگیرید : موجودیتهای استاد، دانشجو، مدیر گروه، مسئول آموزش ، کارمند آموزش همه عواملی(Actors) هستند که از سیستم استفاده میکنند و همه اونها تحت یک عامل کلی به نام کاربر عمومی سازی میشن(Generalize ) . حالا شما بدون داشتن نمودار یوزکیس چطور میخواین کلاس کاربر رو طراحی کنین؟ در فاز شناخت (Inception ) سیستم به طور کلی شناخته میشود و نمودارهای یوز کیس آن طراحی شده و در مرحله تعیین معماری نرم افزار یا همان فاز Elaboration سیستم تشریح میشود. نمودار یوزکیس تکمیل شده و نمودار کلاس و روابط بین کلاسها مشخص شده و ترسیم میشود.

[Neo2011]

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

[mahdikoochooloo]

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

[mahdikoochooloo]

آقای نئو متاسفانه منم لیست بالایی از کلاس ها رو تو تحلیلم دارم می بینم که البته تو مرحله بعدی که اینا رو طراحی کردم خیلی هاش رو ادغام می کنم حدود 21 الی 25 تا کلاس
آیا منظورتون از کلاس های بلند بالا این تعداد کلاس برای یک پروژه کوچکه؟
اگر بله لطف می کنید بگید چطور باید سیستم رو تحلیل کرد تا فقط کلاس های واقعا مورد نیاز بیرون کشیده بشن؟
متشکر

[hossein2007]

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

سلام دوست عزیز.
این که فرمودید: "یک تحلیلگر باید یک ذهن ویژوال قوی داشته و کل سیستم رو بتونه تو ذهنش تصویر سازی ذهنی کنه" اشتباه است.

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


تحلیل نیازمندی ها. (توسط مهندس صنایع یا مهندس نرم افزاری که تجربه تحلیل مناسب دارد)
طراحی ساختار های نرم افزار. (توسط مهندس نرم افزار)
پیاده سازی. (توسط برنامه نویس مسلط به ابزارهای برنامه سازی مورد نظر طراح)


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

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

در واقع جمله درست این هست : "یک طراح (مهندس نرم افزار) باید یک ذهن ویژوال قوی داشته و کل سیستم رو بتونه تو ذهنش تصویر سازی ذهنی کنه"

در صورت علاقه به ادامه بحث می تونیم بیشتر بحث کنیم.

[mahdikoochooloo]

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

[mahdikoochooloo]

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

[mahdikoochooloo]

ادامه این تاپیک در این تاپیک
چون فکر می کنم یک موضوع جدید شد :
http://barnamenevis.org/showthread.php?299197-%D8%B3%D9%88%D8%A7%D9%84%DB%8C-%DA%A9%D9%87-%D8%A8%D8%A7%DB%8C%D8%AF-%D8%B9%D9%84%D9%85%D8%A7%DB%8C-%DB%8C%D9%88-%D8%A7%D9%85-%D8%A7%D9%84-%D8%B4%D8%B1%DA%A9%D8%AA%DB%8C-%D8%AD%D9%84-%DA%A9%D9%86%D9%86&p=1312197#post1312197

[Neo2011]

نه منظورم از لیست بلند بالا، تعداد کلاس نیست. منظورم کلاسهای بی مورد. برای تحلیل صحیح اول باید برید با کاربر نهایی که میخواد با نرم افزار کار کنه ملاقات کنید ( اگر پروژه برای خودتون هستش که خودتون بشید کاربر نهایی و ببینین که از سیستم چی میخواین ). توجه داشته باشید که یوزکیس ها قابلیت های وظیفه مندی نرم افزار رو نشون میده. در مرحله اول شما به عنوان تحلیل گر از دو جهت سیستم رو ارزیابی میکنید. Use case Modeling و Business Usecase Modeling . اما فرق بیزینس یوز کیس مدل با یوز کیس مدل چیه؟ بیزینس یوز کیس مدل برای تحلیل و مدلسازی کل عملیات سیستم استفاده میشه یعنی حتی کارهای غیر نرم افزاری و یوزکیس مدل فقط برای کارهای نرم افزاری( یعنی کارهایی که نرم افزار باید انجام بده). و اما روش پیدا کردن کلاسها 1 - روش مبتنی بر داده 2 روش مبتنی بر وظیفه . در روش اول مبنای کار شناسایی ساختمان داده های مورد نیاز مسئله میباشد در حالیکه در روش دوم کلاسها بر اساس وظیفه ها شناسایی میشوند. در روش CRC (class, Responsibilities & collboration از یه کارت 3*2 اینچی استفاده میشود که دارای 3 فیلد نام کلاس، وظایف کلاس و همکاران کلاس در انجام وظایف خود میباشد. در واقع در اکثر مسائل یک سری کلاسها وجود دارن که به کلاس اولیه معروفند و کاملا مشهود هستن که میتونن مبنایی برای شناسایی کلاسهای بیشتر باشند. برای شناخت کلاس جدید به ازای هر وظیفه یا مسئولیت یک کلاس تلاش میکنیم که جوابی برای این سوال که " اگر این وظیفه بخواهد انجام شود چه اتفاقی می افتد؟" پیدا کنیم و بدین ترتیب همکاران کلاس شناسایی خواهند شد.

[mahdikoochooloo]

ادامه این تاپیک در این تاپیک
چون فکر می کنم یک موضوع جدید شد :
http://barnamenevis.org/showthread.php?299197-%D8%B3%D9%88%D8%A7%D9%84%DB%8C-%DA%A9%D9%87-%D8%A8%D8%A7%DB%8C%D8%AF-%D8%B9%D9%84%D9%85%D8%A7%DB%8C-%DB%8C%D9%88-%D8%A7%D9%85-%D8%A7%D9%84-%D8%B4%D8%B1%DA%A9%D8%AA%DB%8C-%D8%AD%D9%84-%DA%A9%D9%86%D9%86&p=1312197#post1312197