Derived Properties

The central part of the given invariant can be seen on line 7 where the operation includesAll is used, which is the OCL way to validate whether a collection is a su-perset of another one. Some things need to be explained in more detail. First, the usage of the operation getValue():OclAny, which is an extension to the UML meta-class ValueSpecification, is required to be able to get the concrete value of a value specification. The UML metamodel defines several operations on this class for retrieving basic types like stringValue():String but excludes a generic definition. Second, the collected values need to be converted to a set usingasSet()(see lines 7 and 8) because values can map to the same specifications. It should be mentioned that, if evaluated at runtime, the invariant only validates the union calculation if subsets is used in the context of a derived union. If subsets is used on a property which is not a derived union, the constraint validates the user defined structure.

Including the described invariant and similar invariants for other runtime elements adds a precise definition of its semantics to the modeling language. Further, our ap-proach allows for an automatic validation of the defined semantics by using existing tools, because no new UML and OCL features are required for the invariant. For ex-ample, instantiations of the metamodel inside the USE tool can be checked or the USE model validator can be applied to verify the semantics.

3.2 Static Structure Modeling

Product

InvoiceLineItem amount : Integer price : Real Invoice

/ total : Real

/highValuedProducts InvoiceProduct *

invoice *

product 1

lineItem

* lineItem {ordered}

1..*

invoice 1

1 context I n v o i c e : : t o t a l :Real derive:

2 s e l f . l i n e I t e m−>c o l l e c t ( amount ∗ p r i c e )−>sum ( )

3

4 context I n v o i c e : : h i g h V a l u e d P r o d u c t s derive:

5 s e l f . l i n e I t e m−>s e l e c t ( i t e m | i t e m . p r i c e > 2 0 0 ) . pro du ct−>a s S e t ( )

Figure 3.8: Class Diagram Including Derived Properties and Their Definitions

attribute named total which is owned by the class Invoice. The derive expression, that computes the total of an invoice by summing up the products of the amounts and the price, is shown below the figure. This attribute can be used like any other attribute inside of an OCL expression, but moreover, the total amount of an invoice can directly be seen in an object diagram as shown in Fig. 3.9. This is different to the usage of query operations, which cannot be directly displayed in an object diagram, since operations, in contrast to derived attributes, can define parameters and there is no possibility inside an object diagram to provide arguments for these parameters.

item2:InvoiceLineItem amount=1

price=10

monitor:Product keyboard:Product item1:InvoiceLineItem

amount=1 price=310

i:Invoice / total=320

/highValuedProducts

product lineItem {ordered}

product

lineItem {ordered}

Figure 3.9: Object Diagram Including Derived Properties

Derived Association Ends

The usage of derived association ends can also help to improve views on a system state.

Like normal links, derived links are a natural way to show connections between objects.

A user can easily identify connected objects without the need to look up object identifiers or to enter a query.

To make these associations visible, they need to be evaluated. In the UML specifica-tion, derived associations, as with derived attributes, are defined by means of constraints, i. e., boolean expressions, which define them in a declarative way. This approach pre-cisely describes the content (the links) of a derived association, but cannot be easily computed if a model is evaluated, because the information about the derived part of the boolean expression would need to be extracted. To provide a usable way, our approach requires the use of expressions that directly evaluate to the expected result. For example, the derive expression for the association end /highValuedProducts shown in Fig. 3.8 on the previous page on the lines 4 and 5 evaluates to a set of Products, because the association end has a multiplicity of more than one. To be able to evaluate a derive expression an evaluation context is needed. As previously described, the context of a derive expression for an attribute is the instance on which it is evaluated. This also holds for binary associations if the result of a navigation to a derived end needs to be calculated, since the instance from which the navigation starts is the context for it (an instance of typeInvoicein the previously used example).

However, there are situations for which such a context instance is not given. If the result of a navigation expression starting at a derived association end must be computed, there is no implicit context instance available. Instead, the derive expression must be evaluated for all instances which could be connected to the starting instance, i. e., for all instances of the opposite association end. If the result of the evaluation contains the starting instance, the instance for which the expression was evaluated is linked to the starting instance.

As an example, consider Fig. 3.8 on the preceding page and the navigation from a Product to an Invoice using the association InvoiceProduct that starts at the de-rived association end /highValuedProducts. To get all connected invoices, the derive expression needs to be evaluated for all instances of Invoice. If the result contains the source product, the invoice is part of the resulting set of the navigation expression. This informal description can be defined using OCL as follows:

1 context Product : : i n v o i c e derive:

2 I n v o i c e . a l l I n s t a n c e s ()−> s e l e c t ( i | i . h ig hV a lu ed Pr o du ct−>c o n t a i n s ( s e l f ) )

Since a navigation, if started from a derived association end, always follows the pattern shown in the previous example, it can be integrated into an evaluator. Another situation, where no implicit context is available, occurs when using derived associations with more than two association ends. To be able to calculate the result, even if evaluated on a given

3.2 Static Structure Modeling

Figure 3.10: Using a Derived Ternary Association to Express Further Rules [A15C]

context instance, all n-tuple (pairs for ternary associations) of possible combinations must be evaluated. In [A15C] we have shown, how n-ary derived associations can be used to visually express additional model constraints. An example using an extended model of the library system introduced earlier is shown in Fig. 3.10. The additional derived association between the three classes together with the defined multiplicity0..1 for the association end dCopyare used to express the constraint, that one user can only borrow a single copy of a book. The definition including the derived expression for the new association is as follows:

1 a s s o c i a t i o n BorrowsCombined between

2 User [ 0 . . ∗ ] r o l e dUser

3 Copy [ 0 . . 1 ] r o l e dCopy derive( aUser : User , aBook : Book ) =

4 aUser . copy−>s e l e c t ( c | c . book=aBook )

5 Book [ 0 . . ∗ ] r o l e dBook

6 end

It uses a pair of copy and book objects to calculate the borrowed copies of the given user (aUser) and the given book (aBook). As it can bee seen in the log at the lower part of Fig. 3.10, the shown system state violates this multiplicity constraint on the derived association end, because the user User1 has borrowed two copies of the book Book1.

Further, one can directly see the instances related to a single lending by looking at the ternary links.