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

4.1 Introduction 57
earlier phase than software. Traditional object-oriented software system modelling considers
a system as a model of a real world problem domain. This domain can be modelled
as ’real word’ entities that collaborate and compose a system. This approach can be
used if such a real world to be studied exists. An example is an automation project
where an automated software system performs the tasks that were done by people and
non-integrated subsystems.
We focus on systems that are technical products. Such products are systems that were
traditionally designed using a functional approach. It is our experience that designers
are not aware of the fact that such systems also implement (at least partially) a model
of an existing problem domain. A new technical product fulfils the need of a user
by offering particular services. The basis for the product is a conceptual solution. It
is this conceptual solution that is basically the idea for the product and that fulfils
the users needs. The conceptual solution often implies the selection of some feasible
technology. For instance chip technology in combination with physical principles that
enable conversion of electrical energy in some other form of energy and vice versa. A
product is a refined implementation of a conceptual solution.
During specification, conceptual solutions can be modelled by abstraction, just like real
world problem domains can. From this point of view we search for the concepts that
enable adequate system modelling instead of software modelling. We need entities that
can model functions, real world entities, data and physical concepts as well.
4.1.3 Objects instead of Functions
Traditional digital hardware design is based on a functional top-down decomposition or
a bottom up approach. Reuse has always been a tradition in hardware design. Over the
years, reusable standard components have grown from simple to very complex building
blocks.
The growth of software complexity led to problems such as quality and productivity
management. Productivity can be improved by reuse. In principle software systems contain
many reusable parts. In practice however reuse of software components appeared
to be difficult. Most differences or changes of requirements appear to be functional ones.
The objects in the problem domain and their relations seemed to be more static than the
functions. By encapsulating data into objects, together with the operations required on
that data, reusable objects could be obtained. Although the promise of reuse appeared
to be premature, object-orientation is certainly a promising paradigm.
Object-oriented techniques resulted in the development of languages as well as of analysis
methods. Object-oriented analysis techniques developed for software are typically
software engineering tools. They do not fulfil the needs of hardware designers. Existing
methods start with implementation independent modelling of the problem domain.
However, designers of complex reactive hardware/software systems should also study
implementation feasibility in the early design phases concurrently with the creation of
an implementation independent domain model.