Deel 4 – Analyse van een bestaande applicatie met Altova UModel

In Deel 1 van deze serie hebben we broncode geïmporteerd in Altova UModel om een UML-project te creëren, en we hebben een klasdiagram van onze bestaande ATM-applicatie bekeken.

In Deel 2 hebben we een reeks UML-gebruiksscenario diagrammen gemaakt om de interacties van gebruikers met het systeem te beschrijven, en we hebben een verbetering van de applicatie gepland om een transactiekosten te implementeren.

In Deel 3 hebben we een UML-toestandsmachine diagram ontworpen om de werking van ons systeem verder te analyseren en te documenteren. In dit deel keren we terug naar de geplande verbetering. We zijn belast met de implementatie van een transactiekosten voor geldopnames: $2 voor opnames van minder dan $100 en $4 voor opnames van $100 of meer. In Deel 2 hebben we een use case diagram gemaakt om te laten zien hoe gebruikers met de nieuwe functionaliteit zullen interageren:

Op basis van onze oorspronkelijke analyse van de objectgeoriënteerde klassen in deel 1, weten we dat ons systeem een "Withdrawal"-klasse (opnameklasse) bevat, wat de logische plaats is om onze nieuwe functionaliteit te implementeren. We kunnen een nieuw klassendiagram voor de "Withdrawal"-klasse weergeven door deze te selecteren in de modelboom en vervolgens, via het contextmenu dat verschijnt bij een rechtermuisklik, een nieuw diagram te maken.

We hebben gekozen voor een hiërarchie diagram, zodat alle eigenschappen van de klasse "Opname" zichtbaar zijn, inclusief de overgenomen eigenschappen van de klasse "Transactie". Voordat we de functionaliteit voor kosten implementeren, hebben we nog een gerelateerde vraag die we moeten onderzoeken. We willen controleren of de huidige code een test bevat om ervoor te zorgen dat het opnamebedrag dat door de gebruiker wordt aangevraagd, niet hoger is dan het huidige saldo van de rekening. Een UML-sequentiediagram stelt ons in staat om de uitvoering van een opname te volgen. UModel kan automatisch sequentiediagrammen genereren op basis van de bewerkingen van omgekeerd geëngineerde klassen. We kunnen de bewerking "uitvoeren" in ons klassendiagram selecteren en vervolgens "Sequentiediagram genereren" kiezen in het contextmenu van UModel om het benodigde diagram te maken.

Het dialoogvenster voor het genereren van sequentiële diagrammen in UModel biedt verschillende opties die ons zullen helpen bij de implementatie van de nieuwe functionaliteit. We hebben gekozen voor "Automatisch bijwerken" omdat we het diagram later willen bijwerken nadat we de code hebben gewijzigd, en het weergeven van de code in een aparte laag kan ons helpen om ons te concentreren op de logica van de transactie.

De grootte van de schuifbalken geeft aan dat we slechts een klein deel van het sequentiële diagram in het huidige venster zien. We kunnen de weergave verkleinen om deze in het venster te laten passen, maar de tekst wordt waarschijnlijk onleesbaar. In plaats daarvan kunnen we gebruikmaken van de flexibele gebruikersinterface van UModel om de boomstructuur van het diagram en de eigenschappenvensters automatisch te verbergen. Dit stelt ons in staat om het hulpmiddelenvenster "Overzicht" te vergroten:

We kunnen het sequentiële diagram verkennen door het rode vierkant in het overzichtvenster te verslepen. Dit stelt ons in staat om snel de vergelijking tussen het opnamebedrag en het saldo van de rekening te vinden.

We kunnen ook de foutmeldingen zien die verschijnen als de geldautomaat niet voldoende contant geld bevat, of als het saldo op de rekening te laag is.

Laten we terugkeren naar het klassendiagram voor "Withdrawal" (geldopname) en daar de eigenschap "kosten" toevoegen, en de standaardwaarde instellen:

We zullen eerst een eerste versie van de implementatie van de kostenberekening maken, zonder de optie voor gebruikers om een transactie te annuleren. Door de broncode van ons model bij te werken, wordt de eigenschap "kosten" toegevoegd aan de klasse "Withdrawal". Vervolgens gaan we naar onze favoriete code-editor om de kostenberekening direct in het bestand "Withdrawal.java" te implementeren. Het testen van onze opnieuw gecompileerde applicatie laat het volgende zien:

Het beginbedrag was $147. Na een opname van $100, is het nieuwe saldo $43. Het bedrag van de transactiekosten wordt weergegeven in een nieuw bericht, en het eindsaldo is correct. Echter, het sequentiële diagram in ons UML-model is nu onjuist, omdat het de functionaliteit voor transactiekosten niet bevat. We kunnen het sequentiële diagram corrigeren door het UML-project bij te werken met de herziene broncode. Het venster "UModel Berichten" geeft aan dat wijzigingen in het bestand "Withdrawal.java" ervoor hebben gezorgd dat het sequentiële diagram opnieuw is gegenereerd. We kunnen eenvoudig door het diagram navigeren om onze nieuwe test van het opnamebedrag te vinden en te controleren of de transactiekosten verhoogd moeten worden naar $4.

Nu ons aangepaste sequentiële diagram de bijgewerkte werking van de geldautomaat grafisch weergeeft, kunnen we er zeker van zijn dat de gestresste automobilist die we in deel 3 van deze serie ontmoetten, genoeg geld heeft om die ijsje te kopen! In het volgende deel zullen we gebruikmaken van een andere functie van UModel om uitgebreide projectdocumentatie te genereren voor ons werk tot nu toe – nog een voordeel van het synchroniseren van ons UML-model en de broncode van de applicatie.

Als u Altova UModel wilt uitproberen op uw bestaande Java-, C#- of Visual Basic-applicatie, klik hier om een gratis, volledig functionele proefversie van 30 dagen te downloaden.