آموزش UML، آموزش RUP، Class Diagram

class diagramهای UML، کلاس های سیستم، روابط داخلی شان، و عملیات ها و صفات کلاس ها را نشان می دهند. Class diagramها، معمولاً برای موارد زیر استفاده می شوند:

• مفاهیم domain را در شکل یک مدل domain، مرور می کند
• مقتضیات فرم یک مدل مفهومی را تحلیل می کند
• طرحی مفصل از نرم افزار شی گرا یا شی محور را نشان می دهد

یک مدل کلاس، از یک یا چند class diagram و مشخصات حمایتی ای تشکیل شده است که عناصر مدل شامل کلاس ها، روابط بین کلاس ها، و رابط های کاربر را توصیف می کند. برای موارد زیر راهنمایی هایی آورده شده است:

• مسایل عمومی
• کلاس ها
• رابط های کاربر
• رابطه ها
• وراثت
• Aggregation و Composition

1. راهنمایی های عمومی

از آنجایی که class diagramها، استفاده های زیادی دارند — از درک نیاز ها گرقته تا توصیف طرح مفصل شما —باید از سبکی متفاوت برای هر شرایطی استفاده کرد. این بخش، راهنمایی های سبک (style) را که مربوط به انواع مختلف class diagram است، توصیف می کند.

شکل 1: تحلیل و نسخه های طراحی یک کلاس

شکل 2: مدل سازی کلاس های association

1. Identify Responsibilities on Domain Class Diagrams.
2. Indicate Visibility Only On Design Models. 
3. Indicate Language-Dependent Visibility With Property Strings.
4. Indicate Types Only On Design Models.
5. Indicate Types On Analysis Models Only When The Type is an Actual Requirement.
6. Design Class Diagrams Should Reflect Language Naming Conventions. در شکل 1 می بینید که،design version کلاس Order، از نام هایی استفاده می کنند که با Java programming conventionهای رایج از قبیل placementDate و calculateTaxes() هماهنگ می شود.
7. Model Association Classes On Analysis Diagrams. شکل 2 نشان می دهد که association classها به صورت کلاس الصاق شده از طریق یک dashed line به یک association، نشان داده شده اند – خط association، کلاس، و dashed line، یک سمبل در UML محسوب می شوند.
8. Do Not Name Associations That Have Association Classes
9. Center The Dashed Line of an Association Class

2. راهنمایی های Class Style

یک کلاس، یک template موثر است که اشیا ازآن ایجاد می شوند. گرچه در دنیای واقعی، Doug، John، و Bill همگی اشیای دانش آموز هستند، ولی ما کلاس Student را مدل سازی می کنیم. کلاس ها، صفات را توصیف می کنند، اطلاعاتی که مربوط به instance، عملیات، عملکردهایشان است که اشیا آنها را ساپورت می کنند. همچنین کلاسها، رابط های کاربر (interface) را نیز تشخیص می دهد. دقت داشته باشید که شاید نیاز به نرم کردن بعضی از راهنمایی های نامگذاری جهت منعکس کردن زبان یا نرم افزار برنامه نوسی تان داشته باشید که از یک فروشنده طرف سوم خریداری کرده اید.

شکل 3: کلاس OrderItem با و بدون کد scaffolding

1. Use Common Terminology for Names
2. Prefer Complete Singular Nouns for Class Names
3. Name Operations with a Strong Verb
4. Name Attributes With a Domain-Based Noun
5. Do Not Model Scaffolding Code. کد Scaffoldin، به صفات و عملیات هایی بازمی گردد که برای پیاده سازی عملکرد پایه ای در کلاس شما لازم هستند، از قبیل کدی که برای پیاده سازی رابطه با کلاس های دیگر لازم هستند. شکل 3، تفاوت بین کلاس OrderItem را با و بدون scaffolding code نشان می دهد.
6. Never Show Classes With Just Two Compartments
7. Label Uncommon Class Compartments
8. Include an Ellipsis ( … ) At The End of Incomplete Lists
9. List Static Operations/Attributes Before Instance Operations/Attributes
10. List Operations/Attributes in Decreasing Visibility
11. For Parameters That Are Objects, Only List Their Type
12. Develop Consistent Method Signatures
13. Avoid Stereotypes Implied By Language Naming Conventions
14. Indicate Exceptions In An Operation’s Property String. می توان خطاها را با یک UML property string نشان داد.

3. رابط های کاربر (Interface)

یک interface، کلکسیونی از امضای عملیات و/یا تعریف های صفات است که مجموعه ای منسجم از رفتارها را تعریف می کند. interfaceها، در UML parlance، توسط کلاس ها و componentها، پیاده سازی و شناسایی می شوند – تا تشخیص دهد که یک interface، یک کلاس، یا یک component، باید عملیات ها و صفاتی را که توسط interface تعریف می شوند، پیاده سازی کند. هرکلاس یا component معینی، ممکن است هیچ یا چند interface، و یک یا چند کلاس را پیاده سازی کند، یا componentها می توانند همان interface را اجرا کنند.

