Class Diagrams – Part 2

Class Diagrams – Part 2

Reading Time: ~ 4 minutes

My dear Softects,

this is the segue from Part 1. If you haven’t checked it out I recommend you to go and do it… now would be good…


The Class Diagram – Where we left off

On part 1 we talked about associations and the contents of the class diagram component. This time we are expanding on that with some simple, but powerful, concepts.

Let’s get on with it.


Generalization can be seen as the IS-A rule. That is: a generalized class is simply a sub-version of the class which it generalizes from.

In programming this concept translates to the concept of inheritance, however since we are still in UML we don|t think about the programming side of it (yet) we represent this by a line with a hollow arrow. The arrow ends in the class which is the parent, a.k.a. the super-class and starts from the class that is inheriting from it, i.e. the child class.

PlantUML Syntax:<br />
Person <|– PoliceOfficer<br />
Person <|– Accountant<br />
Hide Methods<br />
Hide Fields<br />

By making the use of generalization we are saying that the child object contain all attributes and actions of the parent class. Yes, the child can do some of the actions a bit differently, but still, all the attributes and other actions are the same. For example on the example above we can have the following action on the person class:

+ seeRobberyInProgress() : void

Now the PoliceOfficer class may implement something like:


Meanwhile the Accountant class:


So although both have the same method they implement it very differently. If you want to know more check the article on Overloading vs Overwriting.

Let’s be fair

Generalization is not always a walk in the park. Sometimes the fact that your are generalizing an object happens to lead to some heavy sub-types! Since the sub-type is getting the properties and operations of his parent type, it might be getting more than he wanted! So it is worth to be critical on what should go where when designing your system to avoid this kind of problems in the future.


A dependency exists if a change in the one type directly affects the other type. This is represented in UML by a dotted line with an arrow at the end, as the following picture shows:

PlantUML Syntax:<br />
EmployeeListView .> Employee<br />
Employee .> EmployeeGateway<br />
Hide Methods<br />
Hide Fields<br />
Hide Circle<br />

This shows that the EmployeeListView depends on Employee, i.e. a change in the Employee class may cause an undesirable effect in the ListView. It is also worth noticing that the dependency shown here is unidirectional, i.e. it goes from the ListView to the Employee. That signifies that a change in the ListView does not affect the Employee, but the other direction does not allow us to say the same.

In general this is something we want to minimize as much as possible. I often see large projects struggling with these and if it is out of control than it is hard to make a change to the system without affecting some other part of the system you didn’t intend to.

How does a dependency gets created?

Dependencies happens for various reasons: you are maybe creating an instance of your type in the other, you are passing messages between the types, you are using the one type as a parameter in another operation.

All these cases listed above might make it so that a simple change in the one class, makes that all actions in which it was used on the dependent class are broken. A good example of this is the change in API from some library your code depended on.

How should I represent my dependencies?

It is an futile battle to try and put all your dependencies in the UML of the part of the system you are trying to represent! Be wise and choose the most relevant ones to convey the message you want with that representation of that part of the system.

Annotations on Dependency

You can add some keywords to help you to better clarify what kind of dependency you are dealing with. This is not an exhaustive list, nor there is one. You are free to make the best judgement of what your case needs:

  • <<call>> – the source calls an operation in the target.
  • <<create>> – the source create an instance of the target.
  • <<use>> – the source requires the target for its implementation
  • <<parameter>> – the source uses the target as a parameter in an operation.
  • <<derives>> – the source is derived from the target

PlantUML Syntax:<br />
EmployeeListView .> Employee: <<use>><br />
Hide Methods<br />
Hide Fields<br />
Hide Circle<br />


You can use anything to describe constraints: notes and comments (we’ll talk about them shortly), as a word on an association line, etc. The only thing you must do is to put these constraints inside curly braces: {}.

This allow someone reading your representation to know some kind of restriction this implementation has:

PlantUML Syntax:<br />
GroceryList “1” –> “{ordered}” Item<br />
Hide Methods<br />
Hide Fields<br />
Hide Circle<br />


Notes and Comments

Last but not least we have notes and comments. Now personally I don’t like these too much. I believe a good design doesn’t need those or at most can use them in very rare occasions. But you CAN use them and that is why we are here: To learn!

Notes can stand on its own or they can be linked with a dotted line to the elements they are commenting on, which can be any element in the class diagram: a type, an association, a generalization…

There is not a lot to it, so here with the examples:

PlantUML Syntax:<br />
class Object<br />
Object <|— ArrayList</p>
<p>note “This is a floating note” as N1<br />
note “This note is connected\nto several objects.” as N2<br />
Object .. N2<br />
N2 .. ArrayList</p>
<p>note “In java, every class\nextends this one.” as N3<br />
N3 — Object</p>

Note> PlantUML (the library rendering these diagrams) also makes use of these balloons for notes. I would use at most the dotted line.


Alright aspiring Softects! That was it for this rendition of Class Diagram! Hope to see you soon!



Yours truly,

Leave your opinion, start a discussion, share an experience or just a compliment...

%d bloggers like this: