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.

4.12 Object Variety 101<br />

Part class<br />

Class B<br />

Attributes<br />

Messages<br />

or that subtype [R<br />

Class A<br />

Attributes<br />

Messages<br />

91].<br />

Class C<br />

Attributes<br />

Messages<br />

Whole<br />

class<br />

Whole-part<br />

symbol<br />

4.11.2 Hierarchy <strong>of</strong> Subsystems<br />

Class B<br />

Attributes<br />

Messages<br />

Class A<br />

Attributes<br />

Messages<br />

Figure 4.28: Different Class Hierarchies<br />

Class C<br />

Attributes<br />

Messages<br />

Superclass<br />

Specialisation<br />

symbol<br />

Subclass<br />

A system composition is visualised as a hierarchical tree <strong>of</strong> modules (subsystems). A<br />

composite can be modelled as a cluster. Clusters <strong>of</strong>fer visual hiding <strong>of</strong> composites at<br />

the various hierarchical levels <strong>of</strong> a model. A module (subsystem) can be a cluster or a<br />

process object. (See Figure 4.16 in Section 4.5). We visualise (nested) clusters in Object<br />

Instance Diagrams, and not in Object Class Diagrams.<br />

Although clusters are described in classes, they are not visualised in Object Class Diagrams.<br />

Whole-part relations between object classes in Object Class Diagrams show<br />

conceptual relations. Aggregates and clusters in Object Instance Models show actual<br />

relations. Actual composites are instances <strong>of</strong> conceptual composites that are denoted<br />

as whole-part relationships in Object Class Diagrams. Object Instance Models <strong>of</strong>fer the<br />

possibility to integrate design aspects into a model. Clusters can visualise instances<br />

<strong>of</strong> conceptual relations as well as topological constraints derived from architecture and<br />

implementation considerations.<br />

4.12 Object Variety<br />

Objects can represent a wide variety <strong>of</strong> concepts and entities. During analysis objects<br />

may come from various sources. Coad and Yourdon mention the following items that<br />

must be looked for to find classes and objects: ’structures, other systems, devices, things<br />

or events remembered, roles played, operational procedures, sites, and organisational units.’<br />

This leads to a natural variety <strong>of</strong> objects that are originating from the problem domain<br />

analysis. Traditional object-oriented methods apprehend this variety by defining classes<br />

and the relations between them.

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

Saved successfully!

Ooh no, something went wrong!