Dependency in UML
Dependency is a directed relationship which is used to show that some UML element or a set of elements requires, needs or depends on other model elements for specification or implementation. Because of this, dependency is called a supplier - client relationship, where supplier provides something to the client, and thus the client is in some sense incomplete while semantically or structurally dependent on the supplier element(s). Modification of the supplier may impact the client elements.
Dependency is a relationship between named elements, which in UML includes a lot of different elements, e.g. classes, interfaces, components, artifacts, packages, etc. There are several kinds of dependencies shown on the diagram below.
Dependency relationship overview diagram - usage, abstraction, deployment.
Usage is a dependency in which one named element (client) requires another named element (supplier) for its full definition or implementation.
The abstraction relates two elements representing the same concept but at different levels of abstraction.
The deployment is a dependency which shows allocation (deployment) of an artifact to a deployment target. (It is not very clear why UML 2.4.1 defines deployment as a dependency but not as an association or just a directed relationship.)
Note, that UML 2.4.1 specification has some confusing clarification that "the presence of dependency relationships in a model does not have any runtime semantics implications, it is all given in terms of the model-elements that participate in the relationship, not in terms of their instances."
This clarification contradicts to the definition of usage dependency which is implementation dependency. An experienced software developer knows what happens at runtime when some dependency is missing, with application killed by LinkageError or ClassNotFoundException from the class loader. So dependency could in fact have some grave runtime semantics implications.
A dependency is generally shown as a dashed arrow pointing from the client (dependent) at the tail to the supplier (provider) at the arrowhead. The arrow may be labeled with an optional stereotype and an optional name. Because the direction of the arrow goes opposite to what we would normally expect, I usually stereotype it as client «depends on» supplier.
Class SearchController depends on (requires) SiteSearch interface.
For many years UML specifications provide contradictory example of the dependency shown below. The explanation for the Figure 7.38 of UML 2.4.1 specification states: "In the example below, the Car class has a dependency on the CarFactory class. In this case, the dependency is an instantiate dependency, where the Car class is an instance of the CarFactory class."
Wrong: Car class has a dependency on the CarFactory class.
Right: CarFactory class depends on the Car class.
This example in fact shows opposite to what UML specification states. CarFactory depends on the Car class. Car class could be defined without the knowledge of CarFactory class, but CarFactory requires Car for its definition because it produces Cars. It is also wrong to say that "... the Car class is an instance of the CarFactory class." The Car class is instantiated by the CarFactory class.
It is possible to have a set of elements for the client or supplier. In this case, one or more arrows with their tails on the clients are connected to the tails of one or more arrows with their heads on the suppliers. A small dot can be placed on the junction if desired. A note on the dependency should be attached at the junction point.
Dependency could be used on several kinds of UML diagrams:
Here's some examples of dependencies:
Web Shopping package uses (depends on) Payment package.
Interface SiteSearch is realized (implemented) by SearchService.
Note, that abstraction dependency has a convention to have more abstract element as supplier and more specific or implementation element as client but UML specification also allows to draw it the opposite way.
Component UserService realized by UserServlet and UserDAO.
Usage
A usage is a dependency relationship in which one element (client) requires another element (or set of elements) (supplier) for its full implementation or operation.
The usage dependency does not specify how the client uses the supplier other than the fact that the supplier is used by the definition or implementation of the client. For example, it could mean that some method(s) within a (client) class uses objects (e.g. parameters) of the another (supplier) class.
A usage dependency is shown as a dependency with a «use» keyword attached to it.
Class SearchController uses SearchEngine class.
Create
Create is a usage dependency denoting that the client classifier creates instances of the supplier classifier. It is denoted with the standard stereotype «create».
Class DataSource creates Connection.
Create could also specify that the designated feature creates an instance of the classifier to which the feature is attached. This dependency may be promoted to the classifier containing the feature.
Create may relate an instance value to a constructor for a class, describing the single value returned by the constructor operation. The operation is the client, the created instance the supplier. The instance value may reference parameters declared by the operation.
Account constructor creates new instances of Account
Instantiate is another usage dependency among classifiers indicating that operations on the client create instances of the supplier. It is denoted with the standard stereotype «instantiate».
It is not very clear why UML 2.4 standard has both «create» and «instantiate».
Call
Call is a usage dependency that specifies that the source operation invokes the target operation. This dependency may connect a source operation to any target operation that is within the scope including, but not limited to, operations of the enclosing classifier and operations of other visible classifiers.
Call is denoted with the standard stereotype «call» whose source is an operation and whose target is also an operation.
This relationship may also be applied to the class containing an operation, with the meaning that there exists an operation in the class to which the dependency applies.
Send
Send is a usage dependency whose source is an operation and whose target is a signal, specifying that the source sends the target signal.
Send is denoted with the standard stereotype «send».
Required Interface
Required interface specifies services that a classifier needs in order to perform its function and fulfill its own obligations to its clients. It is specified by a usage dependency between the classifier and the corresponding interface.
The usage dependency from a classifier to an interface is shown by representing the interface by a half-circle or socket, labeled with the name of the interface, attached by a solid line to the classifier that requires this interface.
Interface SiteSearch is used (required) by SearchController.
If interface is represented using the rectangle notation, interface usage dependency is denoted with dependency arrow. The classifier at the tail of the arrow uses (requires) the interface at the head of the arrow.
Interface SiteSearch is used (required) by SearchController.
