Information Technology Reference
In-Depth Information
objects involved in it. In other words, an ODP interaction is a piece of shared
behaviour.
Figure 3.3 illustrates the state machine of the Handset information object.
This diagram shows not only the effect of the actions on the corresponding
information objects, but also the states in which the actions are allowed,
serving as pre- and post-conditions for those actions.
RepairRequest
Broken
InitialTests
UnderInspection
SendToManufacturer
FixedByStaff
UnderManufacturerRepair
FixedHandset
UnableToFix
Operational
Unfixable
CloseOrder
Dispose
FIGURE 3.3: State machine for the Handset information object.
3.3.4 Invariant Schemata as Constraints
We have seen how invariant schemata can be used to specify the informa-
tion object types and their relationships, but they can also be used to express
other kinds of constraints on the information handled by the system.
For example, we may need to express the fact that no handset can be
referenced simultaneously by more than one repair order, or that users should
have unique names in the system. These kinds of invariant have already been
incorporated into the UML class diagram that describes the information object
types by choosing the multiplicity of the association ends, or adding some
OCL constraints to the elements (see, for example, the constraints specified
for classes User or RepairOrder in figure 3.1).
Other OCL constraints can be used to specify further restrictions on the
model, or to express integrity constraints. For example, we could restrict
the number of repair orders currently open in a centre, in accordance with
a possible enterprise policy stating such a business rule, by simply adding
an OCL constraint to the ServiceCentre information object type, as in the
following fragment.
