Information Technology Reference
In-Depth Information
concerned. The idea of introducing a policy to increase flexibility is generic,
and so can be applied in any viewpoint. Each policy has a number of pieces
of information associated with it, and these constrain the behaviour of the
system in different ways. We can distinguish the following terms.
Policy is the term used when referring to the whole collection of infor-
mation or referring to a variation point in the specification.
The affected behaviour is that part of the system behaviour that is
modified or controlled by the policy. A policy might, for example, control
the conditions that must hold before a loan handset is issued, perhaps
based on the previous reliability of the user. The step Get Loan Phone
would then be the affected behaviour.
A policy value expresses the constraints applied at the variation point
during a particular epoch. Changing the policy value changes the sys-
tem's behaviour. Policy values for an access control policy, for example,
might select suitable mechanisms, so that one policy value might require
password validation, while another that replaces it requires presentation
of a valid certificate.
Policy-setting behaviour is the behaviour that modifies the policy
value. If no such behaviour is defined, the policy cannot be changed
by mechanisms within the running system. It could still be changed by
actions not forming part of the system's specication, such as choosing
deployment information before the system is first started, or changing
it and then reinitializing the system. However, it is expected that most
systems will need to be able to evolve dynamically, and so there will be
definitions of the way policies can be changed, and of any constraints on
when such changes should take effect. For example, a change in financial
policy should not become visible within the scope of a compensatable
transaction! The designer also needs to decide what should happen if
a change of policy would leave the system in what has just become a
forbidden state; it may be necessary to define some transitional rules to
deal with such situations.
A policy envelope indicates limits on what policy values are acceptable.
If system managers are given complete freedom to install absolutely any
policy value, it becomes impossible to reason about the correctness of
the system design. Any required system property may be invalidated
by suciently draconian policy values. However, if the policy envelope
expresses constraints that must be true for any acceptable policy value,
the impact of changing a policy can be limited and so meaningful de-
ductions about system behaviour can be made that are true whatever
valid policy value is applied.
Policy envelopes can be expressed in a number of ways. The most re-
strictive approach is to limit the setting of policy values to selection from a
