مشكل در رابطه بين دو كلاس در يك Uml Class Diagram

[Programmer 1]

سلام،
لطفا به اين صفحه مراجعه كنيد:
http://www.dofactory.com/Patterns/Pa...te.aspx#_self2

اين الگوي composite هستش كه بنده در مورد قسمتي از نمودار ابهام دارم، سوالم اين هست كه چرا رابطه بين كلاس Composite و componenet در نمودار از نوع Aggregation است در حالي كه با توجه به كد من احساس ميكنم بايد رابطه از نوع Composition باشه چون با توجه به اين خط از كد اول:

private List<Component> _children = new List<Component>();

طول عمر كلاس كامپوننت وابسته به كلاس composite است، و به عبارتي كلاس component‌بدون كلاس Composite غير قابل تصوره كه اين تعريف دقيقا مفهوم رابطه Composition‌رو ميرسونه حالا موندم چرا اينجا از رابطه Aggregation استفاده شده!؟

ضمنا يك سوال ديگه هم در مورد uml دارم،‌

وقتي در مورد روابط در uml صحبت ميكنيم بايد به مفهوم بصري اش نگاه كنيم يا به كد؟ مثلا بايد به اين نگاه كنيم كه چون دكمه هاي مينيمايز و ماكسيمايز و خروج وابسته به پنجره هستند رابطه بين اينها از نوع composition است يا بايد به كد نگاه كنيم؟ اگه بايد به كد نگاه كنيم چرا همه جا آوردند اين رو با مثال هاي شهودي بيان كردند شبيه اين :
http://javapapers.com/oops/associati...on-dependency/

همچنين چرا اينقدر تفاوت در توضيح وجود داره، يه جاهايي اصلا به رابطه Dependency اشاره نشده، يه جايي تفاوت Dependency و Assosiation‌ بيان شده. يه جا پياده سازي اينترفيس توسط كلاس هاي تابعه از نوع realization عنوان شده و يه جاي ديگه از نوع generalization .

حتي در نمودار هاي مربوط به ديزاين پترن ها هم اختلاف نظر وجود داره،‌ من نميدونم اگه اين uml يك ابزار مهندسي هستش پس اين تفاوت نظر ها در چيه. من سوالم رو حتي در Stackoverflow و ... هم پرسيدم ولي اونها مثل اينكه حوصله اين مباحث رو ندارن،‌ به قول Agile اي ها مثل اينكه اين ابزار فقط براي تزئئين ساخته شده و از هيچ استاندار محكمي هم تبعيت نميكنه.

دوستان لطفا در اين زمينه توضيح دهيد، ضمنا اگر منبعي براي آشنايي با uml مخصوصا بحث relationship ها سراغ داريد بيان كنيد، لطفا منبعي كه معرفي مي كنيد :

روابط رو با توضيح+كد+نمودار معرفي كنه، وجود تنها يكي از اينها كفايت نميكنه، حداقل اگه كد تنها هم وجود داشته باشه مشكلي نيست.

من آدم تنبلي نيستم كه دنبال اين چيزها نباشم، مشكل اينه كه بدبختي اصلا چيزي پيدا نميشه كه بخونيم. همه چي پراكنده است و كامل نيست، دنبال يك منبع كامل و دقيق و طبق استاندارد هستم.

لاتين و يا فارسي بودن منبع نيز مهم نيست.

با سپاس/.

[Programmer 1]

از اينكه پاسخي ارائه نشدم ناراحت نيستم، از اينكه اين مسائل جز بدنه اصلي دانش مهندسي نرم افزار است و هيچ دغدغه اي بين مهندسين محترم وجود نداره در حيرتم!

حالا باز يكي پيدا ميشه ميگه شما نبايد انتظار داشته باشيد تو اين محيطها پاسخ شما رو بدهند، حرف شما درست؟ ولي براي يك سوال،‌ دو سوال، 10 سوال ... واقعيتش مدتيه هرچقدر سوال خوب و اصولي هم پرسيده ميشه پاسخي ارائه نميشه، خب با اينكار كلا فلسفه وجودي اين سايت زير سوال ميره!

