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

198 Modelling of Concurrent Reactive Behaviour
modules. This is a binding mechanism for binding modules together. (There should be fewer
links between modules (external bindings) than within modules (internal bindings)).’ [R 91].
This class-oriented approach is not very appropriate for hardware/software systems.
We define modules as architectural blocks, which are instances bound in an architecture
structure or topology. We relate views directly to scenarios, in contrast to a grouping of
classes.
More appropriate and more often referred to is Jacobson’s [J 92] approach to scenarios
which he entitles as use cases in OOSE. Jacobson entitles terminators as actors, and
defines a user as ’an actual person who uses the system. An actor represents a certain role that
a user can play.’ Actors are regarded as a class and users as instances of this class. ’These
instances exist only when the user does something to the system. The same person can thus
appear as instances of several different actors’ [J 92]. This concept of user is very interesting,
because it emphasises the completely different roles that persons can play.
Before we elaborate on use cases we have to make some remarks about names and
definitions. In OOSE we find examples of undesirable redefinitions of common notions,
in this case user and actor. In our point of view a user is a person that is using a system
which was designed for his needs. So for instance a maintenance engineer, or a test
engineer is not a user. An operator is a person that has a monitoring and control task
which is performed by interaction with a system. Users, operators and engineers are
examples of persons that play different roles. The same person may possibly play various
roles at different times. We recommend to distinguish between the various types of users
as separate objects or terminators and name them according to their precise role. We
define an actor as an object or terminator that models a device that transforms a message
to a (physical) effect for the environment of a (sub)system. This is the common notion,
which is often mentioned in connection with sensors. Sensors and actors are respectively
input and output devices of a system. We think that it is extremely important to let the
meanings of concepts coincide with the meaning in common spoken language as good
as possible. After all, specification is all about communication between people.
Based on his view of user, Jacobson defines a use case as follows. ’An instance of an actor
carries out a number of different operations on the system. When a user uses the system, she or
he will perform a behaviourally related sequence of transactions in a dialogue with the system.
We call such a special sequence a use case. Each use case is a specific way of using the system and
every execution of the use case may be viewed as an instance of the use case. A basic course is the
most important course of events, alternative courses are variants on the basic course. Extensions
relate use cases. They specify how use case descriptions may be inserted into others’ [J
Jacobson describes the use of use cases throughout the system development process and
describes very useful heuristics and guidelines that go together with our scenarios very
well.
The main difference between use cases and our scenarios is that use cases are rather
human-interface-oriented and context-level-oriented. A context level is the very abstract
specification level, where the system is considered as a whole. Use cases are narrative
behaviour descriptions. So the system behaviour is described on context level as a
92].