8.2 Derived Attributes

Because an Executable UML model captures the information inherent in a domain, redundant attributes are generally frowned upon. However, there are occasions when a clear understanding of a domain is best served by capturing the dependency between attributes explicitly.

Definition: A derived attribute is an attribute whose value can be computed from other attributes already in the model.

Figure 8.9 shows two derived attributes, each prefixed by a / (slash).

Figure 8.9. Derived Attributes

The attribute ProductSelection.selectionValue can be defined in OCL like this:

context Selection inv:
       Self.selectionValue =
               Self.quantity * Self.unitPriceOfSelection;

or in action language this way:

self.selectionValue = self.quantity * self.unitPriceOfSelection;

Executable UML enforces this constraint by prohibiting writing to the attribute totalSelectionPrice and by requiring any model compiler to guarantee the constraint before the attribute can be read.

Derived attribute dependencies can span multiple classes. Figure 8.9 also shows how the class Order allows a customer to purchase several different products in one transaction. Each product is represented as a distinct ProductSelection.

In this example, Order.totalOrderAmount is derived from the sum of all the associated ProductSelection.totalSelectionPrice. Its definition in OCL looks like this:

context Order inv:
      Self.totalValue =
              Self.Selection.selectionValue ->sum()

This derived attribute definition is written in action language, as shown below.

total = 0.00;
select many selections related by self->Selection[R3];
for each selection in selections
        total = total + selection.selectionValue;
end for;
self.totalValue = total;

Unlike the identifier idiom, which can be represented by tags, the derived attribute marker (/) indicates the presence of a constraint that must be specified.

Specifying an attribute as a derived attribute asserts the dependency between the attributes. It does not require the model compiler to recompute totalPurchasePrice every time either quantitySelected or unitPriceForOrder changes, nor to compute the value of totalPurchasePrice only when it is read. Either of those two times, or any time between them, meets the constraint.

This rule gives the model compiler (and the architects programming the model compiler) the necessary flexibility to establish their own desired performance properties.