[cups_of_java]

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

[cups_of_java]

اين الگوي composite هستش كه بنده در مورد قسمتي از نمودار ابهام دارم، سوالم اين هست كه چرا رابطه بين كلاس Composite و componenet در نمودار از نوع Aggregation است در حالي كه با توجه به كد من احساس ميكنم بايد رابطه از نوع Composition باشه چون با توجه به اين خط از كد اول:
1
private List<Component> _children = new List<Component>();

طول عمر كلاس كامپوننت وابسته به كلاس composite است، و به عبارتي كلاس component‌بدون كلاس Composite غير قابل تصوره كه اين تعريف دقيقا مفهوم رابطه Composition‌رو ميرسونه حالا موندم چرا اينجا از رابطه Aggregation استفاده شده!؟

هدف الگوی Composite امکان "دسترسی پک شکل" به یک ساختار سلسه مراتبی درختی و یا مرکب از اشیاست. بیشتر منظورش کل به جز بودن و ساختار اشیاست، بنابراین رابطه رو با Aggregationl مدل کرده نه Composition (گول نام Composite رو نباید بخوری اینجا)
اگه با Composition مدل میکرد محدودیت زیادی رو بین Componentها میزاشت و الگو رو محدود به موارد خاصی می کرد. ضمنن زمانی که شما قرار هست به طور تو در تو و بازگشتی رابطه تعریف کنی Composition یعنی اینکه هر کی فقط تا وقتی وجود داره که شی صاحبش هم وجود داشته باشه... این یعنی یا همه هستن یا همه نیستن! که تو کاربرد های الگوی Composite منطقی نیست. نمی دونم منظورم رو میگیری؟ فرق رابطه Aggregation با Compostion رو خوب درک کردی؟
Composition خودش یه نوع Aggregation هستش اما خیلی قوی! یعنی اون شی داخلی فقط واسه این هست که شی بیرونی باشه!!! بیرونی بمیره، درونی هم باید بمیره! بیرونی تمام طول عمر و جریان اطلاعات رو به درونی کنترل می کنه. این محدودیت ها توی این الگو اصلن مطرح نیست.

وقتي در مورد روابط در uml صحبت ميكنيم بايد به مفهوم بصري اش نگاه كنيم يا به كد؟ مثلا بايد به اين نگاه كنيم كه چون دكمه هاي مينيمايز و ماكسيمايز و خروج وابسته به پنجره هستند رابطه بين اينها از نوع composition است يا بايد به كد نگاه كنيم؟

UML برای حرف زدن بین آدما به زبان شی گراست! مثل زبان مادری! یا زبان انگلیسی! UML رو میشکن تا بتونن یه سیستم یا یه نرم افزار رو خوب بفهمن و بسازن و نگهش دارن! UML رو از روی کد نمیکشن. خودت رو نباید توی این مسائل قوطه ور کنی. سعی کن یاد بگیری و درست و بجا ازش استفاده کنی. خیلی سختش نکن برای خودت.

همچنين چرا اينقدر تفاوت در توضيح وجود داره، يه جاهايي اصلا به رابطه Dependency اشاره نشده، يه جايي تفاوت Dependency و Assosiation‌ بيان شده. يه جا پياده سازي اينترفيس توسط كلاس هاي تابعه از نوع realization عنوان شده و يه جاي ديگه از نوع generalization .

هر متنی رو نخون. اینا مباحث کلاسیک و بازی هستن توی نرم افزار. و گاهی تفسیرای مختلفی ازشون شده. اما درک و مفهوم کلی همیشه یکیه ازشون.
Dependency کلن به رابطه یک چیز (شی) به چیز دیگه میگن. یعنی اگه دیگری رو تغییر بدیم اون شی دچار تغییر میشه احتمالن. این ابتدایی ترین رابطه بین دو موجود در دنیای نرم افزار هستش. (مثلن اسم هر کلاسی که توی کلاست داری استفاده می کنی هر جاش که باشه)
Assosiation همون dependency هستش وقتی که شدید تر به چشم میاد. مثلن وقتی یک پراپرتی تو کلاست میزاری از نوع کلاس B! این یعنی دیگه یه B توی کلاست تعریف کردی! این میشه Association!
Generalization رابطه از فرزند به پدر هستش به معنی کلی کردن و چشم پوشی کردن از جزییات پیاده سازی
Realization برعکس همون رابطه بالا هستش یعنی از پدر به فرزند! همین!

یک کلام:
همه قرار نیست مفاهیم رو توی UML به یک شکل نشون بدن! ممکنه به N شکل بشه اینا رو ترسیم و حتی پیاده سازی کرد تو کد! گاهی این جزییات اصلن مهم نیست. مواقع کمی پیش میاد که خیلی مهمه اما!
همون الگوی Composite رو میشه با Composition هم پیاده سازی کرد! اون یه ایده اس! ممکنه شما جایی نیاز داشته باشی که با Composition انجامش بدی بجای Aggregation!
منظورو میگیری؟ یعنی مفاهیم رو درک کن و ازشون استفاده کن. به فکر این نباش که چرا فلان جا اینطوری کرد یه جا دیگه اونطوری! خیلی مواقع میشه یه رابطه ای که تو یه نرم افزار Composition هستش تو یه کابرد دیگه باید Aggregation باشه!!! پس اینا همه تو شرایط مسئله معنی پیاده می کنن و استفاده میشن.

اگه سوال داشتی اینجا بپرس اگه توضیح بیشتر خواستی بهم تو مسنجر پی ام بده

[Programmer 1]

ممنونم بابت وقتي كه گذاشتيد ولي در بين حرف هاتون ابهامات زيادي وجود داره.

هدف الگوی Composite امکان "دسترسی پک شکل" به یک ساختار سلسه مراتبی درختی و یا مرکب از اشیاست. بیشتر منظورش کل به جز بودن و ساختار اشیاست، بنابراین رابطه رو با Aggregationl مدل کرده نه Composition (گول نام Composite رو نباید بخوری اینجا)

من تعريف دقيق اين الگو رو ميدونم مشكل من در uml diagram اي است كه براي اين الگو تعريف شده،‌ ضمنا ما براي تعريف رابطه بين دو كلاس در uml به مفهوم الگو نگاه نمي كنيم، بنده مي تونم همين الگوي composite رو به گونه اي پياده سازي كنم كه چنين رابطه اي بينشون وجود نداشته باشه، لذا اصلا به ذهنم خطور نكرده كه رابطه رو با اسم الگو اشتباه كنم!

UML برای حرف زدن بین آدما به زبان شی گراست! مثل زبان مادری! یا زبان انگلیسی! UML رو میشکن تا بتونن یه سیستم یا یه نرم افزار رو خوب بفهمن و بسازن و نگهش دارن! UML رو از روی کد نمیکشن. خودت رو نباید توی این مسائل قوطه ور کنی. سعی کن یاد بگیری و درست و بجا ازش استفاده کنی. خیلی سختش نکن برای خودت.

درسته،‌ولي نه اينقدر بي ضابطه اگه قرار بود كه uml فقط يك زبان مشترك براي فهميدن منطق برنامه به صورت بصري بود در همين باقي مي موند و به استاندارد تبديل نميشد، وقتي هم چيزي استاندارد ميشه نبايد بگيم خيلي سخت نگيريم و بايد بين تك تك واژه ها و كلمات تفاوت عميق قائل بشيم! اگه واقعا قرار باشه اينقدر بي ضابطه باشه كه فقط در حد يك زبان مشترك باشه، ترجيح ميدم اصلا به سمتش نرم!

هر متنی رو نخون. اینا مباحث کلاسیک و بازی هستن توی نرم افزار. و گاهی تفسیرای مختلفی ازشون شده. اما درک و مفهوم کلی همیشه یکیه ازشون.
Dependency کلن به رابطه یک چیز (شی) به چیز دیگه میگن. یعنی اگه دیگری رو تغییر بدیم اون شی دچار تغییر میشه احتمالن. این ابتدایی ترین رابطه بین دو موجود در دنیای نرم افزار هستش. (مثلن اسم هر کلاسی که توی کلاست داری استفاده می کنی هر جاش که باشه)
Assosiation همون dependency هستش وقتی که شدید تر به چشم میاد. مثلن وقتی یک پراپرتی تو کلاست میزاری از نوع کلاس B! این یعنی دیگه یه B توی کلاست تعریف کردی! این میشه Association!
Generalization رابطه از فرزند به پدر هستش به معنی کلی کردن و چشم پوشی کردن از جزییات پیاده سازی
Realization برعکس همون رابطه بالا هستش یعنی از پدر به فرزند! همین!

درسته قبول دارم هر متني رو نخونم ولي شما يك متن مرجع معرفي كنيد با تمامي ضابطه ها و طبق استاندارد با كمال ميل مي پذيرم.
روابطي كه تعريف كرديد رو از منابع مختلفي بررسي كردم و دنبال اين نوع تعاريف با مثال هاي شهودي نيستم در اين مطلع هستم ولي من دنبال اين هستم كه اين روابط روي كد نمايش داده بشه، مثلا دو تا كلاس بيان بشه و رابطه اشون دقيقا مشخص بشه. واقعا بايد در سطح عميق تري اين موضوع بررسي بشه.

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

با اين جمله كاملا مخالفم، پس اين زبان مشترك به چه دردي ميخوره واقعا! uml يعني اينكه وقتي از يك الگوي استاندارد مهندسي صحبت ميكنيم، اون دياگرام استاندارد uml بايد توي ذهن شكل بگيره، نه اينكه توي ذهن هر كسي شكل خاصي از اون دياگرام شكل بگيره، شايد بگيد كد مهمه،‌ خب اگه در نهايت بر اساس كد تصور شكل ميگيره پس اين دياگرام به چه دردي ميخوره!

تك تك توضيحاتتون رو خوندم ولي احساس ميكنم بايد تجديد نظري توي توضيحاتتون داشته باشيد،‌ اين نوع تعاريف براي برنامه نويسان مبتدي و فقط در حد كار راه اندازي براي يك پروژه دانشجويي كاربرد داره،‌ بنده در يك سطح عميقتر، دقيقتر و علمي تر مي خوام اين قضيه بررسي بشه.

بازم ممنونم بابت وقتي كه گذاشتيد و به خاطر وقتي كه گذاشتيد تشكر كردم ولي واقعيتش به پاسخ دقيقي نرسيدم هنوز!

[cups_of_java]

ضمنا ما براي تعريف رابطه بين دو كلاس در uml به مفهوم الگو نگاه نمي كنيم

یا من منظورتو نمیگیرم یا من منظورم رو خوب نمی رسونم بهت! ببین اتفاقن شما از روی مفهوم وجودیه مسائل مدل می کنی روابط رو!!! (رابطه به تنهایی معنا نداره)

درسته،‌ولي نه اينقدر بي ضابطه اگه قرار بود كه uml فقط يك زبان مشترك براي فهميدن منطق برنامه به صورت بصري بود در همين باقي مي موند و به استاندارد تبديل نميشد، وقتي هم چيزي استاندارد ميشه نبايد بگيم خيلي سخت نگيريم و بايد بين تك تك واژه ها و كلمات تفاوت عميق قائل بشيم! اگه واقعا قرار باشه اينقدر بي ضابطه باشه كه فقط در حد يك زبان مشترك باشه، ترجيح ميدم اصلا به سمتش نرم!

