Anwendung von Reverse Engineering für die Erzeugung von UML Diagrammen aus Quellcode

Inhaltsverzeichnis

1 Einleitung
1.1 Motivation
1.2 Zielsetzung
1.3 Vorgehensweise

2 Reverse Engineering
2.1 Begriffsbestimmungen
2.2 Einsatzarten für UML
2.3 Weitere Ziele für Reverse Engineering

3 Welche Anforderungen stellt die Literatur an die Werkzeuge?
3.1 Allgemeine Anforderungen
3.2 Erkennen des Programmverhaltens
3.3 Abgeleitete Anforderungen
3.4 Kriterienkatalog

4 Evaluation der Werkzeuge
4.1 Kurzeinführung in den JAVA-Quellcode
4.2 Auswahl der Werkzeuge
4.3 Soyatec eUML2
4.4 EclipseUML
4.5 Zusammenfassung

5 Zusammenfassung und Ausblick

A Quellcode
A.1 Main
A.2 Package DAO
A.3 Package DAO.Dummy
A.4 Package Person
A.5 Package Kunde

Literaturverzeichnis

Kapitel 1 Einleitung

Diese Arbeit soll die Möglichkeiten des Reverse Engineerings in ausgewählten Werkzeugen auflisten und bewerten. Dazu werden selbst erstellter Beispiel- code (Java) zu UML Diagrammen umgewandelt und die Funktionalität dieser Tools mit den Anforderungen aus der aktuellen Literatur zu Reverse Engineering verglichen.

Bezüglich des Beispielcodes beschränkt sich diese Arbeit auf Reverse En- gineering von reinem Code — UI-Engineering ist nicht Bestandteil dieser Arbeit.

1.1 Motivation

Die Arbeit eines Softwareentwicklers ist stetigen Änderungen unterworfen. Einerseits durch neue Programmiersprachenkonstrukte, von den ersten de- klarativen Sprachen bis zu den objektorientierten Sprachen, andererseits auch durch veränderte Vorgehensweisen, die durch die Objektorientierung entstanden sind (Komponentenorientierung, Serviceorientierung). Hand in Hand mit diesen Veränderungen entwickelten sich auch die verwendeten Werkzeuge weiter: Einst wurde Code in einem einfachen Texteditor verfasst und dann manuell mit einem Compiler in ein ausführbares Programm über- setzt. Später kamen dann sukzessive Unterstützungen hinzu, sodass heute eine Entwicklungsumgebung ohne Hilfestellungen, wie “Syntax Highlight- ing“, Formulareditor oder Intellisense unvorstellbar wäre.

Diese Verbesserungen unterstützen den Entwickler allerdings nur während des Vorgangs der Implementierung, nicht bei der Planung einer Codeänderung, beim Verstehen von einzelnen Codepassagen, beim Ersichtlichmachen von Abläufen und Zusammenhängen oder beim Übersetzen eines Programmierkonzepts oder Modells in Programmcode.

Mit Hilfe von UML können auch die komplexesten Softwareprojekte über- blickt werden, deshalb haben sich viele Werkzeuge etabliert, die den Softwa- reentwickler in der Modellierung mit UML unterstützen. Die Übersetzung eines detaillierten UML-Modells in Code ist häufig nur eine Routineauf- gabe und wird daher ebenfalls von vielen Werkzeugen automatisiert. Einige dieser Werkzeuge können Code und Modell synchron halten oder das Modell aus dem Code ableiten. Im Idealfall integrieren sich diese Werkzeuge in die bevorzugte Entwicklungsumgebung des Entwicklers (zum Beispiel als Addin) und lassen damit erahnen, wie in naher Zukunft Entwicklungsumgebungen aufgebaut sein könnten.

Inzwischen existieren sogar Werkzeuge, die (mehr oder weniger) direkt aus einem Modell ein ausführbares Programm produzieren können¹. Also wer- den möglicherweise in Zukunft Programme nicht mehr programmiert, son- dern designed? In manchen Bereichen und für spezielle Teilanforderungen funktioniert das Designen von Programmteilen bereits, es ist aber meist im- mer noch zusätzliche “Handarbeit“notwendig, um das Programm fertig zu stellen.

