4.3.1 Multiplicities for the Hospital System
Consider first the association between and . Here are some extracts from the requirements document:
A patient may be treated by any number of doctors …
A doctor can treat any number of patients.
The first extract indicates that there is no upper limit on the number of doctors who have treated a patient. It is also possible that a patient has not been treated by any doctors; they may only just have been admitted to the hospital, for example. So the multiplicity of at the end is .
The second extract states that a doctor can treat any number of patients. Allowing for the situation where a doctor has not yet treated any patients, the multiplicity at the end is also .
Now consider the association between and . Here are some extracts from the requirements document:
In the hospital, there are a number of wards, each of which may be empty or have on it one or more patients.
Each patient is on a single ward …
The first extract states that a single object may be linked to 0, 1 or more objects, indicating a multiplicity of at the end of the association. The second says that each patient is on one ward. Thus each object is linked to exactly one object. The multiplicity of at the end is therefore 1.
The class diagram in Figure 18 shows the multiplicities for the and associations.
Figure 18 Multiplicities for the and associations.
You may have wondered why the multiplicities for do not take account of the statement ‘Every ward has a fixed capacity, which is the maximum number of patients that can be on it at any one time …’ so that in practice no ward can have the unlimited number of patients indicated by a multiplicity of . This is because an association represents all the links that are its instances. Different wards have different capacities, so it would not be possible for the multiplicity at the end of the association to specify an upper limit that would apply to all objects. If the requirements had stated, for example, that all wards have a capacity of 15, we could have dispensed with the attribute in , and modelled the limit by a multiplicity of at the end of .
In general, if you do not know the upper limit for a multiplicity, then the best you can do is assign an upper limit of *. In practice this is likely to indicate an unknown – and possibly variable – upper limit rather than an infinite one.
Make a sketch of the diagram in Figure 18, and add the multiplicities for the associations , , and .
You will need to refer to the requirements document for the Hospital System: click on the link below.
Figure 19 shows our class diagram.
Here is a brief justification of our solution, including relevant extracts from the requirements document:
Each team is headed by a consultant doctor who is … in the team.
Each doctor is in exactly one team.
Remember that consultant doctors are a kind of doctor, so that it is possible to deduce from the second extract that ‘Each consultant doctor is in exactly one team.’ Because the first extract specifies that a team must be headed by a consultant doctor who is in that team, it can also be deduced that each consultant doctor can only head one team.
Each team is headed by a consultant doctor… in the team.
The rest of the team are all junior doctors, at least one of whom must be at grade 1.
Each doctor is in exactly one team.
The first two extracts indicates that each team must contain at least two doctors – the consultant doctor that heads it, and at least one junior doctor at grade 1, so at least two in all.
The third extract provides the multiplicity at the end.
Each patient is … under the care of a single team of doctors … .
This tells us that each object will be linked to exactly one object. There is no information on the number of patients that can be cared for by a team, so we use * for the upper limit at the end. Since there is no information to the contrary, we assume that it is also possible that there are times when a team has no patients under its care, for example when a team is newly constituted, or when all the patients under its care have been discharged.
…the consultant who heads that team is responsible for the patient.
This is similar to the association. Each patient is the responsibility of a single consultant doctor, and each consultant doctor may have responsibility for zero, one or more patients.
Suppose that a particular patient, represented as the object called , has been treated by a particular doctor, , on three different occasions. In an object diagram modelling the system domain at some point after these three treatments have taken place, how many links would be needed between and ? may be a Object, or it may be a object. The actual class is irrelevant here: any kind of doctor may be involved in treating a patient.
There would be only one link. Although a single object can be linked to zero or more objects, there can, for a particular association, only ever be a single link between two particular objects. As far as the conceptual model is concerned, either a particular doctor has treated a particular patient or not. Multiple treatments are not recorded. (We will return to this in the next section.)
A multiplicity specifies the number of different instances of a class that can be linked to a single instance of an associated class, not the number of links between particular instances of two classes. However, it is possible to have two or more associations between two classes, as in the case of and between and . This might result in there being two links between two objects.
In this section you have learnt various techniques for identifying associations between classes, which represent the links between the objects of these classes. You also learnt about the important role of multiplicities, and how to identify and specify them.