شکل 5: interfaceها روی UML class diagramها

1. Interface Definitions Must Reflect Implementation Language Constraints. در شکل 5، می بینید که یک standard class box، برای تعریف interface PersistentObject استفاده شده است.
2. Name Interfaces According To Language Naming Conventions
3. Apply “Lollipop” Notation To Indicate That A Class Realizes an Interface
4. Define Interfaces Separately From Your Classes
5. Do Not Model the Operations and Attributes of an Interface in Your Classes. در شکل 5، می بینید که کلاس Shipment، شامل صفات یا عملیات های که توسط دو interface که شناسایی می کند، نمی شود.
6. Consider an Interface to Be a Contract

4. راهنمایی های رابطه (Relationship)

برای راحتی، عبارت relationships، شامل همه مفاهیم UML از قبیل associationها، aggregation، composition، dependencyها، inheritance، و realizationها را شامل می شوند – به عبارت دیگر، اگر خطی روی یک UML class diagram وجود داشته باشد، آن را یک رابطه در نظر می گیریم.

شکل6: Shipping یک order

شکل 7: Modeling یک order

شکل 8: استادها و سمینارها.

شکل 9: مدل سازی افراد در یک دانشگاه.

رابطه ها را به صورت افقی مدل سازی کنید

1. Collaboration Indicates Need for a Relationship
2. Model a Dependency When The Relationship is Transitory
3. Depict Similar Relationships Involving A Common Class As A Tree. در شکل 6، می بینید که هم Delivery و هم Order، یک dependency روی OIDGenerator دارند. توجه داشته باشید که چگونه دو dependency در ترکیب با “tree configuration” ترسیم شده اند؛ به جای اینکه به صورت دو خط جدا جهت کاهش clutter در دیاگرام ترسیم شوند.
4. Always Indicate the Multiplicity
5. Avoid a Multiplicity of “*”
6. Replace Relationships By Indicating Attribute Types. در شل7، می بینید که مشتری ها دارای یک صفت shippingAddress از نوع Address هستند یعنی، قسمتی از کد scaffolding که برای حفظ رابطه بین اشیاء و اشیاء آدرس استفاده می شود–
7. Do Not Model Implied Relationships
8. Do Not Model Every Single Dependency
9. Center Names on Associations
10. Write Concise Association Names In Active Voice
11. Indicate Directionality To Clarify An Association Name
12. Name Unidirectional Associations In The Same Direction
13. Word Association Names Left-To-Right
14. Indicate Role Names When Multiple Associations Between Two Classes Exist
15. Indicate Role Names on Recursive Associations
16. Make Associations Bi-Directional Only When Collaboration Occurs In Both Directions. lives at association در شکل 9، یک طرفه است.
17. Redraw Inherited Associations Only When Something Changes
18. Question Multiplicities Involving Minimums And Maximums

6. راهنمایی های وراثت

وراثت، رابطه های “is a” و “is like” را مدل سازی می کند و شما را به راحتی قادر به استفاده مجدد از داده ها و کد موجود می کند. وقتی "A" از "B" ارث می برد، گفته می شود که "A" زیرکلاس "B" و "B" سوپرکلاس "A" است. به علاوه، وقتی "A" همه صفات و متدهای "B" را به ارث می برد، به آن " وراثت محض" گفته می شود. نشانه گذاری مدل سازی UML برای وراثت، خطی با یک سرفلش (arrowhead) است که از زیرکلاس به سوپرکلاس اشاره می کند.

1. Apply the Sentence Rule For Inheritance
2. Place Subclasses Below Superclasses
3. Beware of Data-Based Inheritance
4. A Subclass Should Inherit Everything

7. راهنمایی های Aggregation و Composition

بعضی اوقات یک شی از اشیاء دیگر دیگر درست می شود. مثلاً، یک هواپیما از بدنه، بالها، موتور، ابزار فرود، دریچه بال هواپیما (فلپ)، و غیره درست شده است. یک delivery shipment، حاوی یک یا دو بسته است. یک تیم متشکل از دو یا چند کارمند است. اینها، مثال هایی از مفهوم aggregation هستند که رابطه “is part of” را نمایش می دهد. موتور، بخشی از یک هواپیما است ، یک package، بخشی از یک shipment است، و یک کارمند، عضوی از یک تیم است. Aggregation، تخصصی از association است، که یک رابطه کل به جزء (whole-part) بین دو جسم است. Composition، شکلی قویتر از aggregation است که "کل" و "اجزاء" عمری همسان دارند، و برای مدیریت چرخه حیاتی اجزای whole، بسیار رایج است؛ زیرا از دیدگاهی سبک دار، aggregation و composition هر دو تخصص های association هستند.

شکل 10: نمونه هایی از aggregation و composition.

1. Apply the Sentence Rule for Aggregation
2. You Should Be Interested In Both The Whole And The Part
3. Depict the Whole to the Left of the Part
4. Apply Composition to Aggregates of Physical Items
5. Apply Composition When the Parts Share The Persistence Lifecycle With the Whole
6. Don’t Worry About Getting the Diamonds Right