UML-Spezifikation der OMG

Verwendung der UML in Innovator

Innovator for Software Architects stellt Ihnen Modellvorlagen mit speziellen Profilen zur Verfügung, die den Standard "Unified Modeling Language" (UML) der Object Management Group (OMG) umsetzen. Auch andere Innovator-Produkte nutzen einige Elemente der UML (z.B. Klassen, Anwendungsfälle).

Auf einige wesentliche Aspekte der UML-2-Spezifikation wird im Folgenden eingegangen, um insbesondere die Überführung dieser Konstrukte in die Innovator-Profile deutlich zu machen.

Sie erfahren,

• wie die UML-Spezifikation der OMG aufgebaut ist

• welche Basiskonstrukte im UML-2-Metamodell verwendet werden

• wie Modell und Paket definiert sind

• wie Elemente und Beziehungen semantischen Ebenen zugeordnet sind

• wie der Erweiterungsmechanismus mit Profilen definiert ist

Aufbau

Die UML-2-Spezifkation der OMG besteht aus zwei Dokumenten:

• "Infrastructure" ist ein MOF-2-konformes Metamodell für die UML 2
• "Superstructure" definiert die Syntax und Semantik der Modellelemente der UML 2

Zusätzlich tangiert dieses Dokumente direkt die UML:

• "Object Constraint Language (OCL)" definiert, wie Restriktionen in den drei anderen Dokumenten formal ausgedrückt werden

Für die Konfiguration von Profilen ist es unabdingbar, sich mit dem Dokument "Superstructure" auseinanderzusetzen. Die anderen Dokumente werden hier nicht betrachtet.

Die wichtigsten Konzepte der Spezifikation "UML 2 Superstructure" sollen an dieser Stelle in Kurzform erwähnt werden. Im Folgenden werden Auszüge aus der offiziellen Spezifikation "OMG Unified Modeling Language (OMG UML), Superstructure, V2.4.1" (OMG Document Number: formal/2011-08-06) verwendet, die – wann immer möglich – wortwörtlich ins Deutsche übersetzt wurden.

Die folgende Abbildung zeigt die Bereiche, die durch den aktuellen UML-Standard abgedeckt werden, und wie diese zueinander in Beziehung stehen. Die Bereiche in den höher liegenden Schichten sind von den Bereichen in den unteren Schichten abhängig, aber nicht umgekehrt.

Abbildung: Schema der semantischen Bereiche der UML (UML Superstructure V2.4.1, Figure 6.1)

Auf der höchsten Abstraktionsstufe lassen sich drei voneinander getrennte Schichten unterscheiden:

• Das Fundament der Hierarchie beschreibt den statischen Teil eines Modells mit Hilfe von "structural entities" (dt. "Struktureinheiten"). Dies trägt der grundsätzlichen Annahme Rechnung, dass es in der UML kein freidefinierbares Verhalten ("disembodied behaviour") gibt – jegliches Verhalten resultiert aus den Aktionen der Struktureinheiten.

  Diese Schicht wird in den vier Kapiteln von Teil I beschrieben:

  • "Classes" (dt. "Klassen")

  • "Components" (dt. "Komponenten")

  • "Composite Structures" (dt. "Kompositionsstrukturen") und

  • "Deployments" (dt. "Verteilungen")

• Die darüber liegende Schicht ist dynamischer Natur und stellt die Grundlage für die semantische Beschreibung aller komplexeren Verhaltensmuster dar. Diese Schicht besteht aus drei getrennten Bereichen, die wiederum zu zwei Unterschichten zusammengefasst sind:

  • Die untere Schicht wird aus der "inter-object behavior base" (mit der die Kommunikation zwischen mehreren Struktureinheiten beschrieben werden kann) und der "intra-object behavior base" (in der es um die Kommunikation innerhalb einer einzelnen Struktureinheit geht) gebildet. Diese Schicht wird im Kapitel "Common Behavior" (dt. "Allgemeines Verhalten") von Teil II beschrieben.

  • Die Schicht "actions" definiert die Semantik einer Reihe von Aktionen. Aktionen stellen die elementarsten Einheiten dar, mit denen in der UML ein Verhalten definiert werden kann. Diese Schicht wird im Kapitel "Actions" (dt. "Aktionen") von Teil II beschrieben.

