Softwaretechnik Praktikum
Gruppe 2

Aufgabenstellung

Ziel der Projektgruppe ist die Implementierung eines Tools, welches die Darstellung sowie Verwaltung von Beziehungen und Gruppen in evolvierenden und koevolvierenden Modellhistorien ermöglicht. Für diese Beziehungen und Gruppen existieren bereits von der Fachgruppe Praktische Informatik erstellte Wiederherstellungsalgorithmen, welche auch Teil des Programms werden. Die zu verwendenen Modellhistorien sollen auf einem bestehenden Historien-Metamodell basieren, welches ebenfalls die Fachgruppe Praktische Informatik entwickelt hat. Das Tool soll Teile der letzten STP-Gruppe verwenden. Darunter Extension Points und die Schnittstelle zu GEF4, die für die Visualisierung genutzt wird. Die graphische Darstellung ist der Projektgruppe frei überlassen, jedoch muss ein Visualisierungskonzept erstellt und von der Projektbetreuung freigegeben werden.


Grundlagen

Evolution
Die Evolution beschreibt die Entwicklung eines Modells. Diese Entwicklung wird in einer Historie gespeichert. Historien besitzen Revisionen, welche aus einer Version des Modells, Gruppen und Tracelinks/Grouptracelinks (siehe unten) bestehen. Veränderungen während der Evolution werden durch eine Differenzberechnung (SiDiff) erkannt und in Differenzdateien gespeichert. Diese Dateien sind innerhalb einer Revision referenziert und enthalten Informationen zu Veränderungen wie dem Erstellen, Ändern und Löschen einzelner Elemente und Gruppen. Aus der Differenzberechnung entstehen auch die zuvor genannten Tracelinks.
Evolutions Bild
Koevolution
Auch die Koevolution beschreibt die Entwicklung von Modellen. Anders als bei der Evolution, betrachtet man hier jedoch die Entwicklung von mehreren unterschiedlichen Modellen und wie diese Modelle miteinander in Verbindung stehen.

Beispiel: Neben dem Klassendiagramm Fahrzeugverwaltung aus der oberen Abbildung existiert noch ein weiteres Modell, eine Datenbank mit dem Namen Fahrzeugverwaltung. Auch diese besitzt Elemente und unterschiedliche Revisionen. Durch Recovery-Prozesse lassen sich nun Gemeinsamkeiten und Unterschiede zwischen den Modellen feststellen. Zum Beispiel kann das Yamaha Motorrad im Klassendiagramm wie auch in der Datenbank vorhanden sein.
Evolutions Bild
Synchronized States
Der Synchronized State beschreibt einen Zustand, bei dem Revisionen aus unterschiedlichen Modellen sich entsprechen, also auf dem gleichen Entwicklungsstand sind. Dieser Zustand wird benötigt, damit der Recovery-Prozess Beziehungen zwischen zwei Revisionen aus unterschiedlichen Modellen (Koevolution) wiederherstellen kann. Ein Synchronized State wird nicht automatisch festgelegt. Der Entwickler selbst entscheidet bei welchen Revisionen ein Synchronized State und somit die Betrachtung der Koevolution sinnvoll ist.

Beispiel: Bei der Entwicklung eines Programms kommen zwei Modelle zum Einsatz. Eins für die GUI und das andere für die Logik. Diese Modelle entwickeln sich nun unabhängig voneinander, sie besitzen Tracelinks und lassen sich als Evolution betrachten. Durch die eigenständige Entwicklung ist es wahrscheinlich, dass sie unterschiedlich schnell voranschreiten. So ist es beispielsweise möglich, dass bei der ersten Testversion des Programms, Version 4 der GUI und Version 8 der Logik zum Einsatz kommen. Diese beiden Revisionen stehen dann in einem Synchronized State. Zwischen ihnen lassen sich Crosslinks wiederherstellen und auslesen.

