Einbindung des Meta-Modell-Integrationsmusters in das Story Driven Modelling von Fujaba

Transkript

1 Institut für Informatik Fachgebiet Softwaretechnik Warburger Str Paderborn Einbindung des Meta-Modell-Integrationsmusters in das Story Driven Modelling von Fujaba Bachelorarbeit zur Erlangung des Grades Bachelor of Science für den Studiengang Informatik von Markus Fockel Görlitzer Str Schloß Holte-Stukenbrock vorgelegt bei Prof. Dr. Wilhelm Schäfer und Jun. Prof. Dr. Christian Sohler September 2008

2

3 Erklärung Ich versichere, dass ich die Arbeit ohne fremde Hilfe und ohne Benutzung anderer als der angegebenen Quellen angefertigt habe und dass die Arbeit in gleicher oder ähnlicher Form noch keiner anderen Prüfungsbehörde vorgelegen hat und von dieser als Teil einer Prüfungsleistung angenommen worden ist. Alle Ausführungen, die wörtlich oder sinngemäß übernommen worden sind, sind als solche gekennzeichnet. Ort, Datum Unterschrift

4 ii

5 Inhaltsverzeichnis 1 Einleitung Problemstellung Lösungsidee Struktur der Arbeit Grundlagen Assoziationen Das Meta-Modell-Erweiterungs- und das Meta-Modell-Integrationsmuster Story-Diagramme Verwandte Arbeiten Bisheriger Ansatz Lösungsansätze Bewertungskriterien Das MME-Muster wird dargestellt Ein Repräsentant für das MME-Muster wird erstellt Fazit Vom vereinfachten zum vollständigen Modell Umgang mit den verschiedenen Transitionsarten Mögliche MME-Link-Vorkommen Ersetzungsmuster Ablauf der Ersetzung Technische Realisierung Transformation vom vereinfachten zum vollständigen Modell Automatische Anwendung des MME-Musters Zusammenfassung und Ausblick 57

6 INHALTSVERZEICHNIS iv

7 Kapitel 1 Einleitung Heutige Software wird aufgrund der hohen Komplexität häufig in Module aufgeteilt. Die einzelnen Module sind wegen ihres geringeren Umfangs besser wartbar. Durch definierte Schnittstellen können Änderungen an einem Modul vorgenommen werden, ohne dass weitere Teile der Software angepasst werden müssen. Außerdem können so Module leicht wiederverwendet werden und lassen sich bei zusätzlichen Anforderungen erweitern. Die modellbasierte Softwareentwicklung ist ein anerkanntes Mittel, um die Komplexität zu beherrschen. Es wird ein Modell der Anwendung entwickelt und nur an diesem gearbeitet, nicht am konkreten Programmcode. Dieser wird automatisch aus dem Modell generiert. Fujaba [2] ist ein erweiterbares UML- CASE-Tool zur modellbasierten Softwareentwicklung und bietet die Möglichkeit, aus dem erzeugten Modell Code zu generieren. Dazu gibt es neben den statischen UML-Diagrammen, wie Klassen- und Objekt- Diagrammen, auch so genannte Story-Diagramme [5], um Verhalten zu beschreiben. Story-Diagramme werden zur Modellierung des Kontrollflusses in Methoden von Klassen verwendet. 1.1 Problemstellung Angenommen ein Unternehmen möchte einen grafischen Firewall-Konfigurator in verschiedenen Ausführungen anbieten. Als Kern-Modul der Applikation dient ein (möglicherweise schon früher implementierter) einfacher Editor. Auf diesem setzt der eigentliche Konfigurator als Plug-In auf. Diese beiden Module bilden die Grundversion des Firewall-Konfigurators. Diese Grundversion ermöglicht die Verbindung von Netzwerken mittels Netzwerken, welche den Datenverkehr zwischen den verbundenen Netzen erlauben. In der modellbasierten Entwicklung von grafischen Editoren werden häufig so genannte Metamodelle verwendet. Ein Metamodell ist das Modell eines Modells. Der Firewall-Konfigurator beschreibt Modelle von Netzwerken und deren Kommunikationsen. Bei der modellbasierten Softwareentwicklung beschreibt man nun ein Modell des Firewall-Konfigurators. Also ein Modell vom Modell ein Metamodell. Sowohl der Kern-Editor, als auch der Firewall-Konfigurator können also als Metamodell bezeichnet werden. Als zweite Ausführung, soll die Grundversion des Konfigurators um ein Sicherheitspaket erweitert werden (siehe Abbildung 1.1). Dieses Sicherheitspaket enthält unter anderem die Klasse Port, welche mittels der bidirektionalen Assoziation erlaubt mit der Klasse Netzwerk des Plug-Ins Firewall- Konfigurator der Grundversion verbunden ist. Über diese Konstruktion sollen Netzwerken auf den Datenverkehr über bestimmte Ports beschränkt werden können. Bidirektionale Assoziationen erlauben die Traversierung in beide Richtungen. Das bedeutet, die verbundenen Klassen können als Tupel betrachtet werden, bei dem jedes Element weiß welches andere Ele- 1

8 KAPITEL 1. EINLEITUNG Abbildung 1.1: Bidirektionale Assoziation zwischen Klassen aus verschiedenen Metamodellen. ment Teil des Tupels ist. In den gängigen Programmiersprachen gibt es keine Entsprechung zu den Assoziationen der UML, daher müssen zur Realisierung einer bidirektionalen Assoziation beide beteiligten Objekte eine Referenz auf das andere speichern und aktuell halten. Verändert eines der beiden Objekte seine Referenz, so muss im selben Augenblick die Referenz des anderen Objekts aktualisiert werden. Das bedeutet, bei jeder Veränderung der Assoziation (Initialisierung, Änderung und Entfernung) sind beide Objekte betroffen und müssen ihre Referenzen konsistent halten. Diese Herangehensweise würde jedoch eine Kompilierabhängigkeit des gegebenen Plug-Ins Firewall-Konfigurator zum erweiternden Plug-In Sicherheitspaket hervorrufen, da (als Teil des Tupels) die Klasse Netzwerk genauso die Klasse Port kennen muss wie anders herum. Um diese Kompilierabhängigkeit zu umgehen, wendet man das Meta-Modell-Erweiterungsmuster (MME-Muster) [4] (s. Abb. 1.2) an. Dieses Entwurfsmuster [7] stellt sicher, dass ein Metamodell erweitert werden kann, ohne eine Kompilierabhängigkeit des ursprünglichen Metamodells zum erweiternden Metamodell zu erzeugen. Abbildung 1.2: Erweiterung des Metamodells Firewall-Konfigurator um die Klasse Port. Der Kern der Software (hier Editor) muss für das MME-Muster gewisse Klassen und Assoziationen bereitstellen. Auf diese gehe ich hier noch nicht genauer ein. Wichtig ist, dass die beiden Klassen Netzwerk und Port Spezialisierungen ein und der selben Klasse Element sind. Weiter wird die gewünschte Assoziation erlaubt nicht mehr direkt zwischen Port und Netzwerk erzeugt, sondern zwischen Port und einem Stellvertreter NetzwerkZuPort. Über diesen Stellvertreter kann dann die Netzwerk erreicht werden und umgekehrt. Das Meta-Modell-Integrationsmuster (MMI-Muster) [4] ist eine Erweiterung des MME-Musters. Durch zweifache Anwendung des MME-Musters werden hier zwei Metamodelle (Plug-Ins) in einem neuen integriert, ohne Kompilierabhängigkeiten zu erzeugen. So können die Plug-Ins miteinander kommunizieren ohne voneinander abhängig zu sein. 2

