|Previous||UML Classes||Table of Contents||UML Packages||Next|
A profile defines limited extensions to a reference metamodel with the purpose of adapting the metamodel to a specific platform
A Profile is a kind of Package that extends a reference metamodel. The primary extension construct is the Stereotype , which
is defined as part of Profiles .
A profile introduces several constraints, or restrictions, on ordinary metamodeling through the use of the metaclasses defined
in this package.
A profile is a restricted form of a metamodel that must always be related to a reference metamodel, such as UML, as described
below. A profile cannot be used without its reference metamodel, and defines a limited capability to extend metaclasses of
the reference metamodel. The extensions are defined as stereotypes that apply to existing metaclasses.
No additional attributes
• metaclassReference: ElementImport [*] References a metaclass that may be extended. Subsets
• metamodelReference: PackageImport [*] References a package containing (directly or indirectly) metaclasses that may be extended.
Issue 9087 - change subsets constraint 9181 - make ‘ownedStereotype ’ derived and fix subsets constraint
/ownedStereotype : Stereotype [*] References the Stereotype s that are owned by the Profile. Subsets
 An element imported as a metaclassReference is not specialized or generalized in a Profile.
self.metaclassReference.importedElement-> select(c | c.oclIsKindOf(Classifier) and (c.generalization.namespace = self or (c.specialization.namespace
= self) )->isEmpty()
 All elements imported either as metaclassReferences or through metamodelReferences are members of the same base reference
 The query allOwningPackages() returns all the directly or indirectly owning packages.
NamedElement ::allOwningPackages(): Set(Package)allOwningPackages = self.namespace->select(p | p.oclIsKindOf(Package))->union(p.allOwningPackages())
A profile by definition extends a reference metamodel. It is not possible to define a standalone profile that does not directly
or indirectly extend an existing metamodel. The profile mechanism may be used with any metamodel that is created from MOF,
including UML and CWM.
Issue 8706 -clarify which metaclasses are visible and which are not
A reference metamodel typically consists of metaclasses that are either imported or locally owned. All metaclasses that are
extended by a profile have to be members of the same reference metamodel. The "metaclassReference" element imports and "metamodelReference"
package imports serve two purposes: (1) they identify the reference metamodel elements that are imported by the profile and
(2) they specify the profile’s filtering rules. The filtering rules determine which elements of the metamodel are visible
when the profile is applied and which ones are hidden. Note that applying a profile does not change the underlying model in
any way; it merely defines a view of the underlying model.
In general, only model elements that are instances of imported reference metaclasses will be visible when the profile is applied.
All other metaclasses will be hidden. By default, model elements whose metaclasses are public and owned by the reference metamodel
are visible. This applies transitively to any subpackages of the reference metamodel according to the default rules of package
import. If any metaclasses is imported using a metaclass reference element import, then model elements whose metaclasses are
the same as that metaclass are visible. Note, however, that a metaclass reference overrides a metamodel reference whenever
an element or package of the referenced metamodel is also referenced by a metaclass reference. In such cases, only the elements
that are explicitly referenced by the metaclass reference will be visible, while all other elements of the metamodel package
will be hidden.
The following rules are used to determine whether a model element is visible or hidden when a profile has been applied. Model
elements are visible if they are instances of metaclasses that are:
1. referenced by an explicit MetaclassReference, or
2. contained (directly or transitively) in a package that is referenced by an explicit MetamodelReference; unless there are other elements of subpackages of that package that are explicitly referenced by a MetaclassReference, or
3. extended by a stereotype owned by the applied profile (even if the extended metaclass itself is not visible)
All other model elements are hidden (not visible) when the profile is applied.
The most common case is when a profile just imports an entire metamodel using a MetamodelReference. In that case, every element
of the metamodel is visible.
the example in Figure 18.8, MyMetamodel is a metamodel containing two metaclasses: Metaclass1 and Metaclass2.
MyProfile is a profile that references MyMetamodel and Metaclass2. However, there is also an explicit metaclass reference
to Metaclass2, which overrides the metamodel reference. An application of MyProfile to some model based on MyMetamodel will
show instances of Metaclass2 (because it is referenced by an explicit metaclass reference). Also, those instances of Metaclass1
that are extended by an instance of MyStereotype will be visible. However, instances of Metaclass1 that are not extended by
MyStereotype remain hidden.
If a profile P1 imports another profile P2, then all metaclassReference and metamodelReference associations will be combined
at the P2 level, and the filtering rules applies to this union.
The filtering rules defined at the profile level are, in essence, merely a suggestion to modeling tools on what to do when
a profile is applied to a model.
The "isStrict" attribute on a profileApplication specifies that the filtering rules have to be applied strictly. If isStrict
is true on a ProfileApplication , then no other metaclasses than the accessible one defined by the profile shall be accessible
when the profile is applied on a model. This prohibits the combination of applied profiles that specify different accessible
In addition to these import and filtering mechanisms, profile designers can select the appropriate metamodel by selecting
the appropriate subpackages, and using the package merge mechanism. For example, they can build a specific reference metamodel
by merging UML2 superstructure packages and classes, and or import packages from one of the UML2 compliance packages (L0-L4)
Issue 7756 - Profiles do not support association subsetting. Clarifying to avoid confusion.
Stereotype s can participate in associations. The opposite class can be another stereotype, a non-stereotype class that is
owned by a profile, or a metaclass of the reference metamodel. For these associations there must be a property owned by the
Stereotype to navigate to the opposite class. The opposite property must be owned by the Association itself rather than the
The most direct implementation of the Profile mechanism that a tool can provide is by having a metamodel based implementation,
similar to the Profile metamodel. However, this is not a requirement of the current standard, which requires only the support
of the specified notions, and the standard XMI based interchange capacities. The profile mechanism has been designed to be
implementable by tools that do not have a metamodel-based implementation. Practically any mechanism used to attach new values
to model elements can serve as a valid profile implementation. As an example, the UML1.4 profile metamodel could be the basis
for implementing a UML2.0-compliant profile tool.
Using XMI to exchange Profiles
Issue 9184 -replace first and second sentences with rules for mapping profile definitions to XMI
A profile is an instance of a UML2 metamodel, not a CMOF metamodel. Therefore the MOF to XMI mapping rules do
not directly apply for instances of a profile. Figure 18.4 on page 686 is an example of a mapping between a UML2 Profile
and an equivalent CMOF model. This mapping is used as a means to explain and formalize how profiles are serialized and exchanged
as XMI. Using this Profile to CMOF mapping, rules for mapping CMOF to XMI can be used indirectly to specify mappings from
Profiles to XMI. In the mapping:
• a Profile maps to a CMOF Package
• the metaclass, Extension::Class, is an instance of a MOF class; Extension::Class maps to itself (that is, a Class in the profile is also the same Class in the corresponding CMOF model; the mapping is the identity transformation).
• a Stereotype maps to a MOF class with the same name and properties
• an Extension maps to an Association as described in the Semantics subsection of Profile::Class on page 684.
The Profile to CMOF mapping should also include values for CMOF Tags on the CMOF package corresponding to the Profile in order
to control the XMI generation. The exact specification of these tags is a semantic variation point. A recommended convention
nsURI = http://<profileParentQualifiedName>/schemas/<profileName>.xmi
• <profileParentQualifiedName> is the qualified name of the package containing the Profile (if any) with . (dot) substituted for ::, and all other illegal XML QName characters removed, and
• <profileName> is the name of the Profile
• nsPrefix = <profileName>
• all others use the XMI defaults
A profile can be exchanged just like any model, as an XMI schema definition, and models that are extended by a profile can
also be interchanged.
Figure 18.6 on page 687 shows a Home stereotype extending the Interface UML2 metaclass. Figure 18.4 on page 686
illustrates the MOF correspondence for that example, basically by introducing an association from the Home MOF class to the
Interface MOF class. For illustration purposes, we add a property (tagged value definition in UML1.4) called magic:String
to the Home stereotype.
The first serialization below shows how
the model Figure 18.5 on page 687 (instance of the profile and UML2
metamodel) can be exchanged.
Issue 9184 -replace entire XMI for example profile definition
<?xml version="1.0" encoding="UTF-8"?>
<uml:Profile xmi:version="2.1" nsURI="http://HomeExample.xml" nsPrefix="HomeExample" xmlns:uml="http://schema.omg.org/spec/UML/2.0/uml.xml"
xmi:id="id0" name="HomeExample" metamodelReference="id2">
<packageImport xmi:id="id2"> <importedPackage href="http://schema.omg.org/spec/UML/2.0/uml.xml"/>
<ownedMember xmi:type="uml:Stereotype " xmi:id="id3" name="Home"> <ownedAttribute xmi:type="uml:Property" xmi:id="id5" name="base_Interface"
<type href="http://schema.omg.org/spec/UML/2.0/uml.xml#Interface"/> </ownedAttribute> <ownedAttribute xmi:type="uml:Property" xmi:id="id4" name="magic">
<type href="http://schema.omg.org/spec/UML/2.0/uml.xml#String"/> </ownedAttribute> </ownedMember>
<ownedMember xmi:type="uml:Extension" xmi:id="id6" name="A_Interface_Home" memberEnd="id4 id5"> <ownedEnd
xmi:type="uml:ExtensionEnd " xmi:id="id7" name="extension_Home" type="id3" isComposite="true" lower="0" upper="1">
</ownedEnd> </ownedMember> </uml:Profile>
Next, we describe an XMI definition from the «HomeExample» profile. That XMI description will itself define in XML how the
models extended by the HomeExample will be exchanged in XMI. We can see here that an XMI schema separated from the standard
UML2 schema can be obtained. This XMI definition is stored in a file called HomeExample.xmi.
Issue 9184 - replace entire XMI for example profile definition
<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema targetNamespace = "http://www.mycompany.com/schemas/HomeExample.xmi" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1"
<xsd:import namespace="http://schema.omg.org/spec/XMI/2.1" schemaLocation="XMI.xsd"/> <xsd:import namespace="http://schema.omg.org/spec/UML/2.0"
schemaLocation="UML21.xsd"/> <xsd:complexType name="Home">
<xsd:choice minOccurs="0" maxOccurs ="unbounded"><xsd:element name="base_Interface" type="xmi:Any"/><xsd:element name="magic" type="xsd:string"/><xsd:element ref="xmi:Extension"/>
</xsd:choice><xsd:attribute ref="xmi:id"/><xsd:attributeGroup ref="xmi:ObjectAttribs"/><xsd:attribute name="base_Interface" type="uml:Interface"<xsd:attribute name="magic" type="xsd:string" use="optional"/>use="optional"/>
</xsd:complexType> <xsd:element name="Home" type="Home"/> </xsd:schema>
Figure 18.9 is
an example model that includes an instance of Interface extended by the Home stereotype.
Now the XMI code below shows how this model extended by the profile is serialized. A tool importing that XMI file can filter
out the elements related to the HomeExample schema, if the tool does not have this schema (profile) definition.
Issue 9184 -replace entire XMI for the example
<?xml version="1.0" encoding="UTF-8"?>
<xmi xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:uml="http://schema.omg.org/spec/UML/2.1"
<uml:Package xmi:id="id1" name="ClientPackage"> <profileApplication xmi:id="id3"> <appliedProfile href="HomeExample.xmi#id0"/> </profileApplication>
<ownedMember xmi:type="uml:Interface" xmi:id="id2" name="Client"/> </uml:Package>
<!-- applied stereotypes --> <HomeExample:Home xmi:id= "id4" base_Interface="id2" magic="1234"/> </xmi>
A Profile uses the same notation as a Package, with the addition that the keyword «profile» is shown before or above the name
of the Package. Profile::metaclassReference and Profile::metamodelReference uses the same notation as Package::elementImport
and Package::packageImport, respectively.
, a simple example of an EJB profile is shown.
The profile states that the abstract stereotype Bean is required to be applied to metaclass Component, which means that an
instance of either of the concrete subclasses Entity and Session of Bean must be linked to each instance of Component. The
constraints that are part of the profile are evaluated when the profile has been applied to a package, and need to be satisfied
in order for the model to be well formed.
Figure 18.11, the package
Types is imported from the profile Manufacturer. The data type Color is then used as the type of one of the properties of
the stereotype Device , just like the predefined type String is also used. Note that the class JavaInteger may also be used
as the type of a property.
If the profile Manufacturer is later applied to a package, then the types from Types are also available for use in the package
to which the profile is applied (since profile application is a kind of import). This means that for example the class JavaInteger
can be used as both a metaproperty (as part of the stereotype Device ) and an ordinary property (as part of the class TV).
Note how the metaproperty is given a value when the stereotype Device is applied to the class TV.