History Store
Der History Store enthält alle Daten, die das Programm für die Visualisierung benötigt. Es spielt dabei keine Rolle, ob dieser für die Darstellung der Evolution oder Koevolution benutzt wird. Inhaltlich sind immer 2 Histories vorhanden, welche die Revisionen enthalten. Revisionen beinhalten Verweise auf Modelle, in denen sich die Elemente befinden sowie erstellte Gruppen und durch den Recovery-Prozess wiederhergestellte (Group-) Tracelinks. Bei den Tracelinks wird zwischen eingehenden und ausgehenden unterschieden, dadurch lässt sich erkennen wann ein Tracelink aufhört zu existieren.

Für die Koevolution sind noch weitere Daten enthalten. Die zu betrachtenden zwei Revisionen sind in einem SyncState im HistoryStore hinterlegt. Diese bestehen aus den zwei Revisionen unterschiedlicher Historien, sowie Crosslinks und Group Crosslinks.

Das Tool bietet neben dem Laden einer History Store Datei auch die Erstellung selbiger. Dazu werden Differenz Dateien (Symmetric und Asymmetric) benötigt, die vorher mit dem Tool SiDiff erstellt werden müssen. Diese beinhalten die Unterschiede zwischen zwei Modell Versionen. Gegebenenfalls können weitere Abhängigkeiten auf andere Modelle oder Metamodelle hier mit eingegeben werden, die notwendig sind, um die Modellversionen laden zu können.

Trace-/Crosslinks
Trace- und Crosslinks sind die visuelle Darstellung von Zugehörigkeiten/Beziehungen. Durch diese lässt sich feststellen, ob und wie sich ein Element über verschiedene Revisionen hinweg verändert hat. Tracelinks beschreiben die Identitätsbeziehung zwischen Elementen aus aufeinanderfolgenden Revisionen einer Historie (Evolution). Crosslinks beschreiben Entsprechungsbeziehungen von Elementen aus Revisionen verschiedener Historien (Koevolution). Aufgrund des Konzepts des History Store können Crosslinks nur existieren, wenn die zu betrachtenden Revisionen als Synchronized States markiert wurden.

In den meisten Fällen liegen Tracelinks in einer 1:1 Beziehung vor. Jedoch sind Split und Merge möglich, wodurch 1:n, n:1 und in seltenen Fällen n:m Beziehungen entstehen können.

Ein Beispiel: Das Modell Flugzeug besitzt in Version 1 zwei Elemente Passagierraum und Cockpit. In der nächsten Version, zwei, werden jedoch beide Elemente zu Personenraum zusammengefasst - es fand ein Merge statt.

Tracelinks besitzen einen Reliability Wert, der angibt, wie wahrscheinlich die Korrekheit des Tracelinks ist. Dieser Wert liegt zwischen 0 und 1, wobei 0 fehlerhaft und 1 korrekt bedeutet. Vom Nutzer manuell hinzugefügte Tracelinks besitzen immer den Wert 1.
Trace und Crosslink
Group Trace-/Crosslinks
Mehrere Elemente einer Revision lassen sich zu Gruppen zusammenfügen. Nimmt man wieder das Klassendiagramm: Fahrzeugverwaltung als Beispiel, kann es sinnvoll sein alle Motorräder in einer Gruppe zusammenzufassen. Die Elemente der Gruppe bleiben immernoch als einzelne Elemente mit ihren Eigenschaften und Tracelinks vorhanden. Es existiert keine maximale Anzahl an Gruppen, ein Element kann Teil keiner Gruppe oder unendlich vieler sein. Man kann Gruppen als ein weiteres Element des History Store betrachten, welches als Eigenschaft die Gruppenmitglieder besitzt.

Für Gruppen gibt es, wie auch für die jeweiligen einzelnen Elemente, Group Trace-/Crosslinks zu anderen Revisionen. Auch hier gilt: Group Tracelinks sind für einzelne Modelle und Group Crosslinks für unterschiedliche Modelle, die ebenfalls einen Synchronized State benötigt. Anders als bei den Trace- bzw. Crosslinks für einzelne Elemente sind aufgrund des History Store Konzepts nur 1:1 Beziehungen möglich.
GroupLink


