Information Technology Reference
In-Depth Information
oc.createdOrder.eMail 'john@john.com' ”, “ assert equals oc.createdOrder.name
'John' ”, “ assert equals oc.createdOrder.orderLine->at(1).name 'shirt' ” and
assert equals oc.createdOrder.orderLine->at(2).name 'trousers' ” make the
attributes Product::quantityOrdered , Order::name , Order::eMail and OrderLine::
name satisfiable.
3.3 Domain Event Type Satisfiability
Domain event types must be satisfiable too. Domain event type satisfiability
comprises the properties of applicability and executability defined in [ 6, 19] :
A domain event type Dev i is applicable if there is a consistent IB state and
one instance d of Dev i with a set of characteristics such that the event con-
straints are satisfied, and Dev i is executable if Dev i is applicable and the
effects of d leave the IB in a state that is consistent and satisfies the event
postconditions.
The satisfiability of a domain event type Dev i can be checked by means of testing.
The idea is to set up a test case TC j such that it:
builds a state of the IB, and
creates an instance d of Dev i , and
asserts the occurrence of d .
If the test set includes such test case TC j , and its execution gives the verdict
Pass , then it is experimentally proved that Dev i is satisfiable: applicable (because
the initial IB state has been found consistent and the event constraints have been
satisfied) and executable (because the new IB state has been found consistent and
the event postconditions have been satisfied).
The test program of Fig. 3 exercises the valid execution of all the domain events
considered in the example (see Sect. 2.1) and this ensures that these domain events
are satisfiable.
If a conceptual schema includes a domain event type Dev i that is unsatisfiable,
then the conceptual modeler will be unable to set ups a test case that builds a state
of the IB, creates an instance of Dev i and asserts its occurrence. Again, this is not
formal proof that Dev i is unsatisfiable, but in many practical cases it provides a clue
that helps to uncover a faulty constraint.
For example, related to the schema of Fig. 2, assume that there is a domain
event type RemoveOrder , whose intended effect is to remove the order to which
it is associated. If one of the constraints of the event is:
context RemoveOrder::thereAreNoOrderLines ():Boolean
body: self.order.orderLine->isEmpty()
then RemoveOrder is not applicable, because an instance of Order is always asso-
ciated with at least one instance of OrderLine . Any assertion of the occurrence of
Search WWH ::




Custom Search