نگرش های مختلفی به این داستان هست... گروهی هستن که قصد دارن UML رو به کد قابل اجرا ترجمه کن شاید اسمشون رو شنیده باشی: Executable UML و یا MDA... اما جدا از اونا... شما UML رو میکشی تا مدل سازی کنی و بعضن به برنامه نویس بگی چی میخوای بسازی... نه اینکه انقدر پر از جزییاتش کنی که بمونی تو گلش! نمی دونم چقد تجربه مدل سازی تو دنیای واقعی داری یا چقد از داستان های واقعی خوندی.... مدل های پیچیده و خیلی با جزییات مهم ترین عامل شکست شما تو یه پروژه می تونن باشن.

درسته قبول دارم هر متني رو نخونم ولي شما يك متن مرجع معرفي كنيد با تمامي ضابطه ها و طبق استاندارد با كمال ميل مي پذيرم.
روابطي كه تعريف كرديد رو از منابع مختلفي بررسي كردم و دنبال اين نوع تعاريف با مثال هاي شهودي نيستم در اين مطلع هستم ولي من دنبال اين هستم كه اين روابط روي كد نمايش داده بشه، مثلا دو تا كلاس بيان بشه و رابطه اشون دقيقا مشخص بشه. واقعا بايد در سطح عميق تري اين موضوع بررسي بشه.

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

ا اين جمله كاملا مخالفم، پس اين زبان مشترك به چه دردي ميخوره واقعا! uml يعني اينكه وقتي از يك الگوي استاندارد مهندسي صحبت ميكنيم، اون دياگرام استاندارد uml بايد توي ذهن شكل بگيره، نه اينكه توي ذهن هر كسي شكل خاصي از اون دياگرام شكل بگيره، شايد بگيد كد مهمه،‌ خب اگه در نهايت بر اساس كد تصور شكل ميگيره پس اين دياگرام به چه دردي ميخوره!

یک نمودار UML یک حرف رو میزنه و به طور استاندارد همه باید برداشت نسبتن یکسانی از دیدنش داشته باشن. اما یک مسئله به طروق مختلفی مدل میشه.... بیش از یک مدل میشه UML کشید برای یک مسله و میشه همشون هم درست باشه.... فقط میشه مقایسشون کرد!

واقعيتش به پاسخ دقيقي نرسيدم هنوز

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

[Programmer 1]

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

نه دوست عزيز همچين قصدي نداشتم و ندارم كه بخوام بحث كنم، وقتم اينقدر آزاد نيست كه بخوام با يه نفر بحث كنم حرفم رو به كرسي بنشونم،‌ آخه كه چي؟ براي چي؟! :) شايد لحنم باعث شده اينطور فكر كنيد،‌البته حق داريد ولي متاسفانه من وقتي به يك تناقض مهم ميرسم كمي اخلاقم بد ميشه و سيستم به هم ميريزه. البته اميدوارم كه شما حرفهاتون با يك پشتوانه علمي و بر اساس تجربيات دانسته هاي علمي باشه و نه بر اساس نقطه نظر شخصي!

حالا باقي حرف هاتون در حالت كلي كمي تا قسمتي درسته و من هم قصد بحث در اين رابطه رو ندارم چون از موضوع دور ميشيم، اجازه بديد بحث رو با يك مثال روشنتر باز كنم تا انشاءا... به جاهاي خوبي برسيم.

ببينيد فرض مثال ما يك اينترفيس با نام IChangable و يك كلاس با نام Car داريم حالا كلاس Car از اين اينترفيس استفاده ميكنه و متدهاش رو پياده سازي ميكنه. در اين حالت رابطه بين اين دو كلاس بايستي از نوع Realization باشه. حالا اگه به جاي همون اينترفيس از يك كلاس آبستركت با چند تا متد Virtual استفاده كنيم بايستي رابطه بين دو كلاس رو از نوع Generalization در نظر بگيريم چون كلاس تابعه Car در پياده سازي متد ها مختار هست.