9 1.2. LÖSUNGSIDEE Möchte man im Story Driven Modelling von Fujaba Beziehungen zwischen Klassen oder Instanzen von Klassen unterschiedlicher Metamodelle modellieren, so muss man zur Zeit das MME-Muster im jeweiligen Klassen- bzw. Story-Diagramm selbst modellieren. Bei jeder Assoziation, die der Benutzer anlegt, muss er sich überlegen, ob die verbundenen Klassen aus verschiedenen Metamodellen stammen. Bei jedem Link, den der Benutzer zeichnet, muss er sich überlegen, ob die verbundenen Objekte Instanzen von Klassen aus verschiedenen Metamodellen sind. Ist dies der Fall, muss er das MME-Muster verwenden, um die korrekte Funktion (ohne Kompilierabhängigkeit) des später generierten Codes zu gewährleisten. In Klassendiagrammen müssen also zusätzlich zur gewünschten Assoziation weitere Klassen und Verbindungen modelliert werden. In Story-Diagrammen müssen zusätzliche Objekte (Instanzen der hinzugefügten Klassen), häufig sogar mehrere Story-Patterns, eingefügt werden. Story-Patterns sind Teile von Story-Diagrammen, die ganze Objektstrukturen (mehrere über Links verbundene Objekte) enthalten. Zum Einen macht dieser Umstand Klassen- und Story-Diagramme unübersichtlich und zum Anderen fordert er vom Benutzer das Wissen, welchem Metamodell die verwendeten Klassen/Objekte angehören und wie das MME-Muster angewendet wird. Zusätzlich muss er die nötigen Klassen/Objekte in jedem Klassen- /Story-Diagramm erneut einfügen. Allein eine Klasse mit mehreren Methoden, die Referenzen auf Objekte aus einem anderen Metamodell enthalten, erzeugt somit einen merklichen Mehraufwand. Diese Form der Anwendung des MME-Musters ist außerdem sehr fehleranfällig. Ziel dieser Arbeit ist es, den Aufwand der Verwendung des MME-Musters zu reduzieren und die Verwendung für den Benutzer weitestgehend transparent zu gestalten. 1.2 Lösungsidee Um den Aufwand der Verwendung des MME-Musters zu verringern, könnte das Muster auf Anstoß des Benutzers automatisch angewendet werden. D.h. die nötigen zusätzlichen Klassen und Assoziationen würden z.b. auf Knopfdruck eingesetzt. Der größte Aufwand bei der Verwendung des MME-Musters entsteht in Story-Diagrammen, wo die Anwendung des MME-Musters kompliziertere Ersetzungen verlangt als in Klassendiagrammen. Um den Aufwand zu minimieren, soll die Anwendung des MME-Musters bis zur Code-Generierung aufgeschoben werden. Dazu führe ich einen Repräsentanten für das MME-Muster als Platzhalter ein. Dieser Repräsentant wird dann direkt vor der Code-Generierung durch das MME- Muster ausgetauscht und nach der Code-Generierung wieder eingesetzt. In Story-Diagrammen muss dabei für alle modellierbaren Fälle eine Semantik-erhaltende Anwendung des Musters gefunden werden. Der Repräsentant hält das Modell übersichtlich und macht die Verwendung des MME-Musters für den Benutzer transparent. Als weitere Erleichterung, soll der Repräsentant an den nötigen Stellen automatisch eingefügt werden. Damit bräuchte der Benutzer sich fast keine Gedanken mehr um das MME-Muster machen. 1.3 Struktur der Arbeit In Kapitel 2 werden Grundlagen für das Verständnis der Arbeit erläutert. Kapitel 3 beschreibt verwandte Arbeiten und insbesondere den bisherigen Ansatz zur Verwendung des MME-Musters. Die detailierte Beschreibung der Lösungsansätze enthält Kapitel 4. Kapitel 5 erläutert die für den gewählten Lösungsansatz nötigen Schritte zur Umwandlung des in Story-Diagrammen vereinfacht dargestellten Modells in ein vollständiges. In Kapitel 6 wird schließlich die technische Realisierung der Lösung beschrieben. Das letzte Kapitel 7 fasst die gewonnenen Erkenntnisse zusammen und gibt einen Ausblick auf weitere Verbesserungen. 3

10 KAPITEL 1. EINLEITUNG 4

11 Kapitel 2 Grundlagen Im Folgenden werden grundlegende Konzepte zum Verständnis der Arbeit erläutert. Das sind Assoziationen (im Abschnitt 2.1), das Meta-Modell-Erweiterungs- und das Meta-Modell-Integrationsmuster (Abschnitt 2.2) sowie Story-Diagramme (Abschnitt 2.3). 2.1 Assoziationen Assoziationen der UML [8] stellen Verbindungen oder Beziehungen zwischen Klassen dar. Es gibt verschiedenste Typen von ihnen, ich betrachte hier jedoch nur eine kleine Auswahl binärer Assoziationen und lege dabei besonderen Wert auf ihre Implementierung. Diese kleine Auswahl enthält nur Assoziationen, die von Fujaba unterstützt werden und von denen ich einige später verwende. Abbildung 2.1: Beispiele verschiedener Arten von Assoziationen. Assoziationen werden durch Eigenschaften wie Namen, Leserichtung, Kardinalitäten und Rollennamen beschrieben. In manchen Fällen werden einige dieser Eigenschaften nur implizit angegeben, weil sie offensichtlich oder unwichtig sind. Assoziationen können in eine oder in beide Richtungen navigierbar sein (uni- oder bidirektional). Unidirektionale Assoziationen wie in Abb. 2.1 (a) sind durch eine Pfeilspitze gekennzeichnet, welche die Navigationsrichtung angibt. Hier ist auch die Kardinalität 0..1 und der Rollenname angegeben. Kardinalität und Rollenname der Klasse Netzwerk wurde hier weggelassen, da durch die einfache Navigierbarkeit kein Netzwerk-Objekt von Port aus erreichbar ist. Eine bidirektionale Assoziation wie in Abb. 2.1 (b) ist in der Regel ohne Pfeilspitzen dargestellt, da die Navigierbarkeit klar ist. Weil diese Assoziation in beide Richtungen navigierbar ist, sind hier auch an beiden Enden Kardinalitäten und Rollennamen angegeben. 5

12 KAPITEL 2. GRUNDLAGEN Eine Spezielle Assoziation zeigt das Beispiel (c) in Abb Hierbei handelt es sich um eine Aggregation. Das bedeutet, dass ein Port-Objekt Teil eines zugehörigen Netzwerk-Objektes ist (dargestellt durch die ungefüllte Raute an der Klasse Netzwerk). Die Kardinalität an der Seite der Raute kann also weggelassen werden, da die Raute die Kardinalität 0..1 impliziert. Die sogenannte Komposition ist eine stärkere Form der Aggregation, die durch eine ausgefüllte Raute dargestellt wird. Bei einer Aggregation, werden die verbundenen Objekte bei Zerstörung des Objekts mit zerstört. Bei der Komposition, müssen die verbundenen Objekte zusätzlich gleichzeitig mit dem Objekt erzeugt werden. Die qualifizierte Assoziation (Beispiel (d) in Abb. 2.1) ist eine weitere spezielle Form einer Assoziation. Sie ist zusätzlich mit einem Kasten gekennzeichnet, der einen Bezeichner enthält. Eine qualifizierte Assoziation ordnet ein Objekt (oder mehrere) einem anderen eindeutig zu (sog. Schlüssel-Wert-Paare). Konkret bedeutet das, dass einem Objekt der Klasse Netzwerk ein (oder kein) Objekt der Klasse Port unter dem Schlüssel k zugeordnet wird. Die Kardinalität 0..1 an Port bezieht sich also auf den Schlüssel, d.h. pro Schlüssel kann einem Netzwerk-Objekt maximal ein Port-Objekt zugeordnet werden Implementierung von Assoziationen in Java Für Assoziationen gibt es keine Entsprechung in objekt-orientierten Programmiersprachen. Also muss man Assoziationen irgendwie auf konkreten Programmcode abbilden. Dazu gibt es verschiedene Ansätze. Ich möchte die in Fujaba verwendete Vorgehensweise etwas näher erläutern. Unidirektionale Assoziationen lassen sich mittels eines Attributs und entsprechenden Zugriffsmethoden (get und set) umsetzen [6]. Für die Klasse Netzwerk aus Abb. 2.1 (a) sähe das aus wie in Listing c l a s s Netzwerk { 2 p r i v a t e P o r t p o r t ; p u b l i c boolean s e t P o r t ( P o r t v a l u e ) { 7 boolean changed = f a l s e ; 8 i f ( t h i s. p o r t!= v a l u e ) { 9 t h i s. p o r t = v a l u e ; 10 changed = t rue ; 11 } 12 return changed ; 13 } p u b l i c P o r t g e t P o r t ( ) { 16 return t h i s. p o r t ; 17 } 18 } Listing 2.1: Umsetzung einer unidirektionalen Assoziation in Fujaba. In dieser set-methode wird dem Attribut (Objektvariable) eine Objektreferenz value zugewiesen, falls dieses nicht schon dem Attribut entspricht (Zeilen 8 und 9). Ein boolescher Wert changed wird zurückgegeben, der angibt, ob das Attribut verändert wurde oder nicht. Für bidirektionale Assoziationen, wie in Abb. 2.1 (b), fällt die Implementierung allerdings etwas komplexer aus, da hier beide Referenzen konsistent gehalten werden müssen. Eine bidirektionale Assoziation 6

