Information Technology Reference
In-Depth Information
unchanged. In fact, this is not the case, since some additional detail of the
user interaction has been made visible, which involves providing the user with
up to date progress information about the repair. This in turn requires that
additional progress signals and a query facility need to be provided by the
Phone Supplier role so that progress of return to manufacturer repairs can be
monitored. These have been added at this stage to underline that, although
ideally this part of the design would be a transparent process from the point
of view of the external parties, in practice it will be an iteration, and in the
real design we would expect tooling facilities to assist in propagating these
additions back into the abstract view.
We mentioned previously that community behaviour could be managed by
the definition of mutable policies (see chapter 10). Doing so narrows the gap
between specification and implementation, since a policy needs to be updated
at runtime, either by replacing some code fragment or adding indirection, so
that the policy is accessed as a separate service. Often, the policy is written in
a separate language, designed to make runtime interpretation straightforward.
A policy may take a number of forms, being either a small fragment of be-
haviour, controlling a particular decision, or a constraint or invariant applied
to a broader behavioural scope. In either case, the way the policy is to be
changed forms part of the community behaviour.
2.7 Accountability and Related Concepts
The enterprise language includes a family of concepts for expressing re-
sponsibility, called accountability concepts. Their aim is to support the trace-
ability of obligations in the overlapping and interacting communities that
make up the enterprise. The basic idea here is that, despite a significant
amount of automation and use of supporting agents, there are parties that
have broader responsibilities derived from some social or legal framework.
These may be natural persons, such as the Phone User, or organizations, such
as the logistics provider Green Transport in figure 2.5. In either case, we need
to be able to trace the way that their rights and responsibilities are linked to
individual system actions and to their consequences.
To help do this, the enterprise language defines a number of kinds of action
that have different consequences for the future behaviour of the system; dis-
tinguishing these different kinds of action provides a framework for analysing
the way responsibilities evolve. First, a commitment is an action that re-
sults in the object performing it undertaking some obligation. Obligations
can then be passed on by their current holder (the principal ) performing a
delegation in which obligation is passed to an agent . An object can also
make facts known in its environment by performing a declaration . This may
be the result of some analysis of available information to derive more general
