UML Class Diagrams Reference
This article is not so much an article but more a point of reference for UML Class diagrams.
If you are like me then you have studied UML and UML class diagrams but use them that infrequently that you often need to refer to reference material for things like whether that should be a white diamond or a black diamond!
So class diagrams are used to show classes in an application and how they relate to each other. It aso shows an overview of class methods, properties etc.
These diagrams are part of UML and are used so that you can read other peoples designs and they can read yours - it gives a common language making communication and collaboration of ideas easier and more reliable. They are particularly useful when showing parts of a system, or isolated ideas. Design patterns for example are a fantastic area in which the use of UML class diagrams brings great benefits.
So lets have a look at a sample class diagram.
We can see that a class diagram is a rectangle and that it is split into three sections stacked on top of each other. The top section is where we put the class name. The second section is where we put class fields and properties and the third section is where we put class methods.
The top section is compulsary but the other two sections may or may not be used as required for the particular purpose of the diagram. Even if the bottom 2 sections are used, it is not necessary to show all attributes and methods - we usually just show the ones of particular interest and significance for the diagram and it's context.
So the class name goes in the top bit but if this is an abstract class then the class name is in italics. If however this isn't a class at all but is an interface then the interface name is put in normal unitalicised text but it contains <<interface>> directly above it. It should also be noted that if we have any abstract methods within an abstract class then these are italicised.
We are able to put symbols next to fields, properties and methods to indicate their levels of access. A - signifies that the access is private while a + indicates that access is public. We can also use a # to indicate that access is protected.
We can also indicate that something in the class is static (eg a method) by underlining it.
We can also place a semi colon and a data type after a field, property or method to indicate what type the data is (for fields and properties) and for methods this shows what the return type is.
If any methods have parameters then these may also be shown in the method signature within the diagram.
So now we have a class diagram we are able to produce a diagram with more than one class in and show how these relate to each other. This is very useful for showing parts of a system, or design ideas in the case of design patterns for example.
A common relationship between classes is of course inheritance and this uses a line with a solid, unfilled arrow on one end as follows.
Another relationship between classes is that of association. For example a customer may have many orders so we have a relationship between the customer class and the order class.
Associations look like this:
Note the type of arrow - arrows are very specific in UML. Now what we can also do is place numbers at each end of the arrow to show things like a customer can have zero or more orders - ie that it is a one to many relationship. We may also have a 1 to 1 relationship and so on.
We actually have two types of association - bi-directional and uni-directional. Uni-diretional associations have an arrow whereas bi-directional associations have no arrow. A uni-directional association indicates that only 1 class knows about the existance of the other.
The different numbers which can be placed at each end of the arrow are as follows:
|
Number/Text |
Meaning |
|
0..1 |
Zero or one |
|
1 |
One only |
|
0..* |
Zero or more |
|
1..* |
One or more |
|
n |
Only n (where n > 1) |
|
0..n |
Zero to n (where n > 1) |
|
1..n |
One to n (where n > 1) |
If we have an association between classes which is weak then this is represented with a dashed line. Weak associations might be when one class has a method which takes an instance of another class as an argument. This is much weaker than say one class having a member field of another class.
It is also possible to place a label on an association such as "has a" in our above example to show that a customer has an order. When adding any such label, if there is any ambiguity as to the direction the label should be read - ie customer has an order or order has a customer then next to the label you can place a black filled triangle/arrowhead indicating which direction the label should be read,
When we are showing these kinds of associations, we don't have to show which fields or properties control the associations. For example a Customer class may have an array of Orders or a List of Orders or an ArrayList of orders but it is not necessary to show what the actual relationship is at code level. The association is more high level than that and certainly we do not draw the arrow from one field to another or anything like that.
Another way we can have an association is through the use of a third class. For example we might have a diagram showing an Employer and Employee and the way we will tackle modelling employment is to use a third class - an employment class which points to an employer, an employee and has start dates and end dates and so on. In this case then we can depict this in UML as follows:
We can of course have a relationship between a class and 1 or more interfaces. These can be represented in one of two ways. If the interace exists on the class diagram then we can use a line just like a normal inheritance line except that it is a dashed line. If on the other hand the interface is not present on the class diagram when we can use a lollipop line. Both of these can be seen below.
Two other types of association we can have are composition and aggregation.
These are very simillar concepts but differ in lifetime of objects. Composition means that when one object is made up of other objects then the child objects are conceptually part of the parent object and wouldn't really exist or make sense on their own. Consider an invoice class for example. This might have a collection of invoice line classes. If we have an invoice and then destroy it then we would want to destroy the line items too. It wouldn't really make sense to have invoice line items wandering about in our code all on their own. This is composition.
Aggregation on the other hand still refers to objects being made up of other objects but in this case the child objects can exist in their own right or as part of some other object even.
So aggregation could be that an object exists in its own right. For example consider a 3D computer game where we have a room and a wall in the room is made of bricks. Within the rules of the game we can shoot the wall and it breaks up and we can then pick up a brick and take it out of the room and use it elsewhere to club a zombie to death. In this case then this would be aggregation.
Another example might be that two rooms share a wall. If we destroy one room then the shared wall could still exist as part of the other wall so this would be aggregation.
The example with the brick is a little tricky actually as shooting the wall changes the state of things quite drastically but hopefully you get the idea.
Aggregation and Composition in UML class diagrams are simillar to association arrows but rather than having an arrow head on the end, they have a diamond. The diamond can be either unfilled or filled in black. An unfilled diamond represents Aggregation and a filled black diamond represents composition. See the examples below.
Note that the diamond is at the end where the parent class is - personally I think this is counter intuitive but thats just how my brain works.
Now one of the things which you are likeley to forget is which diamond do you need - an unfilled one or a black one? Well I have a simple memory aid. Look at the capital A of Aggregation. It has a little unfilled white bit at the top so use that to remind you of an unfilled diamond. Also composition implies that killing the parent object means that you should kill the child objects so think death, then think black death then think black diamond. Sounds silly but this is the way memory tricks work.
I'm sure there are many more things we could look at under this topic but I think this is enough to get you off the ground reading and writing uml class diagrams.
Any comments or corrections welcome via the form below.