8.2 Derived Attributes

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).

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.

8.3 Referential Constraints

When we begin abstracting classes and attributes, our candidate classes might include attributes such as

• Book.publisher

• CreditCardCharge.accountNumber

• Order.customerID

Attributes like these are characteristics of the classes, but they also refer to the related classes. It is important, then, that we capture the fact that each such attribute is tied to an association.

8.3.1 Referential Attributes

A referential attribute identifies the instance of the associated class.

Definition: A referential attribute is an attribute whose value is the value of an identifying attribute in one or more associated classes.

We tag the referential attribute with {R n }, where n is the number of the association being formalized . For example, the attribute BookProduct.publisher refers to the identifier of Publisher, formalizing the association named R1. See Figure 8.10.

Once there is a referential attribute formalizing the association, there is no need to put in a " backwards pointer" in Publisher. That would be redundant, because it formalizes the same fact about R1. (Model compilers can optimize the actual storage scheme for the association based on the pattern of usage of access, not on the placement of the referential attribute.)

Names of referential attributes.

There is no requirement that the name of the referential attribute be exactly the same as the identifying attribute of the referred-to class, only that the set of values the referential attribute can take on is the same as a currently existing value for the identifying attribute.

When a class is identified by multiple attributes, an association is formalized using all of the identifier's attributes, though there are some exceptions described in Section 8.4: Association Loops .

Referential attributes not mandatory.

For the purposes of knowledge formalization, the existence of the association and its description is sufficient to communicate meaning.

Shlaer-Mellor required referential attributes for all associations, even if it meant inventing identifiers. This practice is not required in Executable UML.

However, referential attributes are useful in cases where it is easier to express constraints and selection expressions in terms of data (attributes) than associations. The following sections provide some examples of these uses of referential attributes.

8.3.2 Derived Identifiers

A book's ISBN ("International Standard Book Number") is a ten-character string. The first set of characters identify a publication group (a national or regional collection of publishers), those in the second set identify the publisher, and the remaining characters identify the book. ^[1]

^[1] Actually, the last character is a check digit, but we'll consider that to be part of the book code.

This string actually comprises three pieces of information:

• the group code

• the publisher code

• the title code

The title code itself does not uniquely identify a book across the entire population of books of all publishers in all languages. By itself, it is not an identifier for a book. Rather, the identifier is the concatenation of all three attributes. A multi-attribute identifier is one solution, but given that the domain experts will consistently refer to the ISBN and that selecting instances of books by three attributes is rather messy, we should really make the ISBN of Figure 8.11 into a single attribute identifier.

In Figure 8.12, we represent the ISBN number as a derived attribute, based on the publication group, publisher, and title code, and Figure 8.13 shows the definition of the attribute.

Definition: A derived identi fi e r is an identifier that is the derived concatenation of several identifying attributes.

Derived identifiers are commonly used in situations where an attribute is unique within a subset of instances and all the instances in the subset are related to a single instance. In this case, the attribute Book.bookNumber must be unique for all books published by a given publisher in a given language. Two publishers (who have distinct publisherCodes) may each publish a book with the same bookNumber. The bookNumber by itself does not uniquely identify a BookProduct, but the combination of language, publisher, and bookNumber does uniquely identify a BookProduct.