Introduzione

Ogniqualvolta in una disciplina dell’ingegneria, vi sia la necessità di realizzare un “artefatto”, indipendentemente dalla sua dimensione e settore di interesse (una casa, un particolare macchinario, un ponte o un dipartimento di un’azienda) si procede cercando di realizzarne un modello. L’obiettivo è produrre una versione razionalizzata del sistema reale, al fine di evidenziarne l’aspetto finale, le prestazioni, l’affidabilità, il comportamento, e così via.
I modelli vengono particolarmente apprezzati quando ci si trova ad affrontare sistemi vasti e/o molto articolati. In queste circostanze, i limiti della capacità umana di comprendere la complessità nella sua interezza emergono in tutta la loro drammaticità. Pertanto è maggiormente sentita la necessità di avvalersi di modelli in grado di descrivere, in maniera più semplice, sistemi comunque complessi.
Si vedrà come l’UML, grazie alla sua organizzazione in “viste”, risponda alla logica necessità della mente umana di concentrarsi, in ogni istante, su un numero limitato di aspetti del sistema: quelli ritenuti importanti per quel particolare momento (vista). Si  rimanda a momenti successivi, l’analisi degli aspetti rilevanti per le altre viste viene.
I modelli sono molto importanti perché permettono, con la assistenza dei clienti, di definire i requisiti del sistema e, con la cooperazione del proprio gruppo, di razionalizzarne il processo di sviluppo. Tale razionalizzazione rende possibile produrre un’adeguata analisi dei tempi (senza dover ricorrere alla sfera di cristallo), una buona stima dei costi, il piano dell’allocazione delle risorse, la distribuzione del carico di lavoro.
Ancora, essi permettono di risparmiare tempo e quindi denaro, contribuiscono a ridurre i fattori di rischio presenti in ogni progetto, consentono di studiare la risposta del sistema a particolari sollecitazioni, e così via. Per esempio, a nessuno (appartenente al settore dell’ingegneria edile!) verrebbe in mente di costruire un grattacielo per studiarne poi la risposta a sollecitazioni di carattere sismico. Il buon senso (purtroppo risorsa sempre rara), suggerisce di procedere con la realizzazione di una versione miniaturizzata sulla quale condurne gli studi del caso.
Non necessariamente un modello deve essere qualcosa di tangibile: talune volte, si tenta di rappresentare un oggetto reale per mezzo di eleganti sistemi di disequazioni, e quindi l’intero modello si risolve in una raffinata astrazione.
Tutto ciò che è fin troppo scontato in molte discipline dell’ingegneria, non lo è altrettanto nel settore dell’informatica, dove in molte organizzazioni (e qui non pensiate che si tratti di un limite delle piccole realtà) la produzione del Sw è ancora un’attività, per così dire, “artigianale”.
Si provi ad immaginare cosa potrebbe accadrebbe se si avviasse la costruzione di un ponte a partire da specifiche sommarie, magari comunicate verbalmente o peggio ancora, si iniziasse subito con la costruzione fisica, affidandosi all’esperienza di qualche costruttore! (Inimmaginabile eh?) Tutto ciò, benché posa sembrare “fuori dal mondo” spesso (molto) accade nel mondo dell’informatica!
Malgrado siano stati versati fiumi di inchiostro (vedi allocati giga byte di memoria) sull’argomento, e svariati gruppi di ricerca lavorino a tempo pieno per la definizione di standard di analisi, in molte organizzazioni (soprattutto italiane), anche di comprovato prestigio nel settore, tale attività è ancora considerata prettamente accademica vezzo di giovani neo-laureati, che, in ultima analisi, è di scarsa utilità nel mondo reale ,dove l’obbiettivo è produrre e l’esperienza è in grado di sopperire a tutto! Il risultato è che spesso si procede cominciando (paradossalmente) da una delle ultime fasi del processo di ingengerizzazione del software, ossia dalla stesura del codice (vedi costruzione del ponte).
Pertanto si inizia concentrandosi prematuramente su come redigere il codice ed, eventualmente, alla fine si scrivono “due righe di analisi”, magari demando il tedioso incarico all’ultimo arrivato nel team.
I rischi nei quali si può incorrere sono noti a tutti, e possono generare delle anomalie, note in letteratura informatica, come “crisi del software”.
L’unico vantaggio di questo modo di procedere è che si placano (almeno momentaneamente) gli stadi d’ansia di taluni manager, i quali, diventano improvvisamente irrequieti quando il team non genera codice, anche se nel frattempo si stanno affrontando, delicate ed impegnative, fasi di analisi e disegno.
L’alibi che viene rispolverato è lo scarso tempo a disposizione, dimenticando quanto incide il processo di manutenzione sull’intero ciclo di vita del software! Il famoso risparmio della massaia!
Ad onor del vero, non è solo e sempre colpa dei tecnici-commerciali che “vendono” l’impossibile, di manager informaticamente poco lungimiranti, o dei capi progetto “invisibili”, che un giorno sono a favore di una soluzione ed il vento dopo (“pardon” il giorno) di quella opposta… Maschere e pugnali!
Molto spesso (è qui doveroso procedere con un po’ di sana autocritica) gli stessi progettisti si sentono più a loro agio quando si deve affrontare un problema di programmazione, piuttosto che quando si deve affrontare la modellazione di un sistema. Vi dice nulla la frase “Che noia! Non ne posso più! Ma quando si comincia a scrivere del codice?”.
Ahimè, a pensare che da oltre un decennio in ambito accademico si afferma che “la programmazione è un incidente -anche molto piacevole se si vuole- dell’informatica!”.
Nella realtà, troppo spesso si liquidano prematuramente le fasi di analisi e disegno del software per tuffarsi a testa bassa nella programmazione, e tutti risultano felici e contenti, fino al momento di installare “l’altalena”. Allora ci si accorge che, per come la si è realizzata, è necessario operare un taglio ortogonale alla base del tronco dell’albero per poterla installare!
Infine, in altre realtà, può succedere di realizzare un’adeguata analisi, di produrre modelli sofisticati, che pur offrendo un elevato livello di astrazione, devono guidare un team di “sviluppatori”, magari laureati da poco in geologia. Per carità, trattasi di attività molto interessante (suppongo), ma che può ingenerare dei problemi a coloro che dovranno spiegare che, quando si richiede di evitare la generazione di codice “monolitico”, non si fa necessariamente riferimento ad una particolare pietra!
Questo per dire che gli strumenti da utilizzare in fase di analisi, purtroppo, possono dipendere, anche fortemente, dal team con cui si lavora. Provate a fornire, sempre allo stesso team di cui sopra, un class diagram… No si otterrà alcun risultato, neanche con l’esempio dell’entomolgo (Ricordate la catalogazione degli insetti un tempo tanto cara a taluni manuali?)
Premesso ciò, va comunque ribadito che il processo di analisi è un’attività estremamente creativa, strettamente dipendente dalle capacità, dalla cultura, dall’esperienza dei singoli…
Il bello è che non esiste una soluzione corretta con la quale andarsi a confrontare alla fine del proprio studio: manca una sorta di settimana enigmistica dell’analisi.
Tutti coloro per i quali tale introduzione, ed in generale la domanda “why we model” è più che scontata, felicitazioni di cuore, significa che si trovano a lavorare nell’APBDM (ossia azienda più bella del mondo!). Purtroppo le realtà lavorative non sono sempre così, ed il fatto che anche i fondatori dell’UML abbiano deciso di dedicare all’argomento un intero capitolo del libro [1] la dice lunga!
 
 
 

