Dependencies

The contents of the Dependencies package is shown in Figure 51. The Dependencies package is one of the packages of the Classes package.

In order to locate the metaclasses that are referenced from this package,
· See "Classifier (from Kernel, Dependencies, PowerTypes)".
· See "DirectedRelationship (from Kernel)".
· See "OpaqueExpression (from Kernel)".
· See "NamedElement (from Kernel, Dependencies)" .
· See "PackageableElement (from Kernel)".

Abstraction (from Dependencies)


Description

An abstraction is a relationship that relates two elements or sets of elements that represent the same concept at different levels of abstraction or from different viewpoints. (See also, the definition of abstration in the Glossary.) In the metamodel, an Abstraction is a Dependency in which there is a mapping between the supplier and the client.

Attributes

No additional attributes.

Associations

Constraints

No additional constraints.

Semantics

Depending on the specific stereotype of Abstraction, the mapping may be formal or informal, and it may be unidirectional or bidirectional. Abstraction has predefined stereotypes (such as «derive», «refine», and «trace») which are defined in the Standard Profiles chapter. If an Abstraction element has more than one client element, the supplier element maps into the set of client elements as a group. For example, an analysis-level class might be split into several design-level classes. The
situation is similar if there is more than one supplier element.

Notation

An abstraction relationship is shown as a dependency with an «abstraction» keyword attached to it or the specific predefined stereotype name.

Examples

In the example below, the Employee class indentified in analysis (i.e., the «type») maps to the same concept in the design model called Employee Record.


Classifier (from Dependencies)

· See "Classifier (from Kernel, Dependencies, PowerTypes)" .

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).

Attributes

No additional attributes.

Associations

Constraints

No additional constraints.

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. The presence of dependency relationships in a model does not have any runtime semantics implications, it is all given in terms of the model-elements that participate in the relationship, not in terms of their instances.

Notation

A dependency is shown as a dashed arrow between two model elements. The model element at the tail of the arrow (the client) depends on the model element at the arrowhead (the supplier). The arrow may be labeled with an optional stereotype and an optional name. It is possible to have a set of elements for the client or supplier. In this case, one or more arrows with their tails on the clients are connected the tails of one or more arrows with their heads on the suppliers. A small dot can be placed on the junction if desired. A note on the dependency should be attached at the junction point.



Examples

In the example below, the Car class has a dependency on the Vehicle Type class. In this case, the dependency is an instantiate dependency, where the Car class is an instance of the Vehicle Type class.



NamedElement (from Dependencies)


See "NamedElement (from Kernel, Dependencies)".

Permission (from Dependencies)


Description

A Permission signifies granting of access rights from the supplier model element to a client model element. Or to put it another way, it signifies that the client requires access to some or all of the constituent elements of the supplier. The supplier element gives the client permission to access some or all of its constituents elements.

Attributes

No additional attributes.

Constraints

[1] The supplier must be a namespace

Notation

A permission dependency is shown as a dependency with a «permit» keyword attached to it.

Examples

In the example below, the Employee class grants access rights to Executive objects. This means that executive objects may access the private properties of salary and homePhoneNumber.

Realization (from Dependencies)

Description

Realization is a specialized abstraction relationship between two sets of model elements, one representing a specification (the supplier) and the other represents an implementation of the latter (the client). Realization can be used to model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc.

Realization is a specialized abstraction relationship between two sets of model elements. Onespecifies the source (the supplier); the other implements the targer (the client). Realization can be used to model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc.

Attributes

No additional attributes.

Associations

No additional associations.

Constraints

No additional constraints.

Semantics

A Realization signifies that the client set of elements are an implementation of the supplier set, which serves as the specification. The meaning of `implementation' is not strictly defined, but rather implies a more refined or elaborate form in respect to a certain modeling context. It is possible to specify a mapping between the specification and implementation elements, although it is not necessarily computable.

Notation

A Realization dependency is shown as a dependency with the keyword «realize» attached to it.

Substitution  (from Dependencies)

Description

A substitution is a relationship between two classifiers signifies that the substitutingClassifier complies with the contract specified by the contract classifier. This implies that instances of the substitutingClassifier are runtime substitutable where instances of the contract classifier are expected.

Associations
Attributes

None.

Constraints

No additional constraints.

Semantics

The substitution relationship denotes runtime substitutability which is not based on specialization. Substitution, unlike specialization, does not imply inheritance of structure, but only compliance of publicly available contracts. A substitution like relationship is instrumental to specify runtime substitutability for domains that do not support specilization such as certain component technologies. It requires that (1) interfaces implemented by the contract classifier are also implemented by the
sunstituting classifier, or else the substituting classifier implements a more specilized interface type. And, (2) the any port owned by the contract classifier has a matching port (see ports) owned by the substituting classifier.

Notation

A Substitution dependency is shown as a dependency with the keyword «substitute» attached to it.

Examples

In the example below, a generic Window class is substituted in a particular environment by the Resizable Window class.

Usage (from Dependencies)


Description

A usage is 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.

Attributes

No additional attributes.

Associations

No additional associations.

Constraints

No additional constraints.

Semantics

The usage dependency does not specify how the client uses the supplier other than the fact that the supplier is used by of the definition or implementation of the client.

Notation

A usage dependency is shown as a dependency with a «use» keyword attached to it.

Examples

In the example below, a Order class requires the Line Item class for its full implementation.