Getting started with UML class diagrams

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 (name and weight) on our class and two public getters for these properties (getName and getWeight).

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:

• + Public
• # Protected
• - Private

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.

Notes

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.

Inheritance

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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

<?php
    class Human {

    protected $name;

    public function __construct($name)
    {
        $this->name = $name;
    }

    public function getName()
    {
        return $this->name;
    }

    }

    class Man extends Human {}

We can represent this in UML with the following diagram:

Association

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 Student class. Teacher may hold a reference to Student in some form of collection, however if we remove Teacher the 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:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

<?php
    class Teacher {

    protected $name;

    protected $students = [];

    public function __construct($name)
    {
        $this->name = $name;
    }

    public function getName()
    {
        return $this->name;
    }

    public function addStudent(Student $student)
    {
        $this->students[] = $student;
    }

    }

    class Student {}

Composition

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.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

<?php
    class Student {

        private $name;

        private $studentId;

        public function __construct($name, StudentId $studentId)
        {
        $this->name = $name;
            $this->studentId = $studentId;
        }

        }

        class StudentId {

        private $number;

        public function __construct($number)
        {
            $this->number = $number;
        }
    }

The class diagram for the above would look like:

Aggregation

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: