The UML has been designed to support a wide variety of application domains. In spite of this design philosophy, it is not possible to cover the needs of every user. In most cases, it is required to apply some adaptations to the UML, possibly caused by the user’s methodology or specific requirements of the target system. Especially, new engineering technologies take some time to be integrated into the UML. This concludes that the UML will probably never be optimally suited for the design of any system one can think of.
Profiles have been introduced in the UML 1.3 to enable the extension (or specialization) of the standard modeling language. At that time, there were many requests to put several modeling elements into the UML. This would have evolved into a huge collection of each new software modeling technique to be incorporated into the UML. Profiles were introduced to allow users to add their own touch to the UML. Prior to the UML 2, extending the UML was limited only to the use of stereotypes and profiles. As depicted in Figure 26, there are the following mechanisms are available to adapt a metamodel to a specific purpose:
• New metamodel
• Extended and modified UML metamodel
• UML Profiles
• (and not shown) Stereotypes
Figure 26: UML Extension Mechanisms
The first option is to define a completely new metamodel based on the M3 layered meta-metamodel.
Alternatively, an uncontrolled extension, a modification of the UML metamodel, can be done. This type of extension is called heavy-weight extension or first-class extension. Controlled extensions based on inherent extension mechanisms are profiles and stereotypes. They are light-weight extensions.
«merge» «merge» «merge» «instanceOf»
«import» M3
Metametamodel
M2 Metamodel
4.4 UML Extension Mechanisms
4.4.1 UML Profiles
The UML introduces a concept of profiles. This package provides extension mechanisms which allow specialization of metaclasses from existing metamodels to tailor them for different purposes. For instance, this includes the ability to align the UML metamodel for different platforms (such as J2EE or .NET) or domains, such as real-time systems, business processes or systems engineering. It is important to note that the profile’s extension mechanism is consistent with the OMG Meta Object Facility (MOF). It is not a first-class extension and therefore, it is not possible to alter existing metamodels. According to the UML 2.1 Superstructure document [OMG06], 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.
UML profiles are UML packages with the keyword «profile» (with surrounding guillemots). A profile is used to extend a meta-model or another profile. It gives further details and semantics to existing UML elements by providing refined elements that extend existing meta-model classes. For this purpose, a UML profile can consist of stereotypes, constraints and tagged values.
A stereotype is an extension (or specialization) of existing metamodeling elements. It describes the domain specific usage context in which a modeling element (class, relation or package) is placed.
Stereotypes are the main components of a UML profile and describe how the UML metamodel can be extended to a specific domain. Stereotypes are specialized classes which are labeled with the keyword
«stereotype». Model elements can be classified upon instantiation by means of stereotypes.
Stereotypes enable the addition of auxiliary UML metaclasses with new meta-attributes and semantics.
As all classes, a stereotype can also own properties like attributes which are referred to as tag definition. A stereotype can also introduce tagged values which assigns an initial value to a tag definition. Tagged values are user-defined and tool- or language-specific name-value pairs and are defined by a name and a type. In contrast to stereotypes, tagged values are used as additional meta-attributes to complement a model element by attaching arbitrary information to a model element.
Stereotypes can also implement generalization hierarchies but only within other stereotype classes. A stereotype extends a metaclass of the metamodel. An extension is visualized by a generalization arrow, but with a filled arrow instead of an unfilled arrow for class generalization. This is a particular association between a metaclass and the stereotype. Both classes are simultaneously instantiated except when the stereotype is marked as being optional (in UML terms by a missing required notation) or being abstract. As a stereotype is an extension to a model element, it can be used together with the metaclass model element. For each tag definition of the stereotype, a tagged value can be added. A stereotype can also own its own notation, e.g. by means of a specific icon for a metaclass.
Figure 27: Generalization and Extension Notation in the UML
Figure 27 gives an overview of the specialization concept in the UML. Classes and UML metaclasses can be specialized while stereotypes can only extend metaclasses. Generalization depicts the relationship (inheritance) between the general and the specialized class. It is denoted by a white filled arrowhead. In contrast, an extension is depicted by a black filled arrowhead. A stereotype can specialize another stereotype, but it cannot extend it. Note that the metaclass and stereotype headings are keywords and not stereotypes (because the notation within guillemots is the same).
Stereotypes can also define constraints in order to indicate restrictions. It is possible to define pre- or post-conditions, invariants and more. Constraints defined by extensions must not contradict the restrictions of the base class. In UML, restrictions can be expressed in any language, such as programming languages or natural languages. In this thesis, the Object Constraint Language (OCL) (see Section 4.5) is used for the profile definition, as it is more precise than natural language and can be evaluated by modeling tools automatically.
4.4.2 Requirements for a UML Profile
The UML offers the extension mechanism profiles to enable tailoring its use for a specific domain by means of a specialization with concrete, specific semantics and notations. UML profiles provide language extensions that specialize the meta-model of the UML and render its semantics and notations more precisely. However, UML profiles restrict this extension to UML to specializations of already existing UML language concepts. In essence, the model developed with a specific application still remains a compatible and valid UML model. This allows such models to be described and to be used through various existing UML tools. To develop a UML profile, concepts of the language have to be aligned to the UML concepts. The specialties of the language concepts have to be modeled in stereotypes, expressed through constraints, tagged values as well as additional notations and semantics. The main challenge for each language concept of the UML profile is to identify the most specific UML concept that still generalizes the original language concept, extend it and possibly constrain.
Furthermore, the UML Superstructure imposes several requirements for a profile. In the following, a brief overview on the most relevant requirements is given. The complete list of requirements can be found in the UML Superstructure document. First, a profile is not allowed to contradict with the already defined semantics of the extended model elements in the UML metamodel. The specialized model elements introduced by a profile shall only introduce more well-defined rules and may give additional constraints. They shall also not contradict with the constraints given in the metamodel. Of course, a profile shall enable the model repository interchange by means of XML datagram interchange between various modeling tools. UML profiles should allow to be applied and retracted from a model without rendering the model ill-formed.