---
title: "Teil 3 – Analyse einer bestehenden Anwendung mit Altova UModel"
date: "2009-05-01"
tags: 
  - "altova"
  - "c"
  - "java"
  - "missionkit"
  - "software-modeling"
  - "uml"
  - "uml-tool"
  - "umodel"
  - "visual-basic"
description: Erfahren Sie, wie Sie mithilfe von UML-Zustandsautomaten in Altova UModel ältere Anwendungen analysieren können, um Ihr Verständnis von Systemzuständen und -übergängen zu verbessern.
---
Status: #blog

Tags:  #altova #c #java #missionkit #software-modeling #uml #uml-tool #umodel #visual-basic

Categories: [Altova](/blog/de/category/altova.md) 
# Teil 3 – Analyse einer bestehenden Anwendung mit Altova UModel

In [Teil 1](https://www.altova.com/blog/2009/04/analyzing-legacy-application-with.html) dieser Reihe haben wir die [Reverse-Engineering-Funktion](https://www.altova.com/de/features_reverse_engineer.html) von [Altova UModel](https://www.altova.com/de/products/umodel/uml_tool.html) verwendet, um Quellcode aus einer bestehenden Simulationsanwendung für Geldautomaten zu importieren. Wir haben ein UML-[Klassendiagramm](https://www.altova.com/de/features_class_diagram.html) erstellt, um die Klassenstruktur und die Beziehungen zwischen den Klassen der Anwendung zu veranschaulichen. In [Teil 2](https://www.altova.com/blog/2009/04/part-2-analyzing-legacy-application.html) haben wir ein UML-[Anwendungsfalldiagramm](https://www.altova.com/de/features_use_case.html) erstellt, um die Interaktionen der Benutzer mit dem System zu dokumentieren, und wir haben mehrere zusätzliche Anwendungsfalldiagramme erstellt, um Interaktionsdetails und eine geplante Erweiterung zu dokumentieren. In dieser Ausgabe werden wir den Geldautomaten aus einer anderen Perspektive betrachten. 

An einem heißen Sommertag entdeckt ein gestresster Autofahrer eine Eisdiele mit einer Durchfahrtsmöglichkeit. Da gibt es jedoch ein Problem: Er hat kein Bargeld dabei! Also biegt er in den Parkplatz eines Einkaufszentrums ein und parkt neben einem Geldautomaten in einer Glaskabine. Bevor er überhaupt aus dem Auto steigt, fragt sich unser überhitzter Bankkunde, ob der Geldautomat funktioniert. Nutzt vielleicht schon ein anderer Kunde ihn für komplizierte Bankgeschäfte? Und selbst wenn sich niemand in der Kabine befindet, könnte der Geldautomat möglicherweise außer Betrieb sein? 

Ein UML-Diagramm [Zustandsdiagramm](https://www.altova.com/de/features_state_machine_diagram.html) (auch Zustandsdiagramm genannt) ermöglicht es uns, die Zustände unseres simulierten Geldautomaten sowie die Auslöser, Ereignisse und Übergänge zwischen den Zuständen abzubilden, sodass wir besser verstehen können, wie unsere bestehende Anwendung funktioniert. Kehren wir nun erneut zu unserer Erfahrung mit der Simulation zurück, um zu beginnen: 

[![Menü zur Anmeldung für die ATM-Simulation](https://lh5.ggpht.com/_REdrfeVqYdU/Sfsxmyu-x6I/AAAAAAAAAFc/1ttoVt3gF-Q/image1_thumb%5B1%5D.gif?imgmax=800 "ATM Simulation Log In menu")](http://lh6.ggpht.com/_REdrfeVqYdU/Sfsxm31zkpI/AAAAAAAAAFY/DTDB2hmhH48/s1600-h/image1%5B3%5D.gif)

[![Menü für Transaktionen bei der Simulation eines Geldautomaten](https://lh3.ggpht.com/_REdrfeVqYdU/SfsxoBbTouI/AAAAAAAAAFk/05wRGaLq5P0/image2_thumb%5B2%5D.gif?imgmax=800 "ATM Simulation Transaction Menu")](http://lh3.ggpht.com/_REdrfeVqYdU/SfsxnsG1tVI/AAAAAAAAAFg/hHwOLukZxYk/s1600-h/image2%5B4%5D.gif) 

Als wir die bestehende Anwendung starteten, wechselte unser simuliertes Geldautomat in den Ruhezustand und wartete auf den ersten Kunden: 

[![UML-Zustandsdiagramm, Beginn](https://lh5.ggpht.com/_REdrfeVqYdU/SfsxoWNUKRI/AAAAAAAAAFs/MpZ4Vt9WJ5o/image3_thumb%5B1%5D.gif?imgmax=800 "UML State Machine Diagram start")](http://lh5.ggpht.com/_REdrfeVqYdU/SfsxoA_hNqI/AAAAAAAAAFo/bm_h5hrfDLI/s1600-h/image3%5B3%5D.gif) 

Als Nächstes kann es hilfreich sein, zusätzliche Zustände zu identifizieren und in separaten, ovalen Formen darzustellen. Wir können diese Ovalformen wie Puzzleteile verschieben, um die logische Reihenfolge zu finden, ohne uns Gedanken über die Übergänge von einem Zustand zum nächsten machen zu müssen.

[![UML-Zustandsautomaten-Diagramm – vorläufig](https://lh3.ggpht.com/_REdrfeVqYdU/Sfsxo2BkWJI/AAAAAAAAAF0/fymyDQyuM9E/image4_thumb%5B1%5D.gif?imgmax=800 "UML state machine diagram - preliminary")](http://lh6.ggpht.com/_REdrfeVqYdU/Sfsxor2MyNI/AAAAAAAAAFw/bFiRGAyCknE/s1600-h/image4%5B3%5D.gif) 

Diese vorläufige Liste der Zustände des Geldautomaten ist nur unser erster Entwurf. Die Zustandsbeschreibungen wurden von den Menüeinträgen unserer bestehenden Anwendung vorgeschlagen, und es ist offensichtlich, dass wir vereinfachen können:

*   Es gibt keinen Unterschied zwischen "Erste Transaktion auswählen" und "Nächste Transaktion auswählen", daher sollten diese zusammengefasst werden.
*   "Abmelden" ist wahrscheinlich kein Zustand, sondern ein sofortiger Übergang, wenn unser Benutzer die Taste 4 im Transaktionsmenü drückt.
*   Wir können die Eingabe des Benutzers eines Abhebungsbetrags oder eines Einzahlungsbetrags als Unterzustände innerhalb des Zustands "Transaktion durchführen" zuordnen.
*   Der dritte Punkt vereinfacht unser Diagramm und würde auch mit unserer Behandlung der Eingabe der Kontonummer und des PIN-Codes durch den Benutzer als Teil der Benutzerauthentifizierung übereinstimmen.

Nachdem wir diese Änderungen vorgenommen und Übergänge hinzugefügt haben, sieht unser Diagramm wie folgt aus: 

[![UML-Diagramm für Zustandsautomaten mit Übergängen](https://lh3.ggpht.com/_REdrfeVqYdU/SfsxpSLK3aI/AAAAAAAAAF8/Mw8IcBdYQco/image5_thumb%5B1%5D.gif?imgmax=800 "UML state amachine diagram with transitions")](http://lh5.ggpht.com/_REdrfeVqYdU/Sfsxo2pmqZI/AAAAAAAAAF4/Vrgu1Fxt8P8/s1600-h/image5%5B3%5D.gif)

Die einfachen Übergänge, die wir hinzugefügt haben, sind Auslöser, die dazu führen, dass das Geldautomat-System einen Zustand verlässt und in den nächsten übergeht. Beachten Sie außerdem, dass jeder Zustand mindestens einen Eintritt und einen Austritt hat – andernfalls könnte die bestehende Anwendung unseren Benutzer in eine Sackgasse zwingen. Das Diamanten-Element zwischen "Transaktion auswählen" und "Transaktion ausführen" ist das UML-Symbol für eine Auswahl von Abläufen. Es mag zunächst unlogisch erscheinen, dass die Anwendung dem Benutzer erlaubt, sich abzumelden, bevor er eine Transaktion durchführt, aber dies ist eine Option, die unsere bestehende Anwendung im Transaktionsmenü bietet. Und es ist bekannt, dass Benutzer in der realen Welt ihre Meinung oft im letzten Moment ändern! Wir haben darauf geachtet, wo immer möglich, eine konsistente Sprache für die Namen und Beschreibungen unserer Elemente zu verwenden. Die Zustände sind mit Verben im Präsens benannt, die auf "-ing" enden. Die Übergänge sind beschriftet, um den Abschluss der Aktion anzuzeigen, die den Zustandswechsel verursacht. Eine konsistente Benennung der Elemente erhöht die Übersichtlichkeit des Diagramms. 

Sobald wir ein funktionsfähiges Zustandsdiagramm wie das oben gezeigte haben, ist es sinnvoll, darüber nachzudenken, was passiert, wenn ein Übergang versucht, aber nicht erfolgreich abgeschlossen wird. Ein ATM-Nutzer könnte beispielsweise eine ungültige Kontonummer/PIN-Kombination eingeben, oder ein authentifizierter Nutzer könnte einen Abhebungsbetrag anfordern, der den Kontostand übersteigt. Wir können unser Zustandsdiagramm erweitern, um diese Möglichkeiten zu berücksichtigen: 

[![Vollständiges UML-Zustandsautomaten-Diagramm](https://lh3.ggpht.com/_REdrfeVqYdU/SfsxpgAdy6I/AAAAAAAAAGE/9yJi6CFcN-M/image6_thumb%5B1%5D.gif?imgmax=800 "Complete UML state machine diagram")](http://lh6.ggpht.com/_REdrfeVqYdU/SfsxpSQ190I/AAAAAAAAAGA/xtG56Cmeogs/s1600-h/image6%5B3%5D.gif) 

Unser Zustandsdiagramm zeigt nun viele alternative Pfade innerhalb der Anwendungsabfolge, nicht nur den einen, stets erfolgreichen "idealen Pfad". Wir haben eine vertikale Anordnung für unser Diagramm gewählt, aber es gibt keine Regel, die diese Form vorschreibt. Einige Anwendungen eignen sich möglicherweise besser für eine horizontale Anordnung, oder es ist vielleicht einfach nur eine persönliche Präferenz. Diese Abbildung zeigt einen kleinen Ausschnitt unseres Zustandsdiagramms in horizontaler Form: 

[![UML-Zustandsautomaten-Diagramm in horizontaler Anordnung](https://lh6.ggpht.com/_REdrfeVqYdU/SfsxqJJG08I/AAAAAAAAAGM/kpCKzjysbwI/image7_thumb%5B1%5D.gif?imgmax=800 "UML state machine diagram in horizontal layout")](http://lh4.ggpht.com/_REdrfeVqYdU/Sfsxp61lanI/AAAAAAAAAGI/jd9Ogb8-01k/s1600-h/image7%5B3%5D.gif) 

Egal für welches Layout Sie sich bei der Darstellung des Zustandsautomaten entscheiden, Sie sollten keine Übergangsverbindungen zeichnen, die sich kreuzen oder überlappen. Das Erstellen eines UML-Zustandsautomaten-Diagramms mag für unsere ATM-Simulation übertrieben erscheinen, da die bestehende Anwendung klein ist und wir alle mit der Funktionsweise von Geldautomaten vertraut sind. Diese Techniken können jedoch sehr aufschlussreich sein, wenn Sie an einer viel größeren Anwendung arbeiten, die in einem unbekannten oder komplexen Themenbereich eingesetzt wird. 

Wenn Sie bereit sind, UML-Zustandsdiagramme für Ihre bestehenden Java-, C#- oder Visual Basic-Anwendungen zu erstellen, [klicken Sie hier, um eine kostenlose, voll funktionsfähige 30-Tage-Testversion von Altova UModel herunterzuladen](https://www.altova.com/de/download/umodel/uml_tool_enterprise.html) In unserem nächsten Abschnitt werden wir uns detailliert mit der Abbuchungstransaktion und der neuen Funktion befassen, die wir in Teil 2 geplant haben.
