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

122 Concepts for the Integration of Specification and Design
to respect and show its structure. By allowing architecture representation, structural
aspects of a conceptual solution can be visualised, and communicated in the project
team. In practice we always saw a design project starting with discussions around block
schemes. Notice that this is a completely different approach than most object-oriented
methods recommend. They recommend starting with finding objects, by considering all
nouns in the Initial Requirements Description as possible classes of objects. Blocks in a
block scheme do not necessarily become objects. We recommend to study and compare
alternative conceptual solutions before starting the creation of Object Class Models and
Object Instance Models.
5.3.2 Awareness
Does this mean that we prefer to introduce a lot of ’implementation thinking’ into the
specification process? This would imply a big danger. From our own experience we
know how important, but also how difficult, it is to educate people to stop this way
of thinking. Of course a specification must pay a lot of attention to ’what’ must be
designed and not ’how’ it must be realised in lower level implementation technology.
Like most methods we also do endorse separation of essence and implementation.
However we disapprove the sequential approach of deriving an essential model before
an implementation model.
The mental transformation necessary to prevent designers from rushing into implementation
has led to a confusion about implementation dependence. The need of
implementation independence in a specification is overemphasised. Every piece of a
model created, leads to structure which guides to implementation constraints. So there
is no such thing as implementation independence. Any problem that is big enough
requires structuring beforehand to make it manageable. And whether we like it or not,
this structuring will influence the implementation till the end.
A keyword in our approach is awareness. We recommend to work simultaneously in
an appropriate collection of views on the system to be designed. When working on
the behaviour view of the model one must be aware of the fact that the focus is on
what the system must do. This requires an attitude of abstraction, generalisation, and
implementation independence.
Working on an architecture model requires the awareness that it should survive as
long as possible. This requires an attitude of observing the real world, looking for
natural structure in a conceptual solution. Awareness can lead to separation of concerns.
Appropriate activities can be performed in the appropriate view, without bothering
about all kinds of details in other views. This means that one is aware of a local
task. Of course there must also be moments of reflection about the entwining of the
views. The behaviour model must be influenced by relevant parts of all views, and
unify all relevant constraints into a POOSL description. For the architecture view this
is performed by laying down clusters and processes that correspond to the modules
in the architecture view. Besides the behaviour view and the architecture views there
usually are test views, maintenance views, safety views, etcetera (see also 5.7 about