analisi-disegno.com

Homepage  | Blog | Per essere avvisati in caso di nuovi documenti | In English


Usare UML

UML può essere usato per:

  1. 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.
  2. 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.


analisi-disegno.com, servizi e materiali per lo sviluppo dei sistemi software, a cura di Adriano Comai.