Previous | UML Classes | Table of Contents | UML Packages | Next |
A manifestation is the concrete physical rendering of one or more model elements by an artifact.
•
Abstraction (from Dependencies ) on page 36
In the metamodel, a Manifestation is a subtype of Abstraction . A Manifestation is owned by an Artifact.
No additional attributes
Issue 8140 - fixed header style and reformatted constraint to match document convention
• utilizedElement : PackageableElement [1] The model element that is utilized in the manifestation in an Artifact. {Subsets
Dependency ::supplier}.
No additional associations
An artifact embodies or manifests a number of model elements. The artifact owns the manifestations, each representing the
utilization of a packageable element.
Specific profiles are expected to stereotype the manifestation relationship to indicate particular forms of manifestation.
For example, <<tool generated>> and <<custom code>> might be two manifestations for different classes embodied in an artifact.
A manifestation is notated in the same way as an abstraction dependency, i.e., as a general dashed line with an open arrow-head
labeled with the keyword <<manifest>>.
The following changes from UML 1.x have been made: Manifestation is defined as a meta association in UML 1.x, prohibiting
stereotyping of manifestations. In UML 1.x, the concept of Manifestation was referred to as ‘implementation’ and annotated
in the notation as <<implement>>. Since this was one of the many uses of the word ‘implementation’ this has been replaced
by <<manifest>>.