Previous UML Classes Table of Contents UML Packages Next

18.1.2 Profiles History and design requirements

   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 Stereotype s and Tagged values. The UML2.0 infrastructure and superstructure specifications have carried this further, by defining it as a specific meta-modeling technique. Stereotype s 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:


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

   Profiles and Metamodels

   There is no simple answer for when you should create a new metamodel and when you instead should create a new profile.