13 2.1. ASSOZIATIONEN kann als ein Tupel zweier Klassen angesehen werden, bei dem die beiden betroffenen Objekte das jeweils andere kennen. Dies könnte man wie zwei unidirektionale Assoziationen implementieren (wie oben beschrieben). Das reicht allerdings nicht aus, denn wenn nun die Methode setport() auf einem Objekt der Klasse Netzwerk aufgerufen wird, wird zwar sein Attribut aktualisiert, das andere Objekt der Klasse Port bekommt davon jedoch nichts mit. Somit entstünde ein inkonsistenter Zustand wie in Abb. 2.2 (a.2) dargestellt. Abbildung 2.2: Aktualisierung der bidirektionalen Assoziation erlaubt. Um die Konsistenz zu halten, wird in der set-methode einer Klasse die set-methode der anderen an der Assoziation beteiligten Klasse aufgerufen. Die Listings 2.2 und 2.3 zeigen den dazu nötigen Code. Abbildung 2.2 zeigt auf der rechten Seite den dadurch entstehenden, konsistenzerhaltenden Ablauf bei Aufruf der Methode setport() auf dem Objekt privatzuweb der Klasse Netzwerk. Zuerst wird die bestehende Verbindung in zwei Schritten abgebaut, um dann in den folgenden zwei Schritten die neue Verbindung aufzubauen. Das Sequenzdiagramm in Abbildung 2.3 zeigt den genauen Ablauf. Nachdem setport() aufgerufen wurde (Schritt 1), setzt privatzuweb in Schritt 1.1 http s Referenz auf null. Daraufhin will http privatzuweb s Referenz auf sich ebenfalls entfernen (Schritt 1.1.1). Da privatzuweb. bereits in Listing 2.2 Zeile 7 auf null gesetzt wurde, wird die Bedingung in Zeile 3 nicht erfüllt und es wird false zurückgegeben. Danach entfernt http seine Referenz und gibt true zurück. Jetzt besteht keine Verbindung mehr zwischen den Objekten privatzuweb und http (auch noch nicht zu ftp). In Listing 2.2 Zeile 10 setzt privatzuweb seine Referenz auf ftp, um dann in Schritt 1.2 die Referenz von ftp zu aktualisieren. In Schritt findet wiederum keine Veränderung statt, sodass schließlich die konsistente Verbindung zwischen privatzuweb und ftp hergestellt ist. 7

14 KAPITEL 2. GRUNDLAGEN 1 p u b l i c boolean s e t P o r t ( P o r t v a l u e ) { 2 boolean changed = f a l s e ; 3 i f ( t h i s. p o r t!= v a l u e ) { 4 P o r t o l d V a l u e = t h i s. p o r t ; 5 6 i f ( t h i s. p o r t!= n u l l ) { 7 t h i s. p o r t = n u l l ; 8 o l d V a l u e. s e t N e t z w e r k v e r b i n d u n g ( n u l l ) ; 9 } 10 t h i s. p o r t = v a l u e ; 11 i f ( v a l u e!= n u l l ) { 12 v a l u e. s e t N e t z w e r k v e r b i n d u n g ( t h i s ) ; 13 } 14 changed = t rue ; 15 } 16 return changed ; 17 } Listing 2.2: Methode für die Rolle der bidirekt. Assoz. erlaubt (Klasse Netzwerk). 1 p u b l i c boolean s e t N e t z w e r k v e r b i n d u n g ( Netzwerk v a l u e ) { 2 boolean changed = f a l s e ; 3 i f ( t h i s. n e t z w e r k v e r b i n d u n g!= v a l u e ) { 4 Netzwerk o l d V a l u e = t h i s. n e t z w e r k v e r b i n d u n g ; 5 6 i f ( t h i s. n e t z w e r k v e r b i n d u n g!= n u l l ) { 7 t h i s. n e t z w e r k v e r b i n d u n g = n u l l ; 8 o l d V a l u e. s e t P o r t ( n u l l ) ; 9 } 10 t h i s. n e t z w e r k v e r b i n d u n g = v a l u e ; 11 i f ( v a l u e!= n u l l ) { 12 v a l u e. s e t P o r t ( t h i s ) ; 13 } 14 changed = t rue ; 15 } 16 return changed ; 17 } Listing 2.3: Methode für die Rolle der bidirekt. Assoz. erlaubt (Klasse Port). 8

15 2.2. DAS META-MODELL-ERWEITERUNGS- UND DAS META-MODELL-INTEGRATIONSMUSTER Abbildung 2.3: Aktualisierung der bidirektionalen Assoziation erlaubt (Sequenzdiagramm). 2.2 Das Meta-Modell-Erweiterungs- und das Meta-Modell-Integrationsmuster Die beiden im Folgenden vorgestellten Entwurfsmuster dienen der Erweiterung (2.2.1) bzw. Integration (2.2.2) von Metamodellen Das Meta-Modell-Erweiterungsmuster Wie in der Problemstellung (s. Abschnitt 1.1) erwähnt, soll ein vorhandenes Software-Modul (ein Metamodell Firewall-Konfigurator) erweitert werden (s. Abb. 1.1, S. 2). Dabei soll keine Abhängigkeit des vorhandenen Moduls vom neuen (Sicherheitspaket) entstehen (keine Kompilierabhängigkeit). D.h. das bereits vorhandene Modul soll unverändert bleiben. Man möchte jedoch eine Assoziation zwischen einer bestehenden Klasse Netzwerk (aus dem vorhandenen Modul) und einer Neuen (Port) etablieren. Diese Assoziation soll in beide Richtungen navigierbar sein, also bidirektional. Die dafür nötigen Referenzen in beide Richtungen würden nach der Implementierung aus Abschnitt 2.1 jedoch eine Kompilierabhängigkeit erzeugen. Eine Lösung dieses Problems stellt das Meta-Modell-Erweiterungsmuster [4, 3] (MME-Muster) dar. Es wird zur Erweiterung eines Metamodells verwendet und ermöglicht bidirektionale Navigation zwischen Klassen aus den verschiedenen Metamodellen ohne eine Kompilierabhängigkeit zu erzeugen. Ich möchte das Beispiel aus der Problemstellung nun erweitern und in der Arbeit durchgehend verwenden (s. Abb. 2.4): Für die Konfiguration einer Firewall wird der grafische Firewall-Konfigurator genutzt. In diesem können verschiedene Netzwerke miteinander über Netzwerken verknüpft werden. Eine solche Verknüpfung bedeutet, dass der Datenverkehr zwischen diesen beiden Netzwerken in der Richtung der Verknüpfung erlaubt ist. Der Firewall-Konfigurator basiert auf dem Kernsystem Editor. Das Kernsystem stellt die Basisfunktionalität für grafische Oberflächen bereit. Das sind z.b. verknüpfbare Knoten und verknüpfende Verbindungen. Diese Elemente sind Spezialisierungen der Klasse Element, welche allgemein gebrauchte Funktionen enthält wie Positionskoordinaten des jeweiligen Elements und einer Methode zum Speichern des selbigen. Werden Verbesserungen an diesem Kernsystem vorgenommen, so profitieren alle erweiterten Editoren, die es verwenden, davon. Nun soll ein Sicherheitspaket bereitgestellt werden, das die Einschränkung von Netzwerken auf bestimmte Ports erlaubt. Damit wird nicht mehr sämtlicher Datenverkehr zwischen zwei Netzwerken erlaubt, sondern nur noch Verkehr über vom 9