• Die oberste Hierarchieebene definiert die Semantik der höherwertigen Verhaltensmodelle der UML: "activities", "state machines" und "inter-actions". Diese Schicht wird in drei Kapiteln von Teil II beschrieben:

  • "Activities" (dt. "Aktivitäten")

  • "Interactions" (dt. "Interaktionen") und

  • "State Machines" (dt. "Zustandsautomaten")

Das Kapitel "Use Cases" (dt. "Anwendungsfälle") ist in der UML ebenfalls dem Verhaltensteil zugeordnet, obwohl die einzelnen Konstrukte deutlich statischen Charakter haben.

Der dritte Teil (Part III) der Spezifikation schließlich befasst sich mit unterstützenden Konstrukten (Modelle, Profile).

Basiskonstrukte

Das "Kernel"-Paket (aus der untersten Schicht) enthält das Kernkonzept für die Modellierung in UML. Darin enthalten sind Konstrukte wie z.B. Klassen, (gerichtete oder ungerichtete) Beziehungen und Pakete. In vielen Fällen werden diese Basiskonstrukte später spezialisiert und mit zusätzlichen Merkmalen und Beziehungen versehen.

Abbildung: Wurzeldiagramm des Kernpakets (Root diagram of the Kernel package, UML Superstructure V2.4.1, Figure 7.3)

Multiplizitätsdiagramm des Kernpakets (Multiplicities diagram of the Kernel package, UML Superstructure V2.4.1, Figure 7.5)

Sehr viele der Beziehungen zwischen UML-2-Metaklassen sind Spezialisierungen der beiden elementaren Beziehungen "ownedElement" oder "source" bzw. "target" aus dem gezeigten Ausschnitt des Kernpakets. Spezielle "ownedElement"-Beziehungen finden sich zwischen nahezu beliebigen Metaklassen, "source"- bzw. "target"-Beziehungen werden hingegen bei der jeweiligen Ausprägung einer gerichteten Beziehung konkretisiert.

Es gibt noch weitere generische Beziehungen, wie z.B. die "type"-Beziehung zwischen den beiden abstrakten Metaklassen "TypedElement" (darunter fallen u.a. Attribute und Parameter) und "Type" (darunter fallen alle "Classifier", d.h. klassenähnliche Metaklassen, wie etwa Komponenten, Schnittstellen etc.).

Modelle und Pakete

Ein Modell ist eine abstrahierte Sicht auf ein physisches System unter einem ganz bestimmten Blickwinkel und für einen definierten Zweck. Dieser Zweck entscheidet darüber, welche Informationen in einem Modell enthalten sind, und was umgekehrt für dieses Modell irrelevant ist. Ein Modell ist in dem Sinne vollständig, dass es das physische System vollständig darstellt, wobei eben nur die für den jeweiligen Zweck relevanten Aspekte mit der gebotenen Detailgenauigkeit gezeigt werden.

Die in einem Modell enthaltenen Elemente lassen sich in drei Hauptkategorien einteilen: Classifier, Ereignisse und Verhalten. Jede Hauptkategorie abstrahiert bestimmte "Individuen" aus einer Implementierung des modellierten Systems:

• Ein Classifier beschreibt eine Menge von gleichartigen Objekten; jedes Objekt ist dabei ein individuelles "Ding", das einen Zustand und Beziehungen zu anderen Objekten hat.

• Ein Ereignis beschreibt eine Menge möglicher Vorfälle; jeder Vorfall ist dabei etwas, das "passiert" und das bestimmte Konsequenzen innerhalb dieses Systems hat.

• Ein Verhalten beschreibt eine Menge möglicher Ausführungen; jede Ausführung ist dabei die Durchführung eines Algorithmus im Rahmen von vorgegebenen Regeln.

Der Inhalt eines Modells wird hierarchisch organisiert, wobei das Toplevel-Paket (das Subsystem) die Grenze des physischen Systems markiert.

Ein Modell darf auch Elemente enthalten, die wichtige Teile der Systemumgebung repräsentieren (Diese Umgebung wird oft mit Hilfe von Akteuren und Schnittstellen dargestellt).

