analisi-disegno.com


(pubblicato su ZeroUno, maggio 2005)

 

È arrivato UML 2.

La nuova versione dell'Unified Modeling Language presenta alcune novità sostanziali, soprattutto per la rappresentazione delle architetture software e per il business modeling.
Di Adriano Comai

Con un ritardo di circa tre anni sui piani iniziali, l'Object Management Group ha finalmente ufficializzato, all'inizio del 2005, la nuova versione (2.0) del linguaggio standard per la rappresentazione dei sistemi software.

I motivi del ritardo sono molteplici, ma hanno principalmente a che fare (anche se può sembrare strano) con l'importanza assunta dal linguaggio nell'ambito dello sviluppo software.

Dalla prima versione ufficiale, nel novembre 1997, UML si è presto diffuso a livello internazionale (e anche italiano) come una notazione in grado di agevolare il colloquio tra i diversi ruoli coinvolti nei progetti di sviluppo.

L'utilizzo di UML nelle aziende è in costante crescita, sia per motivazioni interne (ad esempio, per rendere omogenee le modalità di documentazione, e come base per le attività di formazione delle persone coinvolte nello sviluppo), sia per motivazioni esterne (partecipazione a progetti interregionali ed internazionali, gestione di rapporti di outsourcing con terze parti). Molti clienti passano ai propri fornitori specifiche in formato UML, e richiedono in seguito documentazione UML della progettazione effettuata. Gli ambienti di sviluppo più diffusi supportano UML, e la notazione è adottata in modo sistematico negli articoli pubblicati su riviste tecniche e nell'editoria informatica.

UML, in sintesi, ha raggiunto in questi anni l'obiettivo che gli autori originari del linguaggio (Grady Booch, Ivar Jacobson e Jim Rumbaugh) si erano prefissi: standardizzare le modalità di rappresentazione dei sistemi software, ponendo fine alla molteplicità delle notazioni utilizzate ed alle conseguenti difficoltà di comunicazione ed interpretazione dei modelli.

Limiti di UML, versioni 1.x

Il successo di UML è stato per alcuni versi singolare, anche perché il linguaggio, pur evoluto nel tempo attraverso una serie successive di revisioni (figura 1) presentava ancora, nella versione 1.5, alcuni limiti rilevanti. Era sufficientemente utile per la rappresentazione di dettagli applicativi (relazioni tra classi ed oggetti, sia a livello strutturale che dinamico, con i diagrammi delle classi e di interazione). Ma molto meno adeguato per rappresentare in modo sistematico l'architettura di un sistema ad alto livello, e insufficiente per rappresentare la scomposizione progressiva dei sistemi di dimensioni medio-grandi in sottosistemi di livello inferiore.

Un altro settore in cui le prime versioni di UML si sono dimostrate poco adeguate è il business modeling. Rappresentare processi organizzativi, ruoli e responsabilità con UML versioni 1.x era possibile, ma la notazione utilizzata era meno intuitiva rispetto ad altri linguaggi derivati dall'analisi strutturata, come i Data Flow Diagram (DFD), e soprattutto rispetto ai diagrammi di flusso. Benché UML includesse un flow chart (il diagramma di attività), il suo utilizzo risultava poco flessibile.

Le difficoltà della revisione

Consapevoli dei limiti del linguaggio, l'Object Management Group e le società produttrici di strumenti di modellazione UML iniziarono nel 2000 a lavorare per produrre la prima vera revisione sostanziale del linguaggio, con l'obiettivo di ufficializzarne la versione 2.0 nel 2002.