Damit diese zusätzliche Handarbeit bei neuen Übersetzungen nicht verloren geht und damit diese Codeänderungen auch im Modell ersichtlich sind, ist Reverse Engineering notwendig. Auch abseits der modellgetriebenen Ent- wicklung gibt es viele Anwendungsbereiche für Reverse Engineering, zum Beispiel, um ein Altsystem ohne ausreichende Dokumentation verstehen zu können oder im Bereich der agilen Vorgehensmodelle, um aus Sourcecode Skizzen zu generieren.

Die zentrale Fragestellung mit der sich diese Arbeit beschäftigt ist:

Funktioniert die in der Literatur propagierte Vorgehensweise bezüglich Reverse Engineering in der Praxis und werden die Anforderungen aus der Literatur ausreichend umgesetzt?

1.2 Zielsetzung

In dieser Arbeit werden anhand der aktuellen Literatur über Reverse Engi- neering Kriterien für JAVA-Werkzeuge ermittelt, und für ausgewählte Werkzeuge das Erreichen dieser Kriterien überprüft. Dabei werden folgende Fragestellungen beantwortet:

- Welche Anforderungen stellt die Literatur an die Werkzeuge?
- Welche Werkzeuge existieren für Reverse Engineering von JAVA-Code?
- Erfüllen diese Werkzeuge die Anforderungen der Literatur?

1.3 Vorgehensweise

Kapitel 2 bietet einen Überblick über die wichtigsten Begriffe zum Thema “Reverse Engineering“und legt dar, welche Einsatzarten unterschieden wer- den können und mit welchem Ziel Reverse Engineering durchgeführt wird.

Kapitel 3 präsentiert eine Zusammenfassung der relevanten Literatur zu Reverse Engineering. Es werden die Anforderungen an Reverse Engineering Werkzeuge herausgearbeitet und für die weitere Vorgehensweise in dieser Bachelorarbeit auf einige Aspekte beschränkt. Abschließend wird für die Auswahl und Bewertung von Werkzeugen aus diesen Anforderungen ein Kri- terienkatalog abgeleitet.

Kapitel 4 zeigt die am Markt befindlichen Werkzeuge und wählt anhand verschiedener Kriterien, wie Verbreitung, Support, unterstützte Programmiersprache (JAVA) und theoretische Erfüllung des Kriterienkatalogs, einige Werkzeuge für eine eingehende Überprüfung aus.

Anschließend erfolgt der Test dieser ausgewählten Werkzeuge mittels JAVACode auf Ihre Fähigkeiten in Reverse Engineering und die Bewertung mit Hilfe des Kriterienkatalogs.

Kapitel 5 enthält dann die zusammengefassten Erkenntnisse, die Beantwortung der Eingangs gestellten Frage und eine Auflistung dessen, was noch unbeantwortet geblieben ist.

Kapitel 2 Reverse Engineering

Dieses Kapitel bietet einen Überblick über die wichtigsten Begriffe zum The- ma “Reverse Engineering“und legt dar, welche Einsatzarten unterschieden werden können und welche Motivation hinter den einzelnen Arten steckt.

2.1 Begriffsbestimmungen

Chikofsky und Cross II präsentierten 1990 in ihrem Artikel “Reverse Engineering and Design Recovery: A Taxonomy“[15] eine genaue und auch heute allgemein anerkannte¹ Spezifizierung der üblichen Terminologie.

Sie erklärten in diesem Artikel unter anderem die Begriffe “Forward Engi- neering“, “Reverse Engineering“, “Restructuring“und “Reengineering“.

Forward Engineering

Forward Engineering ist demnach der traditionelle Prozess, in dem man sich ausgehend von höheren Abstraktionsebenen und implementierungsunabhän- gigen Designs bis zur physischen Implementierung des Systems vorarbeitet.

Reverse Engineering

Reverse Engineering bezeichnet den Prozess der Analyse eines Systems,

- um die Komponenten des Systems und ihrer Beziehungen zueinander zu identifizieren und
- um eine Repräsentation des Systems in einer anderen Form oder auf einer höheren Abstraktionsebene zu erzeugen.

