UML Class Diagrams ³

A UML class diagram represents each class or interface using a box containing three sections and relationship lines connecting these boxes. Within a box, the top section contains the name of the class or interface , the middle section describes its attributes , and the bottom section describes its behaviors . Figure 9-2 shows a class diagram box for a car class with two attributes and two behaviors, and an interface box for simpleNavigation with no attributes and one behavior.

Figure 9-2. Class diagram representation for class car and interface simpleNavigation

For class diagrams describing a large number of classes and interfaces , it is commonplace for the box to omit the attributes and behaviors sections.

Entries are typically shown using the camel case notation convention,⁴ where multiple words of an entry have no intervening space and appear in lowercase with the first letter of each new word appearing in uppercase. Indeed, the convention for text appearing in class diagram boxes is to use lower camel case, where the first letter of the first word also appears in lowercase. Abstract entries are shown using the italic font.

The name of the class or interface appearing in the upper box is centered. When it describes an interface, the identifier <<interface>> appears above the interface name.

Attributes are left-justified, showing the name of the attribute and its type, separated by a colon . The type may be followed by an equal sign and a value if the field is to have a default starting value.

Behaviors also are left-justified. The signatures for the behaviors described in the bottom section are enclosed in parenthesis and show the parameter name and parameter type separated by a colon. This is followed by the type of return value,⁵ separated from the right parenthesis by a colon, with void indicating the absence of a return value.

Each member described in the bottom two sections is preceded by a visibility level setting , which may be any of the following:

The relationships between the boxes are shown using lines connecting them, and fall into three categories:

• Class-level relationships

• Instance-level relationships

• General relationships

Class-Level Relationships

There are two class -level relationships to depict how different classes or interfaces relate to one another. One is known as a generalization relationship , which uses a solid line with an unfilled triangular arrowhead on one end to describe the “is a” relationship existing between a child class inheriting from a parent class. The arrowhead of a generalization relationship line points to the parent class. The other is known as a realization relationship , which uses a dashed line with an unfilled triangular arrowhead on one end to describe the “implements a” relationship existing between one entity implementing the behavior defined by the other entity. The realization relationship usually occurs in the form of a class implementing the behavior of an interface . The arrowhead of a realization relationship line points to the entity contributing the definition of the behavior .

Instance-Level Relationships

Three instance-level relationships , known as links, depict how different objects relate to one another, each subsequent term representing a specialization of the one preceding it:

• Association

• Aggregation

• Composition

The association link depicts a “relates to” connection between two entities. The following are variations of an association link:

• Unidirectional

• Bidirectional

• Reflexive

A unidirectional association implies that only one entity connected on each end of the relationship line knows about the other entity. For instance, a class vehicle and class vehicleRegistrationAgency are connected via a unidirectional association because vehicleRegistrationAgency knows about vehicle but vehicle does not know about vehicleRegistrationAgency. This is represented by a simple solid line connecting the two entities with an arrowhead pointing to the entity that knows nothing about the other.

A bidirectional association implies that the entity connected on each end of the relationship line knows about the other entity. For instance, class patient and class physician are connected via a bidirectional association because each one knows about the other: a patient is treated by a physician, and a physician treats a patient. The patient and physician classes may or may not have relationships with other types of classes, such as patient having a relationship with the diet class and physician having a relationship with the professional organization class, but these other classes can exist independently of the patient and physician classes. Meanwhile, the relationship between patient and physician is symbiotic; neither would exist without the other. This is represented by a simple solid line connecting the two entities.

A reflexive association illustrates a class with a relationship to itself. An example of this is an employee class having a relationship to a manager, and manager also is represented by the employee class. This type of relationship is represented by a simple solid line starting out from one of the sides of the class box and then making a 270-degree turn to return and connect back to the top or bottom of the class box; effectively, both ends of the line connect to the same class box.

The aggregation link depicts a “has a” connection between two entities. This usually means that an attribute of one class is a pointer to the instance of another class; that is, the containing object aggregates pointers to one or more other objects. An aggregation link represents a connection stronger than other variations of an association link. This is represented by a solid line with an unfilled diamond arrowhead on one end. The arrowhead of an aggregation relationship line points to the entity that does the aggregating. The containing object necessarily knows about the contained object, but the reverse is not necessarily true.