Qualità di un modello.

• accurato: deve descrivere correttamente il sistema da realizzare;
• consistente: le diverse viste devono completarsi vicendevolmente ed essere prive di incoerenze;
• semplice: deve poter essere compreso, senza troppi problemi, da persone estranee al processo di modellazione;
• manutenibile: la variazione dello stesso deve essere il più semplice possibile;

UML

 Metodi e linguaggi

Aree di intervento.

1. visualizzare;
2. specificare;
3. costruire;
4. documentare;

Tutti i tecnici per i quali la fase di disegno e quella di sviluppo coincidono, l’utilizzo di un formalismo per illustrare progetti (punto uno), potrebbe sembrare un qualcosa di superfluo! 
In genere, l’UML permette di rappresentare, per mezzo di un formalismo rigoroso, le proprie idee, le decisioni prese, le soluzione adottate…
Il grande vantaggio è che, poiché UML è uno standard internazionale, non legato alle singole imprese (open), facilita la divulgazione delle informazioni. In teoria, un qualunque tecnico (non geologo, possibilmente!), di qualsivoglia nazionalità, dipendente della più anonima delle software house, con un minimo di conoscenza dell’UML, dovrebbe essere in grado, studiando il modello del progetto, di comprenderne, facilmente, e senza le ambiguità tipiche del linguaggio naturale, ogni dettaglio.
I vantaggi che ne derivano sono notevoli e fin troppo evidenti. Basti pensare alla notevole semplificazione del processo di manutenzione, che da solo, tipicamente, incide più del 50% nel ciclo di vita dei sistemi Software; alla possibilità di allocare nuove risorse in corso d’opera, senza correre il rischio che ciò diventi controproducente, ecc.
Un altro vantaggio è che costringe il progettista ad analizzare, con maggior dettaglio, alcuni aspetti del sistema, anche di un certo rilievo, che, viceversa, potrebbero incautamente venir trascurati da un’analisi non molto rigorosa.
Per ciò che concerne l’utilizzo dell’UML per “specificare” (punto 2), esso dovrebbe risultare “auto-commentante”. Si consideri che, in questo contesto, tale termine si riferisce alla possibilità di realizzare modelli completi, precisi e non ambigui. L’UML dispone di meccanismi necessari per la specifica di tutti i dettagli ritenuti rilevanti in ogni fase del ciclo di vita del software.
Sebbene l’UML sia un linguaggio visuale per la progettazione, i modelli generati per mezzo di esso, si prestano ad essere implementati con diversi linguaggi di programmazione. Ciò equivale a dire che è possibile realizzare un “mapping” esplicito tra un modello UML e un linguaggio di programmazione. Ovviamente, tale legame risulta più immediato per i linguaggi fortemente basati sul paradigma O.O., quali C++, Java, Small-Talk, Ada,…
Sul mercato sono presenti diversi “tools” in grado di generare codice a partire dal relativo modello, sia interattivamente (a partire dalla fase di disegno ovviamente) e sia su richiesta.
Ciò risulta particolarmente utile quando il modello deve essere realizzato, parallelamente, da un team di programmatori (cioè sempre!), in quanto, le classi generate presentano un’“interfaccia” stabile e ben definita, alla quale ciascun sviluppatore può far riferimento.
Sebbene alcuni “tools” tentino, in casi particolari, di dettagliare determinati metodi con l’appropriato codice, è consigliabile non utilizzare questa “inutility”, almeno che non si tratti di meri metodi get/set di proprietà (che tra l’altro vanno ben ponderati per non venir meno al principio dell’information hiding).
Il “mapping” tra modello e linguaggio di programmazione permette, tra l’altro, la realizzazione di funzioni di “reverse engeneering”: fornendo ad un opportuno “tool” i codici sorgenti o, talune volte anche quelli “compilati”, esso è in grado di ricostruire a ritroso il modello fino, ovviamente, alla fase di disegno. Purtroppo ancora non si è riusciti a realizzare un “tool” in grado di ricostruire i requisiti del cliente; un vero peccato!
Il processo diretto (engineering) e quello inverso (reverse engineering) determinano quello che in gergo viene definito round-trip engeneering.
Nel mondo dell’ideale, la funzione di reverse non dovrebbe mai venir utilizzata… Però può capitare di dover “mettere le mani” su un codice scaricato da Internet o scritto in tempi precedenti e non opportunamente documentato: in tali casi il reverse engeneering si fa particolarmente apprezzare!