Redocumentation ist eine Form von Reverse Engineering und erzeugt eine neue aber äquivalente Repräsentation auf der gleichen Abstraktionsebene, aber üblicherweise in einer anderen Darstellungsform.

Design Recovery bezeichnet eine andere Form von Reverse Enginee- ring. Hierbei wird die durch Reverse Engineering gewonnene Repräsentation der niedrigeren Abstraktionsebene um zusätzliche Informationen ergänzt, wie Kenntnisse über das Einsatzgebiet, externe Informationen, mehr oder weniger exakte Analysen. Ziel ist das Zusammenfassen aller verfügbaren In- formationen über ein System auf einer hohen Abstraktionsebene.

Restructuring und Reengineering

Restructuring ist die Transformation von einer Darstellungsform in eine andere auf der gleichen Abstraktionsebene, wobei die Funktionalität (das Verhalten nach außen, funktional und semantisch) unverändert bleibt. Die Umstrukturierung von Quellcode ist zum Beispiel eine Form von Restruc- turing.

Reengineering meint die Neuentwicklung eines Systems. Häufig wird mittels Reverse Engineering eine Abstraktion des Altsystems erzeugt, welche dann als Ausgangsbasis für die Neuentwicklung verwendet wird.

Bedeutung für diese Arbeit

Bezieht man diese Definitionen auf Quellcode und UML, bedeutet Reverse Engineering nichts anderes, als die Generierung von UML-Modellen aus Pro- grammcode. Dem Gegenüber bezeichnet der Begriff Forward Engineering die Generierung von Programmcode aus UML-Modellen. Diese Vorgänge kön- nen manuell durch den Entwickler durchgeführt, oder auch mit Hilfe von speziellen Werkzeugen teilweise oder vollständig automatisiert werden.

Roundtrip-Engineering schließt den Kreis und bezeichnet den gemeinsamen, automatisierten Einsatz von Forward- und Reverse Engineering mit dem Ziel der Synchronisation von UML-Modellen und Quellcode, damit Änderungen auf beiden Seiten möglich sind[26] [vgl. S. 410ff].

2.2 Einsatzarten für UML

Die Gründe, warum jemand Reverse Engineering zur Generierung von UMLModellen einsetzen will, sind vielfältig und hängen unter anderem davon ab, wie UML für Forward Engineering verwendet wird.

Martin Fowler identifiziert folgende Einsatzarten für UML: Skizze, Blaupause und UML als Programmiersprache[16] [S. 20-23]

Einsatz als Skizze

UML hilft den Entwicklern, bestimmte Aspekte ihres Systems zu kommunizieren. Das Wesentliche an einer Skizze ist ihre Selektivität. Vorab skizzieren bedeutet, grob bestimmte Probleme zu umreißen. Ziel dabei ist, Ideen und Alternativlösungen verständlich zu machen.

Mit Reverse Engineering erklärt man anhand der Skizzen, wie ein bestimmter Teil des Systems funktioniert. So kann in einem Review oder einer Codeinspektion der neue Programmcode einer Iteration anhand der Skizze erklärt und diskutiert werden.

Einsatz als Blaupause

Hier geht es nicht darum, einzelne Aspekte darzustellen, sondern um Vollständigkeit. Eine Blaupause soll immer ein vollständiges Abbild des zu entwerfenden Systems bilden. Im Zuge des Forward Engineerings muss das Modell so genau sein, dass es dem Programmierer als direkte Grundlage für die Implementierung dienen kann.

Reverse Engineering muss hier ebenfalls ein vollständiges Modell des Sys- tems erzeugen. Der Einsatzzweck kann dann sein, dass aus einem schlecht dokumentierten Altsystem ein Modell erzeugt wird, das als Ausgangsba- sis für den Forward Engineering Prozess für ein neues System oder eine Erweiterung dienen kann. Die zweite Einsatzmöglichkeit ist, das bereits vorhandene Modell mit den Änderungen aus dem Code zu aktualisieren und so Änderungen auf beiden Seiten (Modell und Code) zu ermöglichen und diese synchron zu halten. Damit würde das oben angesprochene Roundtrip Engineering verwirklicht.

