Handbuch
Dieses Handbuch führt anhand der Benutzungsschnittstelle durch den Prozess der struktur- und verhaltensbasierten Entwurfsmustererkennung im Werkzeug Reclipse. Als Beispiel wird ein Mediaplayer verwendet. Es wird zunächst erklärt, wie die Spezifikationen der Struktur- und Verhaltensmuster zur Analyse aufbereitet werden. Danach wird dargestellt, wie der Quelltext des Programms in ein Strukturmodell transformiert und die Strukturanalyse durchgeführt wird. Anschließend wird die Benutzung des Reclipse Tracers und des Werkzeugs zur Instrumentierung des ausführbaren Programmcodes erläutert. Zum Abschluss wird die Durchführung der Verhaltensanalyse mit Reclipse behandelt.
Generierung von Struktur- und Verhaltensmusterkatalogen
Im Folgenden wird von bereits existierenden Spezifikationen von Struktur- und Verhaltensmustern ausgegangen. Es wird nur kurz darauf eingegangen, wie die Struktur- und Verhaltensmuster mit Hilfe der Editoren spezifiziert werden. Ausführlicher wird beschrieben, wie aus den vorhandenen Mustern Kataloge generiert werden, die von der Struktur- und Verhaltensanalyse verwendet werden können.
Die Struktur- und Verhaltensmuster eines Katalogs werden in einem Fujaba-Modell gespeichert. Darin ist auch die Spezifikation des Strukturmodells enthalten. In Reclipse werden die Fujaba-Modelle wiederum Eclipse-Projekten zugeordnet. Nach dem Öffnen eines Modells stehen die Spezifikationen zur Bearbeitung zur Verfügung. Der Reverse-Engineer kann neue Struktur- oder Verhaltensmuster hinzufügen, existierende ändern oder entfernen. In Abbildung 1 ist das State-Strukturmuster zu sehen, das im Editor zur Bearbeitung geöffnet wurde.
Abbildung 1: Die Spezifikation des State-Strukturmusters in Reclipse
Auf der linken Seite ist der so genannte Project Explorer zu sehen, über den man Zugriff auf alle Projekte und die darin enthaltenen Dokumente erhält. Das Fujaba-Modell ist geöffnet und zeigt unter anderem alle darin vorhandenen Strukturmuster an. Links unten ist im Outline eine Übersicht über den Editor zu sehen. Rechts oben ist der Editor, mit dem das Modell bearbeitet werden kann. Die Werkzeuge zur Bearbeitung sind über die Palette am rechten Rand des Editors zu erreichen. Dazu gehören zum Beispiel Werkzeuge zum Hinzufügen von Annotationen, Objekten oder auch Verbindungen. Aus Platzgründen wurde die Palette hier jedoch eingeklappt. Rechts unten befindet sich die Properties-Sicht, mit der man bestimmte Eigenschaften der im Editor angezeigten Elemente ändern kann, wie zum Beispiel ihre Namen. In diesem Beispiel werden die Eigenschaften des Strukturmusters angezeigt. Man kann den Namen, die Vererbungshierarchie oder die Beschreibung des Strukturmusters ändern.
Abbildung 2: Die Spezifikation des State-Verhaltensmusters in Reclipse
In Abbildung 2 ist die Spezifikation des State-Verhaltensmusters zu sehen. Das Verhaltensmuster wurde links aus der Liste der im Modell vorhandenen Verhaltensmuster ausgewählt. In dieser Ansicht ist die Palette am rechten Rand des Editors ausgeklappt. Sie enthält Werkzeuge zum Hinzufügen von Verhaltensmusterobjekten, Nachrichten und Kombinierten Fragmenten oder zum Selektieren von Elementen.
Die Spezifikationen der Struktur- und Verhaltensmuster können in dieser Form nicht von Reclipse zur Analyse verwendet werden. Deshalb werden aus den Spezifikationen Kataloge exportiert, die die Muster in einer für die Analyse aufbereiteten Form enthalten. Dazu wird im Project Explorer aus dem Kontext-Menü des Modells der Menüpunkt Export aufgerufen. Es wird ein Wizard geöffnet, in dem man den Punkt Structural Patterns Catalog im Zweig Fujaba auswählt (siehe Abbildung 3). Ein Wizard besteht meist aus mehreren Dialogen, die nacheinander verschiedene Informationen abfragen. Anschließend wird eine Aufgabe anhand dieser Informationen ausgeführt.
Abildung 3: Der Export-Wizard
Der Wizard zum Export eines Strukturmuster-Katalogs besteht aus den Dialogen, die in Abbildung 4 dargestellt sind. Zunächst wählt man das Fujaba-Modell aus, aus dem der zu exportierende Strukturmuster-Katalog stammt. Im nächsten Dialog wird der Strukturmuster-Katalog ausgewählt. Grundsätzlich existiert immer ein \emph{Main Catalog}, der alle Strukturmuster des Modells enthält. Weitere Strukturmuster-Kataloge können vom Reverse-Engineer im Modell erzeugt werden und enthalten Teilmengen der vorhandenen Strukturmuster. Des Weiteren wird in diesem Dialog angegeben, wo der generierte Strukturmuster-Katalog als Datei abgelegt werden soll.
Abbildung 4: Der Export eines Strukturmuster-Katalogs
Aus den Strukturmustern werden Java-Klassen generiert, die von der Strukturanalyse zur Suche in der Struktur verwendet werden. Damit diese Java-Klassen übersetzt werden können, müssen im folgenden Dialog die Bibliotheken angegeben werden, die zur Übersetzung notwendig sind. Im letzten Dialog muss der Reverse-Engineer entscheiden, ob das Modell mit den Strukturmuster-Spezifikationen im generierten Katalog gespeichert werden soll. Das Modell wird zur Auswertung der identifizierten Kandidaten benötigt. Außerdem können weitere Optionen ausgewählt werden, die zur Suche nach Fehlern während der Generierung nützlich sind. Nach Betätigung der Finish-Schaltfläche werden die Java-Klassen generiert, übersetzt und in einer Bibliothek zusammengefasst, die später von der Strukturanalyse verwendet wird.
Abbildung 5: Der Export eines Verhaltensmusterkatalogs
Zum Export der Verhaltensmuster wird wiederum der Export-Wizard geöffnet. Hier wählt man nun den Punkt Behavioral Patterns Catalog (Abbildung 3) aus. Nach Auswahl des Modells mit den Verhaltensmustern wird der Dialog aus Abbildung 5 angezeigt. Darin gibt man die zu exportierenden Verhaltensmuster und eine Datei für den Katalog an. Die Verhaltensmuster werden dann in endliche Automaten transformiert und in einer generischen Beschreibungssprache gespeichert.
Strukturbasierte Entwurfsmustererkennung
Zur Strukturanalyse legt man zunächst ein neues Fujaba-Modell an. In diesem Fall wurde ein Modell mit dem Namen "Parsed Mediaplayer Model" erzeugt und in das Projekt mit dem Quelltext des Mediaplayers gelegt. Dann öffnet man den Import-Wizard über das Kontext-Menü des Modells, um den Java-Quelltext in das Modell zu importieren. Im Wizard wählt man den Punkt "Fujaba Model from Java Source File(s)" aus (Abbildung 6).
Abbildung 6: Der Import-Wizard
Nach Auswahl des Modells, in das der Java-Quelltext importiert werden soll, gibt der Reverse-Engineer im nächsten Dialog des Wizards (Abbildung 7) die Java-Quelldateien oder auch die Verzeichnisse mit den Quelldateien an. Verzeichnisse können rekursiv nach Java-Quelldateien durchsucht werden. Im letzten Dialog kann man einige Optionen auswählen, unter anderem, ob für jedes Java-Paket ein eigenes Klassendiagramm erzeugt werden soll, oder ob alle Klassen in ein einzelnes Klassendiagramm aufgenommen werden sollen.
Abbildung 7: Der Import von Java-Quelltext in ein Fujaba-Modell
Abbildung 8: Der Mediaplayer dargestellt im Klassendiagramm
Nach dem Import kann sich der Reverse-Engineer die Java-Klassen in Klassendiagrammen darstellen lassen. Es werden keine Assoziationen zwischen den Klassen angezeigt, da diese das Ergebnis weiter gehender Analysen sind. In Abbildung 8 ist das Klassendiagramm des Mediaplayers dargestellt.
Abbildung 9: Das Reclipse-Menü
Die Strukturanalyse wird über den Menüpunkt "Start Structural Patterns Recognition..." im Reclipse-Menü aufgerufen (Abbildung 9). Es wird ein Wizard geöffnet, in dem man zunächst das Modell auswählt, in dem nach Strukturmustern gesucht werden soll.
Abbildung 10: Der Dialog zum Starten der Strukturanalyse
Im zweiten Dialog (Abbildung 10) wählt man als erstes den Strukturmuster-Katalog aus. Dies ist der Katalog, der zuvor exportiert wurde. Des Weiteren wählt man ein Strukturmodell. Die Strukturanalyse könnte auch auf andere Strukturmodelle wie zum Beispiel für Matlab/Simulink eingesetzt werden. Das entsprechende Strukturmodell wird hier bestimmt. Zur Analyse von Java-Quelltexten wählt das "UML and JavaAST Analysis" Modell. Zur Strukturanalyse stehen verschiedene Inferenzalgorithmen zur Verfügung. In diesem Fall wird die iterative Inferenz verwendet. Im unteren Bereich des Dialogs kann angegeben werden, ob nach optionalen Elementen der Strukturmuster gesucht werden soll und ob die Kandidaten bewertet werden sollen. Soll eine Bewertung durchgeführt werden, muss der Strukturmuster-Katalog das Fujaba-Modell mit den Spezifikationen der Strukturmuster enthalten. Die Strukturanalyse wird schließlich durch Betätigung der Finish-Schaltfläche gestartet.
Abbildung 11: Das Ergebnis der Strukturanalyse
In Abbildung 11 ist das Ergebnis der Strukturanalyse zu sehen. Im Klassendiagramm werden die Annotationen zweier Kandidaten angezeigt, eine State- und eine Strategy-Annotation. Diese beiden Kandidaten sind jedoch nur ein kleiner Ausschnitt aus allen gefundenen Kandidaten. Die im Klassendiagramm dargestellten Kandidaten können zur besseren Übersicht gefiltert werden. Im unteren Bereich ist die Annotations-Sicht geöffnet, die dagegen alle identifizierten Kandidaten, sowie ihre Bewertungen und die von ihnen annotierten Elemente auflistet. Des Weiteren werden darin Abhängigkeiten zwischen den Kandidaten angezeigt. Zum Beispiel baut der dargestellte Strategy-Kandidat auf einen Delegation-Kandidaten und drei OverridingMethod-Kandidaten auf, die wiederum von weiteren Kandidaten abhängig sind.
Abbildung 12: Der Export der Kandidaten und der Trace-Definition
In der Verhaltensanalyse werden die Kandidaten aus der Strukturanalyse überwacht. Dazu benötigt die Verhaltensanalyse zum einen für jeden Kandidaten die Bindung der Strukturmustervariablen an die Elemente der Struktur und zum anderen die Methoden, die zur Laufzeit des Softwaresystems beobachtet werden müssen. Die Bindungen der Strukturmustervariablen sind in den Annotationen enthalten und werden durch Export der Annotationen zur Verfügung gestellt. Dazu wählt man im Export-Wizard den Punkt "Structural Pattern Annotations aus (Abbildung 3). In Abbildung 12 ist auf der linken Seite der Dialog des Export-Wizards für die Annotationen zu sehen. Hier gibt man die Typen der Annotationen, die exportiert werden sollen, und die Datei für die Annotationen an. Auf der rechten Seite in Abbildung 12 ist der Dialog zum Export der Trace-Definition dargestellt. Er wird im Export-Wizard über den Punkt "Trace Definition aufgerufen. Die Trace-Definition enthält die Informationen, welche Methoden zur Laufzeit überwacht werden müssen.
Verhaltensbasierte Entwurfsmustererkennung
Im Folgenden wird beschrieben, wie zunächst die Daten der Gesamtanalyse für die Software-Tomographie in Daten für Teilanalysen aufgetrennt werden. Dann wird erklärt, wie das zu untersuchende Softwaresystem zur Laufzeit mit Hilfe des Reclipse Tracers oder der Instrumentierung beobachtet wird. Bei der Ausführung wird ein Trace aufgezeichnet, der anschließend durch die Verhaltensanalyse untersucht wird.
Software-Tomographie
Zur Anwendung der Software-Tomographie muss die Gesamtanalyse in viele kleine Teilanalysen aufgeteilt werden. Im Falle der Entwurfsmustererkennung bedeutet das, dass die Gesamtheit der durch die Strukturanalyse identifizierten Kandidaten in Form von Annotationen in viele kleine Gruppen von wenigen Annotationen getrennt werden muss. Gleichzeitig muss die Trace-Definition ebenfalls auf die jeweils zu untersuchenden Kandidaten eingeschränkt werden. Zu diesem Zweck gibt es den Trace Definition Splitting Wizard. Er wird über das Kontext-Menü einer Trace-Definition aufgerufen.
Abbildung 13: Das Zertrennen der Trace Definition und der Annotationen
Abbildung 13 zeigt die zwei Dialoge des Wizards. Im ersten Wizard werden die ursprüngliche Trace-Definition und die Datei mit allen von der Strukturanalyse erzeugten Annotationen ausgewählt. Gleichzeitig werden die Dateinamen der neu zu erzeugenden, aufgetrennten Trace-Definitionen und Annotationen angegeben.
Im zweiten Dialog können nun aufgrund von drei Kriterien die Daten getrennt werden. Zunächst einmal können die Annotation in Gruppen gleicher Größe aufgeteilt werden. Die Anzahl der Annotationen jeder Teilgruppe kann festgelegt werden. Passend zu jeder Teilgruppe von Annotationen wird jeweils eine Trace-Definition generiert. Die Dateien werden in nummerierter Form abgelegt. Die Annotationen können aber auch nach ihrem Typ und sogar nach einzelnen Annotationen aufgetrennt werden. So können zum Beispiel alle Annotationen des Strategy-Entwurfsmusters separiert von allen anderen zusammen mit einer passenden Trace-Definition gespeichert werden.
Die so entstandene Trace-Definition, die nur einen Teil der Gesamt-Trace-Definition enthält, bildet schließlich die Eingabe zum Debugging beziehungsweise zur Instrumentierung. So wird nur ein Teil der Gesamtanalyse durchgeführt und der Einfluss auf das zu untersuchende System gering gehalten.
Debugging
Der Reclipse Tracer wird über die Toolbar gestartet. Abbildung 14 zeigt das Menü des Reclipse Tracers. Es können mehrere Konfigurationen für Programme, die zur Laufzeit beobachtet werden sollen, abgerufen werden. Zur Erzeugung einer neuen Konfiguration wählt man "Reclipse Tracer..." aus.
Abbildung 14: Das Menü zum Aufruf des Reclipse Tracers
Es wird ein Dialog geöffnet, mit dem Konfigurationen verwaltet werden können. In den Abbildungen 15 und 16 wird die Konfiguration des Mediaplayers bearbeitet. Auf der Main-Seite werden die Hauptklasse, mögliche Programmparameter, das Arbeitsverzeichnis und die Trace-Definition konfiguriert. Die Classpath-Seite wird zur Konfiguration des Klassenpfads verwendet. Die hier nicht abgebildeten Seiten JRE und Options dienen zum Einstellen der Java-Laufzeitumgebung beziehungsweise einiger Optionen.
Abbildung 15: Die Konfiguration des Reclipse Tracers für den Mediaplayer
Abbildung 16: Die Konfiguration des Klassenpfads und der Listener
Auf der Seite Listener werden die Module konfiguriert, die die vom Tracer beobachteten Methodenaufrufe verarbeiten. Es stehen zwei Module zur Verfügung. Das Modul Behavioral Patterns Inference übergibt die Methodenaufrufe der Verhaltensanalyse. Dazu benötigt das Modul den Verhaltensmuster-Katalog und die Annotationen aus der Strukturanalyse. Des Weiteren muss man angeben, in welche Datei die Ergebnisse der Verhaltensanalyse gespeichert werden sollen. Der Reverse-Engineer kann entscheiden, ob die Traces, die für einen Kandidaten überprüft werden, gespeichert werden sollen. Das zweite Modul Trace File Logger dient zum Protokollieren des Traces.
Wird das zu untersuchende Programm durch den Reclipse Tracer gestartet, so werden in einer eigenen Perspektive Informationen über den Ablauf angezeigt. Abbildung 17 zeigt die Ausgaben bei der Ausführung des Mediaplayers.
Abbildung 17: Ausführung des Mediaplayers durch den Reclipse Tracer
Auf der linken Seite der Perspektive ist der Execution Monitor. Darin sind alle beobachteten Methoden in einem Baum unterhalb ihrer jeweiligen Klasse aufgelistet. Zu jeder Methode wird außerdem angegeben, ob und wie oft sie aufgerufen wurde. In der Sicht Tracer am unteren Rand werden Meldungen des Reclipse Tracers ausgegeben. Sollte das zu untersuchende Programm Fehler oder sonstige Meldungen auf der Konsole ausgeben, so werden diese in der Sicht Console angezeigt. Die Trace-Definition kann in dem Editor rechts oben angezeigt und bearbeitet werden.
Instrumentierung
Zur Instrumentierung steht ebenfalls ein Wizard zur Verfügung. Er wird über das Reclipse-Menü aufgerufen (Abbildung 9). Der Instrumentierungs-Wizard besteht aus sechs Dialogen, die im Folgenden erläutert werden.
Abbildung 18: Die Konfiguration der Instrumentierung
Im ersten Dialog in Abbildung 18 kann der Reverse-Engineer entscheiden, ob er eine neue Instrumentierungs-Konfiguration erzeugen will, oder ob er eine existierende bearbeiten oder ausführen möchte. Im zweiten Dialog gibt der Reverse-Engineer die Java-Klassen und Bibliotheken an, die instrumentiert werden sollen. Auch die Angabe von Verzeichnissen, die rekursiv nach Java-Klassen durchsucht werden können, ist möglich.
Die Instrumentierung benötigt eine Trace-Definition, in der die Methodenaufrufe aufgelistet sind, die überwacht werden sollen. Die Trace-Definition wird im dritten Dialog angegeben. Des Weiteren muss die Hauptklasse des Programms angegeben werden. Die Hauptklasse wird besonders instrumentiert, um den Start und das Beenden des Programms überwachen zu können. Der Reverse-Engineer kann entscheiden, ob die angegebenen Dateien durch die Instrumentierung überschrieben oder in ein anderes Verzeichnis kopiert werden sollen. Die instrumentierten Klassen benötigen zur Ausführung eine Bibliothek, die die Laufzeitumgebung der Instrumentierung enthält. Diese Instrumentierungs-Bibliothek kann in eine der zu instrumentierenden Bibliotheken eingefügt werden oder in ein gegebenes Verzeichnis kopiert werden. In beiden Fällen muss der Reverse-Engineer sicherstellen, dass die Instrumentierungs-Bibliothek zur Laufzeit des zu untersuchenden Programms für alle Klassen im Klassenpfad zur Verfügung steht. Zusätzlich zur Instrumentierungs-Bibliothek wird eine Konfigurationsdatei für die Laufzeitumgebung erzeugt, die ebenfalls entweder in die angegebene, zu instrumentierende Bibliothek eingefügt oder in das gegebene Verzeichnis geschrieben wird. Auch diese Konfigurationsdatei muss im Klassenpfad zu finden sein.
Im vierten Dialog werden analog zum Reclipse Tracer Module konfiguriert, die während des Ausführung des Programms über ausgeführte Methodenaufrufe informiert werden. Es stehen die gleichen zwei Module zur Verfügung, wie im Reclipse Tracer. Das Modul Behavioral Patterns Inference übergibt die Methodenaufrufe der Verhaltensanalyse. Das Modul Trace File Logger dient zum Protokollieren des Traces. Dazu benötigt es die Angabe, in welche Datei der Trace gespeichert werden soll, und einen Namen für den Trace. Da Traces sehr groß werden können, kann die Datei komprimiert werden. Dabei wird eine Datei im Zip-Format angelegt, in die die eigentliche Trace-Datei eingefügt wird.
In einigen Fällen sollen bestimmte Klassen nicht instrumentiert werden. Liegen diese Klassen in zu instrumentierende Bibliotheken oder Verzeichnissen, deren restliche Klassen alle instrumentiert werden sollen, so können im vierten Dialog diese Klassen angegeben werden. Dazu muss nur ihr voll qualifizierter Klassenname in die Liste eingetragen werden. Im letzten Dialog hat der Reverse-Engineer die Gelegenheit, die Instrumentierungs-Konfiguration zu speichern, um sie bei einer späteren Gelegenheit noch einmal zu verwenden.
Verhaltenserkennung
Die Verhaltensanalyse kann im Online- oder Offline-Modus durchgeführt werden. Für den Online-Modus muss das Modul Behavioral Patterns Inference im Reclipse Tracer beziehungsweise in der Instrumentierung aktiviert werden. Zur Offline-Analyse muss das Modul Trace File Logger aktiviert werden, damit der Trace während der Programmausführung aufgezeichnet wird. Der Trace kann anschließend durch die Verhaltensanalyse im Offline-Modus untersucht werden. Dazu ruft man im Reclipse-Menü "Start Behavioral Patterns Recognition..." auf (Abbildung 9).
Abbildung 19: Starten der Verhaltensanalyse im Offline-Modus
Abbildung 19 zeigt den Dialog, der dadurch geöffnet wird. Hier muss man die Datei angeben, die die Annotationen aus der Strukturanalyse enthält, die Datei, die den Trace enthält, und die Datei, die den Verhaltensmusterkatalog enthält. Außerdem muss der Reverse-Engineer angeben, in welche Datei die Ergebnisse der Verhaltensanalyse geschrieben werden.
Abbildung 20: Das Ergebnis der Verhaltensanalyse
Nach der Durchführung der Verhaltensanalyse wird die Sicht Behavioral Analysis Result geöffnet (Abbildung 20). Darin kann der Reverse-Engineer zu jedem Kandidaten, der ausgeführt wurde, die untersuchten Traces ansehen. Die Kandidaten kann man in der Kombobox unter Design Pattern Candidates auswählen. In der Mitte links ist die Variablenbindung des Strukturmusters an die Elemente der Struktur aufgelistet. Dies ist das Ergebnis der Strukturanalyse. In der Mitte daneben sind die Messwerte der Verhaltensanalyse zu dem ausgewählten Kandidaten zu finden. Jeder der untersuchten Traces kann auch einzeln untersucht werden. Dazu wählt man rechts einen der Traces aus. Es wird angegeben, ob der Trace akzeptiert wurde, und die Bindung der Verhaltensmusterobjekte an die Instanzen zur Laufzeit wird in einer Tabelle aufgelistet. Im unteren Bereich wird der ausgewählte Trace als Sequenzdiagramm visualisiert. Bei Traces, die verworfen wurde, wird der letzte Methodenaufruf, der zum Verwerfen geführt hat, ebenfalls im Sequenzdiagramm visualisiert. So kann der Reverse-Engineer leicht feststellen, warum der Trace verworfen wurde. Um die Visualisierung der Traces zu ermöglichen, muss bei der Online-Analyse im Modul Behavioral Patterns Inference im Reclipse Tracer beziehungsweise bei der Instrumentierung die Eigenschaft 'logTraces' auf 'true' gesetzt werden. Bei der Offline-Analyse muss im Dialog aus Abbildung 19 die Option 'Log matched traces' aktiviert werden.
Das Ergebnis der Verhaltensanalyse kann auch unabhängig von der vorhergehenden Verhaltensanalyse betrachtet werden. Dazu kann man in der Sicht Behavioral Analysis Result das Ergebnis aus einer Datei laden. Dazu betätigt man die Schaltfläche mit dem geöffneten Ordner in der Toolbar der Sicht.