16 KAPITEL 2. GRUNDLAGEN Administrator festgelegte Ports (wie z.b. HTTP, FTP,...). Das Sicherheitspaket soll aber nicht direkt in den Firewall-Konfigurator integriert werden, um die Modularität der Software zu erhöhen. Zum Beispiel weil verschiedene Varianten der Software angeboten werden sollen, wobei das Sicherheitspaket nur im teureren Produkt enthalten sein soll. Die Netzwerken werden durch die Klasse Netzwerk aus dem Metamodell Firewall-Konfigurator verwirklicht. Diese Klasse ist eine Spezialisierung der Klasse Verbindung aus dem Kernsystem Editor. Die den Netzwerken zuzuordnenden Ports werden von der Klasse Port des hinzukommenden Metamodells Sicherheitspaket repräsentiert und erben von der Klasse Knoten. Beide Klassen sind somit auch Spezialisierungen der Klasse Element. Die gewünschte Erweiterung des Metamodells für dieses Sicherheitspaket (s. Abb. 2.4) ist nun, die Klasse Netzwerk mit der Klasse Port über eine bidirektionale Assoziation erlaubt zu verknüpfen. Die Assoziation ist bidirektional, damit die jeweilige Netzwerk weiß auf welchen Ports sie Verkehr erlauben soll. So erhielte man jedoch eine Kompilierabhängigkeit, da die bidirektionale Assoziation Referenzen in beide Richtungen benötigt (s. 2.1). Abbildung 2.4: Gewünschte Erweiterung des Metamodells für das Sicherheitspaket. Das MME-Muster (s. Abb. 2.5) erlaubt jedoch die Kompilierabhängigkeit zu umgehen. Dazu verbindet man die Assoziation erlaubt nicht direkt mit der Klasse Netzwerk, sondern stellvertretend mit einer Hilfsklasse NetzwerkZuPort, wobei man die Kardinalitäten der Assoziation erhält. Die Hilfsklasse NetzwerkZuPort muss dabei von dem erweiternden Metamodell Sicherheitspaket bereitgestellt werden. Um nun eine Verbindung zu Netzwerk zu ermöglichen, existiert im Kernsystem Editor die Klasse ElementReferenz (speziell für das MME-Muster). Die Hilfsklasse muss eine Spezialisierung der Klasse ElementReferenz sein, um über die im Kernsystem vorhandene, qualifizierte Assoziation verbindet Element und damit auch die Netzwerk zu erreichen. Um von einem Objekt der Klasse Netzwerk zu einem Objekt der Klasse Port zu gelangen, verwendet man ebenfalls die Assoziation verbindet. Als Schlüssel (key) für diese qualifizierte Assoziation dient der Name der Hilfsklasse, also hier NetzwerkZuPort. Ports sind für eine Netzwerk über genau eine Instanz dieser Hilfsklasse erreichbar. Andersherum erreichen Ports Netzwerken über jeweils genau eine Instanz. D.h. hinter dem Schlüssel NetzwerkZuPort verbirgt sich bei jeder Netzwerk genau eine Instanz der Hilfsklasse 10

17 2.2. DAS META-MODELL-ERWEITERUNGS- UND DAS META-MODELL-INTEGRATIONSMUSTER Abbildung 2.5: Erweiterung des Metamodells Firewall-Konfigurator um die Klasse Port. NetzwerkZuPort über die sie alle ihr zugeordneten Ports erreicht. Ein Beispiel solcher Verbindungen zeigt Abb Die Netzwerk privatzuweb erreicht den Port http über die Instanz privatzuwebports der Hilfsklasse. Andersherum erreichen die Ports http und ftp sie über selbige. Abbildung 2.6: Beispiel des MME-Musters auf Objekt-Ebene. Somit wurde das gegebene Metamodell Firewall-Konfigurator um die Klasse Port erweitert. Auf diese Weise sind weitere Erweiterungen des Metamodells möglich Das Meta-Modell-Integrationsmuster Angenommen neben dem Firewall-Konfigurator wird auch ein Deployment-Editor verwendet, der auf demselben Kernsystem basiert. Der Deployment-Editor wird verwendet, um die Hardware-Ressourcen zu verwalten. D.h. in welchen Gebäuden oder Räumen steht welcher Server, PC, Switch, etc. Diese Geräte operieren in unterschiedlichen Netzwerken. Welche dies sind, geht aus dem Deployment-Editor vielleicht noch hervor, aber, um herauszufinden wie Server aus unterschiedlichen Netzwerken miteinander kommunizieren können (konkret welche Ports zwischen ihren Netzwerken freigeschaltet sind), muss die Firewall-Konfiguration herangezogen werden. Eine hilfreiche Erweiterung der beiden Systeme wäre also ein Editor, der anzeigt, welche Kommunikationsmöglichkeiten zwischen den Servern besteht. Dazu verbindet man also die Netzwerkinformationen mit den Servern. Dabei möchte man von einem Server 11

18 KAPITEL 2. GRUNDLAGEN über sein Netzwerk zu anderen Servern gelangen. Das bedeutet, dass man in einem Modell (Deployment) sowohl von einem Server zu einem Netzwerk navigieren können muss, als auch anders herum. Somit braucht man eine bidirektionale Assoziation zwischen den Klassen Server und Netzwerk (s. Abb. 2.7). Abbildung 2.7: Die gewünschte Verbindung von Firewall-Konfigurator und Deployment-Editor. Die beiden Systeme sollen autonom also ohne eine (Kompilier-)Abhängigkeit weiter funktionieren. D.h.es soll weder der Deployment-Editor vom Firewall-Konfigurator abhängen, noch andersherum. Diese Komponenten sollen somit auch völlig unverändert bleiben. Eine Lösung dieses Problems bzw. eine Umsetzungsmöglichkeit des neuen Editors bietet das Meta-Modell-Integrationsmuster [4, 3] (MMI-Muster). Das MMI-Muster wird zur Integration zweier Metamodelle verwendet. Es ermöglicht bidirektionale Verknüpfungen zwischen Klassen aus zwei verschiedenen Metamodellen ohne eine Kompilierabhängigkeit zwischen diesen zu erzeugen. Der neue Editor Netzwerk-Deployment enthält eine Klasse NetzwerkServerIntegration. Diese dient als Bindeglied zwischen der Klasse Netzwerk aus dem Metamodell Firewall-Konfigurator und der Klasse Server aus dem Metamodell Deployment-Editor. Um eine bidirektionale Verknüpfung der beiden Klassen zu ermöglichen, wird das MME-Muster zweimal angewendet. Einmal zwischen der Klasse NetzwerkServerIntegration und der Klasse Netzwerk und einmal zwischen NetzwerkServerIntegration und Server (s. Abb. 2.8). Abbildung 2.8: Ein Beispiel des Meta-Modell-Integrationsmusters. Das MMI-Muster lässt sich schlecht automatisieren, da hier ein neues Metamodell erzeugt werden muss, um zwei gegebene Metamodelle miteinander zu verknüpfen. Dieser Punkt benötigt den Eingriff des Be- 12

