Luoghi comuni su UML

UML – lo Unified Modeling Language – è ormai molto diffuso. Si sono però diffusi anche alcuni luoghi comuni, che in alcuni casi ne frenano l’utilizzo, in altri casi creano aspettative non realistiche.

1 – Che richieda un cambiamento nel modo di lavorare, l’adozione di una nuova “metodologia”.

UML non è una metodologia, e non richiede di cambiare le proprie modalità di lavoro. E’ un linguaggio – notazione per rappresentare i sistemi software (per “fare i disegnini”) in modo standard. È l’esatto equivalente, nel mondo del software, alla notazione utilizzata in tutto il mondo per rappresentare gli impianti elettrici. A nessun elettricista verrebbe in mente di utilizzare una notazione diversa da quella standard per rappresentare un impianto: non ne avrebbe nessun vantaggio. Lo stesso vale per UML.

2 – Che l’utilizzo di UML costi di più in termini di tempo (e alla fine, anche in termini economici).

L’alternativa all’utilizzo di UML non è l’assenza di ogni forma di rappresentazione e documentazione. L’alternativa consiste nell’utilizzo di un’altra notazione, non standard.

Quasi tutti coloro che sono coinvolti in progetti software usano forme di rappresentazione grafica. Disegnano rettangoli e frecce. Farli in UML non costa di più che farli in altro modo, ma agevola la comunicazione e la comprensione.

3 – Che le rappresentazioni debbano essere necessariamente dettagliate.

È una variante del luogo comune precedente. A volte l’esplicitazione puntuale di tutti gli aspetti di dettaglio, anche di quelli che sembrerebbero ovvi (il “mettere i fiorellini”) può essere necessaria. Dipende da cosa vogliamo comunicare, a chi, in quali circostanze.

In molti altri casi, in particolare quando la notazione viene usata per ragionare su problemi concreti, i fiorellini sono dannosi, perché fanno perdere tempo. UML può essere usato in modo molto pragmatico, per rappresentare solo ciò che ci serve, senza dettagli inutili.

4 – Che UML sia difficile.

Un po’ è vero. Come ogni linguaggio – notazione, necessita di un periodo di apprendimento. E poiché UML è molto articolato (intende rappresentare qualunque tipo di sistema software, realizzato con qualunque tecnologia, a diversi livelli di astrazione) l’apprendimento “completo” richiederebbe – se fattibile! – davvero parecchio tempo.

Fortunatamente, si può usarlo in modo pragmatico, anche senza conoscerne tutti i dettagli e tutte le sfumature, dopo un buon corso di formazione (se al termine del corso i partecipanti non si sentono in grado di iniziare ad applicare UML nel loro lavoro concreto, è segno che il corso non ha funzionato).

5 – Che UML richieda una sponsorizzazione da parte del management per essere utilizzato all’interno delle organizzazioni.

L’utilizzo di UML è il frutto di una decisione individuale, che può essere presa dal singolo sviluppatore software.

In alcuni casi, il management comprende i vantaggi derivanti dall’utilizzo di un linguaggio – notazione standard per favorire la comunicazione, sia all’interno dell’organizzazione che verso l’esterno. E può agevolarne la diffusione. In altri casi, il management è indifferente. Ma è comunque improbabile che ne proibisca o ostacoli l’utilizzo.

6 – Che per usarlo siano necessari strumenti di modellazione costosi.

Gli strumenti costosi hanno una loro utilità, nei contesti organizzativi in cui tutte le loro potenzialità (o almeno la maggior parte) vengono effettivamente sfruttate.

Ma per rappresentare i sistemi in UML possono essere perfettamente adeguati anche strumenti a basso costo, o gratuiti. Dipende dalle esigenze concrete, da valutare caso per caso con un’analisi del rapporto tra costi e benefici.

7 – Che l’utilizzo di UML sia consigliabile solo per i progetti che utilizzano tecnologie “object oriented”.

È una leggenda, nata dal fatto che è stato creato da esperti nello sviluppo software object oriented. Alcuni concetti hanno radici object oriented, altri no.

In ogni caso, UML è perfettamente adeguato anche per rappresentare sistemi realizzati con altre tecnologie, ad esempio con quelle utilizzate in ambito mainframe alcuni decenni fa.

8 – Che l’utilizzo di UML sia in contrasto con i metodi di sviluppo agili.

I metodi di sviluppo software “agili” tendono a ridurre al minimo la documentazione, e vedono in modo negativo i progetti (“non agili”) in cui per lunghi periodi si producono documenti anziché software concreto.

Alcuni sostenitori dei metodi agili pensano, sbagliando, che UML sia appropriato solo per gli approcci “non agili”. In realtà viene usato in molti contesti come strumento di comunicazione informale all’interno dei gruppi di lavoro, in modo assolutamente non burocratico. Le decisioni relative al documentare
in misura maggiore o minore, a quali documenti siano necessari, a chi debba produrre quali documenti e quando, sono totalmente indipendenti da UML.

9 – Che il suo utilizzo migliori il livello di competenze nella progettazione software.

Purtroppo no. UML è solo un linguaggio – notazione per la rappresentazione dei sistemi, non una bacchetta magica. Può al massimo favorire il confronto tra diverse possibili soluzioni, visto che agevola la comunicazione e la comprensione reciproca tra i partecipanti ai progetti.

D’altra parte, la grande maggioranza dei testi e degli articoli sulla progettazione software pubblicati negli ultimi anni utilizza UML. Quindi conoscerlo è opportuno per chi vuole, studiando, migliorare la propria professionalità.