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 To top of page

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 To top of page

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 To top of page

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 To top of page

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 To top of page

None
 

 Back to Index
 

Display Organization Process Web using frames
Copyright  © 1987 - 2001 Rational Software Corporation 

Wylie College Process Web Example
Version 2001.02