Class Relationships

With the UML, it is the relationships between classes that provide structure to what you are creating. This article explains how to use the UML to illustrate various kinds of class relationships. It is taken from chapter two of Fast Track UML 2.0 written by Kendall Scott (Apress, 2004; ISBN: 1590593200).

Class Relationships

Classes, by themselves, aren’t particularly useful. It’s the relationships among classes that provide the foundation for the structure of a new system. The following sections explore how you use the UML to illustrate various kinds of class relationships.

Associations

An association is a simple structural connection between classes.

You might think of an association as representing a “peer” relationship. (You look at other kinds of relationships that involve “parents” and “children,” and “parts” and “the whole,” later in the chapter.) Instances of classes involved in an association will most likely be communicating with each other at program execution time, but all we’re concerned with here is the fact that these instances have some attachment to each other. (By the way, an instance of an association— in other words, a structural connection between objects—is called a link.)

There are two basic kinds of associations: binary associations and n-ary associations.

A binary association, which exists between two classes, appears as a straight line that connects them. Figure 2-1 shows some example associations between classes.


Figure 2-1Binary associations

An n-ary association, which exists among three or more classes, appears as a set of lines connected to a central diamond, as shown in Figure 2-2.


Figure 2-2N-ary association

The n-ary association is considered something of an advanced modeling construct; you’re much more likely to see—and use—plain binary associations in your models.

An association is assumed to be bidirectional, which means that you can navigate from either class to the other one. However, you can specify that navigation can only occur from one class to another by using a feathered arrow, as shown in Figure 2-3.  


Figure 2-3One-way navigation between classes

Establishing the navigation arrow on this association means that a Customer has access to his or her Password, but no one can in turn use a Password to identify a Customer.

You can add several kinds of details, or adornments, to an association. These adornments include the following:

  • An association can have a name that indicates the nature of the relationship. If a name is present, there can also be a triangle that points in the direction in which you should read the name. See Figure 2-4.


Figure 2-4.  Named association

  • An association can contain roles, which are the faces that classes present to other classes. As shown in Figure 2-5, roles generally appear in pairs.


Figure 2-5Association roles

You read an association with role names from a class to the role immediately next to it to the class on the other side of the association. In other words, you would read this association in one direction as “Reviewer writes Review” and in the other direction as “Review is written by Reviewer.”

A class can play the same role or different roles within different associations.

  • An association can show multiplicity. See the section “More About Attributes” in Chapter 1 for more on this topic. Figure 2-6 shows two examples of association multiplicity.


Figure 2-6Association multiplcity

When an association has multiplicities attached to it, you read from a class to the value next to the other class, across the association. So, in Figure 2-6, one Account can be associated with many Billing Info objects, but each Billing Info object is associated with only one Account.

{mospagebreak title=Aggregation}

An aggregation is a special kind of association—a “whole/part” relationship within which one or more classes are parts of a larger whole. A class can be aggregated to one or more other classes.

Using aggregation is an excellent way to establish a “pecking order” of complexity, with more complex classes aggregating less complex ones. For a system of any size, doing this can only help viewers of your models more easily understand the concepts that are important to them while enabling them to ignore concepts expressed at lower levels of detail.

An aggregation appears as a line with an open diamond at one end. The class next to the diamond is the whole class; the class at the other end of the line is the part class. See Figure 2-7.


Figure 2-7Aggregation notation

If a given class aggregates more than one class, you can show each aggregation using a separate line, or you can consolidate the lines. Figure 2-8 shows both variations.


Figure 2-8.  Aggregating multiple classes

A class can also aggregate itself, as shown in Figure 2-9.


Figure 2-9Self-aggregation

This self-aggregation construct is useful in situations such as those that involve “rollups” for reporting purposes. (A rollup is a consolidation of information expressed at one or more particular levels of detail into a higher level of detail.)


Figure 2-10.  Aggregations

NOTE Multiplicities now appear on each aggregation relationship. If an aggregation doesn’t show multiplicity values, the default is many (*) parts and one whole.

Figure 2-10 shows that an instance of the Order class aggregates one each of instances of the ShippingInfo and BillingInfo classes and one or more instances of the Book class. An important property of aggregation is that the aggregated classes are still basically independent of the aggregating class. In other words, when a particular Order goes away (because it’s been archived, for example), the ShippingInfo and BillingInfo instances that were aggregated to that Order are still present in the system. (The Book instance, of course, is gone.)

