Dependencies - Practices

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-16.  Dependency

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.

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-17.  Usage 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-18.  Create 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.)

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-20.  Abstraction 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-21.  Derivation 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-22.  Realization 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-23.  Refinement 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-24.  Trace 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.)

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-25.  Permission 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-26.  Substitution dependency

Figure 2-26. Substitution dependency