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
- mapping: Expression
An composition of an Expression that states the abstraction
relationship between the supplier and the client. In some cases, such
as Derivation, it is usually formal and unidirectional; in other cases,
such as Trace, it is usually informal and bidirectional. The mapping
expression is optional and may be omitted if the precise relationship
between the elements is not specified.
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
- client: NamedElement [1..*] The element that is
affected by the supplier element. In some cases (such as a Trace
Abstraction) the direction is unimportant and serves only to
distinguish the two elements.
- supplier: NamedElement [1..*] Designates the element
that is unaffected by a change. In a two-way relationship (such as some
Refinement Abstractions) this would be the more general element. In an
undirected situation, such as a Trace Abstraction, the choice of client
and supplier is not relevant.
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
- contract: Classifier [1] (Specializes Dependency.target.)
- substitutingClassifier: Classifier [1] (Specializes Dependency.client.)
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.