Derived association

CHAPTER

UCP 5 UUCP TCF EF For the running example we obtain

6.4 Associations

6.4.3 Derived association

Just as useful as derived attributes are derived associations, that is, associations that instead of being represented physically are calculated from available information. For example, suppose it is often necessary to know which books a given customer has already bought in the Livir system. As books are not linked directly to the customer in the conceptual model, referring to that information could be a bit more complicated than expected.Figure 6.16shows an example of how a conceptual model for Livir could relate books and customers indirectly through orders and purchasing items;

in this case, the set of all books bought by a customer would be referred asthe set of books linked to the items linked to the orders linked to the customer.

Compared to the preliminary conceptual model of Chapter 3,Figure 6.16introduces the concept ItembetweenBook andOrder. Items are necessary if the concept Bookmeans the published title, not the physical copy. In this case, what is ordered is anItem, which represents one or more physi- cal copies of a given Book. The book may have its price updated regularly, but a change in the book price should not affect the price of former orders. Thus, the price of an item remains the same even if the price of the book was changed.

Note that with this model there is no direct link between the customer and the books she has already bought. Creating a new straight association between Customer and Book would not be a good solution because it would be redundant to the model, as the set of books may already be obtained indirectly. Furthermore, a new association between Customer and Book could associate

Customer 1 1

* * 1

Order Item * Book

FIGURE 6.16

A customer indirectly associated to books.

126 CHAPTER 6 Conceptual Modeling: Fundamentals

anycustomer withanybook, not only those that were already bought by the customer through her orders. This model allows the representation of inconsistent information, which would require some checking mechanism (for example allowing only books that were bought to be associated to the customer).

A modeling solution for that case, when it is relevant to have straight access to a collection of objects that can already be derived from existing information, is to use a derived association, as depicted inFigure 6.17.

UML allows derived associations to be navigated in both directions. It is assumed that both roles are derived. In the case of Figure 6.17 the opposite role Customer must also be considered derived, even if its default role name does not indicate this in the diagram.

The multiplicity of both roles of the derived association of Figure 6.17 is multiple because by navigating on the normal associations it can be seen that a customer may have ordered zero or more books, and that a book may have been ordered by zero or more customers. Usually, the multiplicity of a derived association is defined by the product of the multiplicities of the roles that must be navi- gated to reach the target concept. The following rules may be used to determine that multiplicity:

• The lower bound of the derived multiplicity is the product of the lower bounds of the roles in the navigation path.

• The upper bound of the derived multiplicity is the product of the upper bounds of the roles in the navigation path.

For example, if the multiplicities found in the path are 1..5, 2..

and 1, then the derived multipli- city is 2..

, because the lower bounds are 1, 2, and 1 (1

²

¹⁵2), and the upper bounds are 5, infinite, and 1 (5

^infinite

^15infinite).

However, if filters are applied to the definition of the derived association, the resulting multi- plicity may be different. For example, if the derived association is defined so that it links a cus- tomer to the most expensive book she has already bought, then the derived multiplicity is 1, and not

^.

As opposed to normal associations that allow links between individual objects to be added and removed, a derived association may only be consulted (similar to derived attributes, which are read only).

A derived association may be defined by an OCL expression as well. The example ofFigure 6.17 may be defined as

Context Customer::orderedBook derive:

self.order.item.book

Customer Order Item Book

/orderedBook

*

1 1

1

* *

*

*

FIGURE 6.17

A derived association.

127 6.4 Associations

The following observations can be made about this OCL expression:

• The context is the class at the origin of the derived association (Customer). The subcontext is the role name of the derived association (orderedBook).

• The clausederive: is used similarly to the case of derived attributes. What determines if the expression is defining a derived attribute or association is the context and the type of

information that is returned by the expression. Derived attributes are defined by expressions that return an alphanumeric, enumeration, or primitive type, while derived associations are defined by expressions that return an object or a collection of objects (data structure).

In object-oriented programming languages, usually the “.” notation can be used only over a single object. OCL, however, allows it to be used over collections of objects.⁷Ifxis a collection, then the meaning ofx.yis the collection ofythat can be obtained as properties ofx. For example, self.order denotes the set of orders of a customer in the current example; self.order.item is the set of items linked to the orders of a given customer; andself.order.item.book is the set of all books linked to the items that are linked to the orders that are linked to the customer.

A derived association may also be used to define a subset of objects from a set of linked objects by the application of a filter. For example, imagine that the bookstore has a record on special cli- ents that have bought above 1000 dollars worth of books. Let us call themgold customers. Let us also assume that theCustomerclass has a derived attributetotalSaleswith the sum of all orders of a customer. The definition of that derived attribute is not important for the example and it will be ignored now. A derived association between the controller and theCustomerclass may be used to model the gold customers as a subset of the customers of Livir.Figure 6.18shows the partial con- ceptual model for this example.

The OCL expression for this derived association has as the context the Livir controller itself, because it is at the origin of the association. The expression that defines the derived association has to denote the set of customers that bought more than 1000 dollars, that is, the instances of CustomerwhosetotalSalesvalue is higher than 1000.

The OCL expression to obtain a subset of elements that satisfy a given Boolean expression like this is select. The Boolean expression is placed inside parentheses after the select command. The Boolean expression usually starts with an iteration variable that in the case of the following expres- sion was named:aCustomer.

/ goldCustomer

+ / totalSales : Money Customer 1

0..1

*

* Livir

FIGURE 6.18

Derived association defining a subset of a normal association.

7In fact, in OCL, even a single object is considered a collection with a single element. This is equivalent to the natural notion of a set, but not to the mathematical notion, because in set theory, a set with one element is not the element. In OCL a set with one element and the element are the same thing.

128 CHAPTER 6 Conceptual Modeling: Fundamentals

Context Livir::goldCustomer derive:

self.customer-.select(aCustomerjaCustomer.totalSales.1000)

In the case of this expression, the iteration variable is called “aCustomer” but it could have any other name. It denotes each one of the customers for the evaluation of the expressionaCustomer.

totalSales.1000.

The arrow notation “-.” is used before select instead of the “.” notation because the select function is applied over the structure of the set, not over its elements.⁸

OCL also allows the iteration variable to be omitted if the context of the expression is not ambiguous. Thus, the expression above can be simplified to

Context Livir:goldCustomer derive:

customer-.select(totalSales.1000)

Observe that inside the parentheses afterselect the context is potentially ambiguous. There, the propertytotalSales could refer both to a customer and to the instance of Livir. What allows us to eliminate the ambiguity is the fact that the propertytotalSalesexists only in theCustomerclass; it does not exist in the Livir class. If it existed in both classes, then the nonabbreviated notation should be used in order to eliminate the ambiguous expression.