UML

Unified Modeling Language (UML)

È uno standard dell’Object Management Group (OMG), ed ISO (19505:2012). Fa quindi parte di una famiglia di standard, che comprende anche SysML e BPMN.

Definizione ufficiale di UML: “Un linguaggio per specificare, visualizzare, e realizzare i prodotti di sistemi software, e anche per il business modeling. UML rappresenta una collezione di ‘best engineering practices’ che si sono dimostrate utili nella progettazione di sistemi complessi e di grandi dimensioni.”

Più semplicemente: una notazione standard per rappresentare in modo visuale (grafico) le caratteristiche dei sistemi, sia a livello business che a livello software.

L’ultima versione dello standard, per la quale ho collaborato alla revisione, è qui: https://www.omg.org/spec/UML/2.5.1/

Riferimenti di base

Storia (in sintesi) di UML

La storia di UML, il processo di standardizzazione ed unificazione metodologica che lo ha definito, è iniziata nel 1994. Punto di partenza l’ingresso di Jim Rumbaugh nella società Rational, in cui operava Grady Booch. Altra tappa importante l’arrivo nella stessa società, a fine 1995, di Ivar Jacobson.

  • 1995 – ottobre: Unified Method versione 0.8 (Booch e Rumbaugh)
  • 1996 – giugno: Unified Modeling Language (UML) versione 0.9 (Booch, Rumbaugh, Jacobson)
  • 1996 – ottobre: UML 0.91 (Booch, Rumbaugh, Jacobson)
  • 1997 – gennaio: UML 1.0 (Booch, Rumbaugh, Jacobson e partner UML, tra cui Microsoft, Oracle, Hewlett-Packard, Digital, Texas Instruments), in risposta alla richiesta avanzata dall’ OMG (Object Management Group) per un framework di interoperabilità tra strumenti di analisi e disegno. All’OMG arrivano anche altre proposte, tra cui quelle firmate da IBM e Platinum
  • 1997 – settembre: Dopo accordi con Platinum, IBM e le altre “cordate”,  la versione 1.1 dello Unified Modeling Language viene sottoposta all’approvazione di OMG. È una proposta congiunta di Rational Software, Microsoft, Hewlett-Packard, Oracle, Sterling Software, MCI Systemhouse, Unisys, ICON Computing, IntelliCorp, i-Logix, IBM, ObjecTime, Platinum Technology, Ptech, Taskon, Reich Technologies, Softeam, e altri.
  • 1997 – 16 novembre: UML 1.1 diventa ufficialmente uno standard OMG (con il nome ufficiale di “UML OMG 1.0”)
  • 1998 – dicembre: UML 1.2 – revisione editoriale, correzione di errori tipografici e grammaticali
  • 1999 – giugno: UML 1.3 – variazioni minori ai diagrammi delle classi, dei casi d’uso, di interazione; specifica degli aspetti semantici e notazionali per modelli e sottosistemi.
  • 2003 – giugno: UML 2.0 approvata in bozza – molte variazioni significative, completa ristrutturazione del metamodello
  • 2005 – marzo: UML 2.0 diventa la versione ufficiale
  • 2015 – marzo: UML 2.5 – completa ristrutturazione della documentazione – ho collaborato alla revisione di questa versione, che ha poi avuto una nuova edizione nel 2017: https://www.omg.org/spec/UML/2.5.1/

A partire dalla versione 2.0 si può ritenere il nucleo (“core”) di UML sostanzialmente stabile.
Prosegue, naturalmente, l’evoluzione dei profili UML, ossia l’estensione di UML per supportare nuovi abiti di applicazione e nuove tecnologie. Ma sono improbabili, a questo punto, evoluzioni significative del nucleo.

Bibliografia essenziale su UML

I testi “primari” su UML sono quelli pubblicati in modo ufficiale da OMG, cioè i veri e propri standard.

I testi “secondari”, cioè introduzioni, approfondimenti, commenti, sono ormai troppo numerosi per elencarli tutti: segnalo qui solo quelli che ritengo fondamentali.

Interessanti, ma oggi solo come documento, i testi pubblicati dai tre autori originari di UML:

Altri testi che trattano UML, ma relativamente ad aspetti specifici, come l’analisi e design Object Oriented , i casi d’uso, il business modeling sono riportati nelle bibliografie delle relative sezioni del sito.

Strumenti UML

Gli strumenti UML disponibili sul mercato sono molti – alcuni gratuiti, altri a pagamento. Elenco aggiornato su Wikipedia.

Usare UML in pratica

UML può essere usato per:

  • Pensare. Nel corso delle attività di sviluppo o di evoluzione di un sistema, UML può servire per ragionare sui problemi e sulle soluzioni.
  • Comunicare (e documentare). Tra soggetti diversi, distanti nello spazio (ad esempio da analisti separati fisicamente dagli sviluppatori) o nel tempo (riprendo in mano modelli che io stesso ho creato in passato). Tra aziende diverse, che devono collaborare su basi contrattuali.

Naturalmente, ci sono differenze. Se uso UML per ragionare, faccio 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.

Vedi anche: Diagrammi per pensare, diagrammi per comunicare

Può capitare, per vari motivi, di usare UML male.

UML è complesso, perché deve poter rappresentare ogni tipo di sistema software, ad ogni livello di astrazione.
Ed è rigoroso, in quanto i concetti che costituiscono il linguaggio sono il frutto di decenni di ingegneria del software, ed hanno significati precisi.

Può mancare una formazione adeguata. A volte si creano molti più diagrammi rispetto a quelli che sarebbero 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.

Gli strumenti di modellazione UML potrebbero aiutare, guidando l’utilizzatore a rappresentare le caratteristiche importanti dei sistemi. Accade raramente.

  • Molti strumenti 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.

La conseguenza è che 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.

Introduzioni e linee guida

Video

Altri 5 brevi video in italiano su come usa UML in pratica.

Notazioni derivate da UML

UML costituisce la base per una serie di notazioni specialistiche. Tra le più significative:

  • SysML (System Modeling Language) per rappresentare sistemi hardware / software
  • SOAML (Service Oriented Architecture Modeling Language) per rappresentare architetture a servizi
  • IFML (Interaction Flow Modeling Language) per rappresentare interazioni a livello di interfaccia utente

Articoli

Formazione: