Graphbasiertes Reengineering

Graphbasiertes Reengineering
Seminar Model-Driven Software Development (MDSD)
Stefan Sosnicki
Inhaltsverzeichnis:
1. Einleitung
2. Graphbasiertes Reengineering
3. Vorstellung der Werkzeuge
3.1 Fujaba
3.1.1 Installation
3.1.2 Reverse Engineering
3.1.3 Restrukturierung und Forward Engineering
3.2 Jumli
3.3 Umodel
4. Vergleich der Werkzeuge
5. Reengineeren einer Java-Anwendung
6. Fazit
2
1. Einleitung
In der heutigen Softwaretechnik gewinnt die Verbesserung und Aufbereitung
von Software, neben der Neuentwicklung, eine immer größere Bedeutung (vgl.
dazu [2]). Es gibt einen großen Bestand an Software, die bereits seit vielen
Jahren eingesetzt wird und auch weiterhin intensive Wartung und Pflege
erfordert.
Softwaresysteme sind aber mit der Zeit vielen verschiedenen Entwicklungen
unterworfen, so kann sich die zugrundeliegende Architektur verändern, neue
Technologien werden entwickelt, die ebenfalls integriert werden müssen, oder
äußere Einflüsse erfordern eine Umstellung der Programme, um beispielsweise
neue Gesetzte zu beachten.
Viele dieser Altsoftware (engl. legacy systems) genannten Programme sind in
alten Programmiersprachen geschrieben oder auf veraltete Systemarchitekturen
zugeschnitten. Solche Altsoftware erschwert die Wartung in vielerlei Hinsicht.
So führen der unterschiedliche Programmierstil, mangelnde Dokumentation und
Kommentierung, und die Verwendung undurchsichtiger Optimierungen dazu,
dass das Programm kaum mehr zu verstehen und daher schwer zu warten ist.
Außerdem kann durch jahrelange Wartung die Übersichtlichkeit noch weiter
verloren gehen.
Allerdings kann man diese Programme nicht immer einfach durch neue ersetzen,
da sie oftmals eng mit den Geschäftsprozessen verknüpft sind und viel
unternehmensinternes Wissen enthalten. Dies, und die oben beschriebenen
Probleme führten zur Entwicklung des Reengineering.
In dieser Arbeit wird der Begriff des Graphbasierten Reengineerings im Rahmen
des Model-Driven Software Development betrachtet und anhand dreier
ausgewählter Tools verdeutlicht.
3
2. Graphbasiertes Reengineering
The Program Transformation Wiki [1] definiert Reengineering als:
„the examination and alteration of a subject system to reconstitute it in a new
form and the subsequent implementation of the new form“
Reengineering wird auch als Redevelopment oder Roundtrip-Engineering
bezeichnet. Beim Graphbasierten Reengineering handelt es sich um eine Form,
bei der graphbasierte Techniken in einem oder mehreren Schritten des
Reengineeringprozesses zum Einsatz kommen.
Der Prozess des Reengineerings wird im Allgemeinen in 3 Phasen unterteilt:
- das Reverse Engineering
- die Restrukturierung des Modells und
- das Forward Engineering.
Im Sinne des Model-Driven Software Development handelt es sich beim
Reverse Engineering um eine vertikale Modelltransformation von einer
niedrigeren in eine höhere Sprachebene. Bei der Restrukturierung des Modells
kann eine horizontale Transformation vorgenommen werden. Und beim
Forward Engineering handelt es sich wieder um eine vertikale Transformation
von der höheren in eine niedrigere Ebene, wobei dies nicht die gleich Sprache
wie vor dem Reverse Engineerung sein muss. Beim Software-Reengineering
wird diese Phase oft auch als Code Generierung bezeichnet. Beim
Graphbasierten Reengineering erfolgt die Transformation in bzw. aus einer
graphbasierten Sprache. Abbildung 1 stellt dies noch einmal schematisch dar.
Abbildung 1: Drei Phasen des Reengineering
4
Das Reverse Engineering dient dazu, das zu wartende Programm in eine
abstraktere Form zu bringen, um es besser verstehen und analysieren zu können.
Beim Graphbasierten Reengineering handelt es sich bei der abstrakteren Form
um eine graphische Sprache, beispielsweise UML.
Auf dieser Ebene wird das Programm umstrukturiert bzw. erweitert. Hierbei
kann es in andere Modelle dieser Ebene transformiert werden, beispielsweise die
Umwandlung einer Darstellung prozeduraler Programmsegmente in ein
objektorientiertes Modell. Bei der Restrukturierung werden meist gängige
Softwaremodellierungstechniken verwendet. In diese Phase des Reengineeringprozesses fallen auch andere Aufgaben, wie die Analyse und Problemerkennung.
Aus dem dabei entstandenen Modell wird mittels Forward Engineering
wiederum ein Modell in der niedrigeren Spracheebene generiert. Damit ist der
Reengineering Prozess abgeschlossen.
All diese Teilschritte können mit Hilfe jeweils einzelner Tools oder mit einem
einzigen, das diese Funktionen unterstützt, durchgeführt werden.
Ein solches Tool zum Graphbasierten Reengineering von Software unterstützt
mindestens eine Sprache für den Prozess des Reverse Engineerings und erlaubt
die Codegenerierung für ebenfalls mindestens eine Sprache. Dies kann die selbe
sein wie beim Reverse Engineering oder aber eine andere, je nach Einsatzgebiet
des Tools. So gibt es beispielsweise Tools, die dazu dienen Programme, welche
in veralteten Sprachen wie Cobol oder Fortran geschrieben sind, in moderne
Sprachen zu portieren. Für die Unterstützung der Restrukturierungsphase
werden meist vielfältige graphische Darstellungsformen und Designhilfen zur
Verfügung gestellt.
Viele dieser Tools wurden dafür konzipiert, den Softwareentwicklungsprozess
zu unterstützen. So steht bei ihnen das Reengineering nicht im Vordergrund,
sondern das Design und der Entwurf von Applikationen. Das Reverse
Engineering stellt eine Zusatzfunktion dar, mit deren Hilfe alte Programme neu
designt werden können, oder das Designmodell von, sich in der Entwicklung
befindlichen, Programmen aktualisiert werden kann. Es gibt aber auch
spezialisierte Werkzeuge, deren einzige Aufgabe das Reengineering von
bestimmten Programmen ist. Deren Aufgaben betreffen beispielsweise das
Portieren von einer Sprache in eine andere, oder die Kapselung prozeduralen
Codes in Objekte1.
1
Die Umwandlung prozeduralen Codes in objektorientierten geht meist auch mit der
Portierung in eine andere Sprache einher.
5
Es gibt auch Reengineering-Werkzeuge, die nicht mit graphischen Modellen
arbeiten. Diese sind meist in einer noch niedrigeren Sprachebene angesiedelt,
beispielsweise Decompiler, oder es bietet sich für ihre spezielle Aufgabe keine
graphische Darstellungsform an.
6
3. Vorstellung der Werkzeuge
Es gibt ein Vielzahl an Software, die Graphbasiertes Reengineering unterstützt.
Hier sollen 3 solche Programme untersucht und mit einander verglichen werden.
Alle 3 ähneln sich von der Art und Zielstellung her. Sie vertreten die geläufigste
Klasse von Reengineering-Tools. Diese 3 sind:
- Fujaba,
- Jumli und
- Altova UModel.
Fujaba ist ein Open-Source-Programm. Sein Name steht für „From UML to
Java and back again“. Es ist ein Softwareentwicklungstool für Java und
ermöglicht es dem Nutzer mit Hilfe von UML Diagrammen Programme zu
modellieren und daraus Java-Klassen zu generieren. Außerdem bietet es die
Möglichkeit einzelne Javadateien oder ganze Verzeichnisse zu importieren und
aus ihnen Klassendiagramme zu erzeugen.
Jumli ist ein Freeware-Programm, das primär zu Schulungszwecken entwickelt
wurde. Es ist eine Entwicklungsumgebung mit UML-Editor und unterstützt die
Sprachen C++, C# und Java und kann aus den UML-Diagrammen Code
generieren und aus Quelldateien auch wieder UML-Diagramme erstellen. Mit
dem UML-Editor kann eine Vielzahl an verschiedenen Diagrammen erstellt
werden.
Altova Umodel ist ein kommerzielles Produkt für die Modellierung und
Entwicklung von Applikationen in Java mit UML-Editor und umfangreichen
Funktionen der Codegenerierung und des Reverse Engineerings. Es verbindet
das Designmodell dauerhaft mit dem Code und ermöglicht es Änderungen auf
der einen Seite automatisch in die andere einfließen zu lassen.
3.1 Fujaba
Die Fujaba Tool Suite wird an der Universität Paderborn entwickelt. Es ist eine
durch Plugins erweiterbare Entwicklungsumgebung für UML und Java. Es
ermöglicht einem, aus dem mit UML erstellten Design, eine komplett lauffähige
Java-Anwendung zu generieren. Außerdem ermöglicht es auch die
Umkehrrichtung, so dass Java-Code geparst und in UML abgebildet werden
kann.
7
3.1.1 Installation
Es gibt auch eine Variante des Programms speziell für Reengineeringzwecke,
die Fujaba Tool Suite RE Edition, welche bereits mit Plugins für das
Reengineeren und die Design-Pattern-Erkennung konfiguriert ist. Jedoch laufen
manche der benötigten Plugins nicht mit der Version Fujaba Tool Suite RE
4.2.0. Daher empfiehlt es sich Fujaba Tool Suite Standard 4.3.1 zu verwenden
und die benötigten Plugins manuell zu installieren. Zu den benötigten Plugins
gehören:
- JavaAST 1.1, enthält einen abstrakten Syntaxbaum für Java-Dateien;
- JavaParser 3.1, Parser für Java-Quellcode;
- Inference Engine 2.1 zur Erkennung von Design Pattern;
- Pattern Specification 2.1, ermöglicht die Erstellung von Diagrammen
für die Spezifikation von Design Pattern;
- Pattern Recognition Engines Generator 1.1, kompiliert Design Pattern
Spezifikationen, damit sie von der Inference Engine verwendet werden
können und
- Association Detection 1.0 für die Erkennung von Assoziationen.
In der Version Fujaba Tool Suite RE 4.2.0 laufen das Plugin für die
Assoziationserkennung und die Erzeugung der Inference Engines nicht, da sie
wegen Abhängigkeiten zu anderen Komponenten, welche für Version 4.3.1
entworfen wurden, nicht installierbar sind. Außerdem wird noch ein Java SDK
ab Version 1.4 benötigt.
3.1.2 Reverse Engineering
Fujaba ermöglicht nicht nur die Generierung von UML-Klassendiagrammen aus
Java-Quellcode, sondern bietet auch eine Möglichkeit im Code verwendete
Design Pattern (Entwurfsmuster) zu erkennen. Design Pattern werden oftmals
beim Erstellen von Programmen verwendet und sind den meisten Entwicklern
geläufig. Daher hilft es dem Reengineerer ein Programm zu verstehen, wenn
solche Muster erkannt werden. Design Pattern werden gewöhnlich informal
beschrieben. Für eine computergestützte Erkennung solcher Entwurfsmuster
müssen diese aber formal beschrieben werden. Hierfür verwendet Fujaba eine
Patternspezifikationssprache basierend auf Graphgrammatiken und einen
iterativen und skalierbaren Ableitungsalgorithmus. Das Pattern Specification
Plugin bietet einen graphischen Editor für die Spezifikation von Design Pattern.
Die Pattern werden in Form von Graphtransformationsregeln beschrieben, die
den Abstract Syntax Graph (ASG) des Quellcodes verwenden. Das Anwenden
der Regeln resultiert in einer Erweiterung des ASG um Annotationselemente,
die mit einer beliebigen Anzahl von ASG Elementen verknüpft werden können.
8
Eine Regel ist durch eine linke und eine rechte Seite definiert. Die linke Seite
der Regel beschreibt die Struktur, die im ASG gefunden werden muss, wenn
eine Instanz dieser Regel existiert. Es können auch von anderen Regeln erzeugte
Annotationen enthalten sein, wodurch Kompositionen von Regeln möglich
werden. Außerdem werden Trigger für die Ausführung der Regel festgelegt.
Abbildung 2: zusammengesetzte Patternregel
Trigger und die Abhängigkeiten der Regeln untereinander bestimmen die
Ausführreihenfolge der Regeln. Die Abhängigkeiten innerhalb des gesamten
Kataloges werden in einem gesonderten Graphen dargestellt (siehe Abbildung
3).
Abbildung 3: Abhängigkeitsgraph
Die rechte Seite der Regel definiert das Annotationselement und Verbindungen
zu einzelnen ASG Elementen, die erzeugt werden, wenn die linke Seite erfüllt
ist. Ein solcher Katalog von Regeln wird in eine Pattern-Erkennungs-Maschine
übersetzt und kann dann bei der Patternableitung verwendet werden.
Nachdem der Quellcode geparst wurde kann die Patternerkennung gestartet
werden, indem ein Katalog von Regeln geladen wird. Der
Ableitungsalgorithmus verwendet ein Netz, in welchem die Regeln in Ebenen
organisiert werden, entsprechend ihrer Abhängigkeiten untereinander und der
9
Trigger. Basierend auf diesem Netz wendet der Algorithmus die Regeln nach
Prioritäten an, beginnend mit den unabhängigen. Erfolgreich angewandte Regeln
erzeugen Annotationen, welche wiederum Regeln auf höheren Ebenen auslösen.
Dies ist die Bottom-Up Methode der Ableitungsmaschine. Regeln auf höheren
Ebenen erhalten eine entsprechend höhere Ausführungspriorität, um schnell gute
Resultate zu erzielen. Höhere Regeln, die ausgeführt werden sollen, können aber
auch noch von Regeln abhängen die noch nicht überprüft wurden. In diesem Fall
wechselt die Ableitungsmaschine zum Top-Down Modus und versucht rekursiv
alle benötigten Regeln anzuwenden.
Die Ableitungsmaschine arbeitet semiautomatisch, da sie den Anwender mit
einbezieht. Dieser kann den Analysevorgang jederzeit pausieren und die bereits
erzielten Ergebnisse betrachten und gegebenenfalls die ermittelten
Wahrscheinlichkeiten ändern und die Analyse fortsetzen. Die gemachten
Änderungen werden dann bei der Bewertung berücksichtigt. Die Resultate der
Analyse, also die erstellten Annotationen, werden direkt im Klassendiagramm
angezeigt (siehe Abbildung 4).
Abbildung 4: Klassendiagramm mit erkannten Design Pattern
3.1.2 Restrukturierung und Forward Engineering
Fujaba bietet neben den gewohnten UML-Diagrammen auch ein erweitertes
Aktivitätendiagramm an. Darin lassen sich sogenannte Story Pattern
10
spezifizieren. In diesen wiederum können Objekte von, im Klassendiagramm
definierten, Klassen und Interaktionen zwischen diesen erstellt werden. Dies
ermöglicht es Funktionen der Klassen vollständig zu definieren, so dass bei der
Codegenerierung bereits lauffähige Programme entstehen. Objekte können
erzeugt und zerstört werden, ebenso wie Referenzen auf andere Objekte.
Außerdem können Constraints für die Ausführung der einzelnen Story Pattern
angegeben werden. Es kann auch direkt Javacode verwendet werden für
bestimmte Bereiche, beispielsweise um Story Pattern in eine Try-CatchAnweisung zu kapseln.
Abbildung 5: erweitertes Aktivitätsdiagramm
Der resultierende Quellcode kann jederzeit im Editor eingesehen werden. Er ist
teilweise mit speziellen Kommentaren versehen um Assoziationen kenntlich zu
machen. Für die Verwendung des Programms muss noch die RuntimeTools.jar
eingebunden werden.
11
3.2 Jumli
Jumli ist eine für Schulungszwecke entwickelte Entwicklungsumgebung mit
UML. Ursprünglich wurde nur Java als Zielsprache unterstützt, daher auch der
Name Java-UML-IDE. Doch mittlerweile können damit auch C++ und C#
Programmen entwickelt werden. Außerdem können auch wxWidgets-Projekte
erstellt werden. Dies ist eine freie und systemunabhängige
Oberflächenbibliothek. Die neueste Version von Jumli selbst wurde damit
erstellt. Die Unterstützung dieser drei Sprachen ist der große Vorteil von Jumli.
Allerdings müssen für die Einbindung von C++ neben einem Compiler auch
noch MSYS, eine GNU Toolsammlung, und tmake, zur Erzeugung von
Makefiles, installiert werden. Für die Verwendung von C# muss ebenso wie für
Java lediglich das SDK installiert werden.
Neben dem Entwurf von UML-Diagrammen und der Code-Generierung aus
diesen, bietet Jumli auch die Möglichkeit Quellcode-Dateien zu parsen und zu
analysieren, wodurch die entsprechenden Klassen erzeugt bzw. abgeändert
werden. Dies ermöglicht es dem Anwender auch, im Quellcode vorgenommene
Änderungen jederzeit mit den UML-Klassen zu synchronisieren. Die QuellcodeDateien müssen in der gleichen Sprache sein wie das Projekt. Jedoch ist es über
Umwege auch möglich beispielsweise C++-Dateien in ein Java-Projekt zu laden
und ihre Klassen ins UML-Diagramm einzufügen. Beim Analysieren von C++Dateien ist noch zu beachten, dass nur Klassen analysiert werden können, also
keine reinen C-Dateien. Abbildung 6 zeigt ein analysiertes C++-Projekt (in
Teilen). Jumli kann auch Assoziationen zwischen Klassen erkennen, jedoch
wird nicht jede richtig erkannt.
Abbildung 6: Reverse Engineering eines C++-Projektes
12
Bei der Code-Generierung werden nur Prototypen der Klassen erzeugt. Die
Methoden müssen noch von Hand programmiert werden. Hierfür bietet Jumli
einen eigenen Editor an. Wie bereits erwähnt können Quellcode und Modell
jederzeit miteinander abgeglichen werden, dabei wird stets nachgefragt welche
Änderungen am Modell vorgenommen werden sollen. Ist der Quellcode
fertiggestellt, so kann das Programm kompiliert und ausgeführt werden.
Debugging ist ebenfalls möglich. Standardklassen können aus dem jeweiligen
Development Kit in ein Diagramm importiert werden. Diese sind dann als
externe Klassen im Projekt verfügbar (siehe Abbildung 7), können jedoch nicht
verändert werden. Per Drag and Drop können Attribute oder Methoden auch
anderen Klassen zugewiesen werden.
Abbildung 7: Jumli-Projekt mit externen Klassen
Da Jumli zu Schulungszwecken entwickelt wurde gibt es eine umfangreiche
Tutorialsammlung, welche noch weiter ausgebaut werden soll.
3.3 Altova UModel
Altova UModel stellt ein ausgereiftes, kommerzielles Produkt für die
Modellierung von Java-Programmen mittels UML dar. Es bietet dem Nutzer
zahlreiche Komfortfunktionen, wie z.B. die Suche nach bestimmten Klassen
oder Diagrammen im Projekt, oder grafisches Hilfsfunktionen. Zudem bietet es
auch über große Projekte eine gute Übersicht, da es neben einem Überblickfenster für das aktuelle Diagramm auch 3 verschiedene Navigationssichten auf
das Projekt bietet:
- Die Model Tree Sicht stellt das Projekt als Baum dar, entsprechend
seiner Packages.
13
- Die Diagram Tree Sicht stellt sämtliche Diagramme des Projektes nach
Diagrammart geordnet dar, oder alle in alphabetischer Reihenfolge.
- Die Favorites Sicht erlaubt es durch ausgewählte UML Elemente zu
navigieren.
Abbildungs 8 zeigt die Oberfläche von UModel.
Abbildung 8: UModel Oberfläche
Neben der Verwendung von Standard UML Diagrammen bietet UModel auch
die Möglichkeit sogenannte Deployment- und Komponentendiagrammen zu
erstellen. Komponentendiagramme dienen dazu einzelne Klassen des Projekts
zu logischen Einheiten zusammenzufassen und die Realisierungsabhängigkeiten
zwischen den einzelnen Teilen, aber auch zwischen den Komponenten selbst,
darzustellen (siehe Abbildung 9).
Abbildung 9: Komponentendiagramm
14
Das Deploymentdiagramm wiederum zeigt, wie sich diese Komponenten in
Artefakten (z.B. jar-Archive) wiederspiegeln und wo sie zum Einsatz kommen
(Abbildung 10). Diese beiden Diagrammarten haben jedoch nur einen rein
dokumentierenden Charakter. Auf das zugrunde liegende Modell haben sie
keinen Einfluss.
Abbildung 10: Deploymentdiagramm
Im Projekt erstellte Packages können auch von anderen Projekten verwendet
werden, und sogar ganze Projekte können als Teilprojekte eingebunden werden.
Die Reverse Engineering Fähigkeiten von UModel beschränken sich auf das
Erzeugen von UML Klassen aus dem Quellcode und UML Dokumentation aus
den javadocs. Eine Assoziationserkennung gibt es nicht. Jedoch können einfache
Assoziationen mit zwei Mausklicks hinzugefügt werden. Es ist nicht nur der
Import von einzelnen Java-Dateien möglich, sondern auch der Import eines
ganzen Eclipse oder JBuilder Projektes. Außerdem steht ein
Kommandozeilentool zur Verfügung, mit dem sich bestimmte Vorgänge
automatisieren lassen. So kann beispielsweise eine neu erstellte Quellcode-Datei
automatisch ins Modell importiert werden.
Für die Code-Generierung verwendet UModel SPL Templates, welche man auch
selber anpassen kann. Somit lassen sich für bestimmte Anwendungsfälle mittels
entsprechender Templates mehr als nur reine Rümpfe von Klassen erstellen.
Zudem bietet UModel Unterstützung für UML Templates und ihre Anbindung
an Java 5.0 Generics. Ein Editor für die Bearbeitung des erzeugten Quellcodes
steht nicht zur Verfügung.
15
Eine stärke von UModel ist die Möglichkeit Model und Code bzw Code und
Model zu synchronisieren. Hierbei wird bei jeder vorzunehmenden Änderung
explizit nachgefragt. Nicht mehr benötigter Quellcode wird wahlweise
auskommentiert oder gelöscht. Die Synchronisation kann auf unterschiedlichen
Ebenen erfolgen, auf projekt-, Package- oder Klassenebene.
Ein Tutorial und eine umfangreiche Hilfe zu UModel sind im Programm
integriert, so dass die Bedienung recht einfach zu erlernen ist.
16
4. Vergleich der Werkzeuge
Als Kriterien für den Vergleich der drei Werkzeuge dienen die Plattformen, auf
denen die Programme lauffähig sind, Bewertung von Schwierigkeiten bei der
Installation, der Umfang der Dokumentation, die Stabilität des Programms im
Betrieb, da hierbei Probleme aufgetreten sind, welche Sprachen die einzelnen
Programme unterstützen und eine Bewertung der Fähigkeiten für die drei Phasen
des Reengineeringprozesses.
Kriterium
Jumli
UModel
Fujaba
Plattform
Windows, Linux
Windows
Windows, Mac, alle
weiteren mit Java
Unterstützung
Installation
Einfache
Einfache
Fujaba Tool Suite
Installation, für
Installation
RE 4.2.0 nicht voll
C++ weitere
(einmonatige
lauffähig,
Komponenten
Trialversion)
Installation der
erforderlich
benötigten Plugins
mühsam
Dokumentation
Umfangreiche Hilfe Umfangreiche Hilfe Manche Funktionen
und Tutorials
mit Tutorial
nicht dokumentiert
(Pattern
Spezifikation), nur
Tutorials von
Dritten
Stabilität
Kleinere Probleme Keine Fehler
Oftmals Neustart
mit externen
aufgetreten
des Programms
Klassen (Interfaces
erforderlich, Pluginwerden z.T. nicht
Inkompatibilitäten
als solche erkannt)
Sprachunterstützung Java, C++, C#
Java
Java
Reverse
Klassengenerierung, Klassengenerierung, Klassengenerierung,
Engineering
AssoziationsSynchronisation
Assoziationserkennung,
erkennung,
Synchronisation
Patternerkennung
Restrukturierung/
Standard UML
Standard UML mit Standard UML und
Modellierung
vielen
Story Pattern für
Komfortfunktionen Funktionssund weiteren
pezifikation
Diagrammarten
Forward
Einfache CodeEinfache CodeBeinahe
Engineering/ Code- Generierung,
Generierung,
vollständige CodeGenerierung
Synchronisation
Synchronisation,
Generierung, keine
Templates
Synchronisation
17
5. Fazit
Der große Vorteil von Jumli ist die Unterstützung gleich dreier Sprachen.
Zudem stellt es eine komplette Entwicklungsumgebung dar und ermöglicht dank
der Synchronisation ein komplettes Roundtrip-Engineering mit nur einem
Programm.
UModel ist als kommerzielles Produkt und nur für Windows nicht für jeden
einsetzbar. Es stellt jedoch eine sehr gute Modellierungsumgebung für JavaProgramme dar und die zahlreichen Zusatzfunktionen und
Synchronisationsmöglichkeiten erleichtern die Entwicklung großer Projekte.
Aufgrund seiner schwachen Reverse Engineering Fähigkeiten und dem
Schwerpunkt auf der Modellierungsphase ist es eher für die Gesamtentwicklung
eines Projekts und der automatischen Wartung des Modells geeignet.
Fujaba bietet mit dem Entwurf von Story Pattern und der Pattern Erkennung
innovative Funktionen. Die Pattern Erkennung macht es zu einem
leistungsstarken Reverse Engineering Tool und die Spezifikation von Story
Pattern ermöglicht die Generierung beinahe vollständiger Klassen aus dem
Modell. Jedoch eignet es sich wegen der mangelnden Stabilität und einer
fehlenden Synchronisationsmöglichkeit nicht so sehr für größere Projekte.
Je nach eigener Aufgabenstellung und Präferenzen eignet sich somit ein anderes
Tool zum Graphbasierten Reengineering.
18
Literatur:
[1] The Program Transformation Wiki, 31.01.2006,
http://www.program-transformation.org
[2] Jürgen Ebert, Konradin-Verlag, Grasbrunn, Informatiktage 2003,
Software-Reengineering - Umgang mit Software-Altlasten, Seiten 224-31
[3] Workshop Software Reengeneering, 31.01.2006,
http://www.uni-koblenz.de/~ist/wsr2004/
[4] Udo Gleich, Thomas Kohler, Juli 1997,
Tool-support for Reengeneering of object-oriented systems
http://www.iam.unibe.ch/~famoos/ESEC97/submissions/gleich.pdf
[5] Fujaba Homepage, 31.01.2006,
http://www.fujaba.de
[6] Jumli Hompage, 31.01.2006,
http://www.jumli.de
[7] Altova Umodel Homepage, 31.01.2006,
http://www.Altova.com/UModel
19