Computer programming has long been considered a related field to that of lin-guistics. After all, programming languages are simply a combination of grammar and vocabulary created for a specific purpose. In a related sense, we can think of classes as nouns in our modeling language. They represent things; entities that exist within the system. In order to form proper and complete sentences, though, we need verbs to describe what it is that our nouns do. In this case, our verbs are associations. Associations express the relationships between classes, and thus describe the actions that define their interactions. In the same way that objects are instances of classes, associations too have instances, called links in UML. Asso-ciations describe the relationships between classes. Links describe the relation-ships between objects. As we described in the previous section, associations are depicted by a line connecting two classes. In Fig.3.5, an association called Consultsdefines the relationship between classes A and B.
3.3.1 Aggregation
Aggregation is a relationship in which one class completely contains another class. Real world examples could include a hotel class that contains a hotel_room or a soccer_team class which contains a soccer_player.
The UML diagram below denotes aggregation between a Country class and a Stateclass.
Figure3.6the Country is the owner class. The diamond ended line connecting the two classes denotes the aggregation relationship, with the diamond end always pointing to the owner class. The State class in this example is called the owned, part, or component class. In most cases, the owner is responsible for construction and destruction of the owned class.
Class Class
Consults Fig. 3.5 Association
between classes
Country
State Fig. 3.6 Example of
aggregation
3.3.2 Generalization
Generalizationis another type of relationship that can be described using UML.
Generalization describes inheritance, which we previously described as a rela-tionship in which a class is derived from a more generalized version of itself. The figure below denotes a superclass, Vehicle, that has two child classes, Pas-senger and Utility. The relationship is denoted by a solid line with an arrowhead that points to the superclass (Fig.3.7).
Earlier in the book, we explained that an inheritance hierarchy was a path of related classes. The starting point on this path has the greatest amount of gener-alization, and the derived classes become more specific as they move along it. In UML diagrams of generalization, the arrow will always point toward the more general end of the hierarchy.
3.3.3 Dependency
A dependency relationship occurs when one entity depends upon or requires the resources of another. Real life examples of this include a bank account, which requires a bank, or a flashlight, which is dependent upon a battery to work. In UML, dependency is indicated by a dashed line, with an arrow at one or both ends. The arrow originates from the independent entity, and points toward the entity that is dependent. In other words, the entity at the tail end of the arrow is dependent upon the entity that is being pointed to. An entity indicator with an arrow at both ends depicts a relationship in which both objects are dependent upon each other, signifying co-dependency. In a dependency relationship, changes to the independent entity will have an effect on the dependent entity. Figure3.8illustrates such a relationship.
3.3.4 Uses and Extends
Usesand Extends are two types of relationships utilized in use case diagrams. The first, uses, specifies that the semantics of the source element are dependent upon the semantics of the public portion of the target element. The second, extends,
Vehicle
Passenger Utility
cargo Fig. 3.7 Generalization
3.3 Associations 45
dictates that the target use case adopts the behavior of the source. Both relation-ships involve selecting common behavior from several use cases for use in a single use case, which is then used or extended by other use cases. The extends rela-tionship is used when the intent is to adopt a certain set of behaviors and then build on those behaviors to create an entity with increased capability. The uses rela-tionship, on the other hand, allows for the straight forward adoption of some common behavior, providing for reuse so that the behavior need not be copied again and again.
3.3.5 Multiplicity
Relationships within the object-oriented paradigm come in a few different flavors, defined by the number of possible associations that a class can have. This is known as multiplicity, which defines the number of instances of an individual class that may be associated with a single instance of another class. For a real world example, imagine the fingers on a human hand. One hand may contain up to five fingers. The hand has what is called a one-to-many relationship with its fingers.
Each finger, however, may be associated with only one hand, known as a one-to-onerelationship. Multiplicity in a UML diagram is denoted either by a single digit, signifying the exact number of relationships that an entity will have, or using the form ‘‘x..y’’. In the second instance, ‘‘x’’ and ‘‘y’’ are numbers, or symbols rep-resenting numbers, and the entity will have a number of relationships that falls somewhere within the range ‘‘x’’ to ‘‘y’’. Table3.1lists the most common types of multiplicities, and the Fig.3.9illustrates a UML diagram indicating multiplicity.
Fig. 3.8 Dependency
Table 3.1 Types and definitions of various multiplicities
Multiplicity Meaning 0..1 0 or 1 instance
0..* 0 to infinite instance (There is no limit of the number of instances)
1 Exactly 1 instance
1..* At least 1 instance (There must be a minimum of 1 instance)