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

352 SHE Framework
things in a problem domain may very well become process objects. In a functional
approach these entities will be modelled as data. However, a conceptual thing can be
considered as an autonomous process object that hides its data, and that can for instance
be requested to give its data or calculate an alternative representation of that data.
11.4.5.4 Hierarchy
For complex systems it will be impossible to come up with a first time right approach
towards the structure of the MFDs. A complex model is structured as a hierarchy of
MFDs. The system level is the highest level in the hierarchy. A system level MFD shows
the combination of flows between the main modules of the system that are represented
as clusters. On the lower levels of the hierarchy, clusters are decomposed into smaller
clusters and process objects. On the lowest level clusters are decomposed into process
objects only.
A general problem of graphical models is that they can be structured in an infinite
number of ways. The way a model is structured has an influence on further actions of
a designer. In a complex system, groups of objects must be clustered. People tend to
cluster objects that are near to each other. There are however a lot of considerations that
are much more important than the accidental proximity of an object.
The architecture of the system determines the system level structure of the MFDs.
Modules from the architecture design are modelled consistently as clusters in
MFDs.
Well defined clusters are necessary to support boundaries that specify for instance
aggregates by abstraction boundaries, hardware/software partitioning by implementation
boundaries, constraints on concurrency with concurrency boundaries
and physical distribution by distribution boundaries.
Various heuristics from other methods can be used. For instance [WM85] recommends
heuristics such as to create minimum interfaces, to use response related
grouping, to use terminator related groupings, etcetera.
An important rule is that a cluster should preferably represent some nameable entity
in the problem domain or in the conceptual solutions to be modelled. Notice that it
can take some time before it becomes clear whether some entity must be modelled as a
process object or as a cluster.
11.4.5.5 Scenarios
There is such a huge amount of aspects that can be considered for a specification that
it is wise to restrict and guide the fields of attention. We introduced scenarios as a
means to abstract information. In general, scenarios that are used for conquering the
functional complexity of a system cannot be determined in advance. They can be diverse
and will emerge during modelling. For example in the Buhrs case (see Chapter 12) we
developed separate scenarios for the modules (stations) in the architecture diagram.
A generic approach can be found by distinguishing different working modes, such as