هر دوي اين رابطه ها مفهوم پياده سازي اختياري/اجباري كلاس مادر در كلاس تابعه رو ميرسونند. حالا مگه ميشه بين اين دو مفهوم مهم كه الگوريتم و منطق برنامه رو تحت تاثير قرار ميده، تفاوت قائل نشيم؟! مگه ميشه اينجا زيادي سختگيري نكنيم؟

براي مثال اين دو دياگرام مرتبط با الگوي Strategy رو در نظر بگيريد،‌ هر كدوم رابطه بين ConcreteStrategy‌و Strategy رو به نوعي بيان كردند.




حالا چند تا سوال.

اگه نبايد زياد سخت بگيريم پس اين تفاوتي كه بين Realization‌ و Generalization وجود داره براي چيه؟ اصلا چرا دو تا رابطه در uml تعريف شده؟!
يا براي اين بي ضابطه بودن هم رنج قانوني تعريف شده و يا نه اصلا ضابطه اي وجود نداره؟ اگه وجود داره كجاست؟ اگه وجود نداره پس اصلا چرا از يك الگوي نادرست استفاده كنيم.

[cups_of_java]

اميدوارم كه شما حرفهاتون با يك پشتوانه علمي و بر اساس تجربيات دانسته هاي علمي باشه و نه بر اساس نقطه نظر شخصي!

من شاید 10% حرفام بر اساس برداشت شخصیم از مسائل و تجربه باشه... اما جزییاتی که میگم و 80% حرفام بر اساس چیزایی که از "بزرگترین استاد شی گرایی ایران" یاد گرفتم و کتابایی که خوندم، هستش. از 10% بقیش هم بگذریم.

من وقتي به يك تناقض مهم ميرسم

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

هر دوي اين رابطه ها مفهوم پياده سازي اختياري/اجباري كلاس مادر در كلاس تابعه رو ميرسونند. حالا مگه ميشه بين اين دو مفهوم مهم كه الگوريتم و منطق برنامه رو تحت تاثير قرار ميده، تفاوت قائل نشيم؟! مگه ميشه اينجا زيادي سختگيري نكنيم؟

آخ آخ! در این مورد حق با شماست و این اشتباه من بوده. من فرق رابطه Generalization و Specialization رو گفتم... رابطه Specialization برعکس Generalization هست که در طراحی شیگرا استفاده میشه.
در مورد Realization کاملن حرفت درسته و حالتی از Inheritance هست که شما واقعن چیزی رو که وجود نداره هنوز Implement می کنی (بالا نوع انتزاعی داری) در حالیکه Generalization یک Inheritance معمولی هستش.

بنابراین من منظورم از بی ظابطه بودن اینجا نبوده... بلکه جایی بوده که شما به عنوان مثال یه Sequence Diagram رو انقدر شلوغش می کنی که دیگه نمیشه فهمیدش! یا مثلن جایی که Class Diagram رو پر از رابطه ها و association هایی می کنی که عینن توی کد هست و نمودارت دیگه به درد طراحی نمی خوره!

يا براي اين بي ضابطه بودن هم رنج قانوني تعريف شده و يا نه اصلا ضابطه اي وجود نداره؟ اگه وجود داره كجاست؟ اگه وجود نداره پس اصلا چرا از يك الگوي نادرست استفاده كنيم.

به عنوان مثال: تو یه زبانی مثل Cپلاس پلاس شما انواع ساختار ها مثل اشاره گر و کنترل حافظه و طول عمر اشیا رو داری. اونجا خیلی خوب میشه فرق انواع dependency و association رو نشون داد اما مثلن توی جاوا اینطور نیست و شما فقط ارجاع داری!!!
مثلن پیاده سازی aggregation و composition توی جاوا یکیه! (شکل کدش) اما توی سی پلاس پلاس شما composition رو با Member variable ها نشون میدی در صورتی که aggregation رو با رفرنس یا اشاره گری از نوع اون کلاس جز نشون میدی!!!

