Element < DirectedRelationship < Dependency < Abstraction < Allocation
From UML2.1.2: 7.3.12 Dependency (from Dependencies):
'Description
A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. This means that the complete semantics of the depending elements is either semantically or structurally dependent on the definition of the supplier element(s).
..Associations
client: NamedElement [1..*]
The element(s) dependent on the supplier element(s). In some cases (such as a Trace Abstraction) the assignment of direction (that is, the designation of the client element) is at the discretion of the modeler, and is a stipulation. Subset DirectedRelationship::source.
supplier: NamedElement [1..*]
The element(s) independent of the client element(s), in the same respect and the same dependency relationship. In some directed dependency relationships (such as Refinement Abstractions), a common convention in the domain of class-based OO software is to put the more abstract element in this role. Despite this convention, users of UML may stipulate a sense of dependency suitable for their domain, which makes a more abstract element dependent on that which is more specific. Subsets DirectedRelationship::target.
..Semantics
A dependency signifies a supplier/client relationship between model elements where the modification of the supplier may impact the client model elements. A dependency implies the semantics of the client is not complete without the supplier. ..'
Please note that:
- 'In some cases .. the assignment of direction (that is, the designation of the client element) is at the discretion of the modeler'
- Yet in any case the supplier is ' independent of the client element(s)' whether or not is 'the more abstract element'
A good rule-of -thumb for Dependency is that the supplier must
precede - in the development or modelling process - the client. A
typical example is when resources are supplied to a client by an
element that is imported from a read-only module or library; clearly
the supplier, the one from the library, must exist first (or at least
be presumed to exist already).
Confusion for SysML allocations used to decompose a single element into many - or to refine an element - may arise because there is a sense in which the element that came first - the one that is to be decomposed or otherwise refined - "requires other model elements" for its engineering specification.
