Teil 1: UML-Einleitung, UML-Erweiterungsmöglichkeiten per UML-Profil, Konfiguration von MDG Technology

UML – Modellierungswerkzeuge richtig konfigurieren [Teil 1]
Keine Kommentare

Die Modellierungssprache UML gehört für viele Entwicklungsprojekte seit Jahren zum Standard. So haben auch Entwickler keine Berührungsängste mit den entsprechenden Modellierungswerkzeugen. Aber was passiert, wenn die UML auch im Fachbereich für die Modellierung von fachlichen Anforderungen eingesetzt werden soll?

Die Sprachelemente der UML sind vielleicht noch relativ einfach zu vermitteln, aber wie können Mitarbeiter eines Fachbereichs in die Lage versetzt werden, mit den notwendigen Modellierungswerkzeugen zu arbeiten? Das funktioniert nur dann, wenn das Modellierungswerkzeug so konfiguriert und angepasst wird, dass der Nutzen den Mitarbeitern durch eine einfache Bedienbarkeit transparent gemacht werden kann. In diesem Artikel wird nun beschrieben, welche Möglichkeiten der Konfigurationen die Modellierungswerkzeuge anbieten.

UML: eine Einleitung

Die Modellierungssprache UML gehört seit Jahren zum Standard der IT-Ausbildung. Sie wird in Entwicklungsprojekten hauptsächlich für das Design von Softwaresystemen und deren Dokumentation eingesetzt. Klassendiagramme, die die Struktur der Entitäten beschreiben, Komponentendiagramme, die den Aufbau und die Architektur der Anwendung verdeutlichen sowie Interaktionsdiagramme, die Abläufe und Methodenaufrufe darstellen, sind dabei die am häufigsten verwendeten Diagrammtypen der UML. Um die modellierten Elemente und die Diagramme konsistent und nachhaltig verwalten zu können, sind entsprechende Werkzeuge unabdingbar. Diese Modellierungswerkzeuge sind in den letzten Jahren so weit entwickelt worden, dass sie kaum noch Wünsche für Entwickler offen lassen. So können sie nahtlos in Entwicklungsumgebungen integriert und über Reverse-Engineering-Funktionen Modelle mit Entwicklungsartefakten synchronisiert werden. Eine Auflistung der zurzeit am Markt erhältlichen Werkzeuge findet sich online.

Nun war allerdings die ursprüngliche Intention für die Modellierungssprache UML eine andere: Sie sollte dazu dienen, die Kommunikation zwischen Fachbereich und IT zu vereinfachen. Über Modelle, in denen unterschiedliche Abstraktionsebenen dargestellt werden können, sollten Anforderungen eindeutiger und konsistenter formuliert und dokumentiert werden. Das ist auch in der entsprechenden Literatur zur Anforderungsermittlung deutlich berücksichtigt worden (siehe z. B. [1] oder [2]). Allein der Lehrplan zur Zertifizierung Requirement Engineering des iREB beinhaltet zu ungefähr 30 Prozent Themen, die sich auf die Modellierung und die Sprache UML beziehen [3]. Trotz alledem hat sich die Modellierung in den Fachbereichen bisher kaum oder gar nicht durchgesetzt. Das ist auf der einen Seite sehr gut nachzuvollziehen, da ein Mitarbeiter, der es gewohnt ist, seine Anforderungen mit Word oder Excel zu formulieren, sich sehr schnell von der Komplexität eines Modellierungswerkzeuges erschlagen fühlt. Auf der anderen Seite werden allerdings alle Möglichkeiten, die mit dem Einsatz eines Werkzeuges geboten werden, verspielt.

Um die Modellierung von Anforderungen im Fachbereich zu verankern, sind somit zwei Schritte notwendig. Zum einen ist das die Vermittlung der Modellierungssprache. Dabei bietet sich nicht nur die UML an, sondern auch die BPMN für die Geschäftsprozessmodellierung, die auch größtenteils von den Modellierungswerkzeugen unterstützt wird. Zum anderen muss das eingesetzte Werkzeug so konfiguriert und angepasst werden, dass der Fachbereich einfach und schnell damit arbeiten kann und der Mehrwert somit deutlich zu Tage tritt.

Im Folgenden soll es nun um die Konfiguration und Erweiterungen eines Modellierungswerkzeugs gehen. Als Modellierungswerkzeug wird der Enterprise Architect der Firma Sparx Systems in der Version 9.3 verwendet; die beschriebenen Konfigurationen und Erweiterungen sollten sich aber auch mit jedem anderen Werkzeug in ähnlicher Art und Weise durchführen lassen. Es sind also folgende Fragen zu beantworten:

  • Welche Hausmittel bietet das Werkzeug selbst für eine fachbereichsadäquate Konfiguration?
  • Wie können erstellte Modelle auf Korrektheit geprüft werden?
  • Wie können die Eingabeoberflächen vereinfacht werden, sodass sie vom Fachbereich schnell bedient werden können?
  • Wie können Fehler in ein Fehlermanagementwerkzeug ohne Medienbruch effizient kommuniziert werden?
  • Wie können Modelle versioniert werden, um Änderungen nachvollziehbar und auswertbar zu protokollieren?
  • Wie können Modelle bei Bedarf in einen Continuous-Integration-Prozess integriert werden?