می خوام بگم خیلی از این جزییات گاهن به زبان برنامه نویسیت هم بر میگیرده! اگر برگرده و شما تو UML خیلی زود بخوای اینو نشون بدی... داری خلاف اصول طراحی که جدا بودن از محیط و تکنولوژی رو ایجاب می کنه رفتار می کنی. این جزییات باید توی طراحی تفضیلی و خیلی دیر تر بیاد تو داستان!

در کل یه نگاهی به مجموعه مقاله های این سایت بکن... میاد دستت که ایده کلی استفاده از UML تو کار واقعن چطوریه:

http://www.agilemodeling.com/essays/umlDiagrams.htm
http://www.ambysoft.com/onlineWritings.html#Modeling
http://www.agilemodeling.com/princip...elWithAPurpose

[cups_of_java]

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

اين الگوي composite هستش كه بنده در مورد قسمتي از نمودار ابهام دارم، سوالم اين هست كه چرا رابطه بين كلاس Composite و componenet در نمودار از نوع Aggregation است در حالي كه با توجه به كد من احساس ميكنم بايد رابطه از نوع Composition باشه چون با توجه به اين خط از كد اول:

1
private List<Component> _children = new List<Component>();


طول عمر كلاس كامپوننت وابسته به كلاس composite است، و به عبارتي كلاس component‌بدون كلاس Composite غير قابل تصوره كه اين تعريف دقيقا مفهوم رابطه Composition‌رو ميرسونه حالا موندم چرا اينجا از رابطه Aggregation استفاده شده!؟

اگه پیاده سازی Composite رو توی خود کتاب GOF که با سی پلاس پلاس هست ببینی متوجه میشه که Aggregation هستش نه Composite! چراش رو بهت گفتم تو پستای بالایی. من تونستم پیاده سازی صحیح سی شارپیش رو برات پیدا کنم
اینم ببین خالی از لطف نیست

اون چیزی که من میخواستم بهت بگم این بوده که: الگوی Composite توی هر زبانی با جزییات متفاوتی و تغییراتی می تونی پیاده سازی بشه. این بستگی به صورت مسله داره بستگی به امکانات اون زبان یا محیط پیاده سازی هم داره!!! پس این جزییات تو این الگو مهم نیست که مثلن Aggregation باشه یا Composition! (اینا تضاد نیست) به جای اینکه ذهنتو با ایناش درگیر کنی به این فکر کن که فلسفه Composite چیه!؟ چرا اومده؟ کدوم نقطش مهم ترین تاثیر رو تو کدت میزاره؟ و اصن تمرکز الگو رو کدوم قسمتشه؟ (اگه اون لینک بالایی رو خونده باشی می تونی جواب این سوال ها رو بدی...)


ولی خب میشه گفت اون سایتی که لینکشو دادی خیلی با دقت و جزییات نوشته نشده مطالبش! سراغش نرو... (یه نصیحت که به تجربه شخصیم و تایید خیلی از دوستان برمیگرده رو بهت بگم: تو مطالعه اصول مهندسی نرم افزار و الگو ها و UML و ... خیلی سمت مطالب .netی و یا سایت های مایکروسافتی نرو. خیلی سواد زیادی ندارن. شما حتی تو سایت خود مایکروسافت هم مطالبی متونی بخونی که دید درستی از شیگرایی بهت نمیده!)
این تقریبن برای همه توی دنیای نرم افزار جا افتاده که تکنولوژی های نرم افزاری مایکروسافتی و به تبع اون توسعه دهندگانی که با اونا کار می کنن از فقر شی گرایی و الگو های کلاسیک و غنی رنج میبرن!!! شما حتی تو MVC هم میری... داستان الگوی MVC اونا خیلی با MVC های رایج Opensourceی ها فرق می کنه! دیدت رو کلن محصور می کنه به خودشون.

وقتي در مورد روابط در uml صحبت ميكنيم بايد به مفهوم بصري اش نگاه كنيم يا به كد؟

نمودار ها قبل از کد کشیده میشن.

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

هیچ وقت سعی نکن جزییات کدت رو توی نمودارت نشون بدی همشو