- Introduction
- 16.1 Applying UML: Common Class Diagram Notation
- 16.2 Definition: Design Class Diagram
- 16.3 Definition: Classifier
- 16.4 Ways to Show UML Attributes: Attribute Text and Association Lines
- 16.5 Note Symbols: Notes, Comments, Constraints, and Method Bodies
- 16.6 Operations and Methods
- 16.7 Keywords
- 16.8 Stereotypes, Profiles, and Tags
- 16.9 UML Properties and Property Strings
- 16.10 Generalization, Abstract Classes, Abstract Operations
- 16.11 Dependency
- 16.12 Interfaces
- 16.13 Composition Over Aggregation
- 16.14 Constraints
- 16.15 Qualified Association
- 16.16 Association Class
- 16.17 Singleton Classes
- 16.18 Template Classes and Interfaces
- 16.19 User-Defined Compartments
- 16.20 Active Class
- 16.21 Whats the Relationship Between Interaction and Class Diagrams?
This chapter is from the book
This chapter is from the book
This chapter is from the book
16.11 Dependency
Dependency lines may be used on any diagram, but are especially common on class and package diagrams. The UML includes a general dependency relationship that indicates that a client element (of any kind, including classes, packages, use cases, and so on) has knowledge of another supplier element and that a change in the supplier could affect the client. That’s a broad relationship!
Dependency is illustrated with a dashed arrow line from the client to supplier.
Dependency can be viewed as another version of coupling, a traditional term in software development when an element is coupled to or depends on another.
There are many kinds of dependency; here are some common types in terms of objects and class diagrams:
- having an attribute of the supplier type
- sending a message to a supplier; the visibility to the supplier could be:
- an attribute, a parameter variable, a local variable, a global variable, or class visibility (invoking static or class methods)
- receiving a parameter of the supplier type
- the supplier is a superclass or interface
All of these could be shown with a dependency line in the UML, but some of these types already have special lines that suggest the dependency. For example, there’s a special UML line to show the superclass, one to show implementation of an interface, and one for attributes (the attribute-as-association line).
So, for those cases, it is not useful to use the dependency line. For example, in Figure 16.6 a Sale has some kind of dependency on SalesLineItems by virtue of the association line. Since there’s already an association line between these two elements, adding a second dashed arrow dependency line is redundant.
Therefore, when to show a dependency?
Guideline: In class diagrams use the dependency line to depict global, parameter variable, local variable, and static-method (when a call is made to a static method of another class) dependency between objects.
For example, the following Java code shows an updatePriceFor method in the Sale class:
public class Sale
{
public void updatePriceFor( ProductDescription description )
{
Money basePrice = description.getPrice();
//…
}
// …
}
The updatePriceFor method receives a ProductDescription parameter object and then sends it a getPrice message. Therefore, the Sale object has parameter visibility to the ProductDescription, and message-sending coupling, and thus a dependency on the ProductDescription. If the latter class changed, the Sale class could be affected. This dependency can be shown in a class diagram (Figure 16.9).
)
Figure 16.9 Showing dependency.
Another example: The following Java code shows a doX method in the Foo class:
public class Foo
{
public void doX()
{
System.runFinalization();
//…
}
// …
}
The doX method invokes a static method on the System class. Therefore, the Foo object has a static-method dependency on the System class. This dependency can be shown in a class diagram (Figure 16.10).
){kind=small}
Figure 16.10 Showing dependency.
Dependency Labels
To show the type of dependency, or to help a tool with code generation, the dependency line can be labeled with keywords or stereotypes.[6] See Figure 16.11.
){kind=small}
Figure 16.11 Optional dependency labels in the UML.