UML or the Unified Modelling Language was developed to help IT professionals a common design language abstracted from specific platforms or programming languages. This article will get you up and running with UML in the form of class diagrams.
The main building blocks
As you can probably guess, the bulk of our class diagram will be made up of classes, abstract classes and interfaces.
The first box is a standard class. We also define properties and methods in here, but we’ll get to that later. Next, we have an abstract class. It’s just like a class, but in italic. The last box is an interface. These are easy to spot, mainly because they say
<< interface >> at the top!
Properties & Methods
While being able to show the class structure of your application is useful, being able to show the properties and methods on these classes is even more useful again.
In the example above, we’ve defined two protected properties (
weight) on our class and two public getters for these properties (
To define a property in the class, we use the format:
visibility name : type
The options we have for the visibility of the property are:
We then define the name of the property followed by it’s type.
Methods are defined in much the same way:
visibility methodName(param: type)
The visibility operators are exactly the same as on the properties.
methodName is the name of the method and we then provide a name and type for each parameter. Abstract methods are shown as italic.
Sometimes you want to give the person reading your diagram some more information than you can with the standard UML constructs, to get around this there is a note representation you can use.
Now that we can display our classes, interfaces, properties and methods in our application design we move on to the real meat of the diagram which is the representations of the relationships between our different objects and how they communicate with the other objects in our application. The types of relationship between different objects are indicated using different types of arrows.
The simplest relationship (also the most overused and possibly dangerous, but that’s another article!) between two objects is inheritance. A simple example would be:
We can represent this in UML with the following diagram:
Association is where one object holds a reference to another object, however the lifecycle of the two objects is totally independent. The common example is a
Teacher and a
Teacher may hold a reference to
Student in some form of collection, however if we remove
Student class should continue to exist independently. Generally, association is the most common type of relationship you’ll use in your UML class diagrams.
I have omitted the methods on
Student to make it more readable. The code for this diagram might look like:
Like association, composition tells us that the object holds a reference to another object, however with composition, the lifecycles of the two objects are linked. If the parent object is destroyed, then so should the child object. A good example of this is when you use value objects.
The class diagram for the above would look like:
Aggregation is a similar concept to association, the main difference being that while the lifecycles of the objects are not linked, there should only ever be one owner of the child object. For example, if our
Student belongs to a
FormTutor class, should
FormTutor ever be destroyed we do not want the
Student also be destroyed, however we do not want the
Student to belong to more than one
FormTutor at a time.
You’d display aggregation as: