Nella scorsa punta si è iniziato ad analizzare come la rappresentazione UML sia applicata ad un caso pratico di un progetto per lo sviluppo di un generico sistema. Continuiamo in quest'ultima puntata a descriverne i tali passi fondamentali.
Tutti i diagrammi e le relazioni descritti nelle precedenti puntate del corso hanno un ben preciso utilizzo a seconda della situazione di analisi del progetto. Conoscere tutti gli elementi tipici di una rappresentazione UML, senza avere ben chiaro quando e come utilizzarli può servire però a ben poco. Nella precedente puntata si è fatto riferimento ad uno sviluppo RAD (acronimo di Rapid Application Development) per la realizzazione di un progetto; le sue fasi principali si possono riassumere in:
■ 1-raccolta delle informazioni;
■ 2-analisi;
■ 3-disegno;
■ 4-sviluppo;
■ 5-deployment.
Avendo già analizzato le prime tre fasi si passerà ora a quella di sviluppo e deployment.
Figura 1: la classe Documento.
Figura 2: la classe Pagina.
Sviluppo e deployment
Attraverso l’uso di diagrammi delle classi, degli oggetti, delle attività e dei componenti, i programmatori hanno la possibilità di implementare il codice per il sistema. Ogni nuova implementazione del codice sarà, necessariamente interfacciata con una opportuna fase di test. Si può, praticamente, dire che le due fasi camminano di pari passo fin quando il codice supera tutti i livelli di test sviluppati nella fase di disegno. Vengono prodotti in questa fase i risultati del test. Il punto di unione tra la fase di disegno e quella di sviluppo è rappresentata dall’interfaccia utente. Qui, uno specialista GUI costruisce dei prototipi di interfaccia che dovranno essere collegati al codice. Naturalmente tale collegamento necessita di una opportuna fase di test e verifica. A questo punto si dovrebbe avere a disposizione il Sistema funzionante completo con l’interfaccia utente. Il completamento del sistema permette agli esperti della documentazione di terminare la stesura di tutto il materiale necessario per descrivere il sistema.
Figura 3: utilizzo del concetto di ereditarietà.
Un caso pratico
Si prenda ad esempio una classica applicazione: quella che permette di scrivere un documento di testo. Si cercherà di descrivere i passi che costituiscono tale applicazione. Si supponga che si stia digitando un documento di testo, utilizzando qualche editor di testi. L’utente ha due possibilità iniziali:
» cominciare a scrivere un nuovo documento;
» aprire un documento esistente.
Il testo da scrivere, ovviamente, verrà digitato tramite l’utilizzo della tastiera. Ogni documento è composto di svariate pagine, ed ogni pagina, a sua volta, è composta da una testata, dal corpo del documento e da un piè di pagina. Nella intestazione e nel piè di pagina è possibile aggiungere la data, l’ora, il numero di pagina, la collocazione del file. Il corpo del documento è formato da frasi. Le frasi, a loro volta, sono composte da parole e segni di punteggiatura. Le parole sono formate da lettere, numeri e/o caratteri speciali. Inoltre, è possibile aggiungere delle immagini e delle tabelle nel documento. Le tabelle sono costituite da righe e colonne ed ogni cella di una tabella può contenere del testo o delle immagini. Dopo aver terminato il documento, l’utente può scegliere di salvarlo o stamparlo. E’ stato descritto, in maniera semplificata ma congruente, il processo di creazione di un documento tramite un editor di testi. Rifacendoci a quanto già detto nella guida circa l’intervista con il cliente, lo sviluppatore è in grado di estrarre la seguente lista di parole chiave:
documento, editor di documenti, testo, tastiera, intestazione, piè pagina, corpo del documento, data, ora, numero di pagina, collocazione del file, pagina, frase, parola, segno di punteggiatura, lettera, numero, carattere speciale, immagine, tabella, riga, colonna, cella, utente.
Tra tali parole si dovranno estrarre quelle che diventeranno delle classi. Nell’esempio descritto l’oggetto attorno a cui ruota un po’ tutto il discorso è il Documento. Per tale ragione, sarà una buona idea identificare nel Documento la classe centrale del Class Diagram. Un documento, come detto, può avere svariate pagine e, quindi, potremo definire un attributo: numeroDiPagine che descrive tale caratteristica. Invece, per le operazioni, sarà bene definire i metodi: Apri( ), Salva( ), Stampa( ),Nuovo( ). Si è detto, poi, che ogni documento è composto di pagine. La Pagina sarà, dunque, un buon candidato per essere una classe del nostro diagramma. La Classe Pagina conterrà un attributo: numeroDiPagina, che identificherà il numero della pagina dell’oggetto; inoltre conterrà le seguenti operazioni: nuovaPagina(), nascondiIntestazione() e nascondiPièdiPagina(). I metodi per la testata e il piè di pagina fanno intendere che è bene definire altre due classi: Intestazione e PièPagina. Tali classi hanno i seguenti attributi in comune: data, ora, numeroDiPagina e pathFile. Tali attributi sono opzionali per ogni intestazione o piè di pagina e l’utente potrà configurarli a suo piacimento. La somiglianza tra Intestazione e PièPagina porta alla definizione di una nuova classe che sia in comune alle due appena descritte. Si è utilizzato il concetto di ereditarietà definito in precedenza. La classe padre sarà BottomUp (questo nome è scelto perchè le intestazioni e i piè di pagina appaiono, rispettivamente, nella parte alta e bassa di ogni pagina del documento) e conterrà gli attributi che sono in comune alle classi Intestazione e PiePagina oltre alle operazioni (anch’esse in comune): visualizza(), modifica() e nascondi(). Le classi Intestazione e PièPagina (figlie di BottomUp) avranno la necessità, quindi, di definire, rispettivamente, soltanto le operazioni: nuovaIntestazione() e nuovoPiePagina(). Prima di passare ad esaminare il corpo del documento o il testo, esaminiamo i componenti di un testo. Come detto, il testo del documento è composto di frasi. Le frasi, a loro volta, sono composte di parole e le parole sono formate da caratteri. Se le parole sono, dunque, array di caratteri e le frasi sono identificabili come array di parole, allora una frase è anche (per una sorta di proprietà transitiva) un array di caratteri. Quindi, il corpo di un documento può essere descritto come un array di caratteri. Per tale ragione, per descrivere il testo di un documento faremo uso della classe Carattere con alcune sottoclassi. La classe Carattere avrà gli attributi: codiceASCII e tipo (il tipo ci informa sulla tipologia di carattere, ovvero se esso è in formato normale, corsivo, grassetto o sottolineato) e definirà le operazioni: Normale(), Corsivo(), Grassetto() e Sottolineato(). Come discendenti della classe Carattere definiremo poi: Lettera, SegnoDiPunteggiatura, CarattereSpeciale e Numero, sfruttando ancora una volta il concetto di ereditarietà. A questo punto sono disponibili tutti i tasselli, basterà solo collegarli tra loro. Utilizzando le associazioni tra le classi otterremo dunque il Class Diagram riportato in figura 4.
Figura 4: il diagramma delle classi completo delle associazioni.
Ovviamente, il modello descritto potrà essere specializzato sempre di più e, quindi, crescere in modo appropriato per poter consentire un appropriato lavoro di analisi e disegno.
Figura 5: una schermata del software Rational Rose.
Figura 6: una schermata del software Microsoft Visual Modeler
Altri tool di sviluppo
Durante questo corso è stato descritto l’uso di un software che consente di agevolare la costruzione di diagrammi UML: StartUML. La scelta non è stata sicuramente casuale, si tratta di un software gratuito ed opensource, quindi accessibile a tutti. Ovviamente non si tratta dell’unico software di questo tipo esistente sul mercato. Probabilmente, il più diffuso è lo strumento della Rational, Rose. Il Rational Rose è stato progettato per fornire ai team di sviluppo tutti gli strumenti necessari per il modellamento di soluzioni robuste ed efficienti. La Microsoft ha prodotto uno strumento che permette di definire un sottoinsieme dei modelli che il Rational Rose mette a disposizione: il Microsoft Visual Modeler. Tale software può essere consigliato a chi si avvicina per la prima volta al mondo del Visual Modeling. Il Microsoft Visual Modeler permette, tra l’altro, di:
» identificare e disegnare oggetti del business e mapparli in componenti software;
» descrivere come i componenti possono essere distribuiti su una rete;
» generare codice base Visual Basic direttamente dalla costruzione del modello;
» utilizzare il reverse engineering per creare i modelli da applicazioni già esistenti. Altro strumento da segnalare è UMLet, un software open source basato su Java che permette la scrittura di diagrammi UML. Tra le opzioni, la possibilità di esportare i diagrammi in SVG, JPG e PDF.
Figura 7: una schermata del software UMLet
Conclusioni
Il processo per la costruzione di un Sistema coinvolge molte persone: prima di tutto il cliente, ovvero la persona che desidera avere una risoluzione ad un problema o ad una sua esigenza. Un analista ha il compito di documentare il problema del cliente e trasmettere tali informazioni agli sviluppatori, i quali costituiscono la parte del team che si occupa di implementare il codice, testarlo ( con il supporto di un team apposito per il test) e installarlo sull’hardware dei computer. Questo tipo di suddivisione dei compiti è necessario poiché al giorno d’oggi i sistemi sono diventati davvero molto complessi e la conoscenza è divenuta molto più specializzata da non poter essere gestita soltanto da una persona. Per organizzare e documentare tutte queste fasi del processo di realizzazione di un sistema è necessario affidarsi ad un apposito linguaggio. La risposta a questa necessità si chiama UML. Il vantaggio di tale tipo di approccio è che la conoscenza generale del team cresce notevolmente, ognuno è in grado di capire a fondo il sistema e il risultato finale non può che essere un sistema più solido (con il cliente più soddisfatto!).
