Abstraction in UML
Abstraction is a dependency relationship that relates two elements or sets of elements (called client and supplier) representing the same concept but at different levels of abstraction or from different viewpoints.
For example, an analysis level class could serve as an abstraction for one or several design level classes. Use case could be abstraction for collaboration.
An abstraction relationship is shown as a dependency arrow from the client at the tail to the supplier at the arrowhead, with the «abstraction» keyword or some other predefined stereotype name attached to. It could be catchy to decide which element is client and which one is supplier. In general, client depends on supplier, and it is a common convention in the OOAD for the abstraction relationship to have the more abstract element as supplier. Nonetheless, UML modeler may decide that for some domain or task it is more appropriate to have a more abstract element dependent on the more specific element.
For example, an analysis level class Customer (supplier) might be implemented as design level class CustomerInfo (client).
Customer from Domain is abstraction for CustomerInfo from DataTransfer.
(Common convention example - the more abstract element as supplier.)
If some UML modeler decides that it is better to show a more abstract element dependent on the more specific element, the relationship will be reversed.
Customer from Domain is abstraction for CustomerInfo from DataTransfer.
(Reverse notation example - the less abstract element as supplier.)
Abstraction relationship between the supplier and the client in some cases, such as derivation, could be formal and unidirectional, while in some other cases, such as «trace», could be informal and bidirectional.
Abstraction has standard stereotypes such as «manifest» (used in deployment diagrams), «derive», «refine», and «trace».
Realization
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).
The meaning of "implementation" is not strictly defined in UML Specification. It implies a more refined or elaborate form in respect to a certain modeling context.
Realization can be used to model stepwise refinement, optimizations, transformations, templates, model synthesis, framework composition, etc.
A Realization dependency is shown as a dashed line with a triangular arrowhead at the end that corresponds to the realized element (the supplier).
Specializations of Realization relationship are interface realization and substitution.
Interface Realization
Interface realization is a specialized realization relationship between a classifier and an interface. This relationship signifies that the realizing classifier conforms to the contract specified by the interface.
A classifier that implements an interface specifies instances that are conforming to the interface and to any of its ancestors. A classifier may implement one or several interfaces.
The set of interfaces implemented by the classifier are its provided interfaces. Provided interfaces describe the set of services the classifier offers to its clients.
A classifier implementing an interface supports the set of features owned by the interface. In addition to supporting the features, a classifier must comply with the constraints owned by the interface.
An interface realization relationship between a classifier and an interface implies that the classifier supports the set of features owned by the interface, and any of its parent interfaces.
For behavioral features, the implementing classifier will have an operation or reception for every operation or reception, respectively, defined by the interface.
For properties, the realizing classifier will provide functionality that maintains the state represented by the property. While such may be done by direct mapping to a property of the realizing classifier, it may also be supported by the state machine of the classifier or by a pair of operations that support the retrieval of the state information and an operation that changes the state information.
The interface realization dependency from a classifier to an interface is shown by representing the interface by a circle or ball, labeled with the name of the interface and attached by a solid line to the classifier that realizes this interface.
Interface SiteSearch is realized (implemented) by SearchService.
If interface is represented using the rectangle notation, interface realization dependency is denoted with interface realization arrow. The classifier at the tail of the arrow implements the interface at the head of the arrow.
Interface SiteSearch is realized (implemented) by SearchService.
Trace
Trace is an abstraction relationship which is mainly used for tracking requirements and changes across models for the elements or sets of elements that represent the same concept in different models.
Since model changes can occur in both directions, the direction of the dependency can often be ignored. The mapping specifies the relationship between the two, but it is rarely computable and is usually informal. The direction (i.e., the designation of the client and supplier) is at the discretion of the modeler.
