Parte 3: Analisi di un'applicazione legacy con Altova UModel

In Parte 1 di questa serie, abbiamo applicato ingegneria inversa funzionalità di Altova UModel per importare il codice sorgente da un'applicazione di simulazione di bancomat esistente. Abbiamo creato un diagramma UML diagramma di classe per illustrare la gerarchia delle classi e le relazioni tra le classi dell'applicazione. In Parte 2 Abbiamo creato un diagramma UML diagramma dei casi d'uso per documentare le interazioni degli utenti con il sistema, e abbiamo creato diversi diagrammi di casi d'uso aggiuntivi per documentare i dettagli delle interazioni e un miglioramento previsto. In questa parte, analizzeremo il bancomat da un'altra prospettiva.

In una calda giornata estiva, un automobilista stressato nota, in lontananza, una bancarella di gelati con un'area di servizio per chi passa in auto. C'è solo un problema: non ha contanti! Allora, svolta verso un parcheggio di un centro commerciale e si ferma vicino a un bancomat situato in una cabina di vetro. Prima ancora di scendere dall'auto, il nostro cliente, a disagio a causa del caldo, si chiede quali siano le condizioni del bancomat. Potrebbe essere già in uso da un altro cliente che ha bisogno di effettuare operazioni bancarie complesse? E anche se non c'è nessuno all'interno della cabina, potrebbe essere che il bancomat non sia funzionante?

Un diagramma a stati UML (chiamato anche diagramma a stati) ci permetterà di rappresentare gli stati del nostro simulatore di bancomat, nonché i trigger, gli eventi e le transizioni tra gli stati, in modo da comprendere meglio il funzionamento della nostra applicazione esistente. Torniamo quindi alla nostra esperienza di esecuzione della simulazione per iniziare:

Quando abbiamo avviato l'applicazione legacy, il nostro simulatore di bancomat è entrato in modalità di attesa, in attesa del primo cliente

Successivamente, può essere utile identificare e rappresentare ulteriori stati disegnandoli all'interno di ovali separati. Potremo spostare questi ovali come pezzi di un puzzle per trovare la sequenza logica, senza preoccuparci delle transizioni da uno stato all'altro.

Questa lista preliminare degli stati dell'ATM è solo la nostra prima bozza. Le descrizioni degli stati sono state suggerite dalle voci del menu della nostra applicazione esistente, ed è evidente che possiamo semplificare:

• Non c'è differenza tra "Seleziona prima transazione" e "Seleziona transazione successiva", quindi queste opzioni dovrebbero essere combinate.
• "Effettua disconnessione" è probabilmente una transizione istantanea, non uno stato, che si verifica quando l'utente preme il tasto 4 nel menu delle transazioni.
• Possiamo assegnare l'inserimento da parte dell'utente di un importo di prelievo o di un importo di deposito come stati secondari all'interno dello stato "Esecuzione transazione". Il terzo punto semplifica il nostro diagramma e sarebbe coerente con il modo in cui gestiamo l'inserimento da parte dell'utente del numero di conto e del PIN, considerandoli parte del processo di "Autenticazione utente". Dopo aver apportato queste modifiche e aggiunto le transizioni, il nostro diagramma avrà questo aspetto:

Le semplici transizioni che abbiamo aggiunto sono dei trigger che fanno sì che il bancomat esca da uno stato e passi al successivo. Notate inoltre che ogni stato ha almeno un ingresso e un'uscita: altrimenti, l'applicazione precedente potrebbe costringere l'utente in una situazione di stallo. L'elemento a forma di diamante tra "Selezione della transazione" e "Esecuzione della transazione" è il simbolo UML che indica una scelta tra diversi percorsi. Inizialmente, potrebbe sembrare illogico che l'applicazione consenta all'utente di disconnettersi prima di eseguire qualsiasi transazione, ma questa è un'opzione offerta dall'applicazione precedente nel menu delle transazioni. E, nella realtà, gli utenti possono cambiare idea all'ultimo minuto! Abbiamo fatto attenzione a utilizzare un linguaggio coerente, per quanto possibile, per i nomi e le descrizioni dei nostri elementi. Gli stati sono denominati con verbi al presente che terminano con "-ing". Le transizioni sono etichettate per indicare il completamento dell'azione che causa il cambiamento di stato. L'uso di nomi coerenti per gli elementi migliora la chiarezza del diagramma.

Una volta che abbiamo un diagramma a stati di funzionamento, come quello mostrato sopra, è utile considerare cosa succede se si tenta una transizione, ma questa non viene completata con successo. L'utente dell'ATM potrebbe inserire una combinazione di numero di conto/PIN non valida, oppure un utente autenticato potrebbe richiedere un prelievo che supera il saldo disponibile sul conto. Possiamo migliorare il nostro diagramma a stati per includere queste possibilità:

Attualmente, il nostro diagramma a stati macchina mostra numerosi percorsi alternativi all'interno dell'esecuzione dell'applicazione, non solo il singolo percorso "ideale" e senza errori. Abbiamo scelto un'orientamento verticale per la disposizione del nostro diagramma, ma non esiste una regola che imponga questa forma. Alcune applicazioni si prestano meglio a una disposizione orizzontale, oppure potrebbe semplicemente trattarsi di una preferenza personale. Questa illustrazione mostra una piccola parte del nostro diagramma a stati macchina in forma orizzontale:

Qualunque sia la disposizione del diagramma a stati che scegliete, evitate di disegnare linee di transizione che si intersecano o si sovrappongono. Disegnare un diagramma a stati UML potrebbe sembrare eccessivo per la nostra simulazione di un bancomat, dato che l'applicazione esistente è piccola e siamo tutti a conoscenza del funzionamento dei bancomat. Tuttavia, queste tecniche possono essere molto utili quando si lavora su applicazioni molto più grandi, che operano in ambiti complessi o sconosciuti.

Se siete pronti a creare diagrammi di macchine a stati UML per le vostre applicazioni Java, C# o Visual Basic esistenti, cliccate qui per scaricare una versione di prova gratuita e completamente funzionante di 30 giorni di Altova UModel. Nella prossima parte, analizzeremo in dettaglio la transazione di prelievo e la nuova funzionalità che abbiamo previsto nella seconda parte.