Erst durch Reverse Engineering ist der Einsatz von UML als Blaupause für das Forward Engineering wirklich sinnvoll. Andernfalls würde nach je- der Code-Generierung die inhaltliche Implementierung der Methodenrümpfe verloren gehen, oder falls die Methodenrümpfe direkt aus dem UML-Modell kommen, müssten alle Anpassungen an der Implementierung erneut durchge- führt werden[32].

Booch, Rumbaugh und Jacobson[11] führen aus, dass Forward Engineering immer zu Datenverlust führen muss, weil die in UML verfassten Modelle semantisch reicher sind als alle existierenden Programmiersprachen. Deshalb ist es nicht möglich mittels Reverse Engineering ein vollständiges Modell zu erzeugen. Bruegge und Dutoit[13] schließen sich der Meinung der drei Autoren an, in dem sie feststellen, dass CASE Tools im besten Fall nur eine Näherung erstellen können, die der Entwickler dann verwenden kann, um manuell ein vollständiges Modell zu erzeugen.

Ich stimme den Autoren prinzipiell zu, aber sie beziehen sich nur auf die ex- istierende offene UML-Notation. Werkzeuge, die ein Roundtrip-Engineering implementieren, fügen hierfür eigene (proprietäre) Erweiterungen zum vor- handenen UML-Modell hinzu und stellen die Verbindung zwischen Quellcode und Modell mittels Kommentaren im Quellcode her. Ob damit das von den Autoren angesprochene “vollständige“Modell erzeugt werden kann, müsste eigens überprüft werden. Pölz[30] beschreibt in seiner Diplomarbeit, dass Codezentrierte CASE Tools nicht alle Features von UML unterstützen und dafür vollständiges Forward- und Reverse Engineering anbieten, was eben- falls darauf hindeutet, dass automatisiertes Reverse Engineering funktion- ieren kann, auch wenn nicht der gesamte semantische Reichtum von UML unterstützt wird.

UML als Programmiersprache

Die Umwandlung von einem vollständigen UML-Modell in Quellcode ist häu- fig eine aufwändige Routinearbeit. Deshalb geht diese Methode noch einen Schritt weiter und versucht direkt oder indirekt (halbautomatisch mit Hilfe mehrerer verschiedener Werkzeuge) aus dem UML-Modell ein ausführbares Programm zu erstellen.

In diesem Fall gibt es kein Reverse Engineering mehr, weil das UML-Modell der Quellcode ist.

2.3 Weitere Ziele für Reverse Engineering

Die Einsatzarten ergeben sich einerseits aus der Verwendungsmethode von UML selbst. Darüber hinaus gibt es aber noch weitere Ziele, die mit Reverse Engineering verfolgt werden und die weniger davon abhängen, wie UML für Forward Engineering verwendet wird.

Wartung und Weiterentwicklung

Guéhéneuc und Triskell bewerten in Ihrem Paper “Automated Reverse- engineering of UML v2.0 Dynamic Models“die Zeit, die in Wartung und Weiterentwicklung investiert wird, mit 50% der gesamten Entwicklungszeit [20]. Weiters verbringen demnach die mit Wartung und Weiterentwicklung beauftragten Personen mehr als 50% ihrer Zeit damit, ein vorhandenes Sys- tem zu verstehen, bevor Änderungen durchgeführt werden können. Bereits 1979 haben aber andere Autoren[39] festgestellt, dass 67% der Zeit im Soft- warelebenszyklus für Wartung und Weiterentwicklung aufgewendet wird.

Die Zeit, die für das Verstehen des Quellcodes aufgewendet werden muss, bezifferte auch Frazer bereits 1992[17] mit 50% der mit Wartung und Weiterentwicklung verbrachten Zeit.

Riva et al[31] schlagen in die selbe Kerbe und unterstreichen ebenfalls die Wichtigkeit von Reverse Engineering für den UML-basierten Softwarewar- tungsprozess.

Jussi Koskinen[25] hat im September 2010 die vorhandene Literatur in einer Tabelle (Tabelle 2.1) zusammengefasst und kommt zum Schluss, dass inzwischen die Kosten für Wartung und Weiterentwicklung sogar mehr als 90% der Gesamtkosten eines Softwareprojekts verursachen.

