Analyse einer Legacy-Anwendung mit Altova UModel – Teil 1

Früher oder später wird fast jeder professionelle Entwickler damit beauftragt, Fehler in einer bestehenden Anwendung zu beheben oder neue Funktionen hinzuzufügen, an deren Entwicklung er selbst nicht beteiligt war. In solchen Situationen können ungenaue oder unvollständige Dokumentation sowie der fehlende Zugang zum ursprünglichen Entwicklungsteam große Hindernisse darstellen. Glücklicherweise kann Altova UModel bestehende Software rückentwickeln, um ein visuelles Modell zu erstellen, das die Analyse beschleunigt und das Verständnis einer älteren Anwendung verbessert. Dies ist der erste Beitrag einer Reihe, in der wir UModel, ein Produkt von Altova, vorstellen werden Ein UML-Tool für die Softwaremodellierung und Entwicklung, um eine in Java geschriebene Simulation eines Geldautomaten (ATM) zu analysieren. Die Anwendung basiert auf verschiedenen Beispielen für Geldautomaten, die in populären Java-Tutorials vorgestellt werden. Da das Beispiel klein ist und die Funktionsweise eines Geldautomaten bekannt ist, werden wir uns stärker auf Techniken konzentrieren, die Sie in Ihren eigenen Java-, C#- und Visual Basic-Projekten anwenden können, anstatt auf den Beispielcode selbst. Hier ist ein Screenshot der Legacy-Anwendung, die in einem Befehlsfenster ausgeführt wird:

Der ursprüngliche Entwickler hat uns freundlicherweise die Anmeldedaten für ein Testkonto zur Verfügung gestellt, sodass wir uns anmelden können. Die Anwendung zeigt dann ein bekanntes Menü für Geldautomaten-Transaktionen an:

Wenn wir den Ordner, der die Anwendung enthält, untersuchen, sehen wir Java-Quellcode-Dateien und kompilierte .class-Dateien, aber keine Projektdateien.

Das ist kein Problem. Das Menü "UModel-Projekt" ermöglicht es uns, ein Projekt, ein Quellverzeichnis oder sogar die Binärdateien einer kompilierten Anwendung zu importieren. Der Quellcode für sehr große Projekte ist wahrscheinlich in mehreren Ordnern organisiert, daher kann es sinnvoll sein, auch wenn Sie eine Projektdatei haben, jeden Ordner einzeln zu untersuchen.

Bevor wir beginnen, sollten wir sicherstellen, dass die Optionen von UModel so eingestellt sind, dass alle in dem Quellcode definierten Klassenbeziehungen automatisch gezeichnet werden:

Beim Import des Ordners möchten wir auch alle JavaDoc-Kommentare im Quellcode als Dokumentation für unser UModel-Projekt einbeziehen

Für unsere erste Betrachtung der bestehenden Anwendung möchten wir einen Überblick auf hoher Ebene erhalten, daher werden wir nicht alle optionalen Bereiche öffnen:

UModel importiert das Projekt in wenigen Sekunden, und das Nachrichtenfenster meldet keine Fehler. Der Diagrammbaum enthält zwei Diagramme:

Wir können auf den Reiter "Modellstruktur" klicken und den Quellordner erweitern, um die Symbole anzuzeigen, die alle von UModel importierten Java-Klassen repräsentieren

Wir können zum Diagrammbaum zurückkehren, um den Inhalt der Quelle anzuzeigen UML-Klassendiagramm. Nachdem wir alle Linienstile auf orthogonal eingestellt und einige Linien und Klassen neu positioniert haben, um Überlappungen zu vermeiden, zeigt das Diagramm deutlich die Anwendungsklassen und ihre Beziehungen:

