7.2 Using invariants to derive associations
Just as there is a relationship between invariants involving attributes and derived attributes, so it is the case that invariants involving links of different associations may indicate that one of those associations can be derived from the others involved in the invariant.
To explore the sorts of interrelationship that can occur between associations, we will start by revisiting the invariant which constrains the allowable links between the classes , and .
Here is the invariant which was formulated in the previous section:
The object linked to any object via is linked via to the object to which that object is linked.
This invariant involves the associations , and , as shown in Figure 30.
Now consider the case of a particular object, say , linked via the association to a object, say , which represents the team that cares for the patient. will in turn be linked via to a object, say , which represents the consultant doctor who heads that team. What the invariant expresses is that the particular object to which must be linked via must be , as shown in the object diagram in Figure 31.
A situation similar to that depicted in Figure 31 holds for all objects. Given any object representing a particular patient, it is always possible to identify the object representing the team which cares for the patient by traversing the link, and then the object representing the consultant doctor who heads that team by traversing the link. As this must be the consultant doctor who is responsible for the patient, it is therefore possible to infer, for any object, the particular object representing the consultant doctor who is responsible for the patient, i.e. the link between the object and the object. In other words, it is possible to derive from and .
The association is called a derived association. As with a derived attribute, the name of a derived association in a class diagram is preceded by a slash, /, as illustrated in Figure 32.
As with derived attributes, you might wonder why the derived association is not simply removed; it is, in a sense, redundant. There are two reasons. The first is that models a relationship that is explicitly mentioned in the requirements document – the responsibility of consultant doctors for patients. It is important, at least at this stage of the development process, that this relationship is explicitly modelled.
The second reason for retaining is that its designation as a derived association is somewhat arbitrary. Consider the following invariant involving , and , which is equivalent to the one above:
The object linked to a given object is linked via to the object to which that object is linked via .
Working from this version of the invariant we could equally well have said that the association could be derived from the and associations, and that it was therefore that was redundant rather than . It is only when the detailed behaviours of the system are analysed in subsequent stages of the development process that we can decide which, if any, of the associations related in this way is actually redundant. However, it is important that the class diagram in the conceptual model should indicate any derived associations that we have identified.
For an association to be derivable, all the links of the association must be derivable. With this in mind, can the association be derived from the associations and ?
Suppose a object (such as in Figure 31) is linked to a object (). Then the object () linked to via must also be linked, via , to . In other words, if there is a object linked to a object, then it is possible to derive the link between the object and the object.
Consider, however, the situation depicted in Figure 33: a consultant doctor represented by heads a team represented by . Suppose also that this particular team does not yet have any patients under its care. This is entirely possible, as indicated by the multiplicity of at the end of . In this case, the consultant represented by would not be responsible for any patients.
Figure 33 A object which is not linked to any objects
We could equally have traversed the links the other way and said, locate first a object linked to and then the object linked to that object.
To derive the link between and shown in Figure 33, it would be necessary to locate first a object linked to via the association and then the object linked to that object via . Neither of these links exists. Therefore it is not possible to derive the link shown in Figure 33.
In summary, we have shown that the link between and in Figure 31 could be derived from the other links in the diagram, but that the link between and in Figure 33 could not (because there are no other links from which it can be derived).
We therefore conclude that because it is not possible to derive all the links of the association, cannot be derived from and .
Reviewing this example, it is instructive to note that what we did to show that is not derivable was to consider a possible combination of objects and links, which conformed to our model, but where an link could not be deduced from other information. This is a generally useful approach, as you will see in the next exercise.
Study the invariant involving the three associations , and given below and the associated extract from the class diagram shown in Figure 34. Decide whether the association can be derived from the other two associations, giving an explanation for your answer.
If is any object, then any object linked to is also linked to the object which is linked to .
Figure 34: The associations , and .
The association cannot be derived. The hypothetical situation portrayed in Figure 35 will demonstrate why.
Figure 35: Links between , and objects
Figure 35 depicts the situation where, at some point in time, the patient represented by is cared for by the team represented by , and has been treated by one of the doctors in that team, represented by . This situation is perfectly acceptable within the conditions imposed on the model. The task is to decide whether, given the links from to and to , it is possible to derive the link between and .
Having traversed the link from to , you could traverse the links to identify all the objects linked to , that is, all the objects that are eligible to treat . However it is not possible to deduce that has treated and that has not.
In summary, a object linked to a object that is linked to a object is not necessarily linked to that object.
Now consider whether it is possible to derive the association from and . Given a object, if there are objects linked to the object, that is, if there are patients cared for by the team represented by the object, then these objects can be identified by traversing the relevant links, while any objects corresponding to doctors who treated these patients can be identified by traversing the relevant links. These objects must be linked to objects via . However, objects corresponding to doctors in the team who have not treated any patients cannot be identified in this way. Consequently, although some of the links are deducible, not all are, and therefore the association is not derivable from and .
Similarly, the association cannot be derived from and .
What the above discussion has shown is that an invariant involving a loop indicates that it may be (rather than will be) possible to derive one of the associations which make up the loop.
Note that a loop may consist of more than three classes and associations.
In this section, you have learnt what is meant by derived attributes and associations, how invariants are used in the derivations, and how they are denoted in the conceptual model. This completes the task of conceptual modelling, and in the next section, all the parts will be drawn together.