The Class Diagram

The most basic of UML diagrams is the Class Diagram. It both describes classes and shows the relationships between them. The types of relationships that are possible are

• When one class is a “kind of” another class: the is-a relationship

• When there are associations between two classes

  - One class “contains” another class: the has-a relationship

  - One class “uses” another class

There are variations on these themes. For example, to say something contains something else can mean that

• The contained item is a part of the containing item (like an engine in a car).

• I have a collection of things that can exist on their own (like airplanes at an airport).

The first example is called composition while the second is called aggregation.^[1]

^[1] Gamma, Helm, Johnson, and Vlissides (the Gang of Four) call the first “aggregation” and the second “composition”—exactly the reverse of the UML. However, the Gang of Four book was written before the UML was finalized. The presented definition is, in fact, consistent with the UML's. This illustrates some of the motivation for the UML; before it came out there were several different modeling languages, each with its own notation and terms.

Figure 2-1 illustrates several important things. First, each rectangle represents a class. In the UML, I can represent up to three things in a class:

• The name of the class

• The data members of the class

• The methods (functions) of the class

I have three different ways of showing these.

• The leftmost rectangle shows just the class' name. I would use this type of class representation when more detailed information is not needed.

• The middle rectangle shows both the name and the methods of the class. In this case, the Square^[2] has the method display. The plus sign (+) in front of display (the name of the method) means that this method is public—that is, objects other than objects of this class can call it.

  ^[2] Whenever we refer to a class name, we will bold it as done here.

• The rightmost rectangle shows what I had before (the name and methods of the class) as well as data members of the class. In this case, the minus sign (-) before the data member length (which is of type double) indicates that this data member's value is private, that is it is unavailable to anything other than the object to which it belongs.^[3]

  ^[3] In some languages, objects of the same type can share each other's private data.

UML notation for access. You can control the accessibility of a class' data and method members. You can use the UML to notate which accessibility you want each member to have. The three types of accessibility available in most object-oriented languages are as follows: Public: notated with a plus sign (+). This means all objects can access this data or method. Protected: notated with a pound sign (#). This means only this class and all of its derivations (including derivations from its derivations) can access this data or method. Private: notated with a minus sign (-). This means that only methods of this class can access this data or method. (Note: Some languages further restrict this to the particular object.)

Class Diagrams can also show relationships between different classes. Figure 2-2 shows the relationship between the Shape class and several classes that derive from it.

Figure 2-2 represents several things. First, the arrowhead under the Shape class means that those classes pointing to Shape derive from Shape. Furthermore, since Shape is italicized that means it is an abstract class. An abstract class is a class that is used to define an interface for the classes that derive from it.

There are actually two different kinds of has-a relationships. One object can have another object where the contained object is a part of the containing object—or not. In Figure 2-3, I show Airports “having” Aircraft. Aircraft are not part of Airports, but I can still say the Airport has them. This type of relationship is called aggregation.

In this diagram, I also show that an Aircraft is either a Jet or a Helicopter. I can see that Aircraft is an abstract class because its name is shown in italics. That means that an Airport will have either Jet or Helicopter but will treat them the same (as Aircraft). The open (unfilled) diamond on the right of the Airport class indicates the aggregation relationship.

The other type of has-a relationship is where the containment means the contained object is a part of the containing object. This type of relationship is also called composition.

Figure 2-4 shows that a Car has Tires as parts (that is, the Car is made up of Tires and other things). This type of has-a relationship, called composition, is depicted by the filled in diamond. This diagram also shows that a Car uses a GasStation. The uses relationship is depicted by a dashed line with an arrow. This is also called a dependency relationship.

Both composition and aggregation involve one object containing one or more objects. Composition, however, implies the contained object is a part of the containing object, whereas aggregation means the contained objects are more like a collection of things. We can consider composition to be an unshared association, with the contained object's lifetime being controlled by its containing object. The appropriate use of constructor and destructor methods is useful here to help facilitate object creation and destruction.

Notes in the UML. In Figure 2-5, there is a new symbol: the Note. The box containing the message “open diamonds mean aggregation” is a note. They are meant to look like pieces of paper with the right corner folded back. You often see them with a line connecting them to a particular class indicating they relate just to that class. Figure 2-5. The Class Diagram with a Note.

Class Diagrams show the relationships between classes. With composition and aggregation, however, the relationship is more specifically about objects of that type of class. For example, it is true Airports have Aircraft, but more specifically, specific airports have specific aircraft. The question may arise—“how many aircraft does an airport have?” This is called the cardinality of the relationship. I show this in Figures 2-6 and 2-7.

Figure 2-6 tells us that when I have an Airport, it has from 0 to any number (represented by an asterisk here, but sometimes by the letter “n”) of Aircraft. The “0..1” on the Airport side means that when I have an Aircraft, it can be contained by either 0 or 1 Airport (it may be in the air).

Figure 2-7 tells us that when I have a Car, it has either 4 or 5 tires (it may or may not have a spare). Tires are on exactly one car. I have heard some people assume no specification of cardinality assumes that there is one object. That is not correct. If cardinality is not specified there is no assumption made as to how many objects there are.

As before, the dashed line between Car and GasStation in Figure 2-7 shows that there is a dependency between the two. The UML uses a dashed arrow to indicate semantic relationships (meanings) between two model elements.