Determining Relationships - How to be a Successful Technical Architect for J2EE Applications

Determining Relationships

A relationship describes how different classes interact. You can determine relationships after you've identified individual classes. The UML literature documents several categories of object relationships. Most applications only need the four types described in the following paragraphs.

Dependency (uses) relationship documents that one class uses another class. At a code level, using another class means referencing the class in some way (e.g., declaring, instantiating, etc.). Because this relationship type is strikingly similar to the association relationship type, I usually ignore the difference between the two types as unnecessary complexity. The relationship in figure 6.1 is read as "Customer uses Account."

Figure 6.1: Dependency Relationship Illustration

Generalizes (extends) relationship documents that one class extends, or inherits the characteristics of, another class. Most medium to large applications have a handful of this type of relationship.

An extends relationship is denoted by a solid line with a hollow arrow. The relationship in figure 6.2 is read as "TrustCustomer extends Customer." The attributes of Customer will be available and usable in all children.

Figure 6.2: Extends Relationship Illustration

Realization (implements) relationship documents that a class implements an interface. An implements relationship is denoted by a dotted line with a hollow arrow. The relationship in figure 6.3 is read as "EmailDelivery implements ReportDeliveryType."

Figure 6.3: Implements Relationship Illustration

Aggregation (collects) relationship documents that a class collects multiple occurrences of a class. A collects relationship is denoted by a solid line with a diamond next to the class doing the collecting. The relationship in figure 6.4 reads "Customer collects Account."

Figure 6.4: Collects Relationship Illustration

Don't document formal relationships to value objects. VOs have so many relationships that if they are documented, the model becomes unreadable and unusable. After all, the purpose of creating the class diagram is to make the application easier for the team to understand and implement. VO relationships are easy for developers to figure out from the method signatures anyway.