Composition is a “strong” form of aggregation. There are two differences between composition and regular aggregation, as follows:

  • Within a composition relationship, the whole and the parts have coincident lifetimes. This means that if a particular instance of the whole is destroyed, so are the instances of the parts.

  • A class can only belong to one composition relationship at a time as a part.

Figure 2-11 shows an example of a composition relationship.


Figure 2-11Composition

This relationship specifies that a GLAccount in a composition relationship with a particular GeneralLedger is destroyed when that GeneralLedger is destroyed.

Composition versus aggregation is generally an issue that comes up during activities such as physical database design. It’s not generally a distinction that you need to worry about at, say, the analysis level.

{mospagebreak title=Generalization}

Generalization refers to a relationship between a general class (the superclass or parent) and a more specific version of that class (the subclass or child). You can think of the subclass as being a “kind of” the superclass.

A generalization appears as a line with an open triangle at one end. The class next to the triangle is the parent/superclass; the class at the other end of the line is the child/subclass. See Figure 2-12.


Figure 2-12Generalization notation

If a given class has more than one child/subclass, you can show each generalization using a separate line, or you can consolidate the lines, as with aggregation. Figure 2-13 shows both variations.


Figure 2-13Generalizing multiple classes

Figure 2-14 shows a sample generalization.


Figure 2-14Generalization

Note the change between Figure 2-14 and Figure 1-3 (see Chapter 1): The operations that used to belong to the Review class have been “pushed down” into Customer Review. This is because these methods don’t apply to the new Editorial Review class. This is a good example of how the subclass, Customer Review, specializes the more general superclass, Review.