Il percorso si è rilevato più accidentato del previsto, a causa di diversi fattori:

  • il metamodello di UML (cioè la semantica degli elementi, e l'insieme delle regole che ne governavano la sintassi) era complesso, con molte aree di ambiguità
  • la notevole diffusione del linguaggio richiedeva che ogni futura versione di UML fosse retro-compatibile, ossia ammettesse come valide le regole sintattiche espresse nelle versioni precedenti del linguaggio
  • gli interessi delle società produttrici degli strumenti UML erano ovviamente in conflitto, ed ogni produttore cercava di forzare il linguaggio verso le proprie estensioni (i propri "dialetti") già realizzate, o comunque rispettando le proprie esigenze e priorità.

Come se tutto ciò non bastasse, a complicare il percorso che ha portato ad UML 2.0 è intervenuto un altro fattore decisivo: l'obiettivo di trasformare UML in un linguaggio sufficientemente preciso per rendere finalmente praticabile in modo sistematico la generazione automatica di codice, mediante l'utilizzo di strumenti conformi alla Model Driven Architecture (MDA), un altro standard OMG pubblicato nel 2002.

Caratteristiche di UML 2.0

Ora che la revisione si è completata, è possibile evidenziare gli aspetti fondamentali del cambiamento rispetto alle versioni precedenti di UML. Aspetti positivi e negativi, dal punto di vista degli utilizzatori del linguaggio, cio&aegrave; le persone coinvolte nei progetti di sviluppo software.

Partiamo dagli aspetti negativi. Il metamodello del linguaggio è diventato più preciso, ma si è anche complicato ulteriormente (e di molto) rispetto a quello delle versioni precedenti. Ciò non ha praticamente alcun effetto sul lavoro concreto di chi sviluppa e utilizza UML nei progetti, ma può risultare ostico per chi debba analizzare a fondo il linguaggio.

In secondo luogo, UML 2.0 ha portato il numero dei diagrammi da otto a tredici.

Diagrammi UML 1Diagrammi UML 2

In alcuni casi, si è trattato di modifiche più formali che di sostanza. I nuovi diagrammi degli oggetti e dei package sono semplicemente varianti del diagramma delle classi, già realizzabili in UML 1.x .

In altri casi, si è cercato di definire meglio varianti notazionali adeguate per particolari settori di sviluppo software. I diagrammi di interazione, che erano in precedenza due (sequenza e collaborazione, ora rinominato "diagramma di comunicazione") sono diventati quattro, con l'aggiunta del diagramma dei tempi, per il mondo real-time, e del diagramma di sintesi dell'interazione, utile per rendere comprensibili interazioni molto complesse.

Tra i diagrammi strutturali è infine comparso il diagramma delle strutture composite, che permette di rappresentare in modo accurato il partizionamento interno di un elemento strutturale (sottosistema, componente) nei suoi elementi costitutivi, caratteristica essenziale per la documentazione degli aspetti architetturali di un sistema.

La proliferazione del numero dei diagrammi, per quanto abbia motivi giustificabili, complica però il lavoro di chi utilizza UML nei progetti. Quali diagrammi bisogna utilizzare? Tutti o solo alcuni? E in quale sequenza temporale? Domande che chi ha già utilizzato UML si poneva anche in passato, ma che i tredici diagrammi disponibili nella versione 2.0 rendono ancora più pressanti.

Veniamo agli aspetti positivi. UML 2.0 ha superato i limiti principali delle versioni precedenti. Il linguaggio è ora adeguato per la rappresentazione degli aspetti architetturali, sia a livello macro che di dettaglio. È possibile, mediante un utilizzo appropriato dei diagrammi strutturali e comportamentali, rappresentare un sistema a livelli diversi, nella scomposizione dei suoi elementi e nella dinamica della loro interazione.

Per quanto riguarda il business modeling, la revisione competa dei diagrammi di attività li rende uno strumento estremamente flessibile ed efficiente per modellare i processi. Diventa anche possibile rappresentare in UML analisi effettuate con le tecniche di analisi strutturata, come i DFD.

Un altro aspetto positivo può sembrare paradossale, alla luce delle osservazioni precedenti sull'aumento della complessità del metamodello di UML e del numero dei diagrammi.

Eppure, dal punto di vista degli utilizzi concreti, UML 2.0 è più semplice delle versioni precedenti del linguaggio. Ad esempio, la maggior parte degli elementi di un sistema (a livello più sintetico, sottosistemi e componenti; a livello di maggior dettaglio, classi e oggetti) possono essere rappresentati in modo analogo, come un semplice rettangolo, anche se è possibile (e può essere consigliabile) utilizzare notazioni più precise per differenziarli tra loro.

Per il diagramma di sequenza, fondamentale per documentare gli aspetti dinamici di un sistema, ma complicato da specificare, sono state introdotte nuove caratteristiche (rappresentazione di condizioni ed iterazioni; possibilità di referenziare tra loro diagrammi diversi) utili per ridurne la complessità e aumentarne la comprensibilità.

Gli strumenti si adeguano

La maggioranza delle organizzazioni che usano UML hanno adottato in questi anni strumenti di modellazione visuale. Con l'arrivo di UML 2.0, si pone il problema di valutare se, e in quali tempi, sia opportuno procedere all'acquisto di una nuova versione, allineata all'evoluzione del linguaggio.

La scelta può essere delicata, in quanto gli strumenti UML sono spesso utilizzati da ruoli progettuali diversi (analisti, architetti software, sistemisti), ed in molte realtà sono stati effettuati in anni recenti investimenti notevoli sia per l'acquisto dei prodotti che in termini di formazione.

In termini generali, il passaggio ad UML 2.0 è comunque consigliabile, perché i vantaggi superano decisamente gli aspetti negativi, ed è quindi opportuno riconsiderare le scelte strumentali sin qui effettuate. Anche perché, a fronte delle sostanziali modifiche di UML 2.0, tutti gli strumenti disponibili sul mercato stanno subendo variazioni rilevanti.

È però opportuno tener conto del fatto che il cambiamento del mercato dei fornitori di strumenti UML negli ultimi anni è stato intenso.

Società indipendenti come Rational e Togethersoft sono state acquisite da partner di dimensioni più rilevanti (rispettivamente, Rational da IBM, Togethersoft da Borland). Si sono inoltre inseriti nel mercato nuovi fornitori, e lo scenario complessivo è decisamente mutato rispetto a pochi anni fa.

Lista strumenti UML 2

Uno degli effetti più rilevanti, per quanto riguarda Rational (la società produttrice di Rose, l'attuale leader di mercato), è stato un legame sempre più stretto dell'offerta Rational nel quadro dell'offerta complessiva di IBM per lo sviluppo software, ed in particolare con la piattaforma di sviluppo Websphere, e la sostituzione di Rose con un insieme di nuovi prodotti (Rational Software Modeler, Rational Software Architect, Rational Developer).


Elenco pubblicazioni.


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