Profiles
Overview
The Profiles package 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).
Extensibility
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).
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.