Per ciò che concerne l’utilizzo dell’UML per la fase di documentazione, la tentazione di considerare il tutto fin troppo ovvio è forte; ciò, tra l’altro, potrebbe generare la felicità del redattore. 
Come ripetuto più volte, l’UML è particolarmente orientato anche a tale utilizzo. Chiaramente, un buon progetto, poco documentato potrebbe perdere parte della sua attrattiva o addirittura non essere compreso.
In particolare, l’UML fornisce sia dei meccanismi molto formali e sia del testo libero, da aggiungere ogni qual volta si ritenga necessario, al fine di aumentare il livello di dettaglio di parti ritenute poco chiare o particolarmente complesse.
 
 
 

Struttura dell’UML

1. Viste;
2. Diagrammi;
3. Elementi del modello;

Le viste mostrano i differenti aspetti di un sistema attraverso la realizzazione di un certo numero di diagrammi. Si tratta di astrazioni, ognuna delle quali analizza il sistema da modellare con un’ottica diversa (funzionale, non funzionale, organizzativa, ecc.). Pertanto, la somma di tali viste fornisce il quadro d’insieme.
I diagrammi permettono di esprimere le viste logiche per mezzo di grafici, l’UML ne prevede ben nove tipi differenti, ognuno dei quali è, tipicamente, destinato ad essere utilizzato per una particolare vista.
Per ciò che concerne gli elementi del modello, essi sono i concetti che permettono di realizzare i vari diagrammi, essi indicano gli attori, le classi, i packages, gli oggetti, ecc.
Durante la fase di definizione dei vari elementi, si è reso necessario decidere quanti e quali elementi standardizzare e, se era il caso di iniziare a catalogare tutti quelli immaginabili. Se si fosse deciso si adottare tale soluzione, inevitabilmente, si sarebbe finiti per rendere lo strumento UML rigido, eccessivamente complesso e sicuramente carente…
Si trova sempre un progettista X che abbia la necessità di esprimere qualche concetto e di non avere gli strumenti per farlo! Addirittura si possono incontrare dei presunti tecnici, nostalgici “guerrafondai” che, non pachi della pace raggiunta dopo decenni di guerra dei “metodi di analisi”, tentino ancora di riaccendere qualche focolaio inventando uno proprio formalismo!
Il buon senso, ovviamente ha portato a preferire un altro approccio. Si è deciso di definire e standardizzare un certo numero di elementi base, ritenuti fondamentali, e di fornire un insieme di meccanismi che consentono di estendere la semantica del linguaggio (stereotypes) e di aggiungere documentazione, note, vincoli, ecc.
Tale soluzione, permette di rispettare il requisito di semplicità, proprietà basilare di qualsiasi modello.
Altri effetti desiderati sono stati quelli di rendere il linguaggio semplice, dinamico, flessibile, tanto da essere in grado di adattarsi a più svari settori.
 
 
 

