7 Derived attributes and associations
7.1 Using invariants to derive attributes
In this section, you will learn:
that some attributes and associations in a conceptual model are derivable from others;
how invariants are involved in this process.
The need for invariants in a conceptual model arises from the fact that the entities in the system domain may be interdependent in a way that is not evident from their representation in the conceptual model's class diagram and class descriptions. Where there are constraints on some aspect of the system domain, an invariant spells out the conditions that ensure that this constraint is reflected in the model.
Some invariants express a relationship between two or more elements of the model. For such invariants, it may be possible, given the values of one or more elements, to work out the value of some other element. For example, given the invariant
For each object, the value of its attribute is equal to the difference (in years) between the current date and the value of its attribute.
and knowing both the current date and the value of a object's attribute, it is possible to work out the value of the object's attribute.
You might justifiably ask why the class needs both the attributes and . The simple answer is that they are both explicitly mentioned in the requirements document.
However, in our final system it may not be necessary to implement both these attributes as instance variables. This is not a decision that can be made until the analysis process has advanced beyond the conceptual model. It will depend on the results of a detailed analysis of the behaviour of the system, which is yet to be carried out. This analysis may reveal that one or other of the attributes does not need to be implemented explicitly, or it may be that the context in which each is required indicates the need to retain both. The decision may also depend on other implementation issues, such as whether the implementation language and hardware contain facilities for accessing the current date in a suitable form.
At this stage of the development process the model needs to reflect all the aspects of the system domain implied by the requirements document. This document refers to both the age and the date of birth of patients, so both these properties need to be modelled as attributes of the class. However, it is also necessary to look out for situations where one aspect of the model can be deduced from another and to flag this up as part of our model. An attribute whose value can be deduced from other element(s) of the model is known as a derived attribute. Derived attributes are indicated in the UML by preceding their names with a slash, /. So we modify the entry for the class in the class descriptions given at the end of Subsection 3.as follows:
|Class||A patient in the hospital|
|The name of the patient|
|The sex (M or F) of the patient|
|The date of birth of the patient|
|/||The age of the patient in years|
Identify a derived attribute for the DVD Library System, and provide a class description for the class to which this attribute belongs.
In the class, can be derived from on the basis of the invariant discussed in Activity 15, which stated that the difference between these two attributes must be three days.
The class description is as follows:
|Class||The loan of a DVD|
|The date of issue of the loan|
|/||The date by which the loaned DVD must be returned|
Alternatively, could be derived from . (But note that it would not be possible to derive a patient's date of birth from their age in years.)
Another attribute value that can be deduced from other aspects of the information in the Hospital System is the number of free beds on a ward. In the discussion following Activity 20 , we formulated the following invariant, which expresses how the number of free beds on a ward can be derived from other aspects of the model:
For each object, the value of its attribute is equal to the value of its attribute minus the number of objects to which it is linked.
From this invariant we see that the value of a object's attribute can be calculated from the value of that object's attribute and the number of links the object has to objects. So the attribute should be marked as derived.
The attribute of should also be marked as derived, since it can be obtained from the type (male or female) of the object the object is linked to. This derivation may seem counter-intuitive – it does not seem sensible to work out the sex of a patient from the type of the ward they are on. Nonetheless it is conceptually possible, so it should be noted.
Is the attribute of the class in the DVD Library System derived? If so, how?
Yes, the attribute is derived. It can be calculated from the following invariant:
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.
Consider the following invariant for the DVD Library System (which is actually captured in the comment on the attribute of the class):
If and are any two distinct objects, then the value of the attribute of is not the same as the value of the number attribute of .
Does this invariant indicate that any attribute of the class can be derived?
No. Given the value of the attribute for one object, this invariant specifies what the value of any other object may not be, not what it is. Invariants involving attributes are not always an indication of derived attributes. It depends on the nature of the condition specified.
You have seen that where an invariant involves the values of attributes, the value of one of those attributes may be derivable from values of other attributes(s) and/or link(s) involved in the invariant. However, it is not necessarily the case that it is the invariant that leads you to identify the derived attribute. It could be that you recognise that an attribute can be derived before you consider invariants, or that you identify both aspects of the model in parallel. The important point is to be aware of the relationship between them: where you have a derived attribute, you will also have an invariant. However, the reverse is not necessarily the case. As you saw in Activity 27 above, an invariant involving attributes does not necessarily indicate that it is possible to derive one of those attributes.