Analisi di un'applicazione legacy con Altova UModel – Parte 1

Prima o poi, quasi tutti gli sviluppatori professionisti si troveranno a dover risolvere bug o aggiungere funzionalità a un'applicazione esistente, di cui non hanno partecipato alla creazione. In queste situazioni, una documentazione imprecisa o incompleta, e la mancanza di accesso al team di sviluppo originale, possono rappresentare ostacoli significativi. Fortunatamente, Altova UModel può analizzare il codice sorgente di software esistenti per creare un modello visivo che accelera l'analisi e migliora la comprensione di un'applicazione legacy. Questo è il primo di una serie di articoli in cui applicheremo UModel, il software di Altova Strumento UML per la modellazione del software e sviluppo, per analizzare una simulazione di un bancomat (Automatic Teller Machine) scritta in Java. L'applicazione si basa su diversi esempi di sistemi ATM (bancomat) tratti da tutorial Java molto diffusi. Dato che si tratta di un sistema di dimensioni ridotte e che il funzionamento di un bancomat è ben noto, ci concentreremo maggiormente sulle tecniche che potete applicare ai vostri progetti Java, C# e Visual Basic, piuttosto che sull'esempio di codice. Ecco un'immagine dell'applicazione legacy in esecuzione in una finestra di comando:

Lo sviluppatore originale ha fornito, in modo molto utile, le informazioni di accesso all'account di esempio, quindi possiamo effettuare il login. L'applicazione presenta quindi un menu di transazioni tipico di un bancomat:

Se esaminiamo la cartella che contiene l'applicazione, notiamo i file sorgente Java e i file .class compilati, ma non troviamo file di progetto.

Non è un problema. Il menu del progetto UModel ci permette di importare un progetto, una directory di codice sorgente, o anche i file binari di un'applicazione compilata. Il codice sorgente di progetti molto grandi è spesso organizzato in diverse cartelle, quindi, anche se si dispone di un file di progetto, potrebbe essere utile esaminare una cartella alla volta.

Prima di iniziare, è importante configurare le opzioni di UModel per assicurarsi che vengano disegnate automaticamente tutte le associazioni tra classi definite nel codice sorgente

Durante l'importazione della cartella, vogliamo anche includere tutti i commenti JavaDoc presenti nel codice sorgente, in modo da utilizzarli come documentazione per il nostro progetto UModel

Per la nostra prima analisi dell'applicazione legacy, vogliamo avere una panoramica generale, quindi non apriremo tutti i moduli opzionali:

UModel importa il progetto in pochi secondi, e la finestra dei messaggi non segnala alcun errore. L'albero dei diagrammi contiene due diagrammi:

Possiamo cliccare sulla scheda "Albero dei modelli" ed espandere la cartella di origine per visualizzare le icone che rappresentano tutte le classi Java importate da UModel

Possiamo tornare all'albero dei diagrammi per aprire il contenuto del diagramma di classi UML di origine UML class diagram. Dopo aver impostato tutti gli stili delle linee su "ortogonale" e riposizionato alcune linee e classi per evitare sovrapposizioni, possiamo vedere che il diagramma illustra chiaramente le classi dell'applicazione e le loro relazioni

Si noti che il nome della classe "Transaction" è scritto in corsivo, indicando che si tratta di una classe astratta (o superclasse), e che le sottoclassi "BalanceInquiry", "Withdrawal" e "Deposit" ne ereditano le caratteristiche. Se si fa clic sulla classe "Transaction" per selezionarla, l'ereditarietà viene illustrata nella finestra di supporto "Gerarchia" di UModel, e qualsiasi commento JavaDoc presente nel codice sorgente immediatamente prima della definizione della classe viene visualizzato nella finestra "Documentazione":

Se utilizzassimo solo un editor di testo per analizzare l'applicazione legacy, dovremmo esaminare ogni singolo file del codice sorgente per comprendere la struttura gerarchica mostrata sopra. Questo perché la classe "Transaction" non identifica internamente le sue sottoclassi. Quando troviamo una sottoclasse, questa non identifica le sue classi "sorelle". E non possiamo essere certi che un'altra classe, con un nome illogico, non sia una sottoclasse di "Transaction" finché non le esaminiamo tutte. È inoltre possibile selezionare ogni classe individualmente per visualizzare la sua documentazione nella finestra "Documentazione". In alternativa, se si preferisce un diagramma più chiaro, è possibile rimuovere le etichette di associazione dal diagramma

Ora, l'asterisco che rappresenta la molteplicità "da zero a molti" degli account presenti nel database bancario è molto più evidente.

Un altro membro del nostro team di sviluppo ha trovato un diagramma di classi parziale, che presumibilmente rappresentava il progetto esistente, e l'ha condiviso con noi. Possiamo subito notare che non assomiglia al diagramma generato da UModel:

La documentazione della nostra vecchia applicazione non corrisponde al codice: un evento sfortunato, ma purtroppo comune! Ci sono diverse differenze tra il vecchio schema e quello che abbiamo generato:

· The associations between ATM and the physical components are shown as composition associations

· The association between ATM and the BankDatabase is described by a text annotation

· The association between ATM and Transaction also has a text annotation, and it does not even exist in the UModel diagram

· Multiplicity is defined at each end of each association, but none were created by UModel

Esaminiamo ora ciascun punto:

· The representation of composition in the Java language is identical to ordinary association, so UModel could not deduce the composition characteristic. Of course the ATM “is composed of” a keypad, screen, cash dispenser, and deposit slot, so we can update the diagram to show composition.

· We can add a text annotation to any UModel association arrow. Simply click the arrow and start typing.

· If UModel did not create an association arrow between the ATM class and the Transaction, one must not be defined in the source code. We will postpone further investigation of this anomaly for now. · Multiplicity as shown in the legacy diagram would also require specific definition in the source code. We’ll leave this for investigation later too. Maybe that old diagram was left in the back of the file cabinet for a reason!

Aggiungeremo l'annotazione, quindi aggiorneremo la caratteristica di aggregazione di ogni associazione ATM nella finestra delle proprietà di UModel. Utilizzeremo anche la barra degli strumenti di layout di UModel per rendere i rettangoli che rappresentano tutte le classi della stessa dimensione. Ora il nostro diagramma di classi avrà questo aspetto:

Il diagramma di classe completato è solo il punto di partenza della nostra analisi. Nelle prossime sezioni, approfondiremo il codice dell'applicazione e genereremo automaticamente altro materiale Diagrammi UML, e creare alcuni nuovi diagrammi, man mano che la nostra comprensione del codice esistente si approfondisce.

Se desiderate iniziare subito e analizzare il codice delle vostre applicazioni Java, C# o Visual Basic più datate, cliccate qui per scaricare una versione di prova gratuita e completamente funzionante di 30 giorni di <2>Altova UModel</2>.