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