Guidelines for UML class diagrams ~ part 2

Today, we continue from where we left off on the topic Guidelines for UML class diagrams ~ part 1. We spoke about the relevant guidelines for General issues, Classes and Interfaces; in this post we will discuss the remaining 3.

4. Aggregation and Composition Guidelines

As it is known an object is made up of other objects. If you were to consider as examples where an airplane consists of wings, a fuselage, engines, flaps, landing gear and so on. A delivery shipment would contain one or more packages and a team consists of two or more employees. These are all examples of the concept of aggregation that illustrates “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, highlighting an entire-part relationship that exists between two objects. Composition is a much potent 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. If you were to consider a stylistic point of view, aggregation and composition are both specializations of association where the guidelines for associations do apply.

1. You should be interested in both the whole and the part

2. Depict the whole to the left of the part

3. Apply composition to aggregates of physical items

5. Inheritance Guidelines

Inheritance models “is a” and “is like” relationships, enabling you to rather conveniently reuse data and code that already exist. When “A” inherits from “B” we say that “A” is the subclass of “B” and that “B” is the superclass of “A.” In addition to this, we have “pure inheritance” when “A” inherits all of the attributes and methods of “B”. The UML modeling notation for inheritance is usually depicted as a line that has a closed arrowhead, which points from the subclass right down to the superclass.

1. Plus in the sentence rule for inheritance

2. Put subclasses below superclasses

3. Ensure that you are aware of data-based inheritance

4. A subclass must inherit everything

6. Relationship Guidelines

At this particular juncture, the term “relationships” will encompass all UML concepts such as aggregation, associations, dependencies, composition, realizations, and inheritance. In other words, if it’s a line on a UML class diagram, it can be considered as a relationship. The following guidelines could be considered as “best practices” and and effort should be made to adhere to them at all times.

Figure A

Figure B

Figure C

1. Ensure that you model relationships horizontally

2. Collaboration means a need for a relationship

3. Model a dependency when a relationship is in transition

4. Depict similar relationships involving a common class as a tree.  In Figure A 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. As a rule it is best to always indicate the multiplicity

6. Avoid a multiplicity of “*” to avoid confusion

7. Replace relationships by indicating attribute types.  In Figure C you see that the customer has a shippingAddress attribute of type Address – part of the scaffolding code to maintain the association between customer objects and address objects.

8. Never model implied relationships

9. Never 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 B is uni-directional.

18. Redraw inherited associations only when something changes

19. Question multiplicities involving minimums and maximums

So while we have made a dent in the interesting subject that is  UML design, you can surely expect more blog posts that are both interesting and compelling on the same subject. We do offer a great deal of information on UML design and would love to field in any questions or doubts that you may have.


Join over thousands of organizations that use Creately to brainstorm, plan, analyze, and execute their projects successfully.

Get started here



Software engineer turned tech evangelist. I handle marketing stuff here at Creately including writing blog posts and handling social media accounts. In my spare time, I love to read and travel.

Leave a comment


19 − 12 =

Back to top