Le viste

1. Use case;
2. Logical;
3. Component;
4. Concurrency;
5. Deployment.

Figura 1:  le viste dello Unified Modeling Language

In breve, la prima vista, use case view, serve per analizzare i requisiti utente, ossia, cosa il sistema dovrà fare. Dunque, si tratta di una vista ad alto livello di importanza fondamentale, sia perché guida lo sviluppo delle rimanenti, e sia perché stabilisce le funzionalità che il sistema dovrà realizzare, quelle per le quali il cliente paga, per intenderci.
A questo livello di analisi, bisogna studiare il sistema considerandolo come una scatola nera, concentrarsi sul cosa fare astraendosi il più possibile dal come.
Importante è dettagliare i requisiti del cliente, carpirne i desideri più o meno inconsci, cercare di prevederne i possibili sviluppi futuri, ecc.. 
La desing view (detta anche logical view), in contrapposizione alla vista precedente, descrive come le funzioni debbono essere realizzate, in altre parole si analizza il sistema dall’interno (scatola trasparente!). In questa vista si trova sia la struttura statica del sistema (diagramma delle classi e diagramma degli oggetti) e sia la collaborazione dinamica dovuta alle interazioni tra gli oggetti del sistema.
La implementation view (deta anche component view), è la descrizione di come il codice (vedi classi) viene aggregato in moduli (package) e le relative interdipendenze.
La process view (detta anche concurrency view), rientra nell’analisi degli aspetti non funzionali del sistema, e consiste nell’individuare i processi ed i processori. Ciò al fine di dar luogo ad un utilizzo efficiente delle risorse, di poter stabilire l’esecuzione parallela di determinati oggetti, di gestire correttamente eventuali eventi asincroni, ecc.
La deployment view, mostra l’architettura fisica del sistema e l’ubicazione delle componenti SW nella struttura stessa.
 
 
 

