Profiles

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

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.

Generalizations

• “Package (from Constructs, Profiles)? on page 184.

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.

• ownedStereotype: Stereotype [*] References the Stereotypes that are owned by the Profile. Subsets Package::ownedMember.

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.

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. A tool can make use of the information about which metaclasses are extended in different ways, for example to filter or hide elements when a profile is applied, or to provide specific tool bars that apply to certain profiles. However, elements of a package or model cannot be deleted simply through the application of a profile. Each profile thus provides a simple viewing mechanism.

As part of a profile, it is not possible to have an association between two stereotypes or between a stereotype and a metaclass. The effect of new (meta)associations within profiles can be achieved in limited ways either by:

1. adding new constraints within a profile that specialize the usage of some associations of the reference metamodel, or

2. extending the Dependency metaclass by a stereotype and defining specific constraint on this stereotype.

As an illustration of the first approach, the examples in Figure 13.6 and Figure 13.7 could be extended by adding a “HomeRealization? stereotype that extends the “InterfaceRealization? UML metaclass. The “Bean? stereotype will introduce the constraint that the “interfaceRealization? association can only target “InterfaceRealization? elements extended by a “HomeRealization? stereotype and the “HomeRealization? stereotype will add the constraint that the “contract? association can only target interfaces extended by a “Home? stereotype. As an illustration of the second approach, one can define a stereotype “Sclass? extending Class and a stereotype “Sstate? extending State. In order to specify the default state of an “Sclass,? a “DefaultState? stereotype extending “Dependency? can be defined, with the constraints that a DefaultState Dependency can only exist between an Sclass and an Sstate.

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

As shown in Figure 13.3 (Extension : Semantics), there is a direct correspondence between a profile definition and a MOF metamodel. XMI can therefore be directly applied to exchange Profiles. We will take the example Figure 13.6 (Extension : Notation) of a profile that we will call “HomeExample? to illustrate how a profile can be exchanged. We will see that a profile can be exchanged as a model, as an XMI schema definition, and that models extended by the profile can also interchange their definition and extension.

Figure 13.6 shows a “Home? stereotype extending the “Interface? UML2 metaclass. Figure 13.8 on page 188 illustrates the MOF correspondence for that example, basically by introducing an association from the “Home? MOF class to the “Interface? MOF class. For illustration purpose, 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 449 (instance of the profile and UML2 metamodel) can be exchanged.

<?xml version="1.0" encoding="UTF-8"?><XMI xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"xmlns:mof="http://schema.omg.org/spec/MOF/2.0" xmlns:uml="http://schema.omg.org/spec/UML/2.0"><uml:Profile xmi:id="id1" name="HomeExample">

</ownedMember>

<metaclassReference xmi:id="id8">

<uml:elementImport xsi:type="uml:ElementImport" importedElement=?id9?/></metaclassReference></uml:Profile>

<mof:Class xmi:id=?id9? href="http://schema.omg.org/spec/UML/2.0/uml.xml#Interface"/><mof:PrimitiveType xmi:id=?id10? href="http://schema.omg.org/spec/UML/2.0/uml.xml#String"/>

<mof:Tag name="org.omg.xmi.nsURI" value="http://www.mycompany.com/schemas/HomeExample.xmi" element="id1"/> <mof:Tag name="org.omg.xmi.nsPrefix" value="HomeExample" element="id1"/><mof:Tag name="org.omg.xmi.xmiName" value="base_Interface" element="id3"/>

</XMI>

We will now obtain 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 a XMI schema separated from the standard UML2 schema can be obtained. This XMI definition is stored in a file called “HomeExample.xmi.?

<?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:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:uml="http://www.omg.org/spec/UML/2.0" 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="UML20.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>

Let us provide an example of an Interface extended by the Home stereotype.

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

<?xml version="1.0" encoding="UTF-8"?><XMI xmi:version="2.1" xmlns:xmi="http://schema.omg.org/spec/XMI/2.1" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:uml="http://schema.omg.org/spec/UML/2.0 " xmlns:HomeExample="http://www.mycompany.com/schemas/HomeExample.xmi">

<uml:Package xmi:id="id1" name="ClientPackage"><ownedMember xsi:type="uml:Interface" xmi:id="id2" name="Client"/><packageImport xsi:type="uml:ProfileApplication" xmi:id="id3">

<HomeExample:Home 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 13.9 , a simple example of an EJB profile is shown.

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

«apply»

Figure 13.10 - Importing a package from a profile

In Figure 13.10 , 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.

13.1.6 Profile

Profiles