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

14 On Specification of Reactive Hardware/Software Systems
a designer. The designer should be able to bridge the gap between final specification
and realisation. Stated otherwise, the designer should be able to construct a realisation
that is an element of the realisation space of the model. In general, a designer will not
think in this rather artificial way. He is not aware of a space. He will consider only a
limited set of alternative implementations. For complex systems he will in general lose
overview on relevant aspects. Therefore a specification should allow the deduction of as
many relevant properties as possible. Each of these properties must be expressed in this
model in an either implicit or explicit way. For reactive hardware/software systems the
properties that concern behaviour and architecture are the most relevant (and difficult)
ones.
Views
When systems are very complex, it is impossible to simultaneously take all relevant system
aspects and properties into consideration. Therefore we need abstraction facilities
that highlight particular related aspects. We call such an abstract model a view. Proper
use of views enables ’reviewing’ a model with different experts. Experts should be able
to reason about the different relevant system aspects, and should not be bothered by
details that are beyond their expertise. Complexity is usually handled by a divide and
conquer strategy. Hierarchical forms of hiding and abstraction also lead to several kinds
of views. The availability of different views avoids confusion between different, yet
related, system aspects. For instance, both behavioural views and architectural views
have a structure. These structures are quite different and serve different purposes. The
structure of behavioural views is often a logical one and is used to partition the system
behaviour into clear and understandable pieces. Architectural views, on the other hand,
are physical structures and represent the structure of (future) implementations.
The modelling of complex reactive hardware/software systems
requires several modelling views.
Explicit Unified Models
Each view determines a collection of (deducible) system properties and implicitly defines
a dedicated realisation space. When a specification is created as a collection of separated
views it can be imagined that the view’s realisation spaces do not intersect. Therefore
views should be created such that they all grasp a good part of the essence of the model.
An adequate strategy must lead to a consistent explicitly defined unified model. This
unified model integrates abstractions of various views in a consistent way. In general, a
view will contain information that is not in the unified model.
Consistency of Views
Not all methods follow the approach of using a unified model. In particular, many
well-known object-oriented methods [SM88, CY91a, CY91b, R 91] typically create three
loosely coupled views (object views, functional views and dynamic views), with a
poorly-defined interrelation. Consequently, it is possible that a specification may define
an inconsistent set of models [HC91, Bri94]. Inconsistencies are not easily discovered,
because the unified model is not shown or described explicitly. It is implicitly defined