The composition link depicts an “owns a” connection between two entities. This also usually means that an attribute of one class is a pointer to the instance of another class; that is, the containing object is composed of pointers to one or more other objects. A composition link represents a connection stronger yet than an aggregation link. This is represented by a solid line with a filled diamond arrowhead on one end. The arrowhead of a composition relationship line points to the entity that does the composing. Again, the containing object necessarily knows about the contained object, but the reverse is not necessarily true.

The difference between aggregation and composition lies in the lifespan of the contained objects. Composition implies a dependent relationship by the contained objects to the containing object, whereas aggregation implies an independent relationship between the contained objects to the containing object. With composition, any contained objects are destroyed when the containing object is destroyed. With aggregation, contained objects are left alive when the containing object is destroyed. A good example for this is the following:

• A car instance “owns a” carburetor instance. When the car is destroyed, so is the carburetor. This is an example of composition.

• A pond instance “has a” duck instance. When the pond is drained, the duck is not destroyed, but merely flies away to find another pond. This is an example of aggregation.

The following types of lines are used to depict these relationships:

An instance level relationship also indicates the cardinality (a.k.a. multiplicity ) between the connected boxes, and denotes the number of entities at each end that can connect through the relationship . These may be one of the following:

0..1	Zero or one
1	Exactly one
0..*	Zero or more
1..*	One or more

For example, a car instance can own one engine instance, so the composition relationship between the two instances would show an “exactly one” cardinality at both the car and engine ends of the relationship line. Also, a car instance may or may not own a super charger instance, but if it does, it would have only one, so the composition relationship between the two instances would show an “exactly one” cardinality at the car end of the relationship line and a “zero or one” cardinality at the super charger end of the relationship line. Meanwhile, a car parking lot may be empty, partially filled, or full of car instances, so the aggregation relationship between the two instances would show an “exactly one” cardinality at the car parking lot end of the relationship line and a “zero or more” cardinality at the car end of the relationship line.

It is also common to use explicit numbers, when they apply, in place of the zeros, ones, and asterisks appearing in the entries above, as in the following examples:

0..4	Zero to four
5	Exactly five
5..9	Five to nine
6..*	Six or more

General Relationships

There is one general relationship, known as dependency. This relationship establishes a connection between an entity that depends on another entity, known as the supplier, for its implementation. There are several types of dependencies that can be described by a general relationship , such as uses, calls, instantiates, etc. It is represented by a dashed line with an open arrowhead on one end. For each general relationship, the description of the corresponding dependency, enclosed by guillemet marks (<< and >>), is specified next to the connecting line. The arrowhead of a general relationship line points to the supplier.

Examples of UML Class Diagrams

So, let’s use UML to model our previous examples, as shown in Figure 9-3, starting with our famous fox and dog entities, as enhanced in Table 3-3 in Chapter 3.

Figure 9-3. UML class diagram modeling fox and dog classes

This UML class diagram in Figure 9-3 depicts the following:

• A fox class with two private instance attributes for alacrity (type string) and color (type string), and three public instance behaviors for jump (with signature otherInstance of type object , and returning nothing), setAlacrity (with signature alacrity of type string, and returning nothing), and setColor (with signature color of type string, and returning nothing).

• A dog class with two private instance attributes for alacrity (type string) and registrationNumber (type num), one static private attribute for lastUsedRegistrationNumber (type num), a static private behavior getNextRegistrationNumber (with empty signature and returning a value of type num), and two public instance behaviors for setAlacrity (with signature alacrity of type string, and returning nothing) and setRegistrationNumber (with empty signature and returning nothing).

• A general relationship, called dependency, between the two classes indicating that the fox uses the dog. In this case, fox is dependent upon dog; there must be an instance of a dog object over which the fox can jump, but dog is not dependent on fox.

