Appendix C. UML Class Diagrams

In this chapter, we present Unified Modeling Language (UML) class diagrams for several POOMA classes. These diagrams are created at the specification level, which indicates the software interface, not its implementation. Figure 4-1 provides a top-level overview of the relationships between classes. Readers interested in the implementation are encouraged to read the corresponding source code. More extensive explanations of these classes appear in the main chapters of this book.

Figure C-1 illustrates a typical UML class diagram. The diagram has three classes: Classname1, Classname2, and Classname2<1>. Most classes are represented by three-part boxes. The top part lists the class's name. The middle part lists public data members, if any. Few POOMA classes have public data members so this section is frequently empty. The bottom part lists public member functions, if any. "Free parameter types" indicate templated parameters. Classname2<1> has only one part, not three. Its three-part box appears in another diagram, presumably because there is not enough room in this one. Both Classname1 and Classname2 have template parameters, each named T. These occur in dashed boxes at the upper-right corner of the class boxes. Files implementing a class are listed at the lower, right corner of the class's box. These implementation files may be different from the header files to include in one's program to use these classes.

Lines connect classes. The solid arrow with large triangular arrowhead indicates that Classname2 is a subtype of Classname1. Since this diagram represents the specification level, subtyping does not necessarily correspond to C++ type inheritance. Also, subtype class boxes need only list members not available in the supertype. For this case, Classname2 has one new member not provided by Classname1. A dashed arrow indicates a class formed by a template instantiation. The class name indicates which template parameters are bound. For example, Classname2<1> instantiates Classname2 with T equal to 1.

Some of the functions require many, similar function arguments. We introduce regular expression notation to reduce the length of the function prototype. For example,

void foo(const X[1-3]&)

abbreviates

void foo(const X1&, const X2&, const X3&)

X[1-3] abbreviates X1, X2, X3. We assume this distributes over const &, to yield C++ code.

These diagrams omit a lot of details. Private and protected data members are not listed. Compile-time types and values are not listed. No indication is given of the actual implementation. Some template arguments of parameters have been suppressed.