Abstraction
UML Common Structure
Abstraction is a dependency relationship that relates two named elements or sets of named elements representing the same concept but at different levels of abstraction or from different viewpoints.
Because abstraction is dependency, it is usually defined as a relationship between client(s) and supplier(s) where client (subset of source) depends on supplier (subset of target). It corresponds to common OOAD convention to consider more abstract element in the abstraction relationship as a supplier. Nonetheless, UML modeler may decide that for some specific domain or task it is more appropriate to have a more abstract supplier element dependent on the more specific client element.
Abstraction allows mapping between the supplier and the client to be formal or informal, and unidirectional or bidirectional, depending on the specific subclass or stereotype of abstraction. For example, Derivation could be formal and unidirectional, while Trace could be informal and bidirectional.
If an abstraction has more than one client, the supplier maps into the set of clients as a group. For example, an analysis level class could serve as an abstraction for one or several design level classes. Use case could be abstraction for several collaborations.
Abstract Syntax
Abstraction has two subclasses - Realization and Manifestation. A manifestation is labeled with the keyword «manifest», and is used in deployment diagrams.
Abstraction is a Dependency, it is subclassed by Realization and Manifestation,
and has standard stereotypes «Derive», «Refine», «Trace».
Abstraction also has few standard stereotypes - «Derive», «Refine», and «Trace», defined in the Standard Profile.
Notation
An abstraction relationship is shown as a dependency relationship 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.
For example, an analysis level class Customer (supplier, subset of target) might be implemented as design level class CustomerInfo (client, subset of source).
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.)
«Derive»
«Derive» is a standard abstraction stereotype which is used to specify a derivation relationship among model elements that are usually, but not necessarily, of the same type. This derivation is defined in UML as "the client may be computed from the supplier". The reason to have such "computed client" could be implementation efficiency. The mapping from the abstraction relationship specifies the computation.
The derivation relationship is related to derived properties, properties which values are produced or computed from other information, for example, by using values of other properties.
Age class is derived from BirthDate class.
Revisions
Definition of «Derive» relationship did not change since UML 1.3. As other stereotypes, until UML 2.4.1 «derive» was in lower case.
«Refine»
«Refine» is a standard abstraction stereotype which is used to specify a refinement relationship between model elements at different semantic levels, such as analysis, design, and implementation. It can be used to model transformations from analysis to design, design to implementation, etc. The abstraction mapping may or may not be computable, and it may be unidirectional or bidirectional.
Models can have refinement dependencies between them, typically represented by dependencies between the elements contained in the models.
Customer class from Design model refines Customer class from Analysis model.
Revisions
UML 1.4.2 Glossary definition for refinement was:
A relationship that represents a fuller specification of something that has already been specified at a certain level of detail. For example, a design class is a refinement of an analysis class.
As other stereotypes, until UML 2.4.1 «refine» was in lower case.
«Trace»
Trace is a standard abstraction stereotype 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. Thus trace is "inter-model" relationship.
These tracing/mapping dependencies between Models are typically represented by dependencies between the elements contained in the models.
Some examples of using Trace are:
- Use case in Use Case Model might trace to collaborations or a package in corresponding Design Model.
- Interfaces and classes from Design Model could trace to components in Implementation Model.
- Components in Implementation Model might trace to artifacts in Deployment Model. In this case though, an alternative is to use specialized manifestation relationship.
Withdraw Cash use case in Use Case Model trace to Withdraw Cash collaboration in Design Model.
The direction of trace (i.e., the designation of the client and supplier) is at the discretion of the modeler, and 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.
Revisions
In UML 1.4.2 «trace» was defined almost the same way as in current version while Glossary definition for trace was:
A dependency that indicates a historical or process relationship between two elements that represent the same concept without specific rules for deriving one from the other.
As other stereotypes, until UML 2.4.1 «trace» was in lower case.