UML Class Diagrams
Class Diagrams
When it comes to defining relationship between classes and objects, class diagrams can get very handy. In this post we will go over what they are, how they are defined, when and why to use them.
The Basics
1. Class Definitions
a. Simple Class Definition
Below figure shows the basic and simplest form of a class diagram.
A class is depicted in the class diagram as a rectangle. This rectangle shape is the most common way of representing a class. It is as simple as this. In most cases , you won’t need more to represent a class then only providing its name and its relationship with the other classes.
b. Simple Class Definition
There might be times where you need to provide more information about a class for it to be more clear in terms of responsibilities and relationship in the diagram with other classes and objects.
And sometimes you may want to be more precise for your class representations, making it easier to implement in source code. Whatever the reason might be, here is how you can define a detailed class.
Let’s go over what we did here. First we decided class diagram into three parts:
First part describes the name of the class.
Second part describes class properties.
Third part describes class methods. As you can see, there are couple of more things in the diagram. One of which is the symbols in front of every property and method definitions.
A dash ( # ) denotes private; a hash ( - ) denotes protected and a plus ( + )
denotes public variable or method definitions.
Also the type of a property or an argument to a method is shown after the colon following the property or argument. Similarly, we define the return value of a method after the colon following the method name.
But again, even though it seems tempting to declare much information about a class, using this type of class diagram might pollute the actual intent of the overall diagram as we often use class diagrams to express the relationship between them instead of giving implementation details.
So my suggestion would be; Use it with caution and avoid as much as you can. Use it only when it is really necessary.
2. Association
Associations between classes are denoted with arrows. Most of the time we write the instance variable name that holds reference to the object as well.
We can also put numbers near to the arrow head. That numbers will indicate the number of references that are held. The direction of the arrow indicates that Car holds a reference to Tire.
Instead of specifying a number, you can also use star ( * ). That indicates that a class that are being associated with another class can hold many reference to that chess.
For example :
As in a lot of resources, you could interpret the above figure as
“Classroom HAS may Students.”
Even though this is not wrong and most of the time if you are new to Class and UML diagrams it might be easier to learn that way, I won’t use that term so often. In some cases, that leads to some misunderstanding. So it is better to continue saying
“Classroom HOLDS references to Student class.”
3. Inheritance
When it comes to identifying inheritance. we again use arrow but in a little bit different form.
In this case, most of the time we draw the arrowhead as empty triangle.
Direction of the arrow when denoting inheritance points to the base class. In the following example,
In some books, you can encounter a little bit different kind of arrows indicating inheritance. But the thing in common is the empty triangle. Check out the following example:
Also, when implementing from a interface, in most book you’ll find that arrow is drawn with dashes instead of straight line.
But most of the time that is not big deal to follow. I wanted to mention that as well because when you encounter that usage with interfaces which definitely you will, I don’t want you to get confused :)
4. Aggregation
Aggregation is a form of association. You could say that aggregation is subset of association. I mean, the difference between the two is really subtle.
You could live without ever using aggregation and everything would just be fine. But most likely you’ll encounter in some diagrams. So it is basically a form of association that indicates there is a whole/part relationship.
As you remember, when we define association between two class , we didn’t specifically say that one class owns the other. That wasn’t the case. It was just like one class were using it by holding a reference to the other class.
However, in the case of aggregation we still holds a reference to another class but also we went to point out that one class owns the other or encompass the other.
Better to give a couple of examples here:
As you can see from these examples, the left side classes owns/includes the right side classes. In a simple association this distinction is not necessarily the case. we could have something like this:
In this case, Database class does not own the logger class, or the logger class is not necessarily be used in the Database class. There is no direct whole/part relation between those classes.
Ok, I think we went through enough about aggregation.
So before we delve into composition, I’d like to express one subtle difference between association and aggregation. As we said earlier, there is no strict relation between classes when we use association.
There can be, don’t get me wrong. But there is one thing that actually backs up this distinction between association and aggregation further, that is an association can be bidirectional. Meaning both classes can be using each other.
Check out the next example
As you can see, these two classes use or hold references to each other. That was not the case with aggregation.
So if you used something like
That would be illegal usage of aggregation.
Ok, onto the next one.
5. Composition
Same goes with composition. Composition is also a form of association where parent/child relationship is a bit more strict or strong.
What do I mean by that?
It means that when we set composition between classes , we basically imply that thinking the child class apart from its parent is irrational. They (parent and child class) make so much sense together that when you separate the child, it would be real pain to find a use case for that child class within the system. Another way to put it is that child class exists because of or to support the parent class.
It is also important to be cognizant that we could simply use association arrows instead of composition arrows and the interpretation of overall diagram wouldn’t change much. But again chances are you’re going to see that usage in most places and sometimes you might just want to indicate that strict relation.
Either way, here it is how you can define it:
As you can see from the diagram, Head and Arms classes are strictly tight to the Person class. They are dependent on each other. But there is one more important thing here to worth mention which is that when I say “child class wouldn’t make much more sense without its parent”, it is important to know that we are talking within the scope of the system/application. So it is possible to find a use case for that child class in another application. So this is very important.
Now that we know what composition end aggregation are, let’s discuss the illegal usages of them.
Illegal Usages of Aggregation
When you think the meaning and usage of aggregation, you can agree that below cycles don’t make much sense, so they are illegal to use based on the UML specification
illegal Usage of composition
Conclusion
Class diagrams has a lot of great tools to help us to design great software architectures. It also enables us to express and visualize our ideas, present them, discuss over them and share them.. But it is good to remember that these are just tools to write write, scalable code. It might be tempting to use all available diagram widgets and over-architecting. Just try to avoid that and try to deliver simple, good and extensible design.
Ok guys, that was my last advise for this post. If ye’re curious how to put all together, in the next post I will go over an example.
See you next time :)
