B.1. Class Diagrams

A UML class diagram summarizes features of a class, its relation to other classes, or both. Beginning with an example, Figure B-1 shows the Starship class.

Figure B-1. UML class diagram summarizing the Starship class.

(This item is displayed on page 544 in the print version)

The diagram of a class is divided into three sections. The top section shows the name of the class in bold type. The middle section shows the fields of the class. The bottom section shows the methods of the class.

The name and type of each field are given, separated by a colon. A static field, such as SPEED_OF_LIGHT, is underlined.

In the methods section, the name, argument types, and return type of each method are given. In Figure B-1, the method accelerate() takes a double and an int as argument, but has a return type of void. Constructors have no return type. Static methods, like main(), are underlined.

UML class diagrams can also be used to show the relationships between classes. In Figure B-2, a Fleet contains zero or more Starships. If a Fleet always contained three to six Starships, the notation 0..* would be replaced with 3..6.

Figure B-2. UML class diagram showing the relationships between the Fleet, Starship, and Battlecruiser classes. The notation 0..* indicates any number that is at least zero.

Figure B-2 also shows that the class Battlecruiser extends the class Starship. In other words, Battlecruiser is a direct subclass of Starship. This is explained in much more detail in Chapter 3. In a UML class diagram, any fields or methods present in the superclass are normally not listed in the subclass.

The words "contains" and "extends" are not normally included in UML class diagrams. Instead, the different arrow styles indicate the relationship in question. A line arrowhead indicates a "contains" or "has-a" relationship. A hollow arrowhead indicates an "is-a" relationship, such as "extends."

When there are many classes involved, it is sometimes clearer to leave out some or all of the fields and methods (Figure B-3).

Figure B-3. Fields and methods are sometimes omitted in UML class diagrams.

Interfaces (Section 2.3) can also be shown in UML class diagrams (Figure B-4). An interface name is labeled with the notation <>. A dashed arrow with a hollow head indicates an "implements" relationship, which is another kind of "is-a" relationship.

Figure B-4. The interface Animal is implemented by the classes Reptile and Mammal, which are extended by other classes.

The methods in an interface are in italics to indicate that they are abstract. In other words, only the method signatures are specified in the interface; it is up to subclasses to provide concrete implementations. An abstract class (Section 5.5) can contain both abstract and concrete methods. In a UML class diagram, the name of an abstract class is italicized (Figure B-5).

Figure B-5. The class Organization is abstract, as is its method chooseNewLeaders(). A Corporation may have other corporations as subsidiaries. A Nation has at least one PoliticalParty, and may have other Nations as neighbors.

Java 1.5 introduces the notion of generic types (Section 4.1). A generic type has one or more other types as parameters. For example, a generic List type allows us to distinguish between a List of Integers and a List of Strings. In a UML class diagram, a type parameter is shown as a small, dashed box at the upper right of a class or interface (Figure B-6). This may contain either a type variable (such as E for element) or the name of a specific class.

Figure B-6. The Sequence class (top) is generic. A Poem (bottom) contains a Sequence of Words.

In very large programs, classes are often grouped into packages (Section 3.3). In a UML class diagram, a package looks something like a file folder drawn behind the classes it contains (Figure B-7).

Figure B-7. The game.ai package contains an interface and two classes. Each of the other two packages contains three classes.

B 2 Instance Diagrams