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

2.7 Summary 31
offer many guidelines and heuristics to produce a stable and maintainable logical system
architecture. They hardly focus on the development of a physical architecture. This is
of utter importance for hardware/software systems. For these systems, the search for
objects has to be accompanied by development or determination of the physical system
architecture. Logical and physical structuring should be performed in a simultaneous,
evolutionary fashion, leading to behavioural views as well as architectural views.
Despite of their simultaneous development, the structures of behavioural and architectural
views can become inconsistent. In addition, these views can become inconsistent
with the unified system model. At some point in time, the views and the unified model
will have to be transformed in order to obtain consistency again. In case of complex
models, these transformations will be very time-costly. To reduce the required effort,
transformations should be supported by automated tools. Automation requires a precise
definition of the transformation that should be supported. Transformations should
not change the intended semantics of the models involved and keep the behaviour of
the unified system model invariant. This leads to the notion of behaviour-preserving
structure transformation. Such a transformation may change the structure of the unified
model, but it leaves the functionality invariant. To ensure invariance properties of
transformations, the notion of ’behaviour-preservation’ has to be made precise and the
offered transformations have to be mathematically proven correct with respect to this
notion. These proofs require the language in which the unified model is expressed to be
a formal language.
2.7 Summary
An activity framework must be supported by behaviourpreserving
transformations that allow a consistent integration of
logical and physical structures. Behaviour-preserving transformations
must be expressed in a formal language and they have
to be mathematically proven correct.
In this chapter we have stated the major requirements that have to be satisfied by our
new specification method for reactive hardware/software systems, called SHE. We have
studied a number of current specification methods and we evaluated our requirements
against them. The requirements for the SHE method are summarised as follows:
The method must be designed using a fundamental conceptual approach.
The method must deliver several modelling views. These views are behaviour
views, architectural views, timing views, requirements views and conceptual
views. The focus must be on behaviour views and architectural views. The
views may be expressed in informal languages.
Abstraction of the separate views must be combined into an explicit unified system
model. This unified model must be expressed in a formal specification language.