UML-Spezifikation der OMG

Generell werden für die Konfiguration von Innovator-Modellen Prinzipien und Elemente des Standards "Unified Modeling Language" (UML) der Object Management Group (OMG) verwendet. Um diese Modelle zielgerichtet unternehmens- oder projektspezifisch anpassen zu können, sind Grundkenntnisse über die UML-2-Spezifikation der OMG unabdingbar.

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 Dokument 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

Profil

Das "Profile"-Paket der UML 2 enthält Mechanismen, die es erlauben, Metaklassen für bestimmte Zwecke zu erweitern.

Abbildung: Elemente des Profilpakets (The elements defined in the Profiles package, UML Superstructure V2.4.1, Figure 18.2)

Profile sind dazu gedacht, einen generischen Mechanismus bereitzustellen, der es ermöglicht, ein existierendes Metamodell durch zusätzliche Konstrukte auf eine spezifische Domäne, Plattform oder Methodik anzupassen. Jede dieser Anpassungen wird in einem Profil zusammengefasst. Dies beinhaltet beispielsweise die Möglichkeit, das UML-Metamodell auf verschiedene Anwendungsdomänen (z.B. Business Intelligence) oder Plattformen (wie z.B. J2EE oder .NET) zuzuschneiden.

Ein Profil kann niemals losgelöst von seinem Metamodell benutzt werden. Einschränkungen, die für ein Metamodell wie die UML gelten, können durch Anwenden eines Profils nicht aufgehoben werden – ggf. werden aber zusätzliche profilspezifische Einschränkungen gültig.

Das vorrangige Konstrukt für eine solche Erweiterung ist das Stereotyp, welches auf existierende Metaklassen angewendet und als Teil eines Profils definiert wird.

Da ein Profil immer gemäß dem durch es erweiterten Metamodell definiert werden muss, ist der Freiheitsgrad einer Profildefinition von vorneherein durch verschiedene Einschränkungen ("Constraints") begrenzt.

Profilimport

Ein Profilimport ("ProfileApplication") ist in der UML 2 eine spezielle Form der gerichteten Beziehung, mit der ausgedrückt wird, dass ein Profil auf ein Paket1 angewendet wird.

Der Import eines Profils durch ein System- oder Teilmodell im Innovator-Modelleditor bedeutet, dass es möglich (aber nicht zwingend notwendig) ist, die Stereotype aus der entsprechenden Profildefinition bei der Modellierung einzusetzen.

Der Import eines Profils durch ein anderes Profil im Konfigurationseditor von Innovator bedeutet, dass die Stereotype des importierten Profils durch das importierende Profil erweitert werden können.

In beiden Fällen können mehrere Profile gleichzeitig importiert werden. Jedoch stehen beim Profilimport durch ein System- oder Teilmodell stets uneingeschränkt alle Profile für den Import zur Verfügung, während es beim Profilimport durch ein Profil stets Einschränkungen aufgrund der Unterbindung von Importzyklen gibt.
Die Einstellungen, für die mehrere Festlegungen möglich sind (z.B. Inhaltszuordnungen von Diagrammen), werden über die importierten Profile additiv aufgesammelt.
Bei widersprüchlichen Einstellungen, für die es nur eine sinnvolle Festlegung geben kann (z.B. Anzeigeoptionen), wird ausschließlich die Festlegung desjenigen (ggf. auch transitiv) importierten Profils mit der betreffenden Einstellung berücksichtigt, das in der Reihenfolge der Profile an erster Stelle steht.

Stereotyp

Ein Stereotyp ist eine Art Klasse, die andere Klassen um zusätzliche Merkmale erweitert. Genau wie eine Klasse kann auch ein Stereotyp Eigenschaften besitzen, die üblicherweise als Stereotypeigenschaften ("tag definitions") bezeichnet werden. Wird ein Stereotyp auf ein Modellelement angewendet (d.h. wird ihm dieses Stereotyp zugewiesen), spricht man bei den Werten dieser Stereotypeigenschaften auch von Eigenschaftswerten ("tagged values").

Weitere Informationen

http://www.uml.org/