19 2.3. STORY-DIAGRAMME nutzers (in Fujaba die Erstellung einer neuen Datei/eines neuen Fujaba Models ), deshalb ist das MMI- Muster kein Bestandteil dieser Bachelorarbeit. Das MME-Muster hingegen lässt sich gut automatisieren, hier muss kein neues Metamodell erzeugt werden. Durch die Automatisierung des MME-Musters wird die Anwendung des MMI-Musters starkt vereinfacht, sodass der Benutzer sich auf die Erzeugung des Fachmodells konzentrieren kann. Darüberhinaus wird die Anwendung des MMI-Musters übersichtlicher (zweifache Anwendung des MME-Musters, keine zum Fachmodell zusätzlichen Elemente im Editor). 2.3 Story-Diagramme Story-Diagramme [5] dienen zur Modellierung von Verhalten. Mit ihnen kann z.b. der Kontrollfluss in Methoden modelliert werden. Story-Diagramme sind spezielle Aktivitätendiagramme. Ein Story-Diagramm hat genauso einen Start- und einen (ggf. mehrere) Endknoten. Die Aktivitäten werden mit Transitionen verbunden, welche den Kontrollfluss bestimmen. Den Transitionen können Guards zugeordnet sein, die Alternativen beschreiben. Das sind (1) und [failure] für das erfolgreiche und nicht erfolgreiche Beenden einer Aktivität, (2) [each time] und [end] für Schleifen und (3) boolescher Ausdruck und [else] für beliebige Bedingungen. Aktivitäten werden bei Story-Diagrammen formal durch spezielle auf Graph-Grammatiken basierende, ausführbare Kollaborationsdiagramme beschrieben und heißen hier Story-Patterns. Story-Patterns beschreiben Veränderungen von Objektstrukturen und enthalten Objekte, Links und ggf. Constraints. Objekte und Links können die Stereotypen und «destroy» angefügt bekommen, um auszudrücken, dass Sie in diesem Story-Pattern erzeugt oder entfernt werden sollen. Ein Story-Pattern stellt zwei Teilschritte dar: Zuerst wird versucht die Variablen (Namen der Objekte) gemäß den modellierten Bedingungen (vorhandene Links, negative Objekte/Links,...) zu binden/zuzuweisen. Sind dann alle Variablen erfolgreich gebunden, werden im zweiten Schritt die modellierten Veränderungen vorgenommen. Das ist das Erzeugen (create) und Entfernen (destroy) von Objekten und Links. Können nicht alle Variablen gebunden werden, gilt das Story-Pattern als fehlgeschlagen (failed) und der zweite Schritt wird nicht ausgeführt. Neben Story-Patterns gibt es noch Statements für konkreten Programmcode. Auf diese Weise können auch komplexe Dinge, wie z.b. Sortieralgorithmen, modelliert werden. Abbildung 2.9 zeigt ein Beispiel. Hier soll ein Aktualisierungsprozess abgebildet werden. Zuerst soll die Netzwerk zwischen zwei gegebenen Netzwerken ohne Ports durch eine neue Netzwerk ersetzt werden, die nur HTTP (Port 80) erlaubt. Ist dieser Netzwerk bereits ein Port zugeordnet (oder mehrere), aber kein HTTP-Port, so wird in einem zweiten Schritt dieser Netzwerk eben dieser Port hinzugefügt. Dieses Beispiel vernachlässigt noch das im vorherigen Abschnitt 2.2 beschriebene MME-Muster. Am Startknoten steht die Deklaration der Methode, die dieses Story-Diagramm umsetzen soll. Daraus ergeben sich übergebene Parameter (hier netz1 und netz2 vom Typ Netzwerk) die im Story- Diagramm als gegeben und damit gebunden vorausgesetzt werden können. Bei ungebundenen Variablen (Objekten) muss der Typ (Klassenname) angegeben werden. Story-Pattern 1 enthält die beiden als Parameter übergebenen Objekte netz1 und netz2, die über eine Netzwerk verb verbunden sein sollen. Diese Netzwerk verb darf keinen Port erlauben (spezifiziert durch das durchgestrichene Objekt p vom Typ Port, das über den Link erlaubt mit verb verbunden ist). Wenn diese Konstellation gegeben ist, d.h. alle Variablen gebunden werden können, ist die erste Phase des Story- Patterns erfolgreich. In der zweiten Phase werden nun Elemente erzeugt und entfernt. Und zwar werden zuerst die Elemente mit dem Stereotyp «destroy» entfernt und danach die Elemente mit dem Stereotyp entfernt ([13] S. 108). Also werden als Erstes das Objekt verb und die hat-links zu netz1 und netz2 entfernt. Darauf folgend wird das Objekt verb2 erzeugt und mit den beiden Netzwerken verbunden. Außerdem wird das Objekt http erzeugt, mit verb2 verbunden und ihr Attribut nr auf den Wert 80 gesetzt. Diese Attributzuweisung ist eine Assertion. Assertions können auch zum Vergleich von Attributwerten benutzt werden (s. Story-Pattern 2). War die erste Phase des Story-Patterns erfolgreich, so wird nun die Transition mit dem Guard 13

20 KAPITEL 2. GRUNDLAGEN adupdate::update() Update::update(netz2: Netzwerk, netz1: Netzwerk): Void 1. Ersetze vorhandene Verbindung ohne Ports durch Verbindung mit HTTP-Port. hat «destroy» hat netz1 verb2: Netzwerk erlaubt hat «destroy» verb: Netzwerk «destroy» hat erlaubt p: Port http: Port netz2 nr := 80 [failure] 2. Füge HTTP-Port hinzu, falls Verbindung ohne ihn vorhanden ist. netz1 http: Port nr := 80 erlaubt hat verb: Netzwerk hat erlaubt p: Port nr == 80 netz2 Abbildung 2.9: Beispiel eines Story-Diagramms. verfolgt. Konnte das Objekt verb allerdings nicht gefunden/gebunden werden (Phase 1 ist fehlgeschlagen und es wurden deshalb keine Veränderungen vorgenommen), so wird Story-Pattern 2 ausgeführt, die über die Transition mit dem Guard [failure] zu erreichen ist. Hier wird erneut nach einer Netzwerk verb gesucht (der gleiche Variablenname ist kein Problem, da sie im vorigen Story-Pattern nicht gebunden werden konnte). Diese Netzwerk soll wiederum nicht mit einem Port-Objekt verbunden sein. Allerdings nur nicht mit einem Port, dessen nr dem Wert 80 entspricht (Assertion). Mit anderen Ports darf sie ruhig verbunden sein. Kann diese Netzwerk verb gebunden werden, so wird sie in der zweiten Phase mit einem neu erzeugten Port http mit der zugewiesenen nr 80 verbunden. Die ausgehende Transition ohne Guard wird unabhängig vom Ausgang der ersten Phase benutzt (es gibt schließlich keine andere). Beide Story-Patterns führen über den rautenförmigen NOP-Knoten ( no operation - nur zur Zusammenführung des Kontrollflusses) schließlich zum Endknoten, wodurch die Methode beendet wird. Abbildung 2.10 zeigt ein Beispiel unter (vereinfachter) Berücksichtigung des MME-Musters. Hier sollen alle Ports einer gegebenen Netzwerk vonverb zu einer zweiten gegebenen Netzwerk zuverb kopiert werden, sodass diese die Ports auch erlaubt. Zusätzlich soll die Anzahl der Kopiervorgänge mitgezählt werden. Um dies umzusetzen ist Story-Pattern 1 ein for-each-story-pattern (gekennzeichnet durch die Kaskadierung). In dieser wird über den zu suchenden Stellvertreter np vom Typ NetzwerkZu- Port ein Port p gesucht (gleichzeitig ein Stellvertreter np2 für zuverb). Wird dieser gefunden (Phase 1 erfolgreich), so wird er zusätzlich mit np2 und darüber mit zuverb verbunden. Um nun alle Ports von vonverb auch mit zuverb zu verbinden muss dieses Story-Pattern so lange angewendet werden, bis Phase 1 nicht mehr zu Erfolg führt. Tritt dieser Fall ein wird das Story-Pattern über die Transition mit dem Guard [end] verlassen. Um die Kopiervorgänge mitzuzählen wird hier der Guard [each time] für for-each-story-pattern-transitionen verwendet. Diese Transition wird jedesmal, wenn die erste Phase des Story-Patterns erfolgreich war, verfolgt (nachdem auch die zweite Phase abgeschlossen ist). Somit wird Story-Pattern 2 nach jedem Kopiervorgang ausgeführt. In dieser wird ein Attribut des (immer) gebundenen Objekts this mittels einer Zuweisung iteriert. this steht in Story-Diagrammen, für das Objekt, 14

