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

6.5 Scenarios 199
collection of texts. During the following analysis and design phases verification of results
towards these informal texts must be executed. Notice that our scenario approach works
rather different. We recommend to identify the necessary players and other objects in the
system as soon as possible. These objects interact via a structure of message flows. This
visualises who needs who. The behaviour of complex systems cannot be defined on the
context level. Therefore we need scenarios on various specification levels and as various
views as a means to discover the complete required behaviour. A top down approach
makes it very difficult to make a complex system specification complete. Unfortunately
Jacobson’s use case approach has the style of top down analysis.
The interesting point in the use case approach is that it looks at several roles that users
can play at different times, and the various forms of behaviour a system can perform
from the point of view of a specific user. We can generalise this approach towards
collaborating instances inside or outside the system. A collaborating instance is also a
kind of user, with specific use cases. This is typically what scenarios can describe.
OOSE develops a design and implementation model after a requirements model and an analysis
model. Use cases can be mapped onto interaction diagrams in the design modelling
phase. Interaction diagrams are graphical representations that show the interactions
between objects and the system environment with respect to time. This is a useful
approach which is also commonly accepted for the design of communication systems.
We consider to implement this form of representation in our method (see future research,
Chapter 13).
Coleman et al. [C 94] define a scenario in the Fusion method as ’a sequence of events
between agents and the system that is carried out for some purpose. Scenarios are represented on
time-line diagrams.’ The Fusion approach starts with the creation of an object model and
the development of an interface model. Scenarios visualised as time-line diagrams play
a very limited role for user interface modelling on context level. They are formalised at
high level into a life-cycle model and an operational model, which define respectively
controllers as regular expressions and operations by preconditions and postconditions.
The concept of scenario is used in relation with object interaction graphs that are used
in the design phase. This method is designed for analysis and design of relatively
small systems. Time-line diagrams are an interesting possible addition to our scenario
narratives.
6.5.3 Developing Scenarios
Scenarios must play a leading role in the design of complex reactive systems. The amount
of interactions can be overwhelming in a complex system. The combination of the use
of the concepts of hierarchical clustering, views, instance-oriented diagramming and
scenarios, enable the necessary abstraction to conquer complexity. The key issue is that
we design a model (which becomes the specification of a system) by playing scenarios. It
is our way to find process objects, communication flows, the type of flows, clusters, data
objects that are transported, etcetera. We play behaviour games as mental processes or
trains of thought. Scenarios are the representations used for reasoning about behaviour,