Information Technology Reference
In-Depth Information
14.5
Expressing Obligations
As we have shown, the description of an enterprise involves more conflicting
constraints and trades-off than are found in the design of a software process.
This leads to emphasis not just on what happens next in a particular situation
(as is the case in traditional software design), but also to consideration of what
might happen, what can happen and what should or should not happen. We
are concerned not just with the rules of a deterministic automaton, but a web
of permissions, obligations and prohibitions. The result is a need for a much
more powerful set of modelling tools. Technically speaking, it takes us from
the world of predicate logic to the world of modal and deontic logics [74,89,99]
| giving the ability to reason about possibilities and conformance to accepted
norms.
This is a more fundamental change than many people realize. It involves
not just extensions to the notations we use, but changes to the way we interpret
existing notations. Instead of basing our assessment of a system on whether
what it just did is consistent with the specification, we need to ask whether
it did the right thing, given all the possible things it could have done in the
circumstances. This involves our tools in checking for optimal decisions (or,
more often, least bad solutions), rather than just checking for correctness, and
few tool builders have yet risen to this challenge.
A simple example can be seen in the treatment of obligations. If I have
an obligation, it is reasonable to assume that I should do the action needed
to discharge it; but it is not obvious, unless explicitly stated, how urgently I
should treat the requirement, or how hard I should strive to overcome other
factors that might currently be preventing the action. However, this is just the
beginning; it is much more dicult, for example, to see what I am expected to
do if I am one of a number of equal members of a community and an obligation
is placed on the community. If the thing is not getting done, what personal
costs should I accept so that the whole group meets its obligation? Why not
leave it to one of the others to do it?
One consequence of these complications is that the statements of expected
actions in our contracts are frequently accompanied by exception handling,
saying what should be done if an obligation is not discharged, or a prohibition
is violated. These may cover what corrective actions are needed or what
compensation becomesdue. For example, community contracts often detail
penalties for late delivery or processes for replacing faulty goods.
One particular set of concepts that must be treated in this way is concerned
with delegation. If an enterprise is to be robust, it must be clear what is
to happen when an object fails or when the demands on a role exceed the
capabilities of any single object. One solution is to introduce a special kind
of community, describing a delegation pattern, in which responsibility can