21 2.3. STORY-DIAGRAMME adcontroller::kopiereports() Controller::kopierePorts(vonVerb: Netzwerk, zuverb: Netzwerk): Void vonverb 1. Kopiere jeden Port p von vonverb zu zuverb. verbindet["netzwerkzuport"] np: NetzwerkZuPort erlaubt p: Port [end] zuverb verbindet["netzwerkzuport"] erlaubt np2: NetzwerkZuPort [each time] 2. Zähle Kopiervorgänge. this skopiert := skopiert+1 Abbildung 2.10: Beispiel-Story-Diagramm zur Verwendung des MME-Musters. dessen Methode das Diagramm repräsentiert (vgl. this-zeiger in Java). Die Berücksichtigung des MME-Musters ist hier nur vereinfacht, da bei diesem Story-Diagramm die Existenz des NetzwerkZuPort-Objekts np2 vorausgesetzt wird. Dieses existiert aber nur, wenn zuverb bereits mit mindestens einem Port verbunden ist. Neben den gewöhnlichen Objekten und Links in Story-Diagrammen, gibt es noch drei weitere Element- Typen. Objekte und Links können auch negativ sein wie das Objekt p: Port aus Abbildung 2.9 (dargestellt durch zwei schwarze Diagonalen durch das Objekt). Negative Links werden genauso durchgestrichen (das wird von Fujaba4Eclipse in Version ba-fockel-end (basierend auf Fujaba4Eclipse-Version 0.7) nicht dargestellt). Negative Elemente dürfen nicht gefunden werden. D.h. wird ein solches Element in der Suchphase eines Story-Patterns gefunden, so schlägt diese Phase fehl. Des Weiteren gibt es sogenannte Multi-Objekt-Knoten. Sie stellen eine Menge von Objekten des gleichen Typs dar, die auch leer sein kann. Multi-Objekt-Knoten werden durch zwei kaskadierte Rechtecke mit gestrichelten Kanten dargestellt. Abbildung 2.11 zeigt ein Beispiel. Dieses Story-Diagramm ist eine Vereinfachung des Diagramms aus der vorherigen Abbildung 2.10 zum Kopieren von Ports. Allerdings können hier die Kopiervorgänge nicht mitgezählt werden, da nicht bekannt ist, wieviele Elemente der Multi-Objekt-Knoten p enthält. Somit kann ein Multi-Objekt-Knoten ein for each-story-pattern einsparen, die Elemente dieser Menge können aber nicht mehr einzeln referenziert werden. Außerdem gibt es optionale Objekte und Links. Optional bedeutet hier, dass das jeweilige Element in der Suchphase gefunden werden kann, aber nicht muss. Die Phase gilt so oder so als erfolgreich, falls keine anderen Elemente des Story-Patterns für Gegenteiliges sorgen. Optionale Objekte werden durch gestrichelte Kanten dargestellt, optionale Links als gestrichelte Linie (wiederum von Fujaba4Eclipse in Version ba-fockel-end (basierend auf Fujaba4Eclipse-Version 0.7) nicht). 15

22 KAPITEL 2. GRUNDLAGEN adcontroller::kopiereportsvereinfacht() Controller::kopierePortsVereinfacht(vonVerb: Netzwerk, zuverb: Netzwerk): Void Kopiere alle Ports von vonverb zu zuverb. vonverb verbindet["netzwerkzuport"] np: NetzwerkZuPort erlaubt zuverb verbindet["netzwerkzuport"] p: Port erlaubt np2: NetzwerkZuPort Abbildung 2.11: Vereinfachtes Story-Diagramm aus Abb

23 Kapitel 3 Verwandte Arbeiten Arbeiten zur Erweiterung von Software gibt es viele. Auch speziell mit der Erweiterung von Metamodellen haben sich schon viele beschäftigt. Eine Erweiterung von Metamodellen über bidirektionale Verbindungen und ohne Transformation des bestehenden Metamodells ließ sich jedoch nicht auffinden. Das Eclipse Modeling Framework (EMF) [1] ist ein Modellierungswerkzeug für Anwendungen basierend auf einem strukturierten Datenmodell. Mit EMF lassen sich Metamodelle beschreiben und daraus Code generieren. EMF kann zwar Metamodelle erweitern (z.b. mittels Vererbung oder unidirektionaler Assoziation), aber die Möglichkeit der Erweiterung mit bidirektionalen Assoziationen (vorhandenes Modell kennt das neue, ohne Kompilierabhängigkeit) konnte ich nicht finden und war den Entwicklern des MME-Musters [4] auch nicht bekannt. Der IPSEN-Ansatz (Integrated Software Project Sup Environment) [11] ist nur entfernt mit der hier betrachteten Lösung verwandt. Bei IPSEN wird die komplette Architektur einer Software-Entwicklungsumgebung betrachtet, um eine Erweiterung bzw. Integration von Metamodellen zu erreichen. Der hier betrachtete Ansatz liegt jedoch auf der Design-Ebene und lässt sich auch in vorhandene Systeme integrieren. Weitere entfernt verwandte Arbeiten [9][10] verstehen unter der Integration von Metamodellen die Zusammenführung von Artefakten vorhandener Tools mit Hilfe einer anschließenden Anwendung. Das erlaubt aber keine Interaktion zwischen den vorhandenen Metamodellen sondern transformiert (model transformation) diese in ein neues zusammenhängendes Metamodell. Dabei muss ggf. vorhandene Redundanz zwischen den Metamodellen entfernt werden. Das Endergebnis wäre ein neues Plug-In, das beide Metamodelle vereint, eine weitere unabhängige Entwicklung allerdings ausschließt. Daher bleibt als einzige Grundlage für eine Lösung der folgende bisherige Ansatz. 3.1 Bisheriger Ansatz Der bisherige Ansatz besteht darin, das MME-Muster bewusst und manuell anzuwenden. Das bedeutet zum Einen, dass der Benutzer es kennen und anwenden können muss. Zum Anderen, muss er wissen aus welchem Metamodell die bei der Modellierung verwendeten Klassen stammen, damit er das MME- Muster an den nötigen Stellen anwendet. Das MME-Muster muss sowohl in Klassendiagrammen als auch in sämtlichen Story-Diagrammen angewendet werden. D.h. in jedem Klassendiagramm müssen zusätzliche Klassen und Assoziationen eingezeichnet werden, die mit dem eigentlichen Fachmodell nichts zu tun haben und in allen zugehörigen Story-Diagrammen (für die Methoden der modellierten Klassen) kommen auch zusätzliche Elemente das sind nicht nur Objekte und Links hinzu. Für das in Abschnitt eingeführte Beispiel (s. Abb. 2.4 S. 10) käme folgender Modellierungsauf- 17

