PTOLEMY II - CiteSeerX
PTOLEMY II - CiteSeerX
PTOLEMY II - CiteSeerX
You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
Introduction<br />
grams, the only constructors available for a class are those shown in the box defining the class. Figure<br />
1.21 does not show all the constructors of these classes, for simplicity.<br />
Classes shown in boxes outlined with dashed lines, such as NamedObj in figure 1.21, are fully<br />
described elsewhere. This is not standard UML notation, but it gives us a convenient way to partition<br />
diagrams. Often, these classes belong to another package.<br />
A.2.3 Interfaces<br />
Figure 1.21 also shows two examples of interfaces, Executable and Actor. An interface is indicated<br />
by the label “” and by italics in the name. An interface defines a set of methods<br />
without providing an implementation for them. It cannot be instantiated, and therefore has no constructors.<br />
When a class implements an interface, the object model shows the relationship with a dotted-line<br />
with an arrow. Any concrete class (one that can be instantiated) that implements an interface must provide<br />
implementations of all its methods. In our object models, we do not show those methods explicitly<br />
in the concrete class, just like inherited methods, but their presence is implicit in the relationship to<br />
the interface.<br />
One interface can extend another. For example, in figure 1.21, Actor extends Executable. This<br />
means that any concrete class that implements Actor must implement the methods of Actor and Executable.<br />
We will occasionally show abstract classes, which are like interfaces in that they cannot be instantiated,<br />
but unlike interfaces in that they may provide default implementations for some methods and<br />
may even have private members. Abstract classes are indicated by italics in the class name. There are<br />
no abstract classes in figure 1.21.<br />
A.2.4 Associations<br />
Inheritance and implementation are types of associations between entities in the object model.<br />
Associations of other types are indicated by other lines, often annotated with ranges like “0..n” or with<br />
diamonds on one end or the other.<br />
Aggregations are shown as associations with diamonds. For example, an Entity is an aggregation<br />
of any number (0..n) instances of Port. More strongly, we say that a Port is contained by 0 or 1<br />
instances of Entity. By containment, we mean that a port can only be contained by a single Entity. In a<br />
weaker form of aggregation, more than one aggregate may refer to the same component. The stronger<br />
form of aggregation (containment) is indicated by the filled diamond, while the weaker form is indicated<br />
by the unfilled diamond. There are no unfilled diamonds in figure 1.21. In fact, they are fairly<br />
rare in Ptolemy <strong>II</strong>, since many of its architectural features depend on containment relationships, where<br />
an object can have at most one container.<br />
The relationship between Entity and CompositeEntity is particularly interesting. An instance of<br />
CompositeEntity can contain any number of instances of Entity, but CompositeEntity is derived from<br />
Entity. Thus, a CompositeEntity can contain any number of instances of either Entity or CompositeEntity.<br />
This is the classic Composite design pattern [42], which supports arbitrarily deeply nested containment<br />
hierarchies.<br />
In figure 1.21, a CompositeActor is an aggregation of AtomicActors and CompositeActors. These<br />
two aggregation relations are derived from the aggregation relationship between Entity and CompositeEntity.<br />
This derived association is indicated with a dashed line with an open arrowhead.<br />
Heterogeneous Concurrent Modeling and Design 43