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

6.5 Scenarios 197
startJob
readyToAccept(PI)
accept(PI)
Job_
Controller
startConfig
Product_
Input_
Handler
startCount/
ShiftCount(Number)
flushFifo
write(PI)
Config_
Handler
PI_Fifo
startConfig
ShiftEndCorr/
shiftCount(Number)
serviceRequested
(ServiceId)/
service(YesNo)
serviceResult
(OkNotOK)
Figure 6.20: Scenario Assembly
Product_
Output_
Handler
readyToAccept(PI)
accept(PI)
in which events and responses are expected to happen. This information is very useful
for later development of POOSL descriptions.
6.5.2 Scenarios in other Methods
Scenario is a concept that is found in methods such as OMT [R 91], OOSE [J 92], Fusion
[C 94], and ROOM [SGW94]. Our concept of scenario is defined and applied broader
than in other methods. Most authors present scenarios as a tool on context level, and
emphasise modelling of the user interface. In contrast, we emphasise the use of scenarios
on all levels of abstraction and as a tool to grasp multidisciplinary views. In spite of the
differences, various authors give very useful and clarifying observations.
Selic et al. [SGW94] define an (action) scenario as ’a series of causally chained events typically
spanning multiple tasks in a system that represent some meaningful high-level operation.’
Rumbaugh et al. [R 91] define a scenario as ’a sequence of events that occurs during one
particular execution of a system. The scope of a scenario can vary; it may include all events
in the system, or it may include only those events impinging on or generated by certain objects
in the system. A scenario can be the historical record of executing a system or a thought
experiment of executing a proposed system.’ Sequences of events are visualised in so-called
event trace diagrams. Events in OMT are a concept that is not the same as messages.
Events are grouped into classes. We only group objects and clusters into classes. A
major difference between our approach and OMT is that we emphasise an instanceoriented
approach whereas OMT uses a class-oriented approach. Our scenarios are
visualised with flows between instances. The class approach in OMT leads to artificial
and confusing definitions of the concept of module and of view. We cite the definition.
A module is ’a logical grouping construct, grouping classes, associations, and generalisations.
A module captures one perspective or view of a situation. For example, electrical, plumbing and
ventilation modules are different views of a building. An object model consists of one or more
modules. Modules partition the model as an intermediate unit of packaging. Class names and
associations must be unique within a module. The same class may be referenced in different