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

Use Case Diagram Relationships Explained with Examples

When it comes to drawing use case diagrams one area many struggles with is showing various relationships in use case diagrams. In fact many tend to confuse <<extend>>, <<include>> and generalization. This article will look into various use case diagram relationships in detail and explain them using examples. To get a deeper understanding of use cases check out our use case diagram tutorial. If you want to draw them while learning you can use out tool to create use case diagrams.

There can be 5 relationship types in a use case diagram.

• Association between actor and use case
• Generalization of an actor
• Extend between two use cases
• Include between two use cases
• Generalization of a use case

Let’s take a look at these relationships in detail.

Association Between Actor and Use Case

This one is straightforward and present in every use case diagram. Few things to note.

• An actor must be associated with at least one use case.
• An actor can be associated with multiple use cases.
• Multiple actors can be associated with a single use case.

Different ways association relationship appears in use case diagrams

Check out the use case diagram guidelines for other things to consider when adding an actor.

Generalization of an Actor

Generalization of an actor means that one actor can inherit the role of the other actor. The descendant inherits all the use cases of the ancestor. The descendant has one or more use cases that are specific to that role. Let’s expand the previous use case diagram to show the generalization of an actor.

A generalized actor in an use case diagram

Extend Relationship Between Two Use Cases

Many people confuse the extend relationship in use cases. As the name implies it extends the base use case and adds more functionality to the system. Here are few things to consider when using the <<extend>> relationship.

• The extending use case is dependent on the extended (base) use case. In the below diagram the “Calculate Bonus” use case doesn’t make much sense without the “Deposit Funds” use case.
• The extending use case is usually optional and can be triggered conditionally. In the diagram, you can see that the extending use case is triggered only for deposits over 10,000 or when the age is over 55.
• The extended (base) use case must be meaningful on its own. This means it should be independent and must not rely on the behavior of the extending use case.

Lets expand our current example to show the <<extend>> relationship.

Extend relationship in use case diagrams

Although extending use case is optional most of the time it is not a must. An extending use case can have non-optional behavior as well. This mostly happens when your modeling complex behaviors.

For example, in an accounting system, one use case might be “Add Account Ledger Entry”. This might have extending use cases “Add Tax Ledger Entry” and “Add Payment Ledger Entry”. These are not optional but depend on the account ledger entry. Also, they have their own specific behavior to be modeled as a separate use case.

Include Relationship Between Two Use Cases

Include relationship show that the behavior of the included use case is part of the including (base) use case. The main reason for this is to reuse the common actions across multiple use cases. In some situations, this is done to simplify complex behaviors. Few things to consider when using the <<include>> relationship.

• The base use case is incomplete without the included use case.
• The included use case is mandatory and not optional.

Lest expand our banking system use case diagram to show include relationships as well.

Includes is usually used to model common behavior

For some further reading regarding the difference between extend and include relationships in use case diagrams check this StackOverflow link.

Generalization of a Use Case

This is similar to the generalization of an actor. The behavior of the ancestor is inherited by the descendant. This is used when there is common behavior between two use cases and also specialized behavior specific to each use case.

For example, in the previous banking example, there might be a use case called “Pay Bills”. This can be generalized to “Pay by Credit Card”, “Pay by Bank Balance” etc.

I hope you found this article about use case diagram relationships helpful and useful. You can use our diagramming tool to easily create use case diagram online. As always if you have any questions don’t hesitate to ask them in the comments section.