UML-Profil
Ein UML-Profil ist der standardisierte Erweiterungsmechanismus der UML: Über Stereotypen, Tagged Values und Constraints erhalten generische Modellelemente eine domänenspezifische Bedeutung, ohne die Sprache selbst zu verändern oder das Modellierungswerkzeug zu ersetzen. Profile machen aus der Allzwecksprache UML eine präzise, auf eine Methodik zugeschnittene Modellierungssprache.
Warum Profile? Plain UML kennt die Domäne nicht
UML ist eine generische Sprache zur Beschreibung von Softwaresystemen; ihre Konzepte reichen daher selten aus, um domänenspezifische Aspekte auszudrücken. Ein typisches Beispiel aus der Embedded-Entwicklung: Mikrocontroller-Software wird mit UML modelliert, doch einem einfachen UML-Element lässt sich nicht mitteilen, dass es einen OS-Task repräsentiert, der von einem Ereignis mit einer bestimmten Zyklusperiode ausgelöst wird. Soll ein Code-Generator aus dem Modell Code erzeugen, muss er aber genau das wissen: Welche Klasse ist ein OS-Task und welche nicht?
Die drei Bausteine eines Profils
| Baustein | Funktion | Beispiel |
|---|---|---|
| Stereotyp | Weist einem UML-Element (Klasse, Signal, Assoziation …) eine domänenspezifische Bedeutung zu, notiert in Guillemets | «Task» auf einer Klasse, «CyclicEvent» auf einem Signal |
| Tagged Value | Zusätzliche Eigenschaft eines Stereotyps, als Attribut oder Referenz modelliert | period eines zyklischen Events, triggers als Referenz auf den ausgelösten Task |
| Constraint | Regel, die profilierte Modelle einhalten müssen und die die Methodik strukturell erzwingt | Jedes «CyclicEvent» muss genau einen Task referenzieren |
Ein konkretes Beispiel: OS-Tasks und zyklische Events
Ein Profil OS definiert den Stereotyp Task (anwendbar auf UML-Klassen) und den Stereotyp CyclicEvent (anwendbar auf UML-Signale). Tagged Values wie period und triggers sind als Attribute bzw. Referenzen der Stereotypen modelliert. Im profilierten Modell trägt jedes Element seinen Stereotyp, die Bedeutung ist explizit: Ein Code-Generator kann prüfen, ob ein Element den Stereotyp OS::CyclicEvent trägt, dessen Tagged Value period auslesen und die Referenz auf den ausgelösten Task auflösen. Daraus erzeugt er gezielt Code für genau diese Semantik. Das ist der Kern der modellgetriebenen Softwareentwicklung mit profilierter UML.
Abgrenzung: Profil oder eigenes Metamodell?
Ein Profil ist die leichtgewichtige Erweiterung: Es spezialisiert vorhandene UML-Konzepte, das Modellierungswerkzeug, die Toolchain und das Know-how der Modellierer bleiben erhalten. Die Alternative ist eine eigene domänenspezifische Sprache mit eigenem Metamodell; sie lohnt sich, wenn die Domäne strukturell nicht zu den UML-Abstraktionen passt. Beide Wege kommen in der Praxis vor: In Projekten mit einem Automotive-Tier-1-Zulieferer und einem Medtech-Unternehmen wurde nach der Domänenanalyse bewusst auf eine eigene DSL verzichtet und stattdessen UML mit projekteigenem Profil eingesetzt. Auch prominente Standards belegen die Tragfähigkeit des Mechanismus: SysML v1 ist als UML-Profil definiert (SysML v2 nutzt dagegen ein eigenes Metamodell), und AUTOSAR-Methodiken werden verbreitet auf UML-Basis mit domänenspezifischen Stereotypen umgesetzt.
UML-Profile in der Praxis
Modellierungswerkzeuge wie Enterprise Architect, CATIA Magic (ehemals MagicDraw) oder IBM Rhapsody verwalten Profile als wiederverwendbare Pakete, in Enterprise Architect etwa als Teil sogenannter MDG-Technologien; die Modellierer wenden die Stereotypen direkt im gewohnten Werkzeug an. Der eigentliche Wert entsteht jedoch erst, wenn die Profilinformation maschinell ausgewertet wird: durch Validierung gegen die Constraints der Methodik oder durch Generatoren, die aus Stereotypen und Tagged Values Code und Konfigurationsartefakte ableiten. Dafür müssen nachgelagerte Werkzeuge die Profile beim Laden der Modelle auflösen; die EA-Bridge etwa lädt profilierte Enterprise-Architect-Modelle einschließlich Stereotypen und Tagged Values für die Weiterverarbeitung. Ein Profil, dessen Stereotypen niemand auswertet, ist dagegen nur Dekoration: Die Methodik steht dann auf dem Papier, nicht im Werkzeug.