UML Profile
A UML profile is the standardized extension mechanism of UML: through stereotypes, tagged values and constraints, generic model elements are given a domain-specific meaning without changing the language itself or replacing the modeling tool. Profiles turn the general-purpose language UML into a precise modeling language tailored to a methodology.
Why profiles? Plain UML does not know the domain
UML is a generic language for describing software systems; its concepts are therefore rarely sufficient to express domain-specific aspects. A typical example from embedded development: microcontroller software is modeled with UML, but there is no way to tell a plain UML element that it represents an OS task triggered by an event with a specific cycle period. If a code generator is to produce code from the model, however, it needs to know exactly that: which class is an OS task and which is not?
The three building blocks of a profile
| Building block | Function | Example |
|---|---|---|
| Stereotype | Assigns a domain-specific meaning to a UML element (class, signal, association …), noted in guillemets | «Task» on a class, «CyclicEvent» on a signal |
| Tagged value | Additional property of a stereotype, modeled as an attribute or reference | period of a cyclic event, triggers as a reference to the triggered task |
| Constraint | Rule that profiled models must comply with and that structurally enforces the methodology | Every «CyclicEvent» must reference exactly one task |
A concrete example: OS tasks and cyclic events
A profile OS defines the stereotype Task (applicable to UML classes) and the stereotype CyclicEvent (applicable to UML signals). Tagged values such as period and triggers are modeled as attributes or references of the stereotypes. In the profiled model, every element carries its stereotype and the meaning is explicit: a code generator can check whether an element carries the stereotype OS::CyclicEvent, read its tagged value period and resolve the reference to the triggered task. From this, it generates code specifically for exactly this semantics. This is the core of model-driven software development with profiled UML.
Profile or dedicated metamodel?
A profile is the lightweight extension: it specializes existing UML concepts, and the modeling tool, the toolchain and the modelers’ know-how are preserved. The alternative is a dedicated domain-specific language with its own metamodel; it is worthwhile when the domain structurally does not fit the UML abstractions. Both approaches occur in practice: in projects with an automotive tier-1 supplier and a medtech company, a dedicated DSL was deliberately not pursued after the domain analysis, and UML with a project-specific profile was used instead. Prominent standards also demonstrate how far the mechanism carries: SysML v1 is defined as a UML profile (SysML v2, by contrast, uses its own metamodel), and AUTOSAR methodologies are widely implemented on a UML basis with domain-specific stereotypes.
UML profiles in practice
Modeling tools such as Enterprise Architect, CATIA Magic (formerly MagicDraw) or IBM Rhapsody manage profiles as reusable packages, in Enterprise Architect for example as part of so-called MDG technologies; modelers apply the stereotypes directly in their familiar tool. The real value, however, only arises when the profile information is evaluated by machines: through validation against the constraints of the methodology, or through generators that derive code and configuration artifacts from stereotypes and tagged values. For this, downstream tools must resolve the profiles when loading the models; the EA Bridge, for example, loads profiled Enterprise Architect models including stereotypes and tagged values for further processing. A profile whose stereotypes nobody evaluates is mere decoration: the methodology then exists on paper, not in the tool.