Organisation

Eine feste Einteilung der Projektteilnehmer in Arbeitsgruppen gab es aufgrund der Gruppengröße nicht. Bei den Team-Treffen, welche in einem festen Rhythmus von zwei Wochen stattgefunden haben, wurden aktuelle Probleme diskutiert. Anhand der Auslastung und Fähigkeiten der Teilnehmer sind neue Aufgaben verteilt worden. Diese konnten in übersichtlicher Form von Tickets im Trac eingetragen werden. Gab es Probleme bei der Bearbeitung, so konnten über den Telegramm Messenger schnell Informationen ausgetauscht werden.

Folgende Tools wurden für die Bearbeitung bzw. Planung des Projekts genutzt: Zu Beginn des Projekts wurden sämtliche Arbeitspakete zusammengetragen und ein Zeitaufwand geschätzt. Anhand dessen wurde ein Zeitplan bis zur Fertigstellung des Projekts aufgestellt. Im laufe des Projekts wurde dieser immer wieder, aufgrund von Fehleinschätzungen, überarbeitet. Im folgenden ist der finale Zeitplan abgebildet.
Zeitplan

Lösungsansätze

Evolution: Koevolution: Workflow: Visualisierung: Interaktion durch den Nutzer

Entwurf

Um dem Nutzer die Arbeit mit dem Programm so einfach wie möglich zu gestalten, sollen die Schritte des Workflows übersichtlich dargestellt werden. Erste Zeichnungen der Benutzerobfläche legen viel Wert auf leichte Verständlichkeit: Eine Navigationsleiste hebt stets hervor, in welchem Abschnitt man sich befindet und welche noch folgen. Die einzelnen Schritte bauen direkt aufeinander auf, sodass der Nutzer sich nur noch Durchklicken muss. Erfahrene Nutzer können einfach zwischen den Punkten hin und her springen.
Frühes Mockup

Vorstellung des Tools

Im folgenden werden die finalen Workflow Steps vorgestellt:

History Selection
Im ersten Workflow Schritt hat der Nutzer die Möglichkeit einen neuen History Store anzulegen oder einen bestehenden zu laden.

Wird ein neuer History Store erstellt so analysiert eine vorgegebene Methode anhand der gegebenen Differenzdateien jede Historie. Dadurch werden Modell-Revisionen und Verweise innerhalb dieser erkannt. Im neuen HistoryStore werden nun entsprechend Revisionen angelegt, welche Verweise auf Vorgänger und Nachfolger besitzen.

Beim Laden eines bestehenden History Store muss der Nutzer die gewünschte Datei über einen eingebauten Dateibrowser auswählen und zusätzlich die zugehörigen Modelldifferenzen(symmetric/asymmetric) laden. History Selection Workflow Step SyncState Selection
Der zweite Workflow Schritt behandelt die Verbindung zwischen den zuvor gewählten Historien. Hier sind bereits vorhandene SyncStates farblich hervorgehoben. Diese bestehenden Verbindungen kann der Nutzer ändern oder neue hinzufügen. Dafür ist jede Historie jeweils durch eine Tabelle mit allen vorhanden Revisionen dargestellt. Möchte der Nutzer nun eine änderung vornehmen, so wählt er aus jeder Tabelle genau eine Revision und drückt den hinzufügen oder löschen Button. SyncState Selection Workflow Step
TLR Configuration
Im dritten Workflow Schritt kann der Nutzer verschiedene Algorithmen auswählen, welche die vorhanden Tracelinks bzw. Gruppentracelinks modifizieren. Die Algorithmen werden in bestimmte Kategorien eingeteilt und gesondert dargestellt. Dabei erhält jeder Eintrag eine Checkbox welche angibt ob der Algorithmus ausgewählt ist oder nicht. Wenn der Nutzer Änderungen an der Auswahl der Algorithmen vorgenommen hat muss der Apply Button betätigt werden um diese umzusetzen. TL-Config Workflow Step
TL Visualization
Der vierte Workflow Schritt visualisiert eine Revision sowie deren Nachfolger jeweils als eigenständigen Graphen. Der Nutzer kann dabei sowohl Historie als auch Revisionen auswählen.