24 KAPITEL 3. VERWANDTE ARBEITEN wand hinzu: In Klassendiagrammen muss die Hilfsklasse NetzwerkZuPort, eine Referenz auf die gegebene Klasse ElementReferenz und eine Generalisierung dahin hinzugefügt werden. Abb. 3.1 zeigt das entstehende Bild. Um eine bidirektionale Assoziation erlaubt zwischen den Klassen Netzkwer und Port aus verschiedenen Metamodellen darzustellen, sind die grau hinterlegten, Fachmodell-unabhängigen Elemente zusätzlich nötig. Abbildung 3.1: Manuelle Anwendung des MME-Musters. In den Story-Diagrammen muss ein Objekt der Klasse NetzwerkZuPort und ein Link der bereits vorhandenen Assoziation verbindet verwendet werden (wie in Abb S. 15). Dies ist aber noch der einfachste Fall, die Erzeugung und Zerstörung einer Verbindung zwischen Objekten unterschiedlicher Metamodelle erfordert sogar zusätzliche Story-Patterns (s. Abb. 3.2 und Abb S. 41). adcontroller::createmme() Controller::createMME(: Netzwerk, : Port): Void 1. Existiert ein passendes NetzwerkZuPort-Objekt? verbindet["netzwerkzuport"] np: NetzwerkZuPort [failure] np 3. Verbinde und np. erlaubt 2. Erzeuge ein passendes Objekt und verbinde es mit. verbindet["netzwerkzuport"] np: NetzwerkZuPort Abbildung 3.2: Story-Diagramm zum Erzeugen einer MME-Verbindung. Zum Erzeugen einer Verbindung zwischen einem Objekt der Klasse Netzwerk und einem Objekt der Klasse Port sind drei Story-Patterns nötig: In Story-Pattern 1 wird ein NetzwerkZuPort-Objekt np gesucht, das über die qualifizierte Assoziation verbindet mit dem Schlüssel NetzkwerkZuPort mit verbunden ist. Ist bereits mit einem Port-Objekt verbunden, so kann

25 3.1. BISHERIGER ANSATZ in diesem Story-Pattern np gebunden werden. Damit träte der Success-Fall ein und als Nächstes würde Story-Pattern 3 ausgeführt. Ist jedoch noch mit keinem Port verbunden, so kann np nicht gebunden werden und man gelangt über den Failure-Fall zu Story-Pattern Hier wird das offensichtlich fehlende NetzwerkZuPort-Objekt erzeugt und mit dem Schlüssel NetzwerkZuPort mit verbunden. 3. Im letzten Schritt wird der eigentlich gewünschte Link erlaubt zwischen und dem - Stellvertreter np erzeugt. Dieses Muster zur Erzeugung einer Verbindung zwischen Objekten aus verschiedenen Metamodellen muss im bisherigen Ansatz immer wieder von Hand modelliert werden. Wie bereits erwähnt muss auch zur Entfernung einer solchen Verbindung ein ähnliches Muster eingesetzt werden. Darüber hinaus gibt es noch weitere Muster die den Einsatz des MME-Musters im bisherigen Ansatz erschweren (s. Kap. 5). 19

26 KAPITEL 3. VERWANDTE ARBEITEN 20

27 Kapitel 4 Lösungsansätze Der bisherige Ansatz (s. Abschnitt 3.1) weist einige Probleme auf, aus denen sich Anforderungen an eine Lösung ableiten lassen. Ein Nachteil des bisherigen Ansatzes ist die Tatsache, dass man das MME- Muster bewusst anwenden muss. Das ist eine Ablenkung von der eigentlichen Arbeit (dem Modellieren des Fachmodells). Der Benutzer muss sich bei jeder Assoziation und jedem Link fragen, ob die verbundenen Klassen bzw. Objekte aus verschiedenen Metamodellen stammen. Das macht die Modellierung fehleranfällig: Eine nötige Anwendung des MME-Musters könnte übersehen werden. Man könnte Fehler bei der Anwendung des Musters machen. In Story-Diagrammen müssen meistens nicht nur ein paar Objekte und Links hinzugefügt werden, sondern ganze Story-Patterns, die den eigentlichen Ablauf (Fachmodell) verschleiern oder zumindest komplexer und damit fehleranfälliger machen. Wenn Fehler durch die Anwendung des MME-Musters auftreten folgt daraus wiederum zusätzlicher Aufwand diese zu finden und zu beheben. Das Zeichnen/Modellieren der zusätzlichen Elemente ist weiterer, vor allem zeitlicher Aufwand. Diese zusätzlichen Elemente verursachen jedoch auch einen Verlust der Übersichtlichkeit der Diagramme. Der Benutzer muss nun zwischen Fachmodell und Hilfskonstrukten unterscheiden. Zusätzlich zur Ausbesserung der Nachteile des bisherigen Ansatzes, sollte eine Lösung am Aufwand ihrer Umsetzung gemessen werden. Muss die Spezifikationssprache erweitert werden, um das MME-Muster zu verbergen/transparenter zu gestalten? Eine Erweiterung der Sprache schränkt die Interoperabilität ein. Altsysteme können mit der erweiterten Sprache nicht umgehen. Außerdem müssen die Benutzer den Umgang damit lernen. Muss die Code-Generierung angepasst werden? Änderungen an der Code-Generierung sind i.d.r. mit hohem Aufwand verbunden. Gibt es für mehrere Programmiersprachen Code-Generierungen, so müssen sie alle angepasst werden. 4.1 Bewertungskriterien 1. Komplexität des Modells (Übersichtlichkeit) (a) Werden die MME-Klassen, -Assoziationen, -Objekte und -Links vor dem Benutzer verborgen? Zusätzliche Elemente füllen das jeweilige Diagramm zusätzlich zum Fachmodell und machen 21

28 KAPITEL 4. LÖSUNGSANSÄTZE es somit schnell unübersichtlich. Eine Lösung sollte also diesen Nachteil ausgleichen, indem sie z.b. diese Elemente gar nicht anzeigt. (b) Ist eine Erweiterung der Spezifikationssprache nötig? Eine Lösung sollte die verwendete Spezifikationssprache nicht um neue Elemente erweitern. Also z.b. eine neue Verbindung von Klassen oder Objekten einführen. (c) Muss der Benutzer wissen, ob zwei Klassen/Objekte aus unterschiedlichen Metamodellen stammen? Beim bisherigen Ansatz muss der Benutzer das MME-Muster bewusst anwenden und dafür wissen, ob zwei Klassen/Objekte aus verschiedenen Metamodellen stammen. Wird dieses Wissen nicht vorausgesetzt ist die Lösung für den Benutzer offensichtlich leichter zu bedienen und somit zu bevorzugen. 2. Aufwand (a) für den Benutzer Muss der Benutzer zusätzliche (mehrere) Elemente modellieren, komplexe Dialoge abarbeiten oder einfach nur einen Knopf drücken? Je weniger Aufwand eine Lösung für den Benutzer bedeutet desto besser. (b) der technischen Realisierung Wie komplex und zeitaufwändig ist die Umsetzung der Lösung? i. Muss die Code-Generierung angepasst werden? ii. Muss das Layout von Diagrammen angepasst werden? Muss z.b. bei der Erzeugung der MME-Klassen das Diagramm neu berechnet werden, damit sich keine Elemente überlappen? 3. Fehleranfälligkeit Was/Wieviel kann der Benutzer (noch) falsch machen? Ziel ist geringe Fehleranfälligkeit. 4.2 Das MME-Muster wird dargestellt Bei der folgenden Gruppe von Lösungen wird das MME-Muster im Editor direkt dargestellt und im Modell gespeichert Manuelle Anwendung des MME-Musters Die manuelle Anwendung des MME-Musters entspricht dem bisherigen Ansatz (s. Abschnitt 3.1). Dieser Ansatz hat die bereits erläuterten Nachteile und kommt somit nicht mehr in Frage Bewusster Anstoß der MME-Muster-Anwendung Bei diesem Ansatz stößt der Benutzer die Anwendung des MME-Musters bewusst an. Der Benutzer muss immer noch wissen, dass das MME-Muster anzuwenden ist, aber nicht mehr wie genau. Denn die Anwendung des Musters wird vom Editor übernommen, der Benutzer muss die Anwendung nur noch einleiten. Dies kann z.b. durch die Verwendung einer speziellen Verknüpfung geschehen oder durch einen Knopf, der die Anwendung des MME-Musters auslöst. Bei Verwendung einer speziellen Verknüpfung muss der Benutzer zusätzlich noch wissen, wo genau das Muster Anwendung finden muss. Verbindet der Benutzer zwei Klassen Netzwerk und Port aus unterschiedlichen Metamodellen (wie in Abb. 4.1 links) mittels einer speziellen Verknüpfung (hier mit Namen erlaubt ), so wird das Modell automatisch wie folgt angepasst: 22

