Dependency relationships

In UML, a dependency relationship is a relationship in which one element, the client, uses or depends on another element, the supplier. You can use dependency relationships in class diagrams, component diagrams, deployment diagrams, and use-case diagrams to indicate that a change to the supplier might require a change to the client.

You can also use a dependency relationship to represent precedence, where one model element must precede another.

Typically, dependency relationships do not have names.

As the following figure illustrates, a dependency is displayed in the diagram editor as a dashed line with an open arrow that points from the client to the supplier.

Two classes are connected by a dashed line with an open arrow

Types of dependency relationships

Because a dependency relationship can represent several different types of relationships, keywords or stereotypes show the precise nature of the dependency.

Type of dependency Keyword or Stereotype Description
Abstraction «abstraction», «derive», «refine», or «trace» Relates two model elements, or sets of model elements, that represent the same concept at different levels of abstraction, or from different viewpoints
Binding «bind» Connects template arguments to template parameters to create model elements from templates
Realization «realize» Indicates that the client model element is an implementation of the supplier model element, and the supplier model element is the specification
Substitution «substitute» Indicates that the client model element takes the place of the supplier; the client model element must conform to the contract or interface that the supplier model element establishes
Usage «use», «call», «create», «instantiate», or «send» Indicates that one model element requires another model element for its full implementation or operation
Note: Several relationships, such as extend relationships and include relationships, use a connector that is similar to that of a dependency relationship, but are not considered dependency relationships.

Using dependency relationships

You can add dependency relationships to models to accomplish the following goals:

  • Connect two packages to indicate that at least one element in the client package is dependent on an element in the supplier package. The dependency relationship does not indicate that all elements in the client package are dependent.
  • Connect two classes to indicate that the connection between them is at a higher level of abstraction than an association relationship. The dependency relationship indicates that the client class performs one of the following functions:
    • Temporarily uses a supplier class that has global scope
    • Temporarily uses a supplier class as a parameter for one of its operations
    • Temporarily uses a supplier class as a local variable for one of its operations
    • Sends a message to a supplier class
  • Connect components to interfaces or other components to indicate that they use one or more of the operations that the interface specifies or that they depend on the other component during compilation.

Example

In an e-commerce application, a Cart class depends on a Product class because the Cart class uses the Product class as a parameter for an add operation. In a class diagram, a dependency relationship points from the Cart class to the Product class. As the following figure illustrates, the Cart class is, therefore, the client, and the Product class is the supplier.

As described in the prior paragraph, two classes are connected by a dependency relationship.

The above relationship indicates that a change to the Product class might require a change to the Cart class.


Feedback