Dependency   A dependency is a type of relationship that signifies that one element, or group of elements, acting as the client depends on another element or group of elements that act as a supplier. It is a weak relationship that denotes that if the supplier is changed the client may be affected. It is a unidirectional relationship.

Explanation

A dependency is a catch-all relationship that signifies that a model element is dependent or relies on another element or group of elements in some way. The arrowhead points towards the element that is the supplier (the one being relied on). Used without a name or a stereotype its meaning is quite weak. The dependency does however have a number of predefined stereotypes that increase the precision of the relationship. A name can also be applied to indicate the nature of the dependency. A dependency can be drawn between any two model elements or sets of elements so in theory it can be very granular and precise. In practice it is most commonly used between elements like packages that contain other elements, and it does little to specify which of the contained elements are involved.

Important Points

		A dependency can be made more specific by adding a stereotype or a name to the dependency.		The dependency relationship can be used more precisely by the addition of a stereotype (predefined or user-defined) which gives more precise meaning to the relationship.
		A dependency is a semantically weak type of relationship.		The dependency relationship is the weakest, or least specific, of the UML relationships. This allows the relationship to be used in a wide variety of circumstances and with great flexibility. This flexibility comes at the cost of precision and specificity.
		A dependency relationship can be reflexive.		This dependency signifies that if an element is changed it can have effects on itself. While this is often the case with many types of elements, and is implied by other relationships between parts of the element it is useful to denote this reflexive relationship for important elements.
		The arrowhead points to the supplier or element on which the client (tail end) depends.		The arrowhead points to the element or set of elements that is required. You can think of it like a hand reaching out for assistance from the other element or set of elements.
		There are three standard types of dependencies, abstraction, permission and usage.		The UML has three predefined types of dependencies that can be used to make the relationship more specific. Each of these has a number of stereotypes that denote particular types, or aspects, of the standard abstraction, permission or usage relationships.
		Whenever a supplier (arrowhead end) of a dependency is changed the client (tail end) is potentially affected.		The nature of the relationship means that if a supplier in a dependency relationship is changed it implies that the client may be affected. The relationship does not imply that it is affected and so in such circumstances the client should be inspected and if necessary changes made.

Related Entries

Abstraction  Type of An abstraction is a related to an dependency because it is a type of dependency relationship. The abstraction specializes the more general dependency relationship, conveying a meaning of evolution, different viewpoint or perspective. There are a number of standard stereotypes that may be added to an abstraction that further qualify its meaning and these add more precision to the less specific or standard abstraction relationship.

Usage  Type of A usage is related to a dependency because it is a type of dependency relationship. The usage specializes the more general dependency relationship, conveying that one element requires the other element in some way. There are a number of standard stereotypes that may be added to a usage that further qualify its meaning adding more precision to the less specific or standard usage relationship.

Permission  Type of A permission is related to a dependency because it is a type of dependency relationship. The permission specializes the more general dependency relationship, conveying that one element is granted rights to view the other element in some way. There are no standard stereotypes defined for a permission, but there are a number of related elements that express aspects of importing and accessing elements between namespaces.

Extend  Type of An extend relationship is essentially a type of dependency. It has the same notation as the dependency with the addition of the stereotype on the relationship. Its meaning is that the base use case (client) relies or depends on the addition use case (supplier). The UML defines the extends relationship as a different element to the dependency presumably because the semantics of the include relationship are more specific than the more general dependency. Most descriptions of the UML categorize this relationship as a type of dependency.

Include  Type of An include relationship is essentially a type of dependency. It has the same notation as the dependency with the addition of the stereotype on the relationship. Its meaning is that the base use case (client) relies or depends on the included use case (supplier). The UML defines the include relationship as a different element to the dependency presumably because the semantics of the include relationship are more specific than the more general dependency. Most descriptions of the UML categorize this relationship as a type of dependency.