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

118 Concepts for the Integration of Specification and Design
5.1 Introduction
Complex hardware/software systems cannot be specified without integration of specification
and design. Traditional methods define a development path partitioned into
a sequence of phases. Design is placed after analysis and specification. A design of
a complex system consists of various activities on various levels of abstraction. On
the lower levels, design means making decisions towards an implementation. On the
higher levels, design means decision making about global system structure, also called
architecture structure. This structure is denoted in Architecture Structure Diagrams in free
style graphical representations.
Design should integrate aspects from multidisciplinary views, such as test, maintenance,
safety and many other aspects. All those aspects provide additional behaviour that must
be integrated into both behaviour and structure of a system. This chapter describes
concepts for performing structure design simultaneously with behaviour modelling.
5.2 Architecture
5.2.1 Definition
We define architecture as a view of a system that reveals a structure, which influences the
modularity of the system. Modularity may be interpreted as logical, physical, spatial
or even temporal modularity. The difference between implementation structure and
architecture is the relative level of abstraction. Architecture design is performed on
a relatively high level. For a system this is ’system level’, for a subsystem it is the
upper level structure of the subsystem. Lower levels of structure design belong to the
implementation design. Free form graphical representations can be used to specify
architectures as structures that consist of modules and their interfaces.
5.2.2 Implementation Dependent Specification
Creation of an architecture structure is a design activity. This is in contrast to implementation
independent specification activities, that are not design activities. There is a community
which strives for specifications that do not contain implementation details. An example
of such an approach can be found in [Par90]. They consider an algorithm, specifying a
piece of behaviour, to be an overspecification. After all, an algorithm implements a specific
approach to realise the behaviour. We choose completely for the opposite point of
view. POOSL is an imperative specification language, which uses algorithms to describe
behaviour. We recommend to start design activities simultaneously with the specification
of the essential objects. This introduces substantial implementation aspects into a
specification. We recommend to do overspecification.
This can be motivated by the necessary industrial practice. We refer to Chapter 2 in
which we argue that implementation and specification cannot be separated. Besides the
fact that structures may be designed, they are often specified (prescribed) in an Initial