Beachten Sie, dass der Name der Transaktionsklasse kursiv dargestellt ist, was darauf hinweist, dass es sich um eine abstrakte Klasse (oder eine Oberklasse) handelt. Die Unterklassen BalanceInquiry, Withdrawal und Deposit erben deren Eigenschaften. Wenn Sie auf die Transaktionsklasse klicken, um sie auszuwählen, wird die Vererbung im Hilfefenster "UModel Hierarchy" dargestellt, und alle JavaDoc-Kommentare, die im Quellcode unmittelbar vor der Klassendefinition erscheinen, werden im Dokumentationsfenster angezeigt

Wenn wir lediglich einen Texteditor verwenden würden, um die bestehende Anwendung zu untersuchen, müssten wir jede einzelne Quelldatei durchsehen, um die oben gezeigte Hierarchie zu verstehen. Das liegt daran, dass die Klasse "Transaction" ihre Unterklassen nicht intern identifiziert. Wenn wir eine Unterklasse finden, identifiziert diese nicht ihre "Geschwister". Und wir können nicht sicher sein, ob eine andere, möglicherweise unlogisch benannte Klasse keine Unterklasse von "Transaction" ist, bis wir sie alle überprüft haben. Sie können jede Klasse einzeln auswählen, um ihre Dokumentation im Dokumentationsfenster anzuzeigen. Oder, wenn Sie ein übersichtlicheres Diagramm bevorzugen, können Sie die Bezeichnungen der Beziehungen im Diagramm entfernen:

Jetzt ist der Stern, der die "null bis viele"-Multiplizität von Konten in der Bankdatenbank repräsentiert, viel deutlicher erkennbar.

Ein weiteres Mitglied unseres Entwicklungsteams hat ein teilweise vollständiges Klassendiagramm gefunden, das angeblich das bestehende Projekt darstellen soll, und es weitergeleitet. Wir können sofort erkennen, dass es sich nicht wie das von UModel generierte Diagramm sieht:

Die Dokumentation für unsere ältere Anwendung stimmt nicht mit dem Code überein – ein leider häufiges, aber unerfreuliches Ereignis! Es gibt mehrere Unterschiede zwischen dem alten Diagramm und dem, das wir erstellt haben:

· The associations between ATM and the physical components are shown as composition associations

· The association between ATM and the BankDatabase is described by a text annotation

· The association between ATM and Transaction also has a text annotation, and it does not even exist in the UModel diagram

· Multiplicity is defined at each end of each association, but none were created by UModel

Betrachten wir nun jeden einzelnen Punkt:

· The representation of composition in the Java language is identical to ordinary association, so UModel could not deduce the composition characteristic. Of course the ATM “is composed of” a keypad, screen, cash dispenser, and deposit slot, so we can update the diagram to show composition.

· We can add a text annotation to any UModel association arrow. Simply click the arrow and start typing.

· If UModel did not create an association arrow between the ATM class and the Transaction, one must not be defined in the source code. We will postpone further investigation of this anomaly for now. · Multiplicity as shown in the legacy diagram would also require specific definition in the source code. We’ll leave this for investigation later too. Maybe that old diagram was left in the back of the file cabinet for a reason!

Wir fügen die Anmerkung hinzu und aktualisieren dann die Aggregationscharakteristik jeder ATM-Beziehung im Eigenschaftenfenster von UModel. Verwenden wir außerdem die Symbolleiste "Layout" in UModel, um die Rechtecke, die alle Klassen darstellen, alle gleich groß zu machen. Unser Klassendiagramm sieht nun wie folgt aus:

Das fertige Klassendiagramm ist erst der Anfang unserer Analyse. In den folgenden Abschnitten werden wir tiefer in den Anwendungscode eintauchen, automatisch weitere UML-Diagramme generieren und im Laufe unseres Verständnisses des bestehenden Codes eigene Diagramme erstellen.

Wenn Sie sofort damit beginnen möchten, Ihre eigenen älteren Java-, C#- oder Visual Basic-Anwendungen zu analysieren und umzugestalten, klicken Sie hier, um eine kostenlose, voll funktionsfähige 30-Tage-Testversion von Altova UModel herunterzuladen.