A profile defines limited extensions to a reference metamodel with the purpose of adapting the metamodel to a specific platform or domain.

*Generalizations

•

InfrastructureLibrary::Constructs::Package

Description

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.

Attributes

No additional attributes

Associations

• metaclassReference: ElementImport [*] References a metaclass that may be extended. Subsets

Package::elementImport

• metamodelReference: PackageImport [*] References a package containing (directly or indirectly) metaclasses that may be extended. Subsets Package::packageImport.

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

		Package::packagedElement
Constraints

[1] 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()

[2] All elements imported either as metaclassReferences or through metamodelReferences are members of the same base reference metamodel.

self.metamodelReference.importedPackage.elementImport.importedElement.allOwningPackages())-> union(self.metaclassReference.importedElement.allOwningPackages() )->notEmpty()

Additional Operations

[1] 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())

Semantics

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.

In 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.

Figure 18.8 Specification of an accessible metaclass

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 metaclasses.

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 other class/metaclass.

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 is:

nsURI = http://<profileParentQualifiedName>/schemas/<profileName>.xmi

where:

• <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>

<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" xmlns:uml="http://schema.omg.org/spec/UML/2.1" xmlns:xsd="http://www.w3.org/2001/XMLSchema">

<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.

Figure 18.9 - Using the HomeExample profile to extend a model

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"?>

<uml:Package xmi:id="id1" name="ClientPackage"> <profileApplication xmi:id="id3"> <appliedProfile href="HomeExample.xmi#id0"/> </profileApplication>

<HomeExample:Home xmi:id= "id4" base_Interface="id2" magic="1234"/> </xmi>

Notation

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.

Examples

In Figure 18.10 , a simple example of an EJB profile is shown.

Figure 18.10 - Defining a simple EJB profile

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 - Importing a package from a profile

In 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.

18.3.6 Profile

Profiles

*Generalizations

•

/ownedStereotype : Stereotype [*] References the Stereotype s that are owned by the Profile. Subsets