|
Usare
UML
UML può
essere usato per:
- Pensare.
Nel corso delle attività di sviluppo o di evoluzione di un sistema,
UML può servire agli sviluppatori per ragionare sui problemi
e sulle soluzioni.
- Comunicare (e documentare).
Tra soggetti diversi, distanti nello spazio (ad esempio da analisti
separati fisicamente dai progettisti e dagli sviluppatori) o nel tempo
(posso trovarmi a riprendere in mano modelli che io stesso ho creato
in passato). Tra aziende diverse, che devono collaborare su basi contrattuali.
Naturalmente, c'è qualche
differenza tra l'utilizzo di UML per pensare e per comunicare. Se lo uso
per ragionare, posso permettermi di fare solo i diagrammi che mi servono
al momento, al livello di dettaglio e di precisione che mi interessa,
senza pormi problemi di comunicazione. Se invece lo uso per comunicare
e documentare, è necessario che chiarisca prima di tutto con chi
voglio comunicare, che cosa esattamente voglio comunicare, e a quale livello
di dettaglio e di precisione.
Utilizzi
scorretti di UML
Capita
sovente che mi vengano presentati esempi scorretti di utilizzo di UML.
La prima causa è legata alla complessità di UML, ed alla difficoltà di
raggiungere un buon livello di competenza. I concetti che costituiscono
il linguaggio sono il risultato di decenni di ingegneria del software,
ed hanno significati precisi. Utilizzare la notazione senza conoscere
bene i concetti rappresentati porta a risultati inefficaci, e a perdite
di tempo.
In molti casi manca una formazione adeguata. Spesso vengono realizzati
molti più diagrammi rispetto a quelli che sarebbero stati necessari; altre
volte ne mancano di essenziali. Bisogna ricordare che ogni progetto ha
le sue caratteristiche specifiche: è importante (tempi, costi, efficacia)
che UML venga utilizzato nel modo migliore nello specifico contesto.
Il secondo motivo che provoca utilizzi scorretti è che UML non è, allo
stato attuale, verificabile in modo automatico (non è "compilabile").
Gli errori, anche gravi, che un utilizzatore può compiere non sono rilevabili
se non a fronte di verifiche condotte da chi conosca bene il linguaggio.
Nell'evoluzione dello standard UML stanno assumendo un peso sempre maggiore
le "well-formedness rules" (regole per la definizione di costrutti
ben formati), che vincolano e precisano gli aspetti semantici e sintattici
che regolano la produzione di modelli corretti. Purtroppo si tratta di
aspetti poco considerati, non tanto dagli utilizzatori del linguaggio
(che non sono tenuti a conoscerne gli aspetti più sofisticati), quanto
dai produttori di strumenti.
Molti strumenti di visual modeling UML
disponibili sul mercato consentono troppi errori, per assenza di controlli,
e permettono utilizzi sbagliati sotto il profilo semantico e sintattico.
All'opposto, non supportano lo standard in modo completo, e non prevedono
ad esempio elementi e costrutti sintattici ammessi dal linguaggio, limitando
così le potenzialità espressive e costringendo a ricorrere a soluzioni
insoddisfacenti per rappresentare aspetti anche molto semplici.
Conseguenze
UML serve a pensare...
ma utilizzare i concetti base in modo improprio può invece complicare
la vita dei gruppi di progetto, che perdono tempo ponendosi domande a
cui non trovano risposta, o intraprendendo percorsi scorretti.
UML serve a comunicare... ma modelli scorretti ostacolano la comunicazione,
anziché agevolarla.
Possibili
rimedi
UML prosegue lungo
la strada di una sempre maggiore precisione (la versione 2.0 è
un passo significativo), e prima o poi i produttori di tool UML miglioreranno
i loro prodotti.
Nel frattempo, qualche suggerimento:
1) Curare la formazione.
2) Leggere i libri consigliati nella bibliografia.
3) Scaricare la versione ufficiale dello standard UML (http://www.omg.org),
e usarla come riferimento.
4) Nelle prime applicazioni
pratiche, se non esistono competenze sufficienti nella vostra organizzazione,
farsi supportare da esperti.
|