I diagrammi

1. Class diagram;
2. Object diagram;
3. Use case diagram;
4. Sequence diagram;
5. Collaboration diagram;
6. Statechart diagram;
7. Actvity diagram;
8. Component diagram;
9. Deployment diagram.

Figura 2: leggenda dei simboli utilizzati per evidenziare la visibilità delle proprietà e dei metodi.

Figura 3: esempio di Class diagramm (Pattern dell’Osservatore).

I diagrammi degli oggetti rappresentano una variante dei precedenti, tanto che anche la notazione utilizzata è pressoché equivalente, con le sole differenze che i nomi degli oggetti vengono sottolineati e le relazioni vengono dettagliate. Gli objects diagrams mostrano un numero di oggetti istanze delle classi e i relativi legami espliciti. Anche questa tipologia di diagramma si occupa della parte statica del sistema e mostra un ipotetico esempio di un diagramma delle classi. Mentre quest’ultimo è sempre valido, un diagramma degli oggetti rappresenta un’ipotetica istantanea del sistema. In sostanza lo si utilizza per esemplificare diagrammi delle classi, o suoi frammenti, ritenuti poco chiari o particolarmente complicati. 
 
 

Figura 4: Class Diagram e relativo Object Diagram.

I diagrammi dei casi d’uso, mostrano un insieme di attori esterni al sistema e le relative connessioni con le funzionalità che il sistema dovrà realizzare. Essi costituiscono il fondamento della use-case view, rappresentandone la parte statica.
 
 
 
 

Figura 5: Esempio di un digramma use-case di un ipotetico (ed improbabile) esercizio di noleggio CD.

I diagrammi di sequenza e collaborazione, vengono anche detti di interazione in quanto mostrano appunto le interazioni tra oggetti del sistema. Pertanto essi si occupano di modellare il comportamento dinamico del sistema. I due diagrammi risultano molto simili, si può passare agevolmente dall’una all’atra rappresentazione (sono isomorfi), e si differenziano per via dell’aspetto dell’interazione che enfatizzano. In particolare, i diagrammi di sequenza evidenziano l’ordine temporale dello scambio di messaggi, mentre i diagrammi di collaborazione mettono in risalto l’organizzazione degli oggetti che si scambiano i messaggi.
 
 

Figura 6: Esempio di un Sequence diagram.

Figura 7: Versione Collaboration diagram.

I diagrammi di stato, arcinoti a tutti (spero), mostrano, in buona sostanza, un automa a stati finiti, e pertanto sono costituiti da stati, transazioni, eventi e attività. Essi vengono utilizzati principalmente come completamento della descrizione delle classi. Anche essi si occupano di modellare la parte dinamica del sistema, e vengono utilizzati per illustrare in dettaglio il comportamento delle sole classi che possono transitare per gli elementi di un ben definito insieme di stati.
 
 
 

Figura 8: Esempio di uno state digramm. Ascensore con stato di stand-by.

I diagrammi di attività non sono altro che particolari versioni dei paleolitici flow chart, e, come tali, si occupano di evidenziare il flusso di attività. Vengono particolarmente utilizzati per mostrare le attività svolte da una particolare funzione del sistema, ma, nulla vieta di utilizzarli per mostrare l’aspetto dinamico di un use case o di un’interazione.
In questo diagramma (finalmente) si ritrovano gli elementi decisionali e condizionali.
 
 
 
 

Figura 9: Esempio di un activity diagram.