The most recent exercise affords many other types of relationships to be included in its corresponding UML class diagram, as shown in Figure 9-4. The numbered circles are references to the numbered items of explanation that follow the UML class diagram.

Figure 9-4. UML class diagram describing exercise program ZOOT105D

1. The report class is a static class – it is marked as abstract – so its name is shown using the italic font.

2. The vehicle class is an abstract class, so its name is shown using the italic font.

3. The car class is a concrete class, so its name is shown using the regular font.

4. The truck class is a concrete class, so its name is shown using the regular font.

5. The simple_navigation interface provides definitions for abstract methods which must be implemented in any class using the interface, so its name is shown using the italic font. Also, interface names in class diagram boxes are preceded with the <<interface>> banner.

6. The navigator class is a concrete class, so its name is shown using the regular font.

7. The gps class is a concrete class, so its name is shown using the regular font.

8. The dead_reckoning class is a concrete class, so its name is shown using the regular font.

9. The classes navigator, gps, and dead_reckoning all implement the simple_navigation interface , so the relationship between their boxes and the interface box is shown using the “implements a” relationship, which is a dashed line with an unfilled triangular arrowhead pointing to the interface each of them implements. We could have shown this relationship using three separate relationship lines, one between each of the three class boxes and the interface box, but here they are shown consolidated, with the relationship lines from each class box merging into the single line pointing to the interface box. Also, the UML standard does not require all relationship lines to be oriented vertically and horizontally as shown in this UML class diagram, but can be oriented diagonally as well.

10. The classes car and truck are both child classes inheriting from the vehicle class, so the relationship between their boxes and their parent class is shown using the “is a” relationship, which is a solid line with an unfilled triangular arrowhead pointing to the parent class from which they inherit.

11. The report class owns instances of vehicle classes, so the relationship between their boxes is shown using the “owns a” relationship, which is a solid line with a filled diamond arrowhead pointing to the owning class.

12. The vehicle class owns instances of classes implementing the simple_navigation interface , so the relationship between their boxes is shown using the “owns a” relationship , which is a solid line with a filled diamond arrowhead pointing to the owning class.

13. For the “owns a” relationship between the report class and vehicle class, the cardinality for the report class is set to 1, indicating that there is exactly one report instance involved in this relationship.

14. For the “owns a” relationship between the report class and vehicle class, the cardinality for the vehicle class is set to 0..*, indicating that there are zero or more vehicle instances involved in this relationship.

15. For the “owns a” relationship between the vehicle class and simple_navigation interface , the cardinality for the vehicle class is set to 1, indicating that there is exactly one vehicle instance involved in this relationship.

16. For the “owns a” relationship between the vehicle class and simple_navigation interface , the cardinality for the simple_navigation interface is set to 1, indicating that there is exactly one simple_navigation instance involved in this relationship .

Summary

In this chapter, we learned about the effort in 1996 between James Rumbaugh, Grady Booch, and Ivar Jacobson to produce a general purpose modeling language to support software engineering, which came to be known as the Unified Modeling Language. We learned about the class diagram, where a class is represented as a box consisting of three sections to denote class name, its attributes, and its behaviors; where names typically follow the lower camel case notation convention; attributes and behaviors are marked with visibility indicators; and the italic font is used to denote abstraction. We also learned that relationship lines connect class boxes on a class diagram and fall into three categories:

• Class-level relationships

• Instance-level relationships

• General relationships

We learned that class-level relationships use the generalization (“is a”) relationship line to denote inheritance and the realization relationship line (“implements a”) to denote implementation of an interface. We also learned that instance-level relationships may be accompanied by a cardinality indication to denote the number of entities at each end that can connect through the relationship, where these relationships use the association (“relates to”) relationship line to denote a unidirectional, bidirectional, or reflexive relationship, use the aggregation (“has a”) relationship line to denote reference to an entity also known by other entities, and use the composition (“owns a”) relationship line to denote reference to an entity known only to the owner. In addition, we learned that general relationships use the dependency (“depends on”) relationship line to point from the dependent entity to the independent one, accompanied by a word enclosed within guillemet marks to indicate the type of dependency.