Weil diese Elemente aus Sicht des physischen Systems aber jenseits der Systemgrenze liegen, werden sie außerhalb der Pakethierarchie abgelegt. Wahlweise liegen sie dann unmittelbar im Modell selbst, oder sie werden in einem separaten Paket gesammelt.

Ein Systemmodell ist in der UML ein stereotypisiertes Modell (zu Stereotypen siehe unten), das verschiedene Modelle des gleichen physischen Systems enthält.

Abbildung: Paketdiagramm des Kernpakets, Ausschnitt (The Packages diagram of the Kernel package, detail, UML Superstructure V2.4.1, Figure 7.14)

Ein Paket wird benutzt, um Elemente zu gruppieren, und stellt einen gemeinsamen Namensraum für diese Elemente bereit. Der Inhalt eines Pakets besteht aus sogenannten "paketierbaren Elementen", dazu gehören Klassen, Ereignisse u.v.a., aber auch Pakete selbst, was eine hierarchische Anordnung von Paketen ermöglicht. Ein Paket ist der Besitzer dieser Elemente, was zur Folge hat, dass alle enthaltenen Elemente aus einem Modell gelöscht werden, sobald dieses Paket gelöscht wird.

Semantische Ebene

Die Mehrzahl der UML-2-Metaklassen lässt sich einer von vier semantischen Ebenen zuordnen. Beziehungen zwischen Metaklassen gehen zwar oft über die Grenzen der beschriebenen Kategorien (Classifier, Ereignisse, Verhalten) hinaus, liegen in der Regel aber innerhalb der gleichen semantischen Ebene.

Die Typebene repräsentiert generische Entitätstypen, wie z.B. Klassen, Zustände, Aktivitäten, Ereignisse etc. Ein Modell wird hauptsächlich aus Elementen dieser semantischen Ebene bestehen.

In der Instanzebene findet man diejenigen Elemente der Laufzeitumgebung, die durch ein Modell abstrahiert werden. Obwohl diese Elemente durchaus dem Modellbegriff genügen würden, gibt es im UML-2-Metamodell oder in UML-2-Modellen keine entsprechenden Metaklassen (Die Instanzebene beschreibt im Gegensatz zu den übrigen Ebenen den MOF-Level 0 und nicht den Level 1 und gehört deshalb nicht zur UML-2-Spezifikation.)

Wertspezifikationen. Die Spezifikation eines Werts ist nicht notwendigerweise eine Instanz, es kann sich genauso gut um eine größere Menge von Instanzen handeln, die jede für sich der Spezifikation genügen. In Modellen gibt es daher üblicherweise gar keine Instanzen, sondern stattdessen Wertspezifikationen (die dann evtl. nur einen einzigen Wert erlauben). UML-2-Modelle enthalten aus diesem Grund immer nur Spezifikationen von Werten und nie die Werte selbst, die erst zur Laufzeit existieren.

Individuelle Verwendung eines Typs innerhalb eines Kontextes. Diese Ebene beschreibt Rollen in einem generischen, wiederverwendbaren Kontext. In einer Instanz dieses Kontextes sind sie zwar an die darin enthaltenen Instanzen gebunden, aber für sich betrachtet handelt es sich um wiederverwendbare strukturelle Bestandteile ihres Kontextes und gerade eben nicht um Instanzen selbst.

Durch eine (weitgehend) konsistente Benennung der Metaklassen wurde seitens der OMG versucht, die Zugehörigkeit eines Elements bzw. einer Beziehung zu einer der vier Semantikebenen herauszustellen.

Tabelle: Beispiele für Metaklassen in den Semantikebenen der UML 2

Typebene	Instanzebene	Wertspezifikation	Verwendung
Classifier, Klasse	Instanz, Objekt	Instanzspezifikation	Rolle, Attribut etc.
Ereignis	Vorfall	Vorkommensspezifikation	unterschiedlich (z.B. Trigger)
Verhalten	Ausführung	Ausführungsspezifikation	Referenz (z.B. Interaktionsreferenz), aber nicht einheitlich (z.B. auch Aktivitätsknoten)

Erweiterungsmechanismus der UML