UML DESIGN CLASS DIAGRAMS (DCD)

UML class diagrams show the classes of the system, their inter-relationships, and the operations and attributes of the classes. Class diagrams are typically used, although not all at once, to:

• Explore domain concepts in the form of a domain model
• Analyze requirements in the form of a conceptual/analysis model
• Depict the detailed design of object-oriented or object-based software

A class model is comprised of one or more class diagrams and the supporting specifications that describe model elements including classes, relationships between classes, and interfaces. There are guidelines for:

1. General issues
2. Classes
3. Interfaces
4. Relationships
5. Inheritance
6. Aggregation and Composition

1. General Guidelines

Because class diagrams are used for a variety of purposes - from understanding requirements to describing your detailed design - you will need to apply a different style in each circumstance. This section describes style guidelines pertaining to different types of class diagrams.

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. In Figure 1 you see that the design version of the Order class uses names that conform to common Java programming conventions such as placementDate and calculateTaxes().
7. Model Association Classes On Analysis Diagrams. Figure 2 shows that association classes are depicted as class attached via a dashed line to an association - the association line, the class, and the dashed line are considered one symbol in the UML.
8. Do Not Name Associations That Have Association Classes.
9. Center The Dashed Line of an Association Class.
10. 1. Model Relationships Horizontally
    2. Collaboration Indicates Need for a Relationship
    3. Model a Dependency When The Relationship is Transitory
    4. Depict Similar Relationships Involving A Common Class As A Tree. In Figure 6 you see that both Delivery and Order have a dependency on OIDGenerator. Note how the two dependencies are drawn in combination in "tree configuration", instead of as two separate lines, to reduce clutter in the diagram.
    5. Always Indicate the Multiplicity
    6. Avoid a Multiplicity of "*"
    7. Replace Relationships By Indicating Attribute Types. In Figure 7 you see that Customer has a shippingAddress attribute of type Address - part of the scaffolding code to maintain the association between customer objects and address objects.
    8. Do Not Model Implied Relationships
    9. Do Not Model Every Single Dependency
    10. Center Names on Associations
    11. Write Concise Association Names In Active Voice
    12. Indicate Directionality To Clarify An Association Name
    13. Name Unidirectional Associations In The Same Direction
    14. Word Association Names Left-To-Right
    15. Indicate Role Names When Multiple Associations Between Two Classes Exist
    16. Indicate Role Names on Recursive Associations
    17. Make Associations Bi-Directional Only When Collaboration Occurs In Both Directions. The lives at association of Figure 9 is uni-directional.
    18. Redraw Inherited Associations Only When Something Changes
    19. Question Multiplicities Involving Minimums And Maximums

    7. Aggregation and Composition Guidelines

    Sometimes an object is made up of other objects. For example, an airplane is made up of a fuselage, wings, engines, landing gear, flaps, and so on.A delivery shipment contains one or more packages. A team consists of two or more employees. These are all examples of the concept of aggregation, which represents "is part of" relationships.An engine is part of a plane, a package is part of a shipment, and an employee is part of a team.Aggregation is a specialization of association, specifying a whole-part relationship between two objects.Composition is a stronger form of aggregation where the whole and parts have coincident lifetimes, and it is very common for the whole to manage the lifecycle of its parts. From a stylistic point of view, because aggregation and composition are both specializations of association the guidelines for associations apply.
    
    
    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