23.08.2013 Views

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

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

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

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

110 Abstraction <strong>of</strong> a Problem Domain<br />

sequential. Process objects have instance variables that hold references to data objects<br />

or to other process objects. The references to other process objects are typically needed<br />

for weakly distributed forms <strong>of</strong> communication with the other process objects. Process<br />

identifiers are used as ’address’ <strong>of</strong> process objects for delivering messages on channels.<br />

Process identifiers are modelled as data objects. Data objects in a process object are<br />

private, which means that they are never shared with other process objects. However,<br />

a private data object can be copied and can thereby emulate travelling from process to<br />

process.<br />

4.15 Operations, Services, Methods<br />

This section introduces elements for the description <strong>of</strong> behaviour <strong>of</strong> objects. It will<br />

appear that we define the concept <strong>of</strong> ’method’ for process objects rather differently than<br />

in the mainstream <strong>of</strong> other object-oriented methods. This subject is strongly related to<br />

other important concepts such as <strong>of</strong> ’state’ and <strong>of</strong> ’behaviour’ (see Section 6.4). There is<br />

also a strong relation between services, methods and messages. Messages are described<br />

in the section about communication (Section 6.3). This section has been limited to the<br />

definition <strong>of</strong> the concepts <strong>of</strong> service, operation and <strong>of</strong> method, and their role in system<br />

analysis.<br />

4.15.1 Operations<br />

We define an operation as an action performed by an object. This may be a transformation<br />

on its internal data or on data furnished by a message, it may also be an input or<br />

output action to its environment. Rumbaugh et al. define an operation as ’a function or<br />

transformation that may be applied to or by objects in a class’ [R<br />

91]. Notice that we give a<br />

broader definition that does not require a one to one relation between an operation and<br />

reception <strong>of</strong> a corresponding message. Operations can be performed by autonomous<br />

process objects on their own initiative, as a postponed response to communication with<br />

other objects. Operations form a grain <strong>of</strong> behaviour. A sequence <strong>of</strong> operations may be<br />

the response on a single message reception.<br />

4.15.2 Services<br />

We define a service as the response <strong>of</strong> an object, on reception <strong>of</strong> a message. The services<br />

<strong>of</strong>fered by an object are defined in the message interface <strong>of</strong> its class. Names <strong>of</strong> messages<br />

correspond to services exported by the message interface to collaborating objects. The<br />

response <strong>of</strong> an object to a message consists <strong>of</strong> accepting the message with its parameters,<br />

followed by performing one or more operations. The response <strong>of</strong> the object becomes<br />

visible when an object produces results in the form <strong>of</strong> sending reply- messages or other<br />

messages. Visible responses give so-called externally observable behaviour.<br />

It is useful to distinguish between various sorts <strong>of</strong> services. Determining sorts enables<br />

communication between people involved in analysis. The various sorts can be checked,

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!