Constraints
- 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 ref-
erence metamodel.
self.metamodelReference.importedPackage.elementImport.importedElement.allOwningPackages())->
union(self.metaclassReference.importedElement.allOwningPackages() )->notEmpty()
Additional Operations
- 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 or another profile. 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 unless they are subsets of existing associations in the reference metamodel. However, it is possible to have
associations between ordinary classes, and from stereotypes to ordinary classes. Likewise, properties of stereotypes may
not be typed by metaclasses or stereotypes.
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 114, 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.
Types
In Figure 115, 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.