Erweiterungsmechanismen von UML

Anfang der 90er Jahre des 20. Jahrhunderts entwickelten sich eine Vielzahl popul¨arer, ob-jektorientierter Modellierungssprachen. Die wichtigsten waren die Object Modeling Techni-que (OMT) [RBL⁺90] von James Rumbaugh, die Booch Method [Boo93] von Grady Booch und der Object-Oriented Software Engineering-Ansatz (OOSE) [JCJO92] von Ivar Jacobson.

Die Object Management Group (OMG) erkannte die erforderliche Vereinheitlichung der ver-schiedenen Modellierungsans¨atze und startete daher 1996 einen Request for Proposal (RFP) zur Entwicklung einer einheitlichen und universell einsetzbaren objektorientierten Modellie-rungsmethode [OMG96]. Daraus entwickelte sich die Unified Modeling Language (UML), die momentan in der Version 1.5 [OMG03d] vorliegt. Derzeit befindet sich die Version 2.0 von

4 Ein Ansatz f¨ur ein modellbasiertes Service Level Management

UML in der Standardisierung, wobei diese momentan als Adopted Specification vorliegt. In UML 2.0 wurde eine Aufteilung des Standards in die Infrastruktur [OMG03g] (grundlegende Sprachkonstrukte, wie z.B. Datentypen) und die Super-Struktur [OMG03h] (Sprachelemente f¨ur den Endbenutzer, z.B. Klassen und Assoziationen) vorgenommen.

Zur Beschreibung der Unified Modeling Language spezifiziert die OMG das als Meta Object Facility (MOF) [OMG02a] bezeichnete System, bei dem UML durch eine vierstufige Hierar-chie von Modellen und Metamodellen beschrieben wird:

• M0 (information layer): beschreibt das laufende System und ist Instanz von M1, z.B.

Kunde ’XYZ Inc.’,Anbieter ’ACME Corp.’, . . .

• M1 (model layer): beschreibt das Design des Systems und verwendet dazu Instanzen der Elemente von M2, z.B.Class ’Kunde’,Class ’Anbieter’, . . .

• M2 (metamodel layer): das Metamodell setzt sich aus Instanzen von M3 zusammen und definiert die Typen der Elemente in M1, z.B. UML Class, UML Attribute, UML Association, . . .

• M3 (meta-metamodel layer): definiert eine Menge von Elementen zur Beschreibung von Metamodellen, z.B.MOF Class,MOF Attribute,MOF Association, . . . Da UML eine generische Modellierungssprache ist, die nicht auf eine spezielle Anwendungs-dom¨ane oder Technologie festgelegt ist, definiert UML lediglich allgemeing¨ultige Modellele-mente, wie z.B. Klassen und Assoziationen, mit denen Modelle gebildet werden k¨onnen. Um spezielle Anforderungen einer Dom¨ane und/oder Technologie hinreichend erf¨ullen zu k¨onnen, bietet UML eine Reihe von Erweiterungsmechanismen, auf die im Folgenden eingegangen wird:

• Stereotypen (Stereotypes),

• Eigenschaftswerte (Tagged Values),

• Einschr¨ankungen (Constraints),

• Profile (Profiles),

• Metamodelle (Metamodels).

Im Rahmen der Model Driven Architecture sind diese Erweiterungsmechanismen notwen-dig, um UML an spezielle Problemdom¨anen anpassen zu k¨onnen und Code-Generatoren da-mit hinreichend semantische Informationen f¨ur automatisierte Modelltransformationen zu bie-ten.

4.1 Grundlagen der Model Driven Architecture

Stereotypes

Das Konzept der Stereotypes (Stereotypen) erlaubt die Erweiterung beliebiger UML-Elemente.

Durch Zuweisung eines Stereotypen werden einem Metamodell-Element (siehe M3) eine neue Bedeutung zugewiesen und die zur Verf¨ugung stehenden UML-Elemente erweitert. Im Zu-sammenhang mit Stereotypen spricht man auch von der Definition von virtuellen Unterklassen von UML-Metamodell-Klassen. Da Stereotypen selbst UML-Metaklassen darstellen, kann ein Anwender neue Stereotypen erzeugen und diese w¨ahrend der Modellierung anderen Modell-elementen zuweisen.

Mit Hilfe von Stereotypen k¨onnen Anforderungen bestimmter Anwendungsdom¨anen oder spezieller Technologien in UML beschrieben werden. Beispielsweise kann eine Komponente durch die Zuweisung eines CORBA Stereotypen als CORBA-Objekt deklariert werden, wohingegen eine andere Komponente durch Zuweisung einesEJB Stereotypen als En-terprise Java Bean identifiziert wird.

Von besonderer Bedeutung sind Stereotypen, wenn UML-Modelle von Werkzeugen weiterbe-arbeitet werden m¨ussen, wie dies in der Model Driven Architecture der Fall ist. Beispielsweise ist ein Code-Generator durch die Verwendung von Stereotypen in der Lage, Code f¨ur unter-schiedliche Zielplattformen zu generieren.

Stereotypisierte Elemente k¨onnen zus¨atzlich durch Tagged Values und Constraints erweitert werden.

Tagged Values

Tagged Values (Eigenschaftswerte) erweitern UML-Elemente um zus¨atzliche Attribute, die als (Name, Wert)-Paare repr¨asentiert werden. Hierbei definiert das Tag den Namen des Attributs, der als String repr¨asentiert wird. Als Wert des Tags sind sowohl einfache Datentypen zul¨assig, wie z.B. Integer, String und Boolean, als auch Referenzen zu allen anderen UML-Modellelementen.