29 4.2. DAS MME-MUSTER WIRD DARGESTELLT Abbildung 4.1: Verbindung der Klassen Netzwerk und Port aus Abb Eine Klasse NetzwerkZuPort wird als Spezialisierung der gegebenen Klasse Elementreferenz erzeugt, eine normale Assoziation mit denselben Eigenschaften (Name, Rollen, Kardinalitäten, etc.) wie die spezielle Verknüpfung wird erzeugt und statt mit Netzwerk mit der erzeugten Klasse NetzwerkZuPort verbunden und die gezogene spezielle Assoziation wird entfernt, sodass im Editor das MME-Muster wie auf der rechten Seite von Abb. 4.1 entsteht (analog zur Abb. 2.5, S. 11). Bei dieser Vorgehensweise muss der Benutzer in Story-Diagrammen weiterhin die nötigen Muster wie im bisheringen Ansatz (s. Abschnitt 3.1) von Hand modellieren, da die im Klassendiagramm generierten Klassen dort berücksichtigt werden müssen. Ein einfaches Ersetzen von Links wäre hier zu kompliziert, da für einige Operationen mehrere Story-Patterns eingesetzt werden müssen (s. Kapitel 5). Bei späteren Änderungen am Ablauf wäre es die Aufgabe des Benutzers dafür zu sorgen, dass die Verbindungen über Metamodell-Grenzen hinweg weiterhin richtig funktionieren. Darüber hinaus kann der Umfang der eingefügten Story-Patterns den Umfang des eigentlichen Fachmodells schnell überschreiten, was die Übersichtlichkeit des Diagramms stark einschränkt (weit stärker als im Klassendiagramm) Automatische Umwandlung gewöhnlicher Assoziationen Auch bei diesem Ansatz werden die nötigen Klassen und Verknüpfungen direkt beim Verbinden der gewünschten Klassen wie im vorigen Abschnitt erzeugt. Der Unterschied besteht darin, dass hier die zusätzlichen Elemente erstellt werden, sobald zwei Klassen aus unterschiedlichen Metamodellen mit einer gewöhnlichen Assoziation verbunden werden. Damit muss der Benutzer nicht mehr wissen, wo das MME-Muster benötigt wird. Streng genommen muss er nicht einmal wissen, dass es möglicherweise irgendwo anzuwenden ist, da der Editor es wenn nötig selbst einsetzt (was beim Benutzer allerdings zu Verwirrung führen könnte). Die mit dem MME-Muster verbundenen Komplikationen in Story-Diagrammen kann allerdings auch dieser Ansatz nicht verbergen. 23

30 KAPITEL 4. LÖSUNGSANSÄTZE Bewertung Diese Gruppe von Ansätzen nimmt dem Benutzer das Erstellen der nötigen Klassen und Assoziationen ab (wenn man vom bisherigen Ansatz absieht). Das Modell kann jedoch, durch eben diese, immer noch schnell unübersichtlich werden, da sie explizit im Diagramm dargestellt werden (Kriterium 1-a nicht erfüllt). Wird zum Erstellen der nötigen Elemente eine spezielle Verbindung verwendet ist dies eine Erweiterung der Spezifikationssprache und somit Kriterium 1-b nicht erfüllt. Die Verwendung einer solchen Verbindung setzt außerdem voraus, dass der Benutzer weiß, welche Klassen aus verschiedenen Metamodellen stammen also wo diese spezielle Verbindung anstatt einer gewöhnlichen Assoziation zu verwenden ist. Damit wäre auch Kriterium 1-c nicht erfüllt. Auch in Story-Diagrammen muss der Benutzer Verbindungen zwischen Objekten aus verschiedenen Metamodellen gesondert behandeln, was die Erfüllung des Kriteriums unmöglich macht. Der Aufwand für den Benutzer hält sich bei diesen Ansätzen, zumindest bei Klassendiagrammen, in Grenzen. Das Zeichnen einer speziellen Verbindung unterscheidet sich nicht vom Zeichnen einer Assoziation und das Drücken eines Knopfes zur Anwendung des MME- Musters ist auch keine außergewöhnliche Handlung. Die Code-Generierung muss hier auch nicht angerührt werden, da sämtliche Änderungen direkt im Editor vor den Augen des Benutzers vorgenommen werden und nicht erst bei der eigentlichen Code-Generierung aus dem Modell (Kriterium 2-b-i erfüllt). Durch das Einfügen der zusätzlichen Elemente in das vorhandene Klassendiagramm muss dieses bei deren Erzeugung neu berechnet werden, damit sich keine Elemente überlappen (Kriterium 2-b-ii nicht erfüllt). Der größte Nachteil ist jedoch, dass in Story-Diagrammen nichts dazugewonnen wird. Die automatisch generierten Klassen müssen in zugehörigen Story-Diagrammen berücksichtigt werden wie zuvor. Und gerade hier fällt der Mehraufwand durch die zusätzlichen Elemente ins Gewicht. Die Fehleranfälligkeit bei Story-Diagrammen ist somit auch die gleiche wie beim bisherigen Ansatz. Der Vorteil dieser Lösungsansätze beschränkt sich also auf Klassendiagramme. Zusammenfassend ist der letzte Ansatz zu bevorzugen. Zum Einen ist hier das Kriterium 1-b erfüllt. Eine Erweiterung der Spezifikationssprache ist nicht nötig, da das MME-Muster, wo nötig, gewöhnliche Assoziationen ersetzt. Zum Anderen ist Kriterium 1-c zumindest in Klassendiagrammen erfüllt, da automatisch überprüft wird, ob zwei verbundene Klassen aus verschiedenen Metamodellen stammen. 4.3 Ein Repräsentant für das MME-Muster wird erstellt Bei den folgenden Lösungsansätzen wird das MME-Muster, im Gegensatz zu den Ansätzen aus dem vorigen Abschnitt, nicht direkt dargestellt, sondern durch einen Repräsentanten ersetzt und nur für die Code-Generierung angewendet Manuelle Modellierung von MME-Assoziationen Verwendung eines speziellen Elements Anstatt einer gewöhnlichen Assoziation wird dem Benutzer eine spezielle Verbindung für Klassen aus unterschiedlichen Metamodellen angeboten. Diese würde dann als Repräsentant für das MME-Muster stehen und es somit weitgehend vor dem Benutzer verbergen. In Story-Diagrammen müsste man dann Instanzen dieser speziellen Verbindung anstelle von gewöhnlichen Links verwenden. Verwendung einer Markierung an einer Assoziation Bei diesem Ansatz ist kein neuer Verbindungstyp (und damit keine Erweiterung der Spezifikationssprache) nötig. Allen Assoziationen, die Klassen verschiedener Metamodelle miteinander verbinden, muss der Stereotyp «MME» hinzugefügt werden (im Folgenden als MME-Assoziationen bezeichnet). Dabei steht dann dieser Stereotyp als Repräsentant für das MME-Muster, wie in Abb. 4.2 an der Assoziation erlaubt dargestellt. Die linke Seite der Abbildung zeigt die Ansicht im Editor, auf der rechten Seite ist das eigentlich zugrunde liegende Modell dargestellt wie es bei der Code-Generierung schließlich ensteht. In Story-Diagrammen können auf diese Weise weiterhin gewöhnliche Links verwendet werden. Bei 24