Testing Conceptual Schema Satisfiability - Intentional Perspectives on Information Systems Engineering - page 279

Fig. 4 Schema fragment
with types that cannot be
satisfied

Employee

1

Manages

Manager

2..*

boss

IsA Employee . However, if we take this inclusion constraint into account then it
cannot be satisfied. If the conceptual modeler writes a test case such as

test EmployeeWithTwoBosses{
emily : = new Employee;
john : = new Manager (employee: = Emily);
natalie : = new Manager(employee: = Emily);
assert consistency;

}

the assertion will Fai l because john and natalie do not have (at least) two bosses.
Any change of the instances of the three types will produce the same result, and
the conceptual modeler will find out soon that the defined cardinality constraints are
wrong.

3.2 Derived Type Satisfiability

Entity and relationship types may be derived. For each derived type, the conceptual
schema includes a derivation rule that defines the population of that type in terms
of the population of other types. In UML, the derivation rules are written in OCL.
Derived types must be satisfiable too [ 6] . Satisfiability of a derived type means that
its derivation rule may derive at least one instance of it at certain time.
The satisfiability of a derived type can be checked by means of testing. The idea
is to write a test case that makes an assertion TA k whose evaluation requires the
derivation of at least one instance of that type.
In the example of Fig. 1 there are ten derived attributes. The assertions “ assert
equals s.shoppingCart.shoppingCartItem->at(1).price 40 ” and “ assert equals
s.shoppingCart.shoppingCartItem->at(2).price 65 ” (specified in the test case
confirmOrder shown in Fig. 3) imply that the attribute ShoppingCartItem::price
is satisfiable and also the attributes ShoppingCartItem::unitPrice and
Product::finalNetPrice . The reason is that the derivation of the price of a
shopping cart item implies the derivation of its unitPrice (its derivation rule expres-
sion is unitPrice ∗ quantity ), and the unitPrice of a shopping cart item corresponds
to the finalNetPrice of its associated product . Similarly, the assertion “ assert equals
oc.createdOrder.total 105 ” implies the satisfiability of the attributes Order::total
(its derivation rule is shown in Fig. 1) , OrderLine::price and OrderLine::unitPrice .
Finally, the assertions “ assert equals shirt.quantityOrdered 2 ”, “ assert equals