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.

2.5 Modelling Concepts 23<br />

entirety. Therefore behaviour should be distributed over modules whose behaviour<br />

can be understood without having to understand the environment they are placed in.<br />

This requires modules to be self-contained, autonomous, relatively independent, and<br />

weakly coupled entities. We will call these entities process objects, or processes in<br />

short. Processes exist in their own right, have their own responsibilities, and they have<br />

their own activities to perform. This is highly desirable since it enables processes to be<br />

reused in contexts other than the one for which they were originally devised. Reuse is<br />

achieved by organising objects into classes. A class is a template from which objects are<br />

instantiated.<br />

Behaviour models should be built from process objects. Process<br />

objects are concurrent, self-contained, autonomous, relatively independent<br />

and weakly coupled entities. Process objects have to<br />

be grouped into classes.<br />

Channels and Clusters<br />

A very important characteristic <strong>of</strong> hardware/s<strong>of</strong>tware systems is structure. Physical<br />

or spatial distribution, physical topology, hardware/s<strong>of</strong>tware partitioning and s<strong>of</strong>tware<br />

layering are all examples <strong>of</strong> phenomena that impose structure. The modelling <strong>of</strong> topology<br />

requires that processes can be structured in a network <strong>of</strong> channels. The other forms<br />

<strong>of</strong> structure require the possibility to group processes into higher-order entities, called<br />

clusters. A cluster acts as an hierarchical abstraction <strong>of</strong> its internals. Hierarchy is an<br />

important concept that helps to manage complexity. To enhance modularity and reuse,<br />

clusters should be organised into classes.<br />

Processes should be connected by channels. It must be possible<br />

to group processes into clusters. Clusters have to be organised<br />

into classes.<br />

Message Passing<br />

Processes (and clusters) are relatively independent and they can perform their activities<br />

concurrently and at their own speed. Despite <strong>of</strong> their autonomy, processes will frequently<br />

have to exchange information. To make the coupling between processes (and<br />

clusters) as weak as possible, information exchange should be based upon message<br />

passing. The essential feature <strong>of</strong> message passing is that information is exchanged by<br />

means <strong>of</strong> an intermediate artefact, called a message. The purpose <strong>of</strong> a message is to<br />

reduce the coupling between the message senders and the message receivers. To exchange<br />

information, the sender and the receiver only have to share the format and the<br />

general semantics <strong>of</strong> a message. They do not have to know anything about each other’s<br />

internals, i.e. about private data. The internals <strong>of</strong> a process are said to be encapsulated<br />

by a strong encapsulation boundary. The only way for other processes to access these<br />

internals is through a clear-cut message interface.

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

Saved successfully!

Ooh no, something went wrong!