UML profile
UML profiles serve to specialize the existing language scope of the Unified Modeling Language (UML) in order to be able to supplement it for modeling specific technical or business domains. Thus, there are already a number of advanced profiles that address both the specifics of certain technologies or specific application domains. In addition, the Object Management Group( OMG) industry consortium, as the institution responsible for the standardization of UML, has also defined some profiles. However, with the necessary knowledge and the unconditional observance of a few rules, any user can also define a profile. In general, UML profiles do not change the metamodel on the M2 level of the layer model defined by the OMG. The extension of the metamodel on the M1 level is rather done by reification. Thus a profile is at the same time a UML model and an extension of the metamodel.
For the realization of profiles existing extension mechanisms of the UML are used, which are also compatible with the modeling tools. Thus, UML profiles are more detailed in their semantics, but still consistent with UML semantics. It is also said that profiles extend the UML with so-called lightweight changes. This expresses the fact that the UML metamodel can be extended or restricted on the basis of given constructs. Profiles are imported and exported using XML Metadata Interchange(XMI).
The different UML profiles
The user of UML profiles must be aware beforehand that they supplement the language scope of the UML individually and that it must be ensured that other users, for example in the area of software architectures or project-related specializations, are also able to understand the profiles. The UML definition already includes two additional standard profiles. In these, for example, special types of artifacts and components are defined.
As can be seen from the figure, UML profiles are an extension in the M2 level of the UML metamodel. Similarly, for the Common Warehouse Metamodel (CWM), there are profiles to extend the scope of functionality - for example, the OLAP profile. The OMG architecture provides for deriving application-specific profiles from existing profiles. There are binding rules for creating profiles. A UML profile
- must not contradict the semantic meaning of existing UML elements,
- must itself be an exchangeable UML model,
- is composed of stereotypes, constraints as well as tagged values,
- shall represent existing relevant elements for a better overview - this can be libraries, definitions of types or models,
- shall take into account the linking of profiles to a new profile,
- may contain rules for graphical representation of stereotypes,
- shall be dynamically interchangeable as well as reusable.
For clarification again briefly the following definitions:
Stereotypes These are mechanisms with which the meaning and representation of the UML can be supplemented. They are derived from elements of the UML metamodel or from standard elements.
Tagged Values Store information about an element and are the properties of stereotypes.
Constraints Express constraints and are written in an informal language such as pseudocode or the Object Constraint Language( OCL).
As also shown in the figure, there are already a number of more advanced profiles that the user can access. In the following some examples are indicated in this connection. Here it can be seen that these address the specifics of a domain as well as a particular technology used.
- UML Profile for Enterprise Distributed Object Computing (EDOC) for platform-independent modeling of distributed enterprise applications,
- UML Profile for Enterprise Application Integration( EAI) for loosely coupled systems that communicate asynchronously or message-based,
- UML Profile for Corba/Corba Component Model( CCM) for component-based programming,
- UML Profile for CORBA for transformations related to model-driven software development,
- UML Testing Profile,
- UML Profile for QoS and Fault Tolerance,
- UML Profile for Schedulability, Performance and Time,
- Special types of systems, for example profiles for embedded systems,
- Special techniques and implementation languages, for example for . NET or specific programming languages such as C++ or Java,
- Special methods and process models, for example to support Model Driven Architecture( MDA) or to map process models such as the V-model or RUP.