UML spezifiziert bereits eine Menge vordefinierter Tagged Values. So besitzt beispielsweise das UML-ElementClassunter anderem das Tagged ValueisAbstract, welches definiert, ob von der Klasse eine Instanz erzeugt werden kann oder nicht.

Die Interpretation der Tagged Values ist nicht als Teil der UML-Spezifikation festgelegt, son-dern obliegt weiterverarbeitenden Werkzeugen, wie beispielsweise Code-Generatoren.

Tagged Values k¨onnen auch verwendet werden, um zus¨atzliche Eigenschaften von Stereoty-pen zu definieren. Hierbei hat auch jedes stereotypisierte UML-Element die entsprechenden Eigenschaften.

4 Ein Ansatz f¨ur ein modellbasiertes Service Level Management

Constraints

Ein Constraint (Einschr¨ankung) definiert ein Pr¨adikat ¨uber einem Modellelement, das des-sen semantische Variationsbreite einschr¨ankt. Constraints k¨onnen allen UML-Elementen ein-schließlich Stereotypen zugewiesen werden.

Die Formulierung von Constraints ist nicht festgelegt. Sie k¨onnen sowohl in nat¨urlicher Spra-che, in maschinenlesbarer Form oder auch in einer formalen Repr¨asentierung wie beispiels-weise der Object Constraint Language (OCL) [OMG03j] formuliert werden. F¨ur eine werk-zeugunterst¨utzte Verarbeitung von Constraints ist die Verwendung einer formalen Repr¨asen-tierung wie OCL notwendig.

Constraints, die einem Stereotypen zugeordnet sind, gelten f¨ur alle UML-Elemente, denen dieser Stereotyp zugewiesen ist.

Profiles

Ein Profile (Profil) stellt eine Menge von UML-Erweiterungselementen (Constraints, Tagged Values, Stereotypes) dar, die f¨ur einen speziellen Anwendungskontext definiert sind. Ein Profil wird auch als virtuelles Metamodell (virtual metamodel) [Fra03] bezeichnet.

Die Erweiterung von UML mit Hilfe von Profiles unterliegt einigen Einschr¨ankungen. So k¨onnen bestehende Metamodelle in ihrer Struktur nicht ver¨andert werden, sondern k¨onnen lediglich f¨ur einen bestimmten Kontext adaptiert werden. Allerdings muss die Semantik al-ler im Profile definierten Elemente konform zur Semantik des zu adaptierenden Metamodells sein. Dies bedeutet, dass alle Erweiterungen additiv zur Semantik der existierenden UML-Metamodell-Elemente sind. Aufgrund dieser Einschr¨ankungen wird ein Profile auch als light-weight built-in extension mechanism [OMG03d] bezeichnet.

Die OMG spezifiziert eine Reihe von Profilen zur Adaption von UML an bestimmte Anwen-dungsdom¨anen:

• UML Profile for CORBA [OMG02c]: Das Profile definiert Elemente, um die Seman-tik von Schnittstellen, die in CORBA IDL definiert sind, mittels UML beschreiben zu k¨onnen.

• UML Profile for Enterprise Application Integration (EAI) [OMG04g]: Definition eines Standards zum Austausch von Metadaten ¨uber den Zugriff auf Anwendungsschnittstel-len. Ziel ist die vereinfachte Integration von Anwendungen durch die Standardisierung der Metadaten.

• UML Profile for Enterprise Distributed Object Computing (EDOC): Dieses komple-xe Profil definiert Elemente zur Modellierung von Komponenten-basierten Enterprise-Applikationen. Das Profile ist sehr umfangreich und besteht aus sieben einzelnen

4.1 Grundlagen der Model Driven Architecture

Spezifikationen: [OMG04b] [OMG04d] [OMG04c] [OMG04i] [OMG04f] [OMG04h]

[OMG04j].

• UML Profile for Schedulability, Performance, and Time Specification [OMG03k]: De-finition von Standardparadigmen zur Modellierung von Zeit-, Schedulability- und Performance-bezogenen Aspekten von Echtzeitsystemen.

• UML Testing Profile [OMG03i]: Definition von Elementen zur Modellierung von Test-Systemen.

Metamodelle

Die Verwendung der Meta Object Facility (MOF) [OMG02a] erm¨oglicht die beliebige Modifi-kation von UML-Metamodellen. Mittels MOF kann die Semantik aller Metamodell-Elemente ver¨andert werden. Weiterhin k¨onnen beliebige Elemente hinzugef¨ugt bzw. entfernt werden;

das gleiche gilt f¨ur Assoziationen zwischen den Metamodell-Elementen. Daher wird die Er-weiterung mittels MOF auch als heavyweight extension [OMG03d] bezeichnet.

Von der OMG werden derzeit drei Metamodelle standardisiert:

• Common Warehouse Metamodel [OMG03a]: Definition von standardisierten Schnitt-stellen f¨ur den einfachen Austausch von Metadaten zwischen Data Warehouse Werk-zeugen in verteilten heterogenen Umgebungen

• CWM Metadata Interchange Patterns [OMG03b]: Definition eines semantischen Kon-texts f¨ur ausgetauschte Metadaten

• Software Process Engineering Metamodel [OMG02b]: Metamodell zur Beschreibung von Software-Entwurfsprozessen