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.
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.
The UML defines the following five types of usage dependencies:
Within Figure 2-18, an instance of the Order class creates one more instances of the JournalEntry 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
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.)
The UML defines the following five types of abstraction dependencies:
Within Figure 2-21, you can derive the association between Account and Order by navigating from Account to BillingInfo to Order.
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.)
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).
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-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.
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.
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
blog comments powered by Disqus