We’ve only looked at “single” inheritance to this point, but the UML also offers a way to model multiple inheritance—in other words, generalizations within which a class is a child of two or more parents. The basic notation is the same; the diagrams just get a little harder to read. Multiple inheritance is something of a tricky subject that’s outside the scope of this book, except as referenced in the following paragraphs. (It’s also something that some implementation platforms, such as .NET, and languages, such as C#, don’t support.)

You can use a generalization set to define partitions for the subclasses of a particular class (the superclass). The superclass acts as the powertype for the generalization set, which means that the instances of that superclass are also subclasses of another class.

Within Figure 2-15, PaymentType serves as a powertype on Payment.


Figure 2-15Powertype

In other words, the instances of PaymentType include those named CreditCard, CorporateAccount, and GiftCertificate—each of which is, in turn, a subclass of Payment. Each of these classes forms its own generalization set; this provides the modeler with extra flexibility in defining behavior associated with each subclass.

The UML offers the following four constraints (see the section “More About Operations” in Chapter 1), which you can use in conjunction with generalization sets:

  • The {incomplete} constraint means that not all children have been speci fied for a given generalization set and that more can be specified.

  • The {complete} constraint means that all children have been specified for a given generalization set and that no more can be specified.

  • The {disjoint} constraint means that given multiple inheritance, no object can be an instance of more than one child within the generalization set.

  • The {overlapping} constraint means that given multiple inheritance, an object can be an instance of more than one child within the generaliza tion set.

{mospagebreak title=Dependencies}

A dependency is a “using” relationship within which a change in one thing (such as a class) may affect another thing (for instance, another class). The dependent element is called the client or source; the independent element is called the supplier or target.

A dependency involving two classes appears as a dashed line with a feathered arrow pointing at the supplier. Figure 2-16 shows an example of a dependency.


Figure 2-16Dependency

If the definition of the Book class changes, the way that the checkAvailability function works may have to change as well.

The UML defines a number of stereotypes that apply to dependencies. These are explored in the following subsections.

Usage Dependencies

A usage dependency is one in which the client requires the presence of the supplier for its correct functioning or implementation.

You model a generic usage dependency using the «use» stereotype. Figure 2-17 shows that instances of the Order class require instances of the OrderItem class in order to function properly.


Figure 2-17Usage dependency

The UML defines the following five types of usage dependencies:

  • A call dependency («call») signifies that the source operation invokes the target operation.
  • A create dependency («create») signifies that the source class creates one or more instances of the target class.

Within Figure 2-18, an instance of the Order class creates one more instances of the JournalEntry class.


Figure 2-18Create dependency

  • An instantiation dependency («instantiate») signifies that one or more methods belonging to instances of the source class create instances of the target class.

Within Figure 2-19, a method belonging to an instance of the HTMLPageHandler class creates an instance of the LoginPage class.


                  Figure 2-19. Instantiation

  • A responsibility dependency («responsibility») signifies that the client has some kind of obligation to the supplier.

  • A send dependency («send») signifies that instances of the source class send signals to instances of the target class. (Signals are discussed in Chapter 6.)

Abstraction Dependencies

An abstraction dependency is one in which the client is at one level of abstraction and the supplier is at a different level.

You model a generic usage dependency using the «abstraction» stereotype. Figure 2-20 shows that the SShoppingCart class is more concrete than the ShoppingCart class. (A session bean is a type of EnterpriseJava Bean [EJB]. See Mastering Enterprise JavaBeans1 for more information about EJBs.)


Figure 2-20Abstraction dependency 

The UML defines the following five types of abstraction dependencies:

  • A derivation dependency («derive») signifies that the client can be computed or inferred from the supplier.

Within Figure 2-21, you can derive the association between Account and Order by navigating from Account to BillingInfo to Order.


Figure 2-21Derivation dependency

  • A realization dependency («realize») signifies that the supplier serves as the implementation of the client. (Note that in this context, “implementation” implies a more elaborate form of the client, not necessarily a physical implementation as, say, program code.)

Within Figure 2-22, the PhysicalOrder class “implements” the Order class. (See the section “Other Stereotypes on Classes” in Chapter 1 for a discus sion of the «implementationClass» stereotype.)


Figure 2-22Realization dependency

Note the differences between this type of dependency and the type of realization discussed in Chapter 1 (see the section “Interfaces, Ports, and Connectors” in Chapter 1).

  • A refinement dependency («refine») signifies that the supplier is at a lower level of abstraction than the client.

Within Figure 2-23, the Order class on the right is an active class that represents a refinement, at the design level, of the Order class on the left.


Figure 2-23Refinement dependency

  • A trace dependency («trace») signifies a conceptual connection among elements contained within different models.

Figure 2-24 shows that you can trace the LoginManager class, which probably belongs to the analysis-level model, to the SessionManager class, which probably belongs to a design-level model.


Figure 2-24Trace dependency

  • A manifestation dependency («manifest») signifies that a target artifact represents the concrete physical realization of one or more source classes. (Manifestations are discussed in Chapter 9.)
Permission and Substitution Dependencies

A permission dependency («permit») signifies that the supplier grants the client permission to access some or all of its constituent elements.

Within Figure 2-25, the Customer class grants the RecommendationEngine class access to its private attributes emailAddress and name.


Figure 2-25Permission dependency

A substitution dependency («substitute») signifies that the client will comply with the contract specified by the supplier at program execution time.

Within Figure 2-26, a more specific Login Page adheres to the basic framework within which a generic HTML Page works.


Figure 2-26Substitution dependency

Figure 2-26. Substitution dependency

{mospagebreak title=Association Classes}

An association class is a cross between an association (see the section “Associations,” earlier in this chapter) and a class (see Chapter 1).

You use an association class to model an association that has interesting characteristics of its own outside of the classes it connects. This construct also comes in handy when you have a many-to-many relationship that you’d like to break into a set of one-to-many relationships (as discussed in the section “Discovering Classes” in Chapter 1).

An association class itself appears as a regular class box. You indicate that it’s an association class by connecting it to the association between the other two classes using a dashed line.

Figure 2-27 shows an example of an association class that was introduced in Chapter 1.


Figure 2-27Association class

There would normally be a many-to-many relationship between Author and Book, because an Author may have written more than one Book and a Book may have more than one Author. The presence of the BookAndAuthor association class allows the pairing of one Author with one Book; the role attribute provides the option of stating whether the Author was the primary author, supporting author, or editor, for example.

Refer to the «enumeration» stereotype in the section “Other Stereotypes on Classes” in Chapter 1 for a discussion of an alternate way to model the role attribute. One of the most useful things about the UML is that it often offers various options for modeling a particular idea. Of course, this can also be a curse, but in general, it’s the opinion of this author that having options is a good thing.

Looking Ahead

In the next chapter, you look at the UML diagrams that show combinations of classes and the relationships among them.


1 Ed Roman, Mastering Enterprise JavaBeans (Second Edition) (New York, NY: John Wiley & Sons, 2001).

[gp-comments width="770" linklove="off" ]
antalya escort bayan antalya escort bayan