I diagrammi dei componenti mostrano la struttura fisica del codice in termini di componenti e di reciproche dipendenze. Essi permettono di illustrare la vista statica dell’implementazione del sistema, e pertanto, sono strettamente connessi ai class diagram. Ciascun componente è un contenitore di classi, interfaccie, … La corrispondenza con i classici package dovrebbe essere eviente.
 
 
 

Figura 10: Esempio di un component diagram di una struttura three-tiered

Infine, si incontrano i diagrammi di dispiegamento che mostrano l’architettura hardware e software del sistema. In particolare vengono illustrati gli elementi fisici del sistema (computer, reti, device fisici,…) e i moduli software da installare su ciascuno di essi.
 
 
 

Figura 11: esempio di un deployment diagram.

Meccanismi generali

Figura 12:  Esempio di utilizzo di un simbolo note.

Altri esempi di meccanismi generali sono i cosiddetti ornamenti (adornments). Essi permettono di aggiungere semantica al linguaggio. Un esempio è la cardinalità delle relazioni in un diagramma delle classi. Si tratta di un numero (o simbolo) che specifica quante istanze di una classe possono essere coinvolte in una relazione con un’altra.
Un altro esempio di ornamento molto frequente è quello utilizzato per evidenziare che una particolare classe è astratta. In tal caso viene introdotta la stringa “{abstract}”, sotto il nome della classe.
Un ultimo esempio di meccanismi generali sono le specificazioni: si tratta di informazioni che generalmente non vengono visualizzate nei diagrammi ma hanno un ruolo importante. Esse, come ne lascia presagire il nome, aggiungono delle specifiche agli oggetti. Per esempio di una classe si può specificare se è persistente o meno, se l’esecuzione dei suoi oggetti avviene in modo concorrente, ecc.
 
 
 

 Meccanismi di estensione

Figura 13: leggenda dei simboli utilizzati per evidenziare la visibilità delle proprietà e dei metodi

Un altro esempio è quello delle classi che rappresentano un utente, anch’esse vengono rappresentate attraverso un omino stilizzato, noto in gergo con il nome di “scarabocchio”!
 
 
 

Figura 14: forme equivalenti per rappresentare una classe relativa ad un attore.

Un altro esempio di meccanismo di estensione sono i “tagged values” (valori etichettati). Si tratta di elementi costituiti dalla coppia (nome, valore). Come al solito ne esistono alcuni predefiniti, ma nulla toglie al progettista di definirsene altri a proprio piacimento. Con questo meccanismo è possibile impostare delle informazioni specifiche relative a dei metodi, informazioni relative allo stato di avanzamento del modello, dati necessari ad altri strumenti di sviluppo e così via. Per esempio, è possibile specificare la versione della revisione di un diagramma o di un suo elemento. A tal fine, è sufficiente impostare sotto il relativo nome la stringa : {versione = 1.02}.
Per terminare, un ultimo elemento di estensione è fornito dai vincoli. Essi esprimono delle restrizioni e possono essere relative all’utilizzo di un elemento o alla relativa semantica. Per esempio, la figura seguente evidenzia il vincolo presente nella Costituzione Italiana, per cui un cittadino elettore è eleggibile alla camera dei deputati se la sua età è maggiore o uguale a 25 anni.
 
 
 

Figura 15: Esempio di vincolo.

I processi

Conclusioni

Bibliografia

• [1] "The Unified Modeling Language User Guide"

Grady Booch, James Rumbaugh, Ivar Jacobson Addison Wesley
Questo libro vanta il primato di essere stato scritto dai progettisti originali del linguaggio, sebbene sia conosciuto come “Grady’s book”, dal nome del suo primo autore. La mancanza di una sua copia (magari autografata!) può generare giudizi di scarsa professionalità per coloro che operano nel settore della progettazione O.O... Ciò però, costituisce una condizione necessaria, ma non sufficiente, in quanto bisogna, assolutamente, aggiungere una copia del [3] e una del [4]. Sono soldi spesi bene! Forse, il limite del libro, se proprio se ne vuole trovare uno, è quello di essere poco accessibile ad un pubblico non espertissimo di progettazione O.O. Un altro piccolo inconveniente è che, probabilmente, taluni esempi possano sembrare di carattere accademico: poco rispondenti alle problematiche del mondo reale.
 