Abbildung in dieser Leseprobe nicht enthalten

Tabelle 2.1: Anteilige Kosten für Wartung & Weiterentwicklung[25]

Ein häufig genannter Grund für die hohen Kosten ist der, dass die vorhan- dene Dokumentation häufig nur unvollständig und/oder veraltet vorliegt. Hier müssen dann Reverse-Engineering-Techniken angewendet werden, um anhand des Quellcodes die Lücken in der Dokumentation wieder zu rekon- struieren.

Verstehen von Altsystemen

Der Kern des Problems ist wiederum die fehlende und/oder unvollständi- ge Dokumentation sowie der Umstand, dass wichtige Entscheidungsträger, die das System ursprünglich entwickelt haben, nicht mehr zur Verfügung stehen[38] [12].

Wenn ein neues Feature hinzugefügt werden soll oder das Altsystem für neue Anforderungen bzw. für neue Umgebungen fit gemacht werden soll, steht man so vor einem ernsthaften Problem. Mittels Reverse Engineering kann entweder das gesamte System neu dokumentiert werden oder die Dokumen- tation kann auch auf einzelne kritische Bereiche beschränkt werden. Erst durch Reverse Engineering wird so das Re-Engineering eines Altsystems er- möglicht.

Unterstützung in agilen Vorgehensmodellen

Eine weitere Motivation für Reverse Engineering liefern Larman und Craig in “UML und Patterns angewendet - objektorientierte Softwareentwick- lung“[26]: Zur Unterstützung agiler Vorgehensmodelle. Demnach kann Re- verse Engineering sinnvoll dafür eingesetzt werden, um Diagramme aus den Codeänderungen seit der letzten Iteration zu erzeugen und diese dann zu präsentieren.

Unterstützung für das Entwerfen von Testszenarien

Durch Reverse Engineering gewonnene UML-Sequenzdiagramme sollen als Ausgangsbasis für Testmodelle und Testorakel genommen werden[12].

Reverse Engineering von Datenbankschemata

2008 stellten Alalfi, Cordy und Dean fest, dass es zwar für die Modellierung von Software mit UML einen Standard gibt, aber ein zugehöriger offener Standard für die Modellierung von Daten fehlt[10].

Es existiert natürlich das Entity-Relationship(ER)-Modell[14], allerdings fehlt eine einheitliche grafische Syntax. Viele Anbieter von UML-Tools haben zwar eigene UML-Profile für die Datenmodellierung definiert, aber es gibt auch da keinen einheitlichen Standard und diese Profile basieren meist auf UML 1.x.

In meinen Recherchen bin ich zum selben Schluss gekommen, ein Blick in die Referenzen des Literaturverzeichnisses bestätigt diese Annahmen ein- drucksvoll.

Die Autoren stellten deshalb ein Tool vor, das die Lücke schließen und die Umwandlung eines SQL-Schemas in ein offenes XMI 2.1² UML-angepasstes Klassenmodell ermöglichen soll.

Kapitel 3 Welche Anforderungen stellt die Literatur an die Werkzeuge?

Dieses Kapitel präsentiert eine Zusammenfassung der relevanten Literatur zu Reverse Engineering. Es werden die Anforderungen an Reverse Engi- neering Werkzeuge herausgearbeitet und für die weitere Vorgehensweise in dieser Bachelorarbeit auf einige Aspekte beschränkt. Abschließend wird für die Auswahl und Bewertung von Werkzeugen aus diesen Anforderungen ein Kriterienkatalog abgeleitet.

3.1 Allgemeine Anforderungen

Als erster Schritt im traditionellen Reverse Engineering Prozess müssen alle Artefakte identifiziert werden[37]. Ein entsprechendes Werkzeug muss daher in der Lage sein, mittels eines UML-Paketdiagrammes einen Überblick über alle verwendeten Bibliotheken zu liefern.

Larman[26] fordert das Reverse Engineering von Paketdiagrammen, um die im Forward Engineering Prozess erstellten Diagramme aktuell zu halten, Reverse Engineering von Interaktionsdiagrammen zur Unterstützung agiler Vorgehensmodelle und die Integration in einer populären IDE (Eclipse, Net- beans, Visual Studio).

