PTOLEMY II - CiteSeerX

Introduction
Appendix A: UML — Unified Modeling Language
UML (the unified modeling language) [40][118] defines a suite of visual syntaxes for describing
various aspects of software architecture. We make heavy use of two of these visual syntaxes, package
diagrams and static structure diagrams. These syntaxes are summarized here. As with most descriptive
syntaxes, any use of the syntax involves certain stylistic choices. These stylistic choices are not part of
UML, but nonetheless can be important to understanding the diagrams. We explain the style that we
use here.
A.1 Package Diagrams
Figures 1.12 and 1.17 show UML package diagrams, which have a simple syntax. A package is
given as a box with a tab, with the tab containing the name of the package. Subpackages are enclosed
in the box of the parent package, and package dependencies are indicated with arrows. A package
dependency occurs when a Java file in a package includes a class in another package (using import in
Java).
A.2 Static Structure Diagrams
Figure 1.16 is a different kind of UML diagram, called a static structure diagram or class diagram.
It represents the relationships between classes, including inheritance relationships, containment relationships,
and cross references. These relationships are called an object model, and represent many
essential features about the design.
A.2.1 Classes
A simplified static structure diagram for some Ptolemy II classes is shown in figure 1.21. In this
diagram, each class is shown in a box. The class name is at the top of each box, its attributes are below
that, and its methods below that. Thus, each box is divided into three segments separated by horizontal
lines. The attributes are members of the Java classes, which may be public, package friendly, protected,
or private. Private members are prefixed by a minus sign “-”, as for example the _container
attribute of Port. Although private members are not visible directly to users of the class, they may
nonetheless be a useful part of the object model because they indicate the state information contained
by an instance of the class. Public members have a leading “+” and protected methods a leading “#” in
a UML diagram. There are no public or protected members shown in figure 1.21. The type of a member
is indicated after a colon, so for example, the _container member of Port is of type Entity.
Methods, which are shown below attributes, also have a leading “+” for public, “#” for protected,
and “-” for private. Our object models do not show private methods, since they are not inherited and
are not visible in the interface to the object. Figure 1.21 shows a number of public methods and one
protected method, _checkLink() in Port. The return type of a method is given after a colon, so for
example, linkedRelationList() of Port returns a List.
Although not usually included in UML diagrams, our diagrams show class constructors. They are
listed first among the methods and have names that are the same as the name of the class. No return
type is shown. For completeness, our object models typically show all public and protected methods of
these classes, although a proper object model might only show those relevant to the issues being discussed.
Figure 1.21 does not show all methods, so that we can simplify the discussion of UML. Our
Heterogeneous Concurrent Modeling and Design 41