Erweiterungsmöglichkeit der UML: UML-Profile

Die UML ist als eine programmiersprachenunabhängige Modellierungssprache entwickelt worden. In konkreten Projektkontexten stellt sich aber immer die Frage, wie projektspezifische Gegebenheiten mittels der Modellierungssprache abgebildet werden können. So sollen zum Beispiel in einem Java-Projekt bestimmte Klassen als Enterprise JavaBeans markiert werden, oder die Data-Transfer-Objects eindeutig erkennbar sein. Diesen Anforderungen trägt die UML dahingehend Rechnung indem über so genannte UML-Profile semantische Erweiterungen an Modellen vorgenommen werden können. Ein UML-Profil setzt sich aus Stereotypen, mit denen modellierte UML-Konstrukte markiert werden und zu den Stereotypen gehörende so genannte Tagged Values, mit denen zusätzliche Informationen im Modell abgelegt werden können, zusammen. Das soll jetzt an einem Ausschnitt aus einem UML-Profil für den Fachbereich verdeutlicht werden.

Anmerkung: Die Spezifikation der UML ist in den letzten Jahren immer weiterentwickelt worden. Insbesondere das Konzept der UML-Profile ist mit der Version 2.0 erweitert worden. So wird in der aktuellen UML-Version der Begriff Tagged Values nicht mehr direkt verwendet, sondern der Begriff Property. In diesem Artikel wird aber weiterhin von Tagged Values gesprochen, da sich dieser Begriff so eingebürgert hat und auch die Modellierungswerkzeuge diesen Begriff weiterhin verwenden.
Abb. 1: Geschäftsobjekte

Abb. 1: Geschäftsobjekte

In Abbildung 1 ist im unteren, rechten Bereich zu erkennen, dass ein Stereotyp Businessobject definiert und ihm zwei Tagged Values Author und Change Date zugeordnet wurden. Stereotypen werden immer durch zwei spitze Klammern (Guillemets) repräsentiert. In enger Zusammenarbeit mit dem Fachbereich kann nun ein UML-Profil erstellt werden, das genau auf die Bedürfnisse und Anforderungen des Fachbereichs abgestimmt ist. Und die Erfahrung zeigt, dass wenn der Fachbereich erstmal auf den Geschmack gekommen ist und die Nützlichkeit dieser zusätzlichen Informationen erkannt hat, er sehr schnell zusätzliche Stereotypen und Tagged Values definieren wird.

Jetzt ist es aber mit der Definition eines UML-Profils noch nicht getan. In einem nächsten Schritt muss abgesichert werden, dass es auch korrekt und durchgehend vom Fachbereich angewendet wird. Um das zu gewährleisten, stellt das Modellierungswerkzeug vielfältige Unterstützungsfunktionen zur Verfügung, die in den nächsten Abschnitten vorgestellt werden sollen.

Konfiguration des Werkzeugs: MDG Technology

Der Enterprise Architect stellt über die so genannte MDG Technology (Model-Driven Generator Technology) ein sehr komplexes Konfigurationstool zur Verfügung. Wie kann das nun genutzt werden, um den Enterprise Architect so zu konfigurieren, dass der Fachbereich in seiner Modellierungsarbeit optimal unterstützt wird? Aus der Abkürzung MDG geht schon hervor, dass ein eigenständiges Modell benötigt wird, aus dem eine Konfigurationsdatei generiert wird, die dann von anderen Modellen importiert werden kann. Mit dieser Technologie kann eine Vielzahl von Eigenschaften (z. B.: Datentypen, Suchen, Muster, Vorlagen für Dokumente) konfiguriert werden, wobei in diesem Artikel nur die wichtigsten angesprochen werden sollen: UML-Profile, Werkzeugkasten, Diagrammtypen und Tagged Values.

Wie oben beschrieben, umfasst ein UML-Profil Stereotypen und Tagged Values. Jetzt wäre es natürlich sinnvoll, wenn der Anwender einen Werkzeugkasten verwenden kann, der genau die definierten Stereotypen und eventuell weitere notwendige Elemente beinhaltet. Und wenn der Anwender ein Diagramm erstellen will, so sollte ihm auch gleich der richtige Werkzeugkasten angeboten werden. Abbildung 1 verdeutlicht das im Modellierungswerkzeug. Rechts unten befindet sich das Diagramm mit dem Namen „Modell“ vom Typ Businessmodelling. Links befindet sich der Werkzeugkasten mit den zu verwendenden Modellelementen. Wie gleich deutlich wird, handelt es sich nur bei dem Element Businessobject um einen Stereotyp.

