Specification of Reactive Hardware/Software Systems - Electronic ...

6.6 Dynamic Behaviour 207
with the problem-domain-orientation that object-oriented analysis methods promise to
have. In object-oriented analysis there is a lot of emphasis on finding objects that model
the real world. The objects are required to have names according to the problem field.
For the notion of state the same requirement should hold. It should be possible to
identify states by giving them distinct and recognisable names. The traditional objectoriented
definition of state makes this impractical. Designers require distinguishable
states during test and verification.
We recommend to use the concept of variables partial state in situations where explicit
information about an object’s state must be stored. Accessors can make this information
available for other objects. By using a variable that stores the named behaviour state
and that is updated when some form of behaviour is entered we can easily make state
explicit. Especially for controllers this approach gives additional information that can
be used for verification, test and maintenance.
6.6.3.5 Global State
The individual notions of variables state and behaviour state cannot give a full state description.
The variables state does not describe what the system is actually doing, during the
state. The behaviour state does not distinguish between situations where a (sub-)system
may produce different results based on the values of its internal variables. We define
the global state of a (sub-)system as an element from the state space that is the Cartesian
product of the behaviour state space and the variables state space.
Besides observable behaviour and observable changes of variables via offered services,
there are usually many detailed invisible state transitions in objects. Operations of an
object often specify context-dependent actions. Their effects depend on the object’s variables
state. An object’s operation may have inner side effects. These are inner changes of
variables, that happen as an additional effect of an operation. A transformer will usually
cause a side effect (see Subsection 4.15.4). Besides side effects on instance variables,
there are effects on local variables. However the latter should not be considered as side
effects. When an operation is finished the lifetime of the local variables is over. So the
effect is not stored in the variables state. When looking at the finest grain of behaviour
description local variables do live some time and form a temporary local variables state
that is in general modelled by a temporary stack.
Side effects are not necessarily harmful. An efficient computation of an accessor function
may require changing the internal state of an object (concrete state) to which the function
is applied, without changing the abstract state of this object [Mey88]. Meyer gives an
example of a class Complex, whose instances have two possible internal representations
of a complex number: Cartesian or Polar. Depending on the last operation an object will
be left behind with its internal variables represented as Polar or Cartesian. This depends
on what was most efficient for the last operation performed. The concrete internal state
(Polar or Cartesian) does not effect the abstract state which is isomorphic to the complex
number.