Handbuch zur Domain Model-Erweiterung

Anpassungen des User-Interfaces

Für die Realisierung des Domain Model-Editors (Abbildung 1) wurde das Grafische User Interface von HeRA um einen weiteren Eingabebereich für die Konstruktionskomponente erweitert. Dieser umfasst eine Toolbar für die elementarsten Operationen und eine grafische Zeichenebene zur Darstellung der einzelnen Elemente des Domain Models.

Editor für Domain Models in HeRA
Abbildung 2: Editor für Domain Models in HeRA

Toolbar

Die Toolbar (Abbildung 2) ist in die folgenden sechs Bereiche unterteilt, Objekte erzeugen, Darstellungsdetails, Redo / Undo, Darstellungsgröße, Editoroptionen, Reifegrad.

Toolbar des Domain Model-Editors
Abbildung 2: Toolbar des Domain Model-Editors

Über den Bereich Objekte einfügen lassen sich Entitäten, Kommentarfelder und Referenzen zum Einfügen auswählen. Dabei kann der Nutzer angeben, wie viele der ausgewählten Elemente der Objektgruppe er einfügen will. Das Einfügen wird durch Angabe der Einfügeposition mittels Klick auf der Zeichenfläche vollendet.

Über die Darstellungsdetails kann der Benutzer zwischen drei Darstellungen der Entitäten wählen. Je nach Wahl werden entweder nur der Name der Entitäten angezeigt, der Name samt Eigenschaften oder zusätzlich noch dessen Fähigkeiten.

Mit den Redo / Undo-Schaltflächen können einzelne Modellierungsschritte zurückgenommen, beziehungsweise erneut ausgeführt werden. Die Schaltflächen der Darstellungsgröße erlauben es dem Benutzer, die Anzeigegröße der Zeichenfläche zu verändern. Über die Editoroptionen lassen sich Funktionen, wie das Anzeigen eines Gitternetzes, zur besseren Orientierung auf der Zeichenebene ein- oder ausschalten.

Der letzte Bereich der Toolbar steuert den Reifegrad des Domain Models. So lassen sich zum einen Leser und Zweitautoren über die Aussagekraft des Modells unterrichten und zum anderen Funktionen, die das Modell als Input nutzen, wie beispielsweise das Kritiksystem, steuern und so diese gezielt für die einzelnen Reifegrade aktivieren beziehungsweise deaktivieren.

Grafische Zeichenebene

Die grafische Zeichenebene dient der Darstellung der Objekte im Modell. Diese lassen sich verschieben und auch wieder löschen. Je nach Objekt stehen verschiedene Optionen im Kontextmenü zur Verfügung, mit denen sich die einzelnen Objekte genauer typisieren lassen. So können Entitäten mit Stereotypen versehen werden und an den Kanten die Art der Assoziation, Kardinalitäten und Beschriftungen eingestellt werden.

Das genaue Verhalten der Zeichenebene und der in ihr enthaltenen Objekte lässt sich in den Editoreinstellungen (Abbildung 3) konfigurieren, welche sich in der Menüleiste von HeRA unter „Einstellungen“ einordnen.

Einstellungen des Domain Model-Editors
Abbildung 3: Einstellungen des Domain Model-Editors

Jedem Element der Zeichenebene wurde ein Kontextmenü hinzugefügt, über das der Nutzer die Eigenschaften des Objektes verändern kann. Einige Eigenschaften können direkt im Kontextmenü geändert werden anderen lediglich in einem extra Fenster, welches im mit dem Menü-Item Eigenschaften ausgewählt werden kann. Zusätzlich stehen dem Nutzer Funktionen wie löschen, kopieren, ausschneiden und einfügen zur Verfügung.

Abbildung 4 zeigt die unterstütze Notation im Überblick

Notation
Abbildung 4: Notation

Erweiterung des Projektbaums

Die Domain Models werden im Projektbaum unter dem Ordner UML-Modelle angezeigt. Dabei können innerhalb eines Projektes mehrere Domain Models verwaltet und bearbeitet werden. Über das Kontextmenü lassen sich die Eigenschaften, wie zum Beispiel der Name, der Autor oder der Reifegrad des Modells, verändern (Abbildung 5). Auch eine kleine Beschreibung lässt sich hier für das jeweilige Modell hinterlegen.

Eigenschaften des Domain Models
Abbildung 5: Eigenschaften des Domain Models

Anpassung des Kritiksystems von HeRA

Analog zu den heuristischen Kritiken für Use Cases kann auch bei der Formulierung der Domain Model-Kritiken mit Hilfe eines Handlers auf die Werte der Domain Models zugegriffen werden.

