---
title: "Deel 3 – Analyse van een bestaande applicatie met Altova UModel"
date: "2009-05-01"
tags: 
  - "altova"
  - "c"
  - "java"
  - "missionkit"
  - "software-modeling"
  - "uml"
  - "uml-tool"
  - "umodel"
  - "visual-basic"
description: Ontdek hoe u legacy-applicaties kunt analyseren met behulp van UML-toestandsmachine-diagrammen in Altova UModel, waardoor u uw begrip van systeemtoestanden en -transities kunt verbeteren.
---
Status: #blog

Tags:  #altova #c #java #missionkit #software-modeling #uml #uml-tool #umodel #visual-basic

Categories: [Altova](/blog/nl/category/altova.md) 
# Deel 3 – Analyse van een bestaande applicatie met Altova UModel

In [Deel 1](https://www.altova.com/blog/2009/04/analyzing-legacy-application-with.html) van deze serie hebben we de [reverse engineering](https://www.altova.com/nl/features_reverse_engineer.html)-functionaliteit van [Altova UModel](https://www.altova.com/nl/products/umodel/uml_tool.html) gebruikt om broncode te importeren van een bestaande simulatieapplicatie voor geldautomaten. We hebben een UML-[klasdiagram](https://www.altova.com/nl/features_class_diagram.html) gemaakt om de klassenhiërarchie en de relaties tussen de klassen van de applicatie te illustreren. In [Deel 2](https://www.altova.com/blog/2009/04/part-2-analyzing-legacy-application.html) hebben we een UML-[gebruiksscenariodagram](https://www.altova.com/nl/features_use_case.html) gemaakt om de interacties van de gebruiker met het systeem te documenteren, en we hebben verschillende aanvullende gebruiksscenariodagrammen gemaakt om details van de interacties en een geplande verbetering te documenteren. In dit deel zullen we de geldautomaat vanuit een ander perspectief bekijken. 

Op een hete zomermiddag ziet een gehaaste automobilist een ijskar met een doorrijstrook voor zich. Er is echter één probleem: geen contant geld! Dus draait hij de auto een parkeerplaats van een winkelcentrum in en parkeert bij een geldautomaat in een glazen kiosk. Voordat hij zelfs maar uit de auto stapt, vraagt onze oververhitte bankklant zich af in welke staat de geldautomaat verkeert. Gebruikt al een andere klant hem misschien voor ingewikkelde bankzaken? En zelfs als er niemand in de kiosk is, kan de geldautomaat dan misschien buiten werking zijn? 

Een UML-diagram [toestandsdiagram](https://www.altova.com/nl/features_state_machine_diagram.html) (ook wel een toestandsdiagram genoemd) stelt ons in staat om de toestanden van onze gesimuleerde geldautomaat in kaart te brengen, evenals de triggers, gebeurtenissen en overgangen tussen de toestanden, zodat we beter kunnen begrijpen hoe onze bestaande applicatie werkt. Laten we terugkeren naar onze ervaring met het uitvoeren van de simulatie om te beginnen: 

[![Menu voor het inloggen bij de simulatie van een geldautomaat](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)

[![Simulatie van een geldautotransactie: menu](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) 

Toen we de bestaande applicatie activeerden, ging onze gesimuleerde geldautomaat in de stand-by modus, in afwachting van de eerste klant: 

[![UML-diagram van een toestandsmachine, begin](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) 

Vervolgens kan het nuttig zijn om aanvullende toestanden te identificeren en deze als afzonderlijke, ovale vormen weer te geven. We kunnen deze ovalen verplaatsen, alsof het stukjes van een puzzel zijn, om de logische volgorde te vinden, zonder ons zorgen te maken over de overgangen van de ene toestand naar de andere.

[![UML-diagram van toestandsmachine - voorlopig](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) 

Deze voorlopige lijst van ATM-statussen is slechts een eerste, ruwe versie. De beschrijvingen van de statussen zijn gebaseerd op de menu-items van onze bestaande applicatie, en het is duidelijk dat we deze kunnen vereenvoudigen:

* Er is geen verschil tussen "Eerste transactie selecteren" en "Volgende transactie selecteren", dus deze moeten worden samengevoegd.
* "Uitloggen" is waarschijnlijk geen status, maar een directe overgang wanneer de gebruiker op 4 drukt in het transactiemenu.
* We kunnen de invoer van een opnamebedrag of een stortingsbedrag door de gebruiker als sub-statussen toewijzen binnen de status "Transactie uitvoeren".
* Het derde punt vereenvoudigt ons diagram en sluit ook aan bij onze manier van omgaan met de invoer van het rekeningnummer en de pincode als onderdeel van de authenticatie van de gebruiker.

Nadat we deze wijzigingen hebben aangebracht en de overgangen hebben toegevoegd, ziet ons diagram er als volgt uit: 

[![Een UML-diagram van een toestandsmachine met overgangen](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)

De eenvoudige overgangen die we hebben toegevoegd, zijn triggers die ervoor zorgen dat de geldautomaat de ene toestand verlaat en de volgende binnengaat. Let op dat elke toestand minstens één in- en één uitgang heeft; anders zou de bestaande applicatie onze gebruiker in een impasse kunnen brengen. Het diamanten element tussen "Transactie selecteren" en "Transactie uitvoeren" is het UML-symbool voor een keuze tussen verschillende verlooprichtingen. In eerste instantie lijkt het misschien onlogisch dat de applicatie de gebruiker de mogelijkheid biedt om uit te loggen voordat een transactie is uitgevoerd, maar dat is een optie die onze bestaande applicatie biedt in het transactiemenu. En in de praktijk blijkt dat gebruikers soms op het laatste moment van gedachten kunnen veranderen! We hebben er zorgvuldig voor gezorgd om waar mogelijk consistente terminologie te gebruiken voor de namen en beschrijvingen van onze elementen. De toestanden zijn benoemd met werkwoorden in de tegenwoordige tijd die eindigen op "-ing". De overgangen zijn gelabeld om aan te geven dat de actie die de toestandwijziging veroorzaakt, is voltooid. Een consistente benaming van de elementen verbetert de duidelijkheid van het diagram. 

Zodra we een werkend overzicht van een toestandsdiagram hebben, zoals hierboven getoond, is het nuttig om te overwegen wat er gebeurt als een overgang wordt geprobeerd, maar niet succesvol wordt voltooid. Een gebruiker van een geldautomaat kan bijvoorbeeld een ongeldige combinatie van rekeningnummer/PIN invoeren, of een geauthenticeerde gebruiker kan een opnamebedrag aanvragen dat hoger is dan het saldo op de rekening. We kunnen ons toestandsdiagram uitbreiden om deze mogelijkheden mee te nemen: 

[![Volledig UML-toestandsmachine diagram](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) 

Nu toont ons diagram van de toestandsmachine veel verschillende paden door de applicatie, en niet alleen het ene, altijd succesvolle "optimale pad". We hebben gekozen voor een verticale lay-out voor ons diagram, maar er is geen regel die bepaalt dat dit de enige optie is. Sommige applicaties lenen zich beter voor een horizontale lay-out, of misschien is dat gewoon uw persoonlijke voorkeur. Deze illustratie toont een klein deel van ons diagram van de toestandsmachine in horizontale vorm: 

[![UML-toestandsmachine diagram in horizontale lay-out](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) 

Welke lay-out voor het diagram van de toestandsmachine u ook kiest, u moet geen overgangslijnen tekenen die elkaar kruisen of overlappen. Het tekenen van een UML-diagram van een toestandsmachine lijkt misschien overbodig voor onze simulatie van een geldautomaat, aangezien de bestaande applicatie klein is en we allemaal bekend zijn met de werking van geldautomaten. Echter, deze technieken kunnen zeer verhelderend zijn wanneer u aan een veel grotere applicatie moet werken die in een onbekend of complex vakgebied functioneert. 

Als u klaar bent om UML-toestandsdiagrammen te maken voor uw bestaande Java-, C#- of Visual Basic-applicatie, [klik hier om een gratis, volledig functionele proefversie van 30 dagen van Altova UModel te downloaden](https://www.altova.com/nl/download/umodel/uml_tool_enterprise.html) In de volgende aflevering zullen we de opnametransactie en de nieuwe functie die we in deel 2 hebben gepland, in detail bekijken.
