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

4.15 Operations, Services, Methods 113
This expression creates a new object of class C. All instance variables are nil after creation.
Initialisation of instance variables must be performed by a transformer that is defined
by the designer, with for example name initialise. This service can be denoted by the
(equivalent) message name in the class of the Object Class Model.
Transformers and accessors are denoted in graphical schemes: they are denoted as
message names in class symbols in Object Class Models. Not all services are denoted
graphically. User defined data objects in POOSL have two predefined services viz. the
primitive methods ’deepCopy’ and ’equality’.
4.15.4.2 Process Object Methods
Process objects can be visualised during analysis in Object Class Models as well as
in Instance Models. Messages are denoted in the classes in the Object Model. These
messages should correspond to messages defined in the Message Flow Diagrams. Notice
that process objects decide for themselves whether they want to accept a message in a
given state. Messages between process objects are communicated via channels. Which
messages are communicated on specific channels is specified in the message interface of
the class. Two process objects that exchange messages have at least one channel to do
this. Architecture design determines the channel topology.
The behaviour of a process is specified in terms of methods. Transformers and accessors
can be modelled straightforward by using the same name for messages and methods.
Many processes will however have the character of a controller. In this case the same
message may evoke different responses at different times, depending on the state of
the process. The object has an autonomous character. Its behaviour may be defined
to be infinite. The branching through various sequences and loops of methods defines
the process behaviour. This behaviour is not defined by the messages, channels, and
attributes solely. In Section 6.5 we will present scenarios as a means to informally
describe the behaviour of a process, as a preparation for the formal definition of the
methods in a class. In general a process will take part in several scenarios. Therefore
the definition of the methods must be postponed until we can join the information of all
scenarios to define the behaviour of a class.
4.15.4.3 Methods, Messages and Events
The description of analysis so far was mainly based on traditional object- oriented
viewpoints. However SHE offers a lot more. For a full understanding of what is
necessary to analyse such complex things as processes, we need to explain various
message flows. For a full description we refer to Section 6.3. Here is a brief overview of
the message flows (see also Figure 3.8):
a single message flow between process objects represents events, commands, requests
without reply, or requests with delayed reply on initiative of the receiver;
a message with reply flow represents a request with waiting for reply, or a client server
communication with waiting for reply;