6.1 What is an invariant?
The aim in constructing a conceptual model is to capture all the relevant information about the system domain provided in the requirements document so that this model can form the basis for the structure of the system. To complete the process, there is one more component to add: invariants. In this section, you will learn:
what is meant by an invariant;
how to identify and express invariants.
An invariant is any condition on the objects of a conceptual model, their attribute values and links, which must hold for the requirements to be satisfied and the consistency of the model to be guaranteed. Such a condition represents a constraint on the real-world entities modelled (i.e. a constraint on the system domain).
We start by illustrating this concept with some examples from the Hospital System. You will find it easier to follow this discussion if you have the requirements document and the class diagram for the system in front of you. These can be found in Sections 3 and 4 of the PDF document below.
Click the link below to view section 3 and 4.
Consider the following extracts from the requirements document for the system:
Each patient is … under the care of a single team of doctors …
A patient may be treated by any number of doctors but they must all be in the team that cares for the patient.
These extracts both imply invariants that must be true of our model at all times:
Each object must be linked to one object – not zero, not more than one.
All the objects linked to a object must be linked to the object to which that object is linked.
We can express these two invariants more precisely as follows:
Each object is linked to exactly one object.
If is any object then any object linked to is also linked to the object which is linked to .
The first of these invariants imposes a condition on the number of links that are allowable between objects of two classes. Fortunately, some invariants, such as those concerned with the numbers of links allowed between an object of one class and object(s) of an associated class, may be evident from the class diagram, and so they would not normally need to be expressed in words. For example, this first invariant is represented by the multiplicity of 1 at the end of the association. However, other types of invariant cannot be shown using the notation used for class digrams here, and need to be included in the text which accompanies the diagram.
The second invariant above is one such example. It expresses a dependency between links of more than one association.
We will shortly discuss invariants which impose other types of condition on objects, attributes and links, but we will first explore the second invariant a bit more closely, by considering, in Activity 14, how it imposes conditions on objects and links.
Figure 25 shows two object diagrams, each modelling part of the hospital system domain at a particular time. One of the diagrams depicts a combination of objects and links which is invalid with respect to the second invariant above. Which diagram is invalid and why? (You may assume that all relevant links are shown.)
Figure 25(a) is invalid. When a object and a (in this case a ) object are linked to each other, both must be linked to the same object, according to the second invariant, above.
Now consider the following extract from the requirements document for the Hospital System:
There are two types of ward, male wards and female wards. A ward can only have patients of the specified sex on it.
This constraint can be represented in the conceptual model as the following invariant:
The attribute of any object has the same value as the type attribute of the linked object.
This invariant expresses a condition on the relationship between attribute values of linked objects.
Using the requirements document for the DVD Library System given in Subsection 3.2, and its completed class diagram in Figure 16, identify two invariants on the model of the DVD Library System. One invariant should relate to the number of allowable links between two objects, and the other to the attribute values of objects of a particular class. Try to express your invariants in terms of objects, attribute values and links, but do not spend too much time getting the wording precise.
Each object is linked to no more than six objects.
For each object, the difference between the values of its and attributes is 3 days.
The examples above demonstrate that invariants can involve a number of different aspects of the conceptual model. Invariants involving additional types of constraint will become evident as we carry out a detailed analysis of the system domain for the Hospital System in and consider the conditions needed to ensure the consistency of that model. First, though, we consider the forms in which invariants are included in the conceptual model.
As the model will contribute to the design of the system, and ultimately its implementation, it is important that invariants are expressed clearly and without ambiguity. An invariant should be formulated as a statement that can be tested for its truth. As evidenced by some of the examples already considered, this is not always easy. Furthermore, there is often more than one way of expressing a particular invariant. For example, we could equally well have stated the second invariant in Activity 15 as:
The attribute of each object has a value that is three days later than that of its attribute.
Figure 26 is a fragment from the class diagram for a university system. The class has attributes , and , while the class has attributes , and .
Write down an invariant which states that the tutor allocated to a student must be from the same region as the student.
The attribute of each object has the same value as the attribute of the linked object.
The attribute of each object has the same value as the region attribute of each object to which that object is linked.
Study the requirements document for the DVD Library System and see whether you can identify any further constraints on the system domain that require invariants involving just the values of attributes.
The description sets out several constraints which will give rise to invariants concerned with the uniqueness of attributes:
No two members may have the same membership number.
No two DVDs may have the same number.
No two films may have the same title.
We could express the invariants noted in Activity 17 in terms of objects and attribute values. If this were done for the first one it would read as follows:
If and member are any two distinct objects, then the value of the number attribute ofa member is not the same as the value of the attribute of a member.
Notice that the introduction of identifiers to refer to objects, e.g. and , makes it easier to express the invariant clearly.
Invariants concerned with the uniqueness of attributes are so common that we will not generally ask you to identify them. However, this does not mean that they are not important. For simplicity, our models will include this information in the comments that accompany attributes in the class descriptions, as we have done for the (in ) and (in ) attributes in the Hospital System.
There is one further invariant for the DVD Library System. Study the two object diagrams in Figure 27, which model the situation regarding two particular films at a certain point in time. One of these illustrates a combination of objects and links which is invalid with respect to the attribute of , and the other a valid combination.
Attributes for the objects and the objects are not depicted because they are irrelevant in this exercise.
(a) Identify which is the invalid combination and which is the valid combination, explaining your answer. (You may assume that all relevant links are shown.)
(b) Write down a real-world constraint that requires an invariant to ensure that invalid combinations such as the one you have identified in part (a) cannot occur.
(a) Combination (a) is invalid. The diagram shows that the library has three copies of the film Lord of the Flies, of which two are on loan. The number available for loan is therefore 1, but the attribute of the object represented by has the value 2.
Combination (b) is fine, as the value of the attribute is consistent with the number of objects which are linked to the object but not linked to any object.
(b) The real-world constraint is that the number of copies of a film that are available is the number of DVDs of that film which are not currently on loan.
The invariant noted in Activity 18 can be written as:
For any object, the value of its attribute is equal to the number of objects it is linked to which are not linked to a object.
We will now complete our list of invariants for the Hospital System.