Standards: Dependency
Dependency |
A semantic relationship between two things in which a change to one thing (the
independent thing) may affect the semantics of the other thing (the dependent thing). |
Related Information: |
|
Topics
Background
A dependency exists between two elements if changes to the definition of one element
may cause changes to the other. With classes, dependencies exist for various reasons: one
class sends a message to another; one class has another as part of its data; one class
mentions another as a parameter to an operation. If a class changes its interface, then
any message its sends may no longer be valid.
The dependency relationship between classes can be considered the loosest form of
relationship as it implies a transient relationship no more than one dependency
relationship is ever required between classes even if the relationship is used for many
purposes and to access many instances of the non-dependent class.
Package dependencies are used to show where class dependencies are allowed if
there is no dependency between the packages then there should not be any relationships
between the classes contained by the packages. This allows the model to explicitly define
the layering and access rules laid down by the architecture.
Naming Standards
The naming of dependencies is optional. Generally dependencies will not be named.
Stereotypes are used to distinguish between different flavors of dependency (i.e.
<<trace>> or <<friend>> etc...)
General Documentation Standards
All dependency documentation is optional. If it adds clarity to the model then
the dependencies can be named and described but this is uncommon in most models.
Stereotypes
The UML defines the following stereotypes for dependencies:
Stereotype |
Used |
Between |
Comments |
<<bind>> |
Yes |
Classes / Objects |
Specifies that the source instantiates the
target template using the given actual parameters. |
<<derive>> |
Yes |
Classes / Objects |
Specifies that the source may be computed
from the target. |
<<friend>> |
No |
Classes / Objects |
Specifies that the source is given special
visibility into the target. |
<<instanceOf>> |
Yes |
Classes / Objects |
Specifies that the source object is an
instance of the target classifier. |
<<instantiate>> |
Yes |
Classes / Objects |
Specifies that the source creates instances
of the target. |
<<powertype>> |
No |
Classes / Objects |
Specifies that the target is a powertype of
the source. |
<<refine>> |
Yes |
Classes / Objects |
Specifies that the source is at a finer
degree of abstraction than the target. |
<<use>> |
Yes |
Classes / Objects |
Specifies that the semantics of the source
element depends on the semantics of the public part of the target. |
<<access>> |
Yes*1 |
Packages |
Specifies that the source package is granted
the right to reference the elements of the target package. This is the default for
package dependencies in Rose. |
<<import>> |
No*1 |
Package |
A kind of access that specifies that the
public contents of the target package enter the flat name space of the source, as if they
had been declared in the source. |
<<extend>> |
Yes*2 |
Use Cases |
Specifies that the target use case extends
the behavior of the source. |
<<include>> |
Yes*2 |
Use Case |
Specifies that the source use case explicitly
incorporates the behavior of another use case at a location specified by the source. |
<<become>> |
No*3 |
Objects |
Specifies that the target is the same object
as the source but at a later point in time and with possibly different values, state or
roles. |
<<call>> |
No*3 |
Operations |
Specifies that the source operation invokes
the target operation. |
<<copy>> |
No*3 |
Objects |
Specifies that the target object is an exact,
but independent, copy of the source. |
<<send>> |
No*3 |
Operations and Events |
Specifies that the source operation sends the
target event. |
<<trace>> |
Yes |
Anything |
Specifies that the target is an historical
ancestor of the source (e.g. used to show traceability between classes in an analysis
model and design classes in the design model descended from them). |
The RUP adds the following stereotype:
Stereotype |
Used |
Between |
Comments |
<<realizes>> |
Yes |
Use-Case Realizations / Use Cases |
Specifies that the that the use-case
realization realizes the behavior defined by the use-case.. |
Notes:
*1 - In Rose dependencies between Packages are all treated as
<<access>> dependencies. They can be stereotyped, even though they have
no specification, by typing in the desired stereotype (including the << and
>>) whilst the dependency is selected.
*2 - In Rose dependencies are not supported between Use Cases -
these stereotypes are applied to uni-directional associations between use cases instead.
*3 - These dependencies are not supported by Rose: if this
information is to be included in a Rose model then notes or comments must be used.
Examples
None
|