Das Domain Model liefert neben seinem Namen, einer Beschreibung, dem Autor, der Version und dem Reifegrad über die Methoden getEntities(), getComments() und getEdges() alle im Modell enthaltenen Elemente. Die einzelnen Modellelemente verfügen wiederum über entsprechende Mechanismen zum Zugriff auf ihre internen Werte.

Markierung der fehlerhaften Elemente im Domain Model

Die einzelnen Elemente des Domain Models können durch eine eindeutige ID identifiziert und einzelne Bereiche markiert werden. So lassen sich bei Entitäten beispielsweise Markierungen für das gesamte Objekt, den Entitätsnamen, die Attribute und Operationen sowie die Typenbezeichnung hinzufügen und der Nutzer kann so auf fehlerhafte Stellen hingewiesen werden. In den Attribut- und Operationsfeldern lassen sich zudem bestimmte Textstellen hervorheben. Die entsprechenden Kontextinformationen werden dabei durch den entsprechenden Bereich adressiert und anhand der ID dem Objekt zugewiesen.

Tabelle 1 zeigt die einzelnen Markierungsmöglichkeiten und die entsprechenden Adressierungen. Die erste Spalte der Tabelle gibt dabei den in der Kritik zu adressierenden Kontext an, während die restlichen zwei Spalten die Art der Markierung wiedergeben. So können einige Elemente im Graph mit einem Symbol markiert, beziehungsweise gewisse Bereiche rot eingefärbt werden. Bei den Highlights handelt es sich um die Möglichkeit, bestimmte Wörter eines Textfeldes durch farbiges Unterstreichen hervorzuheben.

Markierungen und ihre Adressen
Tabelle 1: Markierungen und ihre Adressen

Zur Überprüfung der modellierten Elemente bietet der Handler zudem eine Werkzeugsammlung (getTools()) an, mit der man neben der Validität von Links auch prüfen kann, ob es zu einem Begriff eine Entität im Domain Model gibt oder ob zwei Entitäten durch eine Kante verbunden sind.

Konsistenzprüfung gegenüber Use Cases

Erweitert man die Szenariobeschreibunegn des Use Cases bzw. deren Erweiterungen um Links auf die Elemente im Domain Model, so können heuristische Kritiken deren Korrektheit mit dem Domain Modell prüfen. Die Links entsprechen dabei dem Folgenden Schema:

Entität.Fähigkeit()

Der Erweiterung ist dabei in der Lage sowohl Getter und Setter aus dem Vorhandensein der Eigenschaften einer Entität zu folgern, als auch die Abhängigkeiten anhand der Beziehungen zwischen zwei Entitäten zu berücksichtigen.

Sonstiges

Ableitung von Vorschlägen aus den Use Cases

Zur Unterstützung des Modellierers wurde HeRA um einen Mechanismus zur Generierung von Modellierungsvorschlägen erweitert. Zum einen kann der Benutzer mit Hilfe des Kontextmenüs einzelne Begriffe aus einem Use Case für die spätere Modellierung als Entität vormerken und so in das Domain Model aufnehmen. Zum anderen generiert HeRA aus den Use Cases eine Vorschlagsliste (Abbildung 6), in der dem Nutzer potentielle Entitäten präsentiert werden. Dieser kann einzelne Begriffe ignorieren oder in einer zweiten Liste für die spätere Umsetzung im Modell vormerken.

Liste mit Vorschlägen für potentielle Entitäten
Abbildung 6: Liste mit Vorschlägen für potentielle Entitäten

Bei der Generierung der Entitätsvorschläge nutzt die Erweiterung entsprechend der Erkenntnisse von Abbott ein einfaches Nominalisierungsverfahren und schlägt alle im Use Case enthaltenen Nomen vor. Dabei werden standardmäßig nur der Auslöser, das Hauptszenario und dessen Erweiterungen berücksichtigt, andere Felder können jedoch über die Einstellungen hinzugefügt werden.

Katalogkomponente für Analysemuster

In der Domain Model-Erweiterung für HeRA ist eine Katalogkomponente realisiert, die oft genutzte Analysemuster enthält. Diese Muster können bei Bedarf vom Anwender in das aktuell geöffnete Domain Model eingefügt werden. Dies hat zum Vorteil, dass zum einen der Eingabeprozess gerade für unerfahrene Anwender vereinfacht wird und zum anderen die Modelle zu einem gewissen Grad standardisiert werden und somit sowohl Qualität als auch Lesbarkeit steigen.

Die Katalogkomponente ist dabei bidirektional gehalten und erlaubt es so dem Nutzer, nicht nur Vorlagen aus dem Katalog in sein Modell zu integrieren, sondern auch eigene Analysemuster hinzuzufügen oder bestehende zu löschen. Dies hat den Vorteil, dass die Auswahl jederzeit auf die aktuellen Bedürfnisse angepasst, neue Erkenntnisse integriert, aber auch veraltetes Wissen entfernt werden kann.

Neben der explorativen Ansicht der Muster ist die Katalogkomponente ebenfalls in das Kritiksystem integriert und kann so gezielt genutzt werden, um dem Anwender im Verlauf des Eingabeprozesses sinnvolle Muster vorzuschlagen und so zu helfen, die Qualität des Modells zu verbessern. Somit ist der Nutzer nicht gezwungen, selbst nach einer besseren Lösung als der Eigenen zu suchen. Diese Unterstützung kommt vor allem dem unerfahrenen Nutzer zu Gute. Ihm fehlt die Erfahrung, die ihm hilft, zu erkennen, wann es sinnvoll ist, ein Analysemuster anzuwenden. Aber auch der erfahrene Anwender zieht seine Vorteile aus dieser Verknüpfung von Kritiksystem und Katalogkomponente, denn gerade in komplexen Modellen kann es schnell passieren, dass man nicht auf den ersten Blick erkennt, dass eine alternative Modellierung sinnvoller wäre.

Die Katalogkomponente mit den Analysemustern (Abbildung 7) wird an der gleichen Stelle in die grafische Oberfläche von HeRA integriert wie auch die Simulationskomponenten. Diese kommt für das Domain Model nicht in Frage und so kann der freie Bereich während der Modellierung anderweitig genutzt werden.

Katalogkomponente für Strukturmuster
Abbildung 7: Katalogkomponente für Strukturmuster

Die Analysemuster können über die Navigationsleiste durchsucht und gegebenenfalls in das gegenwärtig geöffnete Domain Model integriert werden. Für jedes Muster wird dabei eine grafische Abbildung, ein Name sowie eine optional einzublendende Beschreibung bereitgehalten.

Neue Muster können im normalen Editor modelliert werden und über das Kontextmenü zur Katalogkomponente hinzugefügt werden. Innerhalb des Kataloges ist lediglich eine Bearbeitung des Namens sowie der Beschreibung des Analysemusters möglich. Geänderte wie auch neu hinzugefügte Muster müssen vor dem Beenden von HeRA einzeln gespeichert werden und werden dann beim nächsten Programmstart automatisch geladen.

Beispielkritik

Besitzen zwei Entitäten mehr als drei identische Einträge, so könnte eine Generalisierung in Betracht kommen. Die angeschlossene Regel erkennt dies und schlägt das Party-Muster vor. Adressiert werden die einzelnen Muster der Katalogkomponente durch den Schlüssel PatternPanel_<Patternname>.

1 var dMs = domainModelHandler.getAllElements();
2 var aktiv = true;
3 if(aktiv){
4 	for(var h=0; h<dMs.length; h++){
5 		var tools = domainModelHandler.getValidationToolsForModel(dMs[h]);
6 		var entities = dMs[h].getEntities();
7 		for(var i=0; i<entities.length; i++){
8 			var feat1 = tools.getEmptyStringList();
9 			feat1.addAll(entities[i].getFeatures());
10 			feat1.addAll(tools.getFeaturesForOwnAssoziations(entities[i]));
11 			for(var j=i+1; j<entities.length; j++){
12 				var eq = 0;
13 				var feat2 = tools.getEmptyStringList();
14 				feat2.addAll(entities[j].getFeatures());
15 				feat2.addAll(tools.getFeaturesForOwnAssoziations(entities[j]));
16 				for(var k=0; k<feat1.size(); k++){
17 					for(var l=0; l<feat2.size(); l++){
18 						if(feat1.get(k).equals(feat2.get(l))){
19 							eq++;
20 						}
21 					}
22 				}
23 				if(eq > parameter){
24 					contextList.addContext(’Elternklasse modellieren’ ,project,
25 					dMs[h], ’PatternPanel_Party’);
26 				}
27 			}
28 		}
29 	}
30 }

Kommentare als Glossareinträge

Eine weitere Funktion erlaubt es dem Modellierer im Domain Model enthaltene Kommentarfelder mit der bestehen Glossarerweiterung zu verknüpfen. So ist es möglich, sowohl den Inhalt der Kommentarfelder in einen neuen Glossareintrag zu speichern, als auch die bestehende Definition eines Eintrages in ein Kommentarfeld zu kopieren. Entsprechende Kommentarfelder sind durch eine Einfärbung der rechten oberen Ecke gekennzeichnet.

Attachments