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

48 Concepts for Analysis, Specification and Design
storeProductInfo, scheduleServices and waitTilNextProductArrivalIsSafe.
Within the method loopForever, four methods (acceptProduct, storeProductInfo, scheduleServices
and waitTilNextProductArrivalIsSafe) are successively called. Subsequently
the method loopForever is called. Hence the method loopForever ends with
a call to itself. In this way infinite (non-terminating) behaviour is specified.
The acceptProduct method starts with the waiting for an accept message with parameter
productInfo to arrive on channel i. The waiting for a message to arrive
is indicated by the question mark. An exclamation mark denotes that a process
wants to send a message. The simultaneous availability of a corresponding send
and receive statement in a pair of processes at the ends of a channel leads to synchronous
message passing. Since the currentPosition(Position) flow in Figure 3.9
is continuous, the Transporter Image is willing to send the currentPosition(Position)
message at any instant in time. Hence the Product Input Handler never has to
wait if it executes the piti?currentPosition(initialPosition) statement. In this way
continuous flows are modelled.
Within the storeProductInfo method local method variable id of class PIKeeperId is
declared between bars ( ). PIKeeperId is a class of data objects.
Finally, in method waitTilNextProductArrivalIsSafe, the statement wake?wakeup(id
id = myId) is specified. The expression id = myId behind the bar ( ) is a reception
condition indicating that the process is only willing to receive this message if the
expression evaluates to true.
The language POOSL has a formal semantics. This means that the behaviour to be executed
is defined unambiguously. Our specification method also incorporates behaviour
preserving transformations. These transformations enable structure modifications that are
proven correct. They allow a channel structure to be redesigned according to constraints
and design decisions that evolve during the modelling process. These transformations
also enable easy maintenance of the POOSL model. Architecture and implementation
structure design decisions can be incorporated into the model easily.
3.6.6 Representations and Method Framework
An analysis and design method must offer a framework in which various modelling
activities take place. Various consistent forms of representations should have well
defined relations. A framework gives guidance to a designer. Figure 3.11 shows the
SHE method in the context of product design. The framework of SHE must enable
all activities to create a specification, largely in the form of a system model, that can
form a bridge between product idea and actual design and implementation. Before
we show a picture of the framework of SHE, we present an overview of the various
forms of representations that are used in the framework. Figure 3.12 gives a simplified
overview of the sorts of representations in SHE. The method yields graphical and textual
results which are visualised as the two main blocks. Graphical models are divided into
Object Models and Structure Models. The Object Models are the Object Class Model
that visualises relations between classes and the Object Instance Model that visualises