Reverse Engineering muss alle Klassen und ihre Attribute und Methoden erkennen[13].

Nach Wu et al[37] sollte ein entsprechendes Reverse Engineering Tool zu- sätzliche Informationen aus der Quellcodeverwaltung generieren und Unter- schiede zwischen verschiedenen Versionen aufzeigen. Damit kann dann genau nachvollzogen werden, was sich geändert hat, wer dafür verantwortlich war und warum die Änderung erfolgte.

Fowler[16] fordert, dass Reverse Engineering Abhängigkeiten erkennen muss, weil sich diese einfach aus dem Code ermitteln lassen und im Forward Engineering Prozess meist nicht vollständig berücksichtigt werden.

Yu et al fordern das Erkennen von Vererbung, Delegaten, Polymorphismus, dynamische Bindung und bekannten Design Patterns aus der Analyse von Execution Traces und bieten auch gleich einen Weg zur Umsetzung an[38]. Auch Kollmann et al[24] fordern die Erkennung von Design Patterns. Zusätzlich wünschen sie sich die Extraktion von Klassendiagrammen in Komponentendiagramme und das Erkennen von Assoziationen.

Vinita et al[35] präsentierten 2008 einen neuen Algorithmus, der es er- laubt alle Aspekte des Codes unabhängig von der verwendeten Program- miersprache in ein Klassendiagramm zu überführen und sie erstellten gleich- zeitig ein Regelwerk für Reverse Engineering - Software. Über die bereits angesprochenen Punkte hinaus fordern sie die Erkennung von Sichtbarkeit, Multiplizität und Parameter von Klassen, sowie die Identifikation von Grup- pen (Namespaces für Paketdiagramme), Kommentare, Objekte (Klassenin- stanzen für Objektstrukturdiagramme), Realisierungen von Interfaces, As- soziationen, Aggregationen und Kompositionen. Weiters verlangen sie die Erkennung von weitergehenden Mechanismen, wie Stereotypen (zum Beispiel «exception»), Tagged Value und Constraints.

Reverse Engineering führt häufig zu einem Zuviel an Informationen auf ei- ner zu niedrigen Abstraktionsebene, deshalb schlagen Booch, Rumbaugh und Jacobson[11] vor, ein vorhandenes Modell anhand eines Systems im ausgeführten Zustand zu animieren. Diesen Vorschlag betrachte ich nicht nur als Ersatz für Reverse Engineering, sondern vielmehr als Ergänzung, deshalb nehme ich es ebenfalls als Forderung aus der Literatur auf.

3.2 Erkennen des Programmverhaltens

Ziel einer Verhaltensextraktion muss das Erstellen eines Sequenzdiagrammes sein, weil dieses die am häufigsten verwendete Form aus der Familie der Interaktionsdiagramme ist[29, S. 521].

Die Extrahierung des Verhaltens kann dabei auf zwei Wege erfolgen:

- statische Analyse: Analyse des Quellcodes
- dynamische Analyse: Analyse des Laufzeitverhaltens im ausgeführten Zustand.

Eine statische Analyse kann ein vollständiges Abbild davon erzeugen, was zur Laufzeit sein könnte, es zeigt aber nicht, was zur Laufzeit tatsächlich passiert[12]. Daher wäre künftig eine Verbindung von statischer und dynamischer Programmanalyse wünschenswert.

Zur dynamischen Analyse sollen nach Briand und Leduc[12] Sequenzdia- gramme aus Execution Traces des zu untersuchenden Programms erstellt werden. Zuerst wird das Programm wiederholt ausgeführt, bis zu einem bestimmten Usecase - Szenario alle möglichen Ausführungspfade durchlaufen und alle Execution Traces generiert worden sind. Aus jedem Execution Trace wird ein “Szenario“-Diagramm erzeugt. (Die Autoren führen diesen Begriff als Abgrenzung zu einem Sequenzdiagramm ein, um klarzustellen, dass ein Szenariodiagramm nur ein unvollständiges Sequenzdiagramm ist. Es zeigt nur das, was in einem speziellen Fall passiert ist, bietet aber keine Ansicht aller möglichen Ausführungspfade eines vollständigen Usecase-Szenarios.) Aus all diesen einzelnen Szenariodiagrammen wird dann ein vollständiges Sequenzdiagramm erzeugt.

