Deel 2 – Analyse van een bestaande applicatie met Altova UModel
In Deel 1 van de serie "Het analyseren van een bestaande applicatie" hebben we onze ATM-simulatie-app geïntroduceerd, de Java-broncode geïmporteerd in een UModel-project, en een klassendiagram verfijnd om een overzicht te krijgen van de applicatieklassen en hun relaties. In dit artikel gaan we gebruiksscenario's maken om de huidige functionaliteit van onze ATM-app te documenteren, en we zullen een gebruiksscenario uitbreiden om een toekomstige verbetering te plannen. Zoals we in Deel 1 zagen, wordt de gebruiker gevraagd om in te loggen met een rekeningnummer en pincode wanneer hij onze ATM-simulatie start, waarna een transactiemenu wordt getoond dat alle beschikbare interacties met de applicatie samenvat:
Met behulp van het menu "Transacties" kunnen we een overzichtelijk use case-diagram maken dat de interacties van de gebruiker met de geldautomaat-simulatie documenteert:
Als u bekend bent met UML-notatie, is het eerste wat u wellicht opvalt, dat de actor in ons diagram er niet uitziet als de typische UML-stickfiguur. UModel stelt softwaremodelleurs in staat om elk Windows .bmp-afbeeldingsbestand toe te wijzen om een actor in een use case-diagram weer te geven. We hebben het hulpmiddelvenster "Eigenschappen" gebruikt om een afbeelding uit de bibliotheek die bij UModel wordt geleverd, toe te wijzen.
Een use case diagram is niet de juiste plek om de applicatie-workflow of objectgeoriënteerde klassen te definiëren, maar simpelweg om te documenteren hoe een gebruiker (een actor in UML-terminologie) met het systeem interageert. We kunnen aanvullende use case diagrammen maken om meer details over elke interactie weer te geven. Het uitwerken van elke interactie in een apart diagram verbetert de duidelijkheid doordat elk diagram eenvoudig en overzichtelijk blijft, en er voldoende ruimte is om verschillende opties te verkennen.
We hebben de authenticatie van het rekeningnummer en de pincode toegevoegd in een notitie in plaats van in een use case-diagram, omdat de gebruiker van de geldautomaat niet de persoon is die die stap uitvoert. Op basis van onze ervaring met geldautomaten kunnen we (omdat we de code nog niet hebben bekeken) aannemen dat een opname wordt geannuleerd als het gevraagde bedrag hoger is dan het saldo op de rekening. Het vergelijken van het opnamebedrag en het rekeningtegoed wordt echter niet door de gebruiker uitgevoerd, dus die activiteit is ook niet weergegeven in een use case-diagram.
De pijl binnen het gebruiksscenario "Contant geld opnemen" geeft een hyperlink aan. Met UModel kunt u één of meerdere hyperlinks toevoegen aan elk element in uw diagrammen. Een hyperlink kan verwijzen naar een URL, een extern bestand of een ander diagram. Het dialoogvenster voor hyperlinks biedt zelfs de mogelijkheid om begeleidende tekst voor uw hyperlinks te definiëren.
Als u meer dan één hyperlink definieert, wordt uw hulptekst een pop-up selectiemenu. Stel dat we de bestaande ATM-simulatie moeten aanpassen om een kosten in rekening te brengen voor elke opname. Als het opnamebedrag minder is dan $100, is de kosten $2. Als het opnamebedrag $100 of meer is, is de kosten $4. Omdat de geldautomaat geen biljetten van $1 heeft, moet de kosten in rekening worden gebracht op de rekening, en niet afgetrokken van het contant geld dat wordt opgenomen. De kosten worden getoond voordat er contant geld wordt uitbetaald, en de gebruiker kan de transactie annuleren. We kunnen deze nieuwe vereiste toevoegen aan ons use case-diagram voor de ATM-opname.
We hebben de kleur van de ovale vorm voor het gebruiksscenario "Goedkeuring van kosten" veranderd om aan te geven dat dit een geplande functie is die nog niet is geïmplementeerd. Sommige ontwikkelaars zouden beargumenteren dat de toelichting die aan de ovale vorm voor "Goedkeuring van kosten" is toegevoegd, overbodig is, aangezien de "include"-aanduiding op zichzelf al aangeeft dat "Goedkeuring van kosten" een vereist onderdeel is van "Contant geld opnemen". Maar veel mensen zijn verward over het verschil tussen "include" en "extend", dus het is het beste om absoluut duidelijk te zijn. We kunnen ook gebruikmaken van de UModel-laagfunctie om alle elementen die betrekking hebben op de nieuwe functie op een aparte laag te plaatsen.
Nu maakt het hulpmiddelvenster "Lagen" het mogelijk om de geplande functie wel of niet weer te geven in onze diagramweergave.
De praktijkervaring met geldautomaten laat zien dat een transactie ontbreekt in de bestaande simulatie. Het transactiemenu biedt geen optie om geld over te maken tussen verschillende rekeningen. Uit de diagrammen die we al hebben gemaakt, blijkt dat het oorspronkelijke ontwerp van de applicatie het moeilijk zal maken om een overboeking te implementeren. De inlog van de gebruiker is gebaseerd op het rekeningnummer, en het lijkt erop dat de bestaande applicatie het concept van een enkele bankklant met zowel een betaalrekening als een spaarrekening niet begrijpt. Als onze manager de functie voor het overboeken van geld aanvraagt, moeten we een gesprek voeren met de enterprise software architect van ons bedrijf. Een gebruikers-ID die aan meerdere rekeningen is gekoppeld, moet niet alleen worden geïmplementeerd in onze ATM-simulatie-app, maar ook in de bankdatabase.
De met een Jolt-prijs bekroonde Altova MissionKit voor Enterprise Architecten is een verzameling van acht XML-, database- en UML-tools voor de softwarearchitect die, naast geavanceerde XML-, webdiensten- en data-integratiemogelijkheden, mogelijk ook UML-modelleringstools en databasebeheertools nodig heeft.
Klik hier om een volledig functionele proefversie van 30 dagen te downloaden. In de volgende aflevering zullen we de bestaande ATM-simulatie vanuit een compleet ander perspectief bekijken, terwijl we ons voorbereiden om de code te bestuderen.