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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

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

The ROOA method [Mor94] distinguishes objects that have an important role in the<br />

system from objects that only play the role <strong>of</strong> attributes <strong>of</strong> other objects. The former<br />

objects are modelled as processes in LOTOS [ISO88] and the latter as values <strong>of</strong> ADTs<br />

(Abstract Data Types). The objects modelled as LOTOS processes, are similar to our<br />

process objects. The objects modelled in terms <strong>of</strong> ADTs, however, differ from our data<br />

objects. In fact, ADTs in LOTOS are not expressive enough to model objects. They are<br />

merely collections <strong>of</strong> data values together with a number <strong>of</strong> operations defined on these<br />

values. The values <strong>of</strong> ADTs are not separately identifiable and are therefore not objects.<br />

The other formal description techniques, SDL [BH93] and Estelle [D<br />

89], distinguish<br />

processes from data, just as LOTOS does. Processes in these languages are expressive<br />

enough to model entities that are similar to our process objects. The data part <strong>of</strong> SDL is<br />

based on ADTs and is not suitable for the modelling <strong>of</strong> data objects. Estelle uses Pascal<br />

types to model data. Pascal has insufficient support for data modularisation and is also<br />

not suitable for the modelling <strong>of</strong> data objects. An object-oriented specification method<br />

that makes a similar distinction between process objects and data objects as we do is<br />

ROOM [SGW94]. Process objects in ROOM are called actors.<br />

4.5 Clusters<br />

A model <strong>of</strong> a complex system contains many different objects. To manage complexity, an<br />

abstraction mechanism is required that groups collections <strong>of</strong> collaborating objects into<br />

single entities. We <strong>of</strong>fer the concept <strong>of</strong> ’cluster’ to do this. A cluster is a boundary around<br />

a group <strong>of</strong> collaborating process objects and clusters. Clusters are not individually identifiable<br />

entities (see Subsection 4.7.3). Therefore clusters are not objects. Nevertheless, a<br />

cluster has a well defined interface, like an object. Another correspondence with objects<br />

is that clusters are grouped in classes. Each cluster is an instance <strong>of</strong> some cluster class.<br />

Since clusters are not objects, cluster classes are not shown in Object Class Diagrams.<br />

Clusters are typically shown in Object Instance Models. Figure 4.15 shows an object<br />

Object A Object B<br />

Object C<br />

Cluster<br />

Figure 4.15: Clustered Objects<br />

cluster, its interface in the form <strong>of</strong> external flows, and its internal objects and message

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

Saved successfully!

Ooh no, something went wrong!