Das Metamodell der UML – Grammatik für Modellierer

Im vorherigen Artikel unserer Blogserie haben wir Ihnen, das Metamodell Requirements Interchange Format (ReqIF) zur Übermittlung von Dokumenten anhand eines konkreten Beispiels vorgestellt.

In vorerst abschließenden Teil unserer Blogserie, möchten wir Ihnen ein weiteres Metamodell, das Metamodell der Unified Modeling Language (UML), und dessen Anwendungsgebiete im Bereich des Requirements-Engineering vorstellen.

Doch was ist eigentlich die Unified Modeling Language?

Die UML ist heutzutage die verbreiteteste Notation, um Systeme, speziell Softwaresysteme zu analysieren und zu entwerfen. Sie dient der Modellierung, Dokumentation, Spezifizierung und Visualisierung komplexer Systeme, unabhängig von deren Fach- und Realisierungsgebiet. Die UML liefert die Notationselemente gleichermaßen für die statische und dynamische Sichtweise zur Analyse, zum Design und für die Architektur und unterstützt insbesondere objektorientierte Vorgehensweisen während der Entwicklung. [1]

Was steckt hinter dem Metamodell der UML?

Vergleichen wir die UML doch einmal mit der natürlichen Sprache, wie wir sie jeden Tag verwenden. In der natürlichen Sprache gibt es Regeln, wie ein grammatikalisch korrekter Satz aufgebaut sein muss. Ähnlich beschreibt das Metamodell der UML Regeln zum Aufbau eines formal korrekten Modells und dient damit als Basis zur Modellierung.

Das UML-Metamodell beschreibt die abstrakte Syntax, die statische Semantik sowie die dynamische Semantik der UML. Die Syntax wird hierbei durch UML-Diagramme dargestellt. Die statische Semantik wird mit Hilfe der Object Constraint Language (OCL) und durch natürliche Sprache beschrieben. Die OCL dient z.B. dazu, die Beschränkung eines Attributs auf einen Wertebereich zu beschreiben. Die dynamische Semantik beschreibt, in natürlicher Sprache, das Verhalten einzelner UML-Elemente und deren Zusammenspiel. Wird bswp. bei einer Komposition das Ganze gelöscht, werden auch seine Teile gelöscht. [2]

Anhand eines Beispiels möchten wir Ihnen das UML-Metamodell etwas erläutern. Nehmen wir einen Auszug eines Use-Case-Diagramms des Systems „Onlineshop“ (Abb.1). Ein Kunde kann seine „Kundendaten ändern“. Dieser Schritt beinhaltet immer den Schritt „Berechtigung prüfen“ d.h. dass der Use-Case „Kundendaten ändern“ den Use-Case „Berechtigung prüfen“ inkludiert. Genauer gesagt, während der Use-Case „Kundendaten ändern“ abläuft, wird in einem Ablaufschritt der Use-Case „Berechtigung prüfen“ aufgerufen und ausgeführt.

 UseCaseBeispielAbb. 1 Use-Cases mit Include-Beziehung

In Abb. 1 sieht man die konkrete Modellierung der Include-Beziehung zwischen den beiden genannten Use-Cases. Nun betrachten wir den für dieses kleine Modell relevanten Auszug aus dem UML-Metamodell.

AuszugMetamodellUseCasesAbb. 2 Auszug aus dem UML-Metamodell

Wie gehören diese beiden Modelle zusammen?

Der in Abb. 2 dargestellte Auszug aus dem UML-Metamodell zeigt, dass ein „UseCase“ eine Spezialisierung eines „BehavioredClassifier“ ist, wobei ein „BehavioredClassifier“ ein Verhalten definiert bzw. Verhaltensvariationen zusammenfasst. Das bedeutet, bezogen auf einen „UseCase“, dass dieser ein Set an Aktionen bündelt, die das zugeordnete „subject“ ausführt und die in einem beobachtbaren Ergebnis resultieren.

Der „Actor“ ist ebenfalls ein spezialisierter „BehavioredClassifier“ und beschreibt eine Rolle, die von einem Benutzer oder einem externen System eingenommen wird und welche mit dem betrachteten System interagiert. In unserem Beispiel ist der Akteur der „Kunde“. Die Assoziation zwischen „Kunde“ und „Kundendaten ändern“ ist in Abb. 2 nicht dargestellt, sie resultiert daraus, dass „Classifier“ Beziehungen untereinander haben können.

Wie bereits erwähnt, kann ein „Classifier“ in der Rolle „subject“ beliebig viele „UseCase“ realisieren, dargestellt durch die Assoziation „useCase – subject“. In unserem Beispiel realisiert das Subjekt „Onlineshop“ die beiden Use-Cases „Kundendaten prüfen“ und „Berechtigung prüfen“. Außerdem kann ein „Classifier“ als Eigentümer beliebig vieler Use-Cases durch die Komposition „classifier – ownedUseCase“ dienen.

Betrachten wir nun die Include-Beziehung aus Abb.1. Ein „Include“ besitzt eine gerichtete Assoziation zu „UseCase“, welche den inkludierten „UseCase“ als „addition“ darstellt. In unserem Beispiel ist „Berechtigung prüfen“ die „addition“. Die Komposition zwischen „Include“ und „UseCase“ referenziert den inkludierenden Use-Case als „includingCase“, in unserem Fall also „Kundendaten ändern“.

Das war nur ein sehr kleiner Auszug aus dem Metamodell der UML zu Use-Case-Diagrammen [2] erklärt an einem kleinen Beispiel. Die Definition der weiteren Diagrammarten bspw. Aktivitäts- und Klassendiagramme ist ähnlich gestaltet. Sollten Sie sich in Ihrem Projekt einmal unsicher zur Verwendung eines bestimmter Modellierungselemente sein, liefert Ihnen das UML-Metamodell definitiv die korrekte Verwendung – oder Sie wenden sich vertrauensvoll an uns bzw. nutzen unser Buch „UML 2 glasklar – Praxiswissen für die UML-Modellierung“.

Das war vorerst der letzte Artikel dieser Blogserie, aber Sie sollten unseren Blog weiterhin verfolgen, um über neue Erkenntnisse und Ergebnisse zur Forschungsarbeit unseres Beraters Alexander Rauh informiert zu sein. Also bleiben Sie uns treu!

Viele Grüße!
Ihre SOPHISTen

Quellen:

[1] Chris Rupp, Stefan Queins & die SOPHISTen: UML 2 glasklar – Praxiswissen für die UML-Modellierung, 4. Auflage, Hanser, 2012

Mehr Informationen zu dem Buch finden Sie unter:
https://www.sophist.de/publikationen/uml-2-glasklar/

[2] Object Management Group, Inc. (2013): UML® Resource Page. Online verfügbar unter http://www.uml.org/, zuletzt geprüft am 31.03.2016

Teil 1: Die SOPHISTen forschen wieder
Teil 2: Metamodelle – Beschreiben und Verstehen eines Modells
Teil 3: ReqIF – Struktur in Spezifikationen mal anders
Teil 4: Dokumentierst du noch oder übermittelst du schon? – Spezifikationen kommunizieren mittels ReqIF