Die Differenzen zweier Revision sind durch farbliche Markierungen hervorgehoben. Rote Elemente stehen dabei für gelöschte Objekte, gelbe für geänderte und grüne für hinzugefügte.

Eine übersichtliche Darstellung des Graphen ist bei größeren Datenbeständen nicht immer möglich. Damit ein performantes arbeiten mit dem Graphen dennoch möglich ist, können einige Methoden zur Filterung genutzt werden: Der Nutzer hat die Wahl Teilbäume ein oder auszublenden. Zudem ist es möglich, den Graphen auf den aktuell ausgewählten Knoten zu zentrieren. Um zu erkennen, welche Knoten einer Gruppe zugehörig sind oder einen Tracelink besitzen, können wahlweise alle Tracelinks und/oder alle Gruppen farblich hervorgehoben werden. Außerdem lassen sich bestimmte Elementtypen per Dropdownmenü ausblenden.

Bei einem Klick auf einen Knoten werden verschiedene Informationen über diesen angezeigt. Ein Linksklick zeigt Tracelinks sowie Gruppen und Gruppentracelinks innerhalb dafür vorgesehener Tabellen an. Zudem werden Funktionen für die Manipulierung von Tracelinks und Gruppen zur Verfügung gestellt. Diese lassen sich wahlweise hinzufügen, ändern oder löschen. Ein Rechtsklick führt zur Darstellung aller Attribute des Knoten. TL-Visual Workflow Step
CLR Configuration
Im fünften Workflow Schritt kann der Nutzer verschiedene Algorithmen auswählen, welche die vorhanden Crosslinks bzw. Gruppencrosslinks modifizieren. Die Algorithmen werden in bestimmte Kategorien eingeteilt und gesondert dargestellt. Dabei erhält jeder Eintrag eine Checkbox welche angibt ob der Algorithmus ausgewählt ist oder nicht. Wenn der Nutzer Änderungen an der Auswahl der Algorithmen vorgenommen hat muss der Apply Button betätigt werden um diese umzusetzen. CL-Config Workflow Step CL Visualization
Der sechste Workflow Schritt visualisiert zwei Revision, welchen sich in Syncstate befinden, als eigenständige Graphen. Der Nutzer kann dabei zwischen den Revisionen wechseln.

Wie auch bei der TL Visualization können bei der CL Visualization einige Methoden zur Filterung genutzt werden. Der Nutzer hat die Wahl Teilbäume ein oder auszublenden. Zudem ist es möglich, den Graphen auf den aktuell ausgewählten Knoten zu zentrieren. Um zu erkennen, welche Knoten einer Gruppe zugehörig sind oder einen Crosslink besitzen, können wahlweise alle Crosslinks und/oder alle Gruppen farblich hervorgehoben werden. Außerdem lassen sich bestimmte Elementtypen per Dropdownmenü ausblenden.

Bei einem Klick auf einen Knoten werden verschiedene Informationen über diesen angezeigt. Ein Linksklick zeigt Crosslinks sowie Gruppen und Gruppencrosslinks innerhalb dafür vorgesehener Tabellen an. Zudem werden Funktionen für die Manipulierung von Crosslinks und Gruppen zur Verfügung gestellt. Diese lassen sich wahlweise hinzufügen, ändern oder löschen. Ein Rechtsklick führt zur Darstellung aller Attribute des Knoten. CL-Visual Workflow Step

Team


Lehrstuhl

Betreut wird das Projekt durch die Fachgruppe Praktische Informatik an der Universität Siegen

Links