UML 2 Manuale di stile: descrizione del progetto


Ho iniziato ad usare notazioni grafiche per l'analisi ed il design ad oggetti nel 1991, quando ho "incontrato" i lavori di Peter Coad ed Edward Yourdon. In seguito ho avuto modo di utilizzare in modo piuttosto intenso la notazione di Booch, ed in misura minore OMT. Ho creduto parecchio in UML sin dall'inizio, cominciando a prenderlo in seria considerazione sin dalla versione 0.8 (quando gli oggetti avevano ancora forma esagonale e non rettangolare).

Durante questi anni, come molti altri, ho sviluppato ciò che all'inizio è uno "stile personale" di utilizzare un linguaggio, e che gradualmente finisce per l'evolvere in un insieme di linee guida, di indicazioni e raccomandazioni. Ho avuto modo di trasmettere ad altri alcune di queste, sia in modo esplicito durante corsi e seminari, sia "per osmosi", come dico spesso, lavorando fianco a fianco nei vari progetti.

Nel tempo, ho "ripulito" e raffinato queste linee guida, anche grazie al feedback di chi lavorava insieme a me. Tuttavia non ho mai trovato il tempo e le energie necessarie per trascriverle in modo organico e strutturato, in un vero e proprio "Manuale di Stile". Dopo un periodo di indecisione, ed osservando una pressoché completa mancanza di una simile guida, anche tra la letteratura in lingua inglese, ho iniziato a scrivere il nucleo di questo documento, che vorrei far crescere in collaborazione con i suoi lettori ed utilizzatori.

Alcuni di voi conosceranno un mio analogo lavoro (il "C++ Manuale di Stile"). Vorrei che il presente documento evolvesse in una direzione analoga, fornendo indicazioni valide sul modo migliore di utilizzare UML.
Non si tratta quindi di un testo sull'analisi o sul design ad oggetti. Esistono altri libri, e numerosi articoli, che coprono questi temi. Né si tratta dell'ennesimo tutorial che spiega cosa sono le classi e gli oggetti. Anche in questo caso, potete trovare numerose trattazioni, sia in libreria che su internet.
Il mio obiettivo è invece l'identificazione di un buon numero di regole di utilizzo di UML come linguaggio, che in quanto tale si presta a stili molto diversi, più o meno chiari, espressivi, leggibili e manutenibili. Ad esempio, esistono tecniche più o meno buone per indicare un comportamento polimorfo in un sequence diagram. Così come esistono molti stereotipi interessanti che possono chiarire a chi legge il significato di una dipendenza generica, e tecniche diverse per rendere più espressivo il ruolo di ogni classe all'interno di un diagramma.

Credo che il risultato finale potrà essere di grande utilità per qualunque azienda o professionista che utilizzi UML come linguaggio di modellazione, durante le fasi di analisi e design. Ognuno potrà estrarre un sottoinsieme delle raccomandazioni, adattarne altre, e definire uno standard aziendale a beneficio dell'uniformità e della chiarezza dei vari diagrammi.
Così come un linguaggio di programmazione non va inteso solo come un mezzo per istruire una macchina, ma anche e soprattutto come un veicolo di comunicazione con altre persone (che in futuro dovranno leggere e manutentere il nostro codice), un linguaggio di modellazione come UML va visto principalmente come uno strumento per chiarire e documentare il nostro lavoro a beneficio di altre persone. Un buon insieme di linee guida può essere di grande aiuto nella stesura di documenti chiari e precisi.

Come ho già avuto modo di sperimentare con il "C++ Manuale di Stile" (e, ancor prima, nelle innumerevoli e spesso animate discussioni "di stile"), una raccomandazione ha assai poco valore se non viene adeguatamente circostanziata. Questo testo non sarà quindi organizzato come un elenco sterile di regole, ma come una guida che, attraverso adeguate considerazioni, arriva a formulare od a sostenere una raccomandazione. Chi legge potrà decidere se seguire, rifiutare od adattare ogni raccomandazione in funzione di quanto le motivazioni portate si trovino in sintonia con la propria esperienza, le proprie attitudini ed il proprio contesto lavorativo.

Per scelta precisa, non farò riferimenti a nessun CASE tool particolare, e per quanto possibile cercherò di distanziarmi anche da particolari linguaggi di programmazione. So bene che tenderò a lasciarmi influenzare dai linguaggi con cui ho maggiore esperienza, che ricadono sotto la categoria dei linguaggi con type checking statico (come C++ e Java). In questi casi, cercherò sempre di farlo notare in modo esplicito; spero che i lettori mi indicheranno ogni situazione in cui dimenticherò di farlo.

In tempi più recenti, ho pensato di anticipare la fase di diffusione di UML 2 e di aggiornare il contenuto del manuale di stile, sia per quanto riguarda le precedenti raccomandazioni (che gradualmente verranno "migrate" verso UML 2), sia iniziando a presentare i nuovi diagrammi, con la consueta analisi critica che sfocia poi in raccomandazioni per il buon utilizzo.
Il testo assume una buona conoscenza della programmazione ad oggetti, ed una conoscenza discreta di UML 1.x, almeno nei suoi elementi essenziali. Non è invece necessario conoscere gli elementi di UML 2, che vengono introdotti partendo da zero.

Ogni analista o progettista che abbia una esperienza concreta con UML, o con un altro linguaggio di modellazione, è invitato a partecipare alla stesura di questo documento.