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

11.4 Essential Specification Modelling 351
we do not recommend a strict top-down approach, nor a bottom up approach. We
propose to start in the middle by modelling the objects that represent the essence of the
system.
One or more conceptual approaches that model the essential functionality of the system
must be evaluated. Useful heuristics for essential modelling can be found in [WM85].
Important heuristics that we take from them are outside-in modelling, minimum interface
modelling, and various heuristics for grouping. We also follow their guideline of
leaving interface technology out of an essential model.
Objects in a problem domain are mapped into a model. External objects that are modelled
as terminators can also be ’mirrored’ into the system as so-called images. In practice
a considerable number of modelling attempts is necessary before we can find a model
that is worthwhile to be completed.
11.4.5.3 Finding Objects
Objects are found as entities, things or concepts in the problem domain. A first approach
is looking at nouns in the Initial Requirements Description. [R 91] gives a useful list of
guidelines for finding objects for OMT. The method OMT focuses on object class models.
We can use the guidelines for finding objects for MFDs as well as for finding classes in
Object Class Diagrams.
Easily found are in general so-called real-world objects. They are found by studying
the existing environment of a system to be designed. We defined image objects and
artefact objects. Artefact objects model the conceptual technical solution that is usually
incorporated in a reactive system.
The modelling of objects requires experience and mature judgement. Entities in the
problem domain are candidate objects. They may become attributes, data objects, process
objects or clusters. A problem domain consists in general of entities on various
levels of abstraction. A collection of data and operations can be enclosed in a domain
boundary. Domain boundaries are modelled as clusters or process objects. Data is modelled
as data objects or attributes that refer to data objects. Whether an entity becomes
a cluster, a process object, a data object or an attribute requires careful consideration.
Process objects are not just entities that perform functions. Objects should be balanced
entities that are worthwhile to become autonomous things that encapsulate properties
and perform behaviour.
The balance between appropriate functionality and the right abstraction of properties
can only be found if various aspects and properties of alternatives are considered. Once
MFDs emerge it is useful to start making Object Class Diagrams. Besides the messages
already found in MFDs, attributes must be written in the object classes. The aspect
of reuse should be considered. Objects must be defined as generic as possible. Other
objects may be designed as controllers that are less reusable. By defining controllers
other objects can be constructed more generic. Notice also that conceptual non-tangible