A dependency is a relationship signifying that one or more model elements require other model elements for their specification or implementation. The complete semantics of the depending elements is either semantically or structurally dependent on the definition of the supplier element(s).
A dependency is shown as a dashed arrow between classes or packages. The model element at the tail of the arrow (the client element) depends on the model element at the arrowhead (the supplier element). You can label the arrow with an optional stereotype and an individual name.
You can also draw a dependency between a Class and other Class elements, such as attributes and operations.
Example of dependency relationships: «access» and «import».
Dependency, abstraction, and usage relationships are defined in the dialog of the same structure. They differ from one another only by the corresponding Specification name. You can specify a dependency by changing its property values in the dependency Specification window. Each property is described in the description area on this window.
Editing property values
For more information about specifying property values, see Editing property values.
There are several kinds of dependencies:
| Dependency kind | Description |
|---|---|
Template binding | Represents a relationship between a templatable element and a template. A template binding specifies the substitutions of actual parameters for the formal parameters of the template. You can specify template binding dependency properties and find each property's description in the template binding dependency Specification window. Descriptions are presented in the description area of the Specification window. |
Abstraction | Relates two elements or sets of elements that represent the same concept at different levels of abstraction or from different viewpoints. In the metamodel, an abstraction is a dependency in which there is a mapping between the supplier and the client. Define an abstraction relationship in the Abstraction Specification window. |
Usage | A relationship in which one element requires another element (or set of elements) for its full implementation or operation. In the metamodel, a usage is a dependency in which the client requires the presence of the supplier. Define a usage relationship in the Usage Specification window. |
Package merge | A directed relationship between two packages, indicating that the contents of the two packages are to be combined. It has a dependency relation with the applied stereotype «merge». Define a merge relationship in the Dependency Specification window. |
Element import | A directed relationship between an importing namespace and a packageable element. The name of the packageable element or its alias is added to the namespace of the importing namespace. It has a dependency relation with the applied stereotype «import». Define an import relationship in the Dependency Specification window. To draw the Element Import link, select the Element Import path to draw in the Class diagram toolbar, from the Abstraction group.
|
Access | Shows that elements can only be accessed from a package, and it cannot be referenced. |
Deployment | The allocation of a deployment target to an artifact or artifact instance. |
Role Binding | A relationship in Composite Structure diagram. Role Binding is used to connect Parts with Collaboration Use. |
Mount | A mount dependency represents a former location of a shared package; that is, a location where the package was mounted in a local project. A mount dependency is created:
The purpose of establishing the mount dependency is to ensure the same containment structure during project transformation to Teamwork Cloud, to maintain the correct scope in utilities like smart packages, validation rules, tables etc. |
Related pages