Deel 3 – Analyse van een bestaande applicatie met Altova UModel

In Deel 1 van deze serie hebben we de reverse engineering-functionaliteit van Altova UModel gebruikt om broncode te importeren van een bestaande simulatieapplicatie voor geldautomaten. We hebben een UML-klasdiagram gemaakt om de klassenhiërarchie en de relaties tussen de klassen van de applicatie te illustreren. In Deel 2 hebben we een UML-gebruiksscenariodagram 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 (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:

Toen we de bestaande applicatie activeerden, ging onze gesimuleerde geldautomaat in de stand-by modus, in afwachting van de eerste klant:

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.

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:

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:

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:

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 In de volgende aflevering zullen we de opnametransactie en de nieuwe functie die we in deel 2 hebben gepland, in detail bekijken.