| Previous | Table of Contents | Next |
The Profiles package of the InfrastructureLibrary contains mechanisms that allow metaclasses from existing metamodels to be
extended to adapt them for different purposes. This includes the ability to tailor the UML metamodel for different platforms
(such as J2EE or .NET) or domains (such as real-time or business process modeling). The profiles mechanism is consistent with
the OMG Meta Object Facility (MOF).
The infrastructure specification is reused at several meta-levels in various OMG specifications that deal with modeling. For
example, MOF uses it to provide the ability to model metamodels, whereas the UML superstructure uses it to model the UML model.
This chapter deals with use cases comparable to the MOF at the meta-meta-level, which is one level higher than the rest of
the infrastructure specification. Thus, in this chapter, when we mention “Class,? in most cases we are dealing with the meta-metaclass
“Class? (used to define every meta class in the UML Infrastructure specification (Association, Property, etc.).
The Profile mechanism has been specifically defined for providing a lightweight extension mechanism to the UML standard. In
UML 1.1, stereotypes and tagged values were used as string-based extensions that could be attached to UML model elements in
a flexible way. In subsequent revisions of UML, the notion of a Profile was defined in order to provide more structure and
precision to the definition of Stereotypes and Tagged values. The UML2.0 Infrastructure and Superstructure specifications
have carried this further, by defining it as a specific meta-modeling technique. Stereotypes are specific metaclasses, tagged
values are standard metaattributes, and profiles are specific kinds of packages.
The following requirements have driven the definition of profile semantics from inception:
1. A profile must provide mechanisms for specializing a reference metamodel (such as a set of UML packages) in such a way that the specialized semantics do not contradict the semantics of the reference metamodel. That is, profile constraints may typically define well-formedness rules that are more constraining (but consistent with) those specified by the reference metamodel.
2. It must be possible to interchange profiles between tools, together with models to which they have been applied, by using the UML XMI interchange mechanisms. A profile must therefore be defined as an interchangeable UML model. In addition to exchanging profiles together with models between tools, profile application should also be definable “by reference? (e.g., “import by name?); that is, a profile does not need to be interchanged if it is already present in the importing tool.
3. A profile must be able to reference domain-specific UML libraries where certain model elements are pre-defined.
4. It must be possible to specify which profiles are being applied to a given Package (or any of specializations of that concept). This is particularly useful during model interchange so that an importing environment can interpret a model correctly.
5. It should be possible to define a UML extension that combines profiles and model libraries (including template libraries) into a single logical unit. However, within such a unit, for definitional clarity and for ease of interchange (e.g., ‘reference by name’) it should still be possible to keep the libraries and the profiles distinct from each other.
6. A profile should be able to specialize the semantics of standard UML metamodel elements, e.g., in a model with the profile “Java model? generalization of classes should be able to be restricted to single inheritance, without having to explicitly assign a stereotype «Java class» to each and every class instance.
7. A notational convention for graphical stereotype definitions as part of a profile should be provided.
8. In order to satisfy requirement [1] above, UML Profiles should form a metamodel extension mechanism that imposes certain restrictions on how the UML metamodel can be modified. The reference metamodel is considered as a “read only? model, that is extended without changes by profiles. It is therefore forbidden to insert new metaclasses in the UML metaclass hierarchy (i.e., new super-classes for standard UML metaclasses) or to modify the standard UML metaclass definitions (e.g., by adding meta-associations). Such restrictions do not apply in a MOF context where in principle any metamodel can be reworked in any direction.
9. The vast majority of UML case tools should be able to implement Profiles. The design of UML profiles should therefore not constraint these tools to have an internal implementation based on a meta-metamodel/metamodel architecture.
10. Profiles can be dynamically applied to or retracted from a model. It is possible on an existing model to apply new profiles, or to change the set of applied profiles.
11. Profiles can be dynamically combined. Frequently, several profiles will be applied at the same time on the same model. This profile combination may not be foreseen at profile definition time.
12. Models can be exchanged regardless of the profiles known by the destination target. The destination of the exchange of a model extended by a profile may not know the profile, and is not required to interpret a specific profile description. The destination environment interprets extensions only if it possesses the required profiles.
The profiles mechanism is not a first-class extension mechanism (i.e., it does not allow for modifying existing metamodels).
Rather, the intention of profiles is to give a straightforward mechanism for adapting an existing metamodel with constructs
that are specific to a particular domain, platform, or method. Each such adaption is grouped in a profile. It is not possible
to take away any of the constraints that apply to a metamodel such as UML using a profile, but it is possible to add new constraints
that are specific to the profile. The only other restrictions are those inherent in the profiles mechanism; there is nothing
else that is intended to limit the way in which a metamodel is customized.
First-class extensibility is handled through MOF, where there are no restrictions on what you are allowed to do with a metamodel:
you can add and remove metaclasses and relationships as you find necessary. Of course, it is then possible to impose methodology
restrictions that you are not allowed to modify existing metamodels, but only extend them. In this case, the mechanisms for
first-class extensibility and profiles start coalescing.
There are several reasons why you may want to customize a metamodel:
• Give a terminology that is adapted to a particular platform or domain (such as capturing EJB terminology like home interfaces, enterprise java beans, and archives).
• Give a syntax for constructs that do not have a notation (such as in the case of actions).
• Give a different notation for already existing symbols (such as being able to use a picture of a computer instead of the ordinary node symbol to represent a computer in a network).
• Add semantics that is left unspecified in the metamodel (such as how to deal with priority when receiving signals in a statemachine).
• Add semantics that does not exist in the metamodel (such as defining a timer, clock, or continuous time).
• Add constraints that restrict the way you may use the metamodel and its constructs (such as disallowing actions from being able to execute in parallel within a single transition).
• Add information that can be used when transforming a model to another model or code (such as defining mapping rules between a model and Java code).
There is no simple answer for when you should create a new metamodel and when you instead should create a new profile.