Yu et al[38] beschreiben in ihrer Arbeit ebenfalls einen Weg, wie die Gener- ierung von dynamischen Modellen aus der Analyse von Execution Traces durchgeführt werden kann. Sie fordern dabei, dass Werkzeuge nicht nur Se- quenzdiagramme, sondern auch Zustandsdiagramme extrahieren müssen.

3.3 Abgeleitete Anforderungen

Erforderliche Diagrammtypen

Aus diesen Anforderungen kann man erkennen, dass ein Reverse Engineering Tool zumindest folgende Diagrammtypen unterstützen soll:

- Klassenstrukturdiagramm
- Paketdiagramm für Artefakte
- Paketdiagramm für Codegruppen (Namespaces)
- Objektstrukturdiagramm
- Komponentendiagramm
- Sequenzdiagramm
- Zustandsdiagramm

UML-Version

Es muss die aktuelle Version UML2.0 unterstützt werden.

Strukturelle Elemente

Für ein vollständiges Klassendiagramm sollen aus dem Quellcode zumindest folgende Informationen gewonnen und im Diagramm dargestellt werden:

- Klassen und deren Sichtbarkeiten und Parameter
- Attribute der Klassen und deren Sichtbarkeiten
- Methoden der Klassen und deren Sichtbarkeiten
- Generalisierung, Interfaces
- Assoziationen

Bei der Darstellung der Attribute und deren Sichtbarkeit soll auch die in der Java Language Specification[19] beschriebene Vorgehensweise der Setter und Getter korrekt aufgelöst und deren Sichtbarkeit erkannt werden.

Methods to get and set an attribute that might be thought of as a variable V should be named getV and setV [19, S. 149]

Eine deutschsprachige Beschreibung kann in der bekannten Publikation “Java ist eine Insel“nachgelesen werden, die auch online verfügbar ist[34, Setter und Getter nach der JavaBeans-Spezifikation].

Abbildung in dieser Leseprobe nicht enthalten

Das Reverse Engineering Tool soll nun nicht eine private Eigenschaft und zwei Methoden modellieren, sondern eine öffentliche, schreibgeschützte Eigen- schaft.

Einen Spezialfall hält diese Methode für boolean-Attribute bereit, denn dort soll der Getter mit “is“beginnen:

Abbildung in dieser Leseprobe nicht enthalten

Sequenzdiagramme

Sequenzdiagramme müssen durch statische und dynamische Analyse erstellt werden können. Im Idealfall wird in einer dynamischen Analyse zusätzlich auf Informationen aus der statischen Analyse zurückgegriffen, bzw. ist es möglich ein Sequenzdiagramm aus der statischen Analyse mit Hilfe von Execution Traces zu überprüfen und zu ergänzen.

Erweiterte Anforderungen

- Regeln, wie Wertegrenzen von Eigenschaften, sollen erkannt und dar- gestellt werden.
- Kommentare zu Klassen, Eigenschaften und Methoden nach Javadoc- Notation sollen erkannt und als Notizen eingebunden werden.
- Es sollen Design Patterns erkannt werden.
- Es sollen zusätzliche Informationen aus der Quellcodeverwaltung ge- neriert werden, damit die Unterschiede zwischen Versionen aufgezeigt werden können.
- Das Werkzeug soll sich in eine populäre IDE integrieren.
In Bezug auf JAVA-Entwicklung kann das nur bedeuten: Entweder Integration in Eclipse oder Integration in NetBeans.
- Das Austauschformat XMI soll unterstützt werden.

[...]

---

¹ Ansätze hierfür finden sich zum Beispiel in der MDA und Executable UML[16].

¹ Anerkannt, weil sie von vielen Autoren zitiert wird, zum Beispiel: Hasselbring und Reussner[21], Knoop[23], Larman[26], Tilley[33], Yu et al.[38]

² XMI (XML Metadata Interchange) ist ein offener Standard der OMG(Object Management Group) zur textlichen Beschreibung von UML-Diagrammen[28]