• [2] "UML Toolkit" 

Hans-Erik Eriksson, Magnus Penker Wiley
Questo libro si fa particolarmente apprezzare per via del taglio pratico dello stesso. Illustra in modo semplice il linguaggio, attraverso numerosi esempi, limitando le digressioni di carattere teorico. Si suppone infatti, che coloro che si occupano di progettazione O.O. abbiano una certa familiarità con i relativi concetti. Chissà perché si ha la sensazione che non sia sempre così! Naturalmente, studiare libri che illustrano gli aspetti teorici dell’informatica, è sempre qualcosa più che auspicabile. È altresì vero, però, che coloro che non hanno tempo da perdere, alla lettura di concetti arcinoti, gradiscono arrivare rapidamente al nocciolo. Ciò spesso equivale a strappare alle nottate lavorative ore preziose per il sonno. 
• [3] The Unified Modeling Language Reference Manual 

Grady Booch, James Rumbaugh, Ivar Jacobson  - Addison Wesley
Il commento da riportare per questo libro, noto per come “Rumbaugh’s book”, è sostanzialmente equivalente a quanto riportato per il primo. Esso però offre un livello di difficoltà decisamente inferiore, e pertanto dovrebbe essere più accessibile. Come suggerisce il nome, si tratta di un manuale, per cui ne rispetta la tipica struttura.
• [4] Design Patterns: Elements of Reusable Object-Oriented Software

Erich Gamma, Richard Helm, Ralph Johnson, John Vlissides, Grady Booch - Addison Wesley.
Si tratta di un ottimo libro che bisogna assolutamente avere se si vuole lavorare nell’ambito della progettazione O.O. . I “pattern” riportati, forniscono un ottimo ausilio al processo di disegno del software. L’utilizzo del libro contribuisce ad aumentare la produttività, fornisce soluzioni chiare, efficienti e molto eleganti. La fase di disegno del software, spesso, si riduce ad individuare e personalizzare i “pattern” che risolvono la problematica specifica. Si è di fronte ad una nuova frontiera della progettazione O.O.: il riutilizzo di parti del progetto. L’unica pecca imputabile, è che i vari diagrammi non sempre rispettano il formalismo UML.
• [5] www.omg.org 

Si tratta del sito ufficiale del Object Managment Group.

Luca Vetti Tagliati è nato a Roma il 3 Dicembre del 1972. Ha conseguito il diploma di laurea in “Ingegneria Informatica ed Automatica” presso l’Università Degli Studi di Roma “La Sapienza”, nel Dicembre del 1996 con votazione 100/100.
Ha iniziato a lavorare nel Novembre del 1991, come analista e progettista di Software a basso livello (Firmware basati su architettura intel 80286) per il controllo di sistemi di acquisizione dati. Si è poi specializzato nelle settore O.O..
Da quattro anni lavora come libero professionista. Attualmente collabora con:
· l’Artis.net Srl (www.Artis.net) di Roma. Società di consulenza informatica, operante nel networking, compiler technology, multimedia systems e software di base. L’area di principale interesse è l’integrazione tra sistemi eterogenei. ARTIS opera nel campo delle Tecnologie dell'Informazione con prodotti hardware e software altamente innovativi che la rendono partner ideale per attività specialistiche.
· I&T SpA di Pomezia.

In particolare, con la I&T SpA collabora alla reingengerizzazione del sistema informatico della Polizia di stato. Il nuovo sistema prevede: la gestione del protocollo, la gestione completa dei verbali, la generazione di statistiche, il collegamento delle sedi “periferiche” (104 sezioni, 20 compartimenti e 300 unità operative), lo scambio dati, in tempo reale, con altri enti quali: il P.R.A., la Motorizzazione Civile, Poste,….
La reingengerizzazione prevede il transito da un’architettura MainFrame based ad una basata su reti di PC.
Il software verrà interamente sviluppato in Java con connessioni a DBMS Oracle 8i.

Luca Vetti Tagliati è raggiungibile all’indirizzo di e-mail : Luca.VT@usa.net