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

2.3 Specifications, Models and Views 15
by the fact that the views should have an intersection since they model the same system.
Creating the intersection, however, only happens in the human brain. Therefore,
separated views do not give a full and in-depth understanding of the actual nature of
the system. In case the unified model is only defined implicitly it is possible that inconsistencies
are only found when the system is actually implemented. This may result in
expensive iterations and redesigns. When using a unified model, many inconsistencies
will already be detected at the moment the different views are actually being unified. An
object-oriented method that follows the approach of creating a unified model is ROOA
[Mor94]. ROOA combines object views, functional views and dynamic views into a
single unified model described in the formal description language LOTOS [ISO88].
Abstractions of the different modelling views must be combined
into an explicit unified system model.
Coherent Views
Another way to detect and solve inconsistencies is by establishing a well-defined interrelation
between the various views. In this case the views are called coherent. For
instance, [HC91] proposes to solve the inconsistency problems in object-oriented analysis
and design by offering a (formal) coherent collection of views. Another method that
produces a coherent collection of views is the Statemate method [H
90]. A disadvantage
of these approaches is that they require the different views to be formally described right
from the start. In our opinion the different modelling views may have a more informal
character (see also Section 2.4).
Unification of Views
The unification of different views into a single one is not straightforward, and sometimes
even impossible. First of all there are always properties that are expressible within one
view, but that cannot be captured in a unified model. Second, the way a property is
expressed in one view may be completely different from the way it is expressed in the
unified model. For instance, a timing property (or constraint) can be expressed explicitly
and naturally within a timing view. It is however conceivable that the same property
can only be captured in an implicit (hidden) way within the unified model. Although
the timing view may not contain more information than the unified model, it presents
the information in an easier manageable manner.
Views for Reactive Hardware/Software Systems
We conclude that both the views as well as the unified model are relevant for the
description of a complex system. For reactive hardware/software systems the views
that we consider most important are presented in Figure 2.1. Five different views are
distinguished. It will appear that each view is in fact again a collection of views.
The Requirement views start as a copy of the initial requirements of a project. While
the initial requirement views are stored, the copy evolves and is kept consistent.
These views are in fact a set of documents such as a purpose description of the
system, a concise behaviour description, environmental requirements for operation