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

3.6 Practical Use of Concepts 49
Generation of Product Idea
and a
Feasible Conceptual Solution
Software Hardware Engineering (SHE)
(Specification and System modelling)
Detailed Design and
Implementation
Figure 3.11: Context of the Specification Method
communication between objects. Communication is shown in two ways. Message Flow
Diagrams show objects and the message flows between them. Instance Structure Diagrams
show objects and the communication channels that are used to transport messages.
Figure 3.12 shows two textual models. The formal part of a model is the formal behaviour
and structure description in the language POOSL. This description is called a Unified
Model because it encompasses both behaviour and structure. The second model is the
Requirements Catalogue. All information that must be in the specification but cannot be
formalised is in this document. So the method uses various forms of representations,
keeps them consistent and formalises them as much as possible in a unified model.
This unified model is a POOSL description. The object instance model encompasses the
Message Flow Diagrams as shown in Figures 3.7 and 3.9. Architecture structure can
be defined in Architecture Structure Diagrams which are free style graphical pictures as
shown in Figure 3.4. The other graphical representations used in the frameworkhave not
been shown in this brief overview. The Object Class Model is used to visualise and define
object classes and their relations. It is a traditional object-oriented approach that we will
use as an additional way to define all necessary objects. The Implementation Structure
Diagrams are more concrete extensions of the rather abstract Architecture Structure
Diagrams.
The Requirements Catalogue contains all additional information and comments that
cannot be formalised in POOSL but are essential for the system specification. An example
is the specification of the environmental conditions such as temperature, humidity,
etcetera. Such items are described separately as Requirements List. The Decisions
Statements describes a motivation for architecture and implementation design decisions.
The System Dictionary contains an alphabetic list of all items in the various models. A
more complete description of the various forms of representations follows in Chapter
11.