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

6.5 Scenarios 195
entities. This subsection showed that considered use of these concepts is necessary to
specify a distribution structure.
6.5 Scenarios
6.5.1 Scenario Concept
A scenario describes the order of a coherent set of actions. A scenario defines and
describes the responses elicited by communication with one or more objects outside the
(sub)system under analysis. Scenarios are used to describe parts of behaviour that is too
complex to be described as a whole.
Scenarios provide two ways to master complex behaviour. They enable a divide and
conquer strategy and are a means to distinguish views on the system. Examples of such
scenarios are an initialisation scenario, a configuration scenario, a normal operation
mode scenario and a shut down scenario. Scenarios can be used also to visualise an
abstraction that fits to the user point of view.
Scenarios that represent a view of a discipline are useful because they enable showing
the right abstraction of behaviour to an expert in the discipline. This enables reviewing
of a model in an efficient way. Examples are a test scenario, a maintenance scenario, a
repair scenario and a safety scenario.
We visualise a scenario by drawing appropriate communication flows into a dedicated
Message Flow Diagram. These flows are the stimuli and responses of the processes that
participate in a specific scenario. In general, only a part of the processes of a model
participates in a particular scenario. Process objects that are superfluous for a particular
scenario must be hidden to prevent cluttering the scenario. In current practice we use
a graphical drawing tool that offers a concept of layers. Layers as well as objects can
be set to be active or visible. Colouring the layers gives additional discrimination that
helps during the development of scenarios. Tools to be developed for SHE must at
least have such a layer feature. In addition they must preserve layers over hierarchy
boundaries. Figure 6.17 through Figure 6.19 show three scenarios for a part of a feeder
model of a mailing machine. Notice that there are differences as well as similarities in
objects and flows in the scenarios. All the flows, objects, and clusters found during the
modelling process must be assembled to be able to describe the POOSL object classes.
The assembled information of all scenarios is shown in a single diagram in Figure 6.20.
This diagram represents a so-called scenario assembly. Notice that we visualise instances
and not classes. Only by making a pile of all instances of a certain class we can get an
overview of all flows (and channels) that we need to describe the class message interface
in POOSL.
In addition to the graphical representation we describe scenarios in a narrative way.
Such a narrative description is called a scenario narrative. A scenario narrative is a text
that describes the causal relations between: