3.4 Generalisation relationships
We have already discussed links between particular entities in the system domain, and briefly introduced the concept of an association between two classes – a relationship whereby the instances of those classes might be linked in a way that is significant for the system domain.
Self-assessment question 2
Suggest a possible association between any two of the classes , and , and give it a suitable name.
You might have suggested any of the following, possibly with slightly different names:
(or ) between the classes and ;
(or ) between the classes and ;
(or ) between the classes and .
Note that associations are highlighted by use of the same font that is used for classes and attributes.
We will discuss associations in detail in Section 4.1 of this course. But there is another, quite different, way in which classes can be related. In the context of the Hospital System the classes and are each related to the class by virtue of the fact that all junior doctors and all consultant doctors are also doctors. This is referred to as a generalisation relationship between the classes and , and also between and ; that is, the class generalises each of the classes and .
To put it another way, each of the classes and is a specialisation of the class ; that is, each of the classes and specialises . The class is referred to as the parent class or superclass of and , with the latter two classes being called child classes or subclasses of .
You saw earlier in the course that a conceptual class is represented in a class diagram by a rectangle containing the name of the class and (optionally) the names of its attributes. Figure 5 shows two ways of representing generalisation relationships in a class diagram.
Figure 5 Depicting the generalisation of and by
Either style of diagram is equally acceptable. In your own work you should produce whichever style is easier for you.
Note that the arrowhead points to the more general class. The orientation of the diagram is not significant: there is no need for a child class to appear beneath its parent class in the class diagram, although it frequently does so in practice.
The implication of specialisation is that a specialised class has its attributes and associations defined in two ways: those that are common to all the objects of the more general class, and those that are specific to itself. When we identified attributes for the classes in the Hospital System in Activity 4, we decided that all three of the classes representing doctors would require a name attribute. In view of what we have just said – that a specialised class has all the attributes of its parent class – this attribute can be removed from the and classes, provided it is made clear in the model that both and specialise . In object-oriented parlance, the child classes in a generalisation relationship are said to inherit properties from their parent class. So objects, for example, will have a attribute inherited from , as well as a attribute, which is specific to the class.
You will see later that the class has an association with the class (representing the treatment by doctors of patients). and will also inherit this association. This is appropriate since, for example, the List Patient's Treatment use case for the Hospital System specifies that the system must be able to list the names of doctors who have treated a patient. It does not specify a particular kind of doctor: those listed may well include both junior doctors and a consultant doctor. This relationship between doctors and patients really means that there may be links between junior doctors and patients, and between consultant doctors and patients.
In deciding whether a generalisation relationship is appropriate, it is necessary to consider the kind of entity each class is modelling as well as any common properties and relationships. For example, a ward has a name, but a ward is clearly not a kind of doctor! An appropriate generalisation relationship is one in which it is possible to use a real-world entity represented by an instance of the child class in place of a real-world entity represented by an object of its parent class. This property, in which an instance of one class can be substituted for an instance of another, is known as substitutability. Thus in the statement ‘Each doctor is in exactly one team’, ‘junior doctor’ can be substituted for ‘doctor’.
(It is important to recognise that identifying a generalisation relationship at the conceptual level (i.e. in the conceptual model) does not necessarily mean that the developers are committed to creating a similar inheritance hierarchy at implementation.)
Here are the modified class descriptions for the class and its subclasses. Note the inclusion of comments to indicate the generalisation relationship.
|Class||A doctor at the hospital. Generalises and|
|The name of the doctor|
|Class||A junior doctor at the hospital. Specialises|
|The grade (1, 2 or 3) of the junior doctor|
|Class||A consultant doctor at the hospital. Specialises|