Abb. 2: MDG Technology

Abb. 2: MDG Technology

In Abbildung 2 ist die notwendige Modellierung für die MDG Technology dargestellt. Im obersten Paket wird der Stereotyp Businessobject mit seinen Tagged Values definiert. Er soll für das UML-Element Class, also für Klassen, verwendet werden. Im nächsten Paket wird ein Werkzeugkasten definiert, der eine Gruppe Elemente enthält. Sie stellt wiederum drei Modellierungselemente bereit: Package und Enumeration als Standardelemente der UML bzw. des Werkzeugs (Präfix: UML::), und ein Element Businessobject, das durch das Präfix UML-Profil:: auf den Namen des Pakets verweist, in dem der Stereotyp definiert ist. Im dritten Paket wird dann der Diagrammtyp Businessmodelling definiert. Der Name des Werkzeugkastens wird aber nicht in der Klasse Businessmodelling abgelegt, sondern in der Klasse Diagramm_Logical im Attribut toolbox. In einem nächsten Schritt sind nun die Typen der Tagged Values zu definieren. Für den Stereotyp Businessobject sind zwei Tagged Values definiert: Author und Change Date. Allerdings sind dem Werkzeug die an dieser Stelle angegebenen Datentypen String und Date völlig egal. Auf welche Datentypen die Tagged Values gemappt werden sollen, ist in einer eigenständigen Konfigurationsoberfläche Tagged Value Types zu pflegen (Abb. 3). Dabei verweist das Präfix EA:: auf den Namen der MDG Technology, die wiederum im MDG Technology Wizard angegeben werden muss.

An dieser Stelle bleibt festzustellen, dass die Erstellung einer MDG Technology nicht unbedingt in sich konsistent und intuitiv ist. Aus den drei Paketen werden nun jeweils einzelne XML-Dateien generiert, die dann über einen MDG Technology Wizard mit den definierten Tagged Value Types zu einer proprietären MTS-Datei zusammengefasst werden. Sie beinhaltet dann die gesamte MDG Technology und kann von anderen Modellen importiert werden.

Abb. 3: Datentypen bei Tagged Values

Abb. 3: Datentypen bei Tagged Values

Bis jetzt wurden nur die von einem Werkzeug angebotenen einfachen Erweiterungsmöglichkeiten verwendet. Einem Mitarbeiter aus dem Fachbereich können dadurch vordefinierte Diagrammtypen mit damit verbundenen Werkzeugkästen bereitgestellt werden, mit denen er seine Modellierung durchführen kann, ohne aus dem gesamten Sprachumfang, den die UML bietet, auswählen zu müssen. Es sind aber noch zwei weitere Hürden zu überwinden. Die vom Werkzeug bereitgestellten Pflegeoberflächen für modellierte Elemente beinhalten alle zu pflegenden Informationen – meistens aufgeteilt auf mehrere Reiter. Für einen Mitarbeiter aus dem Fachbereich ist es aber ausreichend, nur die Felder angezeigt zu bekommen, die er pflegen muss. Somit ist es sinnvoll, eigene Pflegeoberflächen aufzubauen, die nur die benötigten Felder enthalten. Bei dem obigen Beispiel wäre das zum Beispiel eine Pflegeoberfläche für Businessobject, die nur die Felder Name, Author und Change Date enthält. Die zweite Hürde ist die Überprüfung der modellierten Informationen auf Korrektheit. Über eine Pflegeoberfläche kann zwar gesteuert werden, ob die Pflichtfelder Author und Change Date ausgefüllt sind und korrekte Daten enthalten, aber für einen Anwender ist es natürlich immer möglich, diese Pflegeoberflächen zu umgehen – ob nun absichtlich oder nicht. Das bedeutet, dass Modelle plausibilisiert werden müssen; es müssen Plausibilisierungsprogramme geschrieben werden, die die modellierten Informationen gegen definierte Regeln plausibilisieren. Für beide Anforderungen stellen die Werkzeuge explizit eine Programmierschnittstelle zur Verfügung, die im Folgenden beschrieben werden soll.

Ausblick

Im zweiten Teil dieses Artikels schauen wir uns den Aufbau der Programmierschnittstelle im Project Browser an, untersuchen das Bereitstellen von Pflegeoberflächen für die modellierten Elemente, nehmen Plausibilisierungsfunktionen unter die Lupe, betrachten die Schnittstelle zu Testwerkzeugen und kümmern uns um das Versionsmanagement.

Links & Literatur

[1] Oesterreich, B.; Scheithauer, A.: „Analyse und Design mit der UML 2.5“, Oldenburg, 2013
[2] Rupp, C.: „Requirements-Engineering und -Management“, Carl Hanser Verlag, 2014
[3] Pohl, K.; Rupp, C.: „Basiswissen Requirement Engineering“, dpunkt. verlag, 2015

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -