UML: un linguaggio di modellazione grafico
L’Unified Modeling Language (UML), in italiano “linguaggio di modellazione unificato”, è uno standard per la visualizzazione grafica di oggetti, stati e processi all’interno di un sistema. Il linguaggio di modellazione può da un lato servire da cianografia per un progetto e garantire così un’architettura strutturata dell’informazione; dall’altro aiuta gli sviluppatori a rappresentare in modo comprensibile il sistema ai non specialisti. L’UML è principalmente utilizzato nello sviluppo di software orientati agli oggetti. In seguito ad ampliamenti dello standard nella versione 2.0 si adatta anche per la rappresentazione dei processi aziendali.
Genesi dell’Unified Modeling Language
Prima che l’UML venisse introdotto nello sviluppo software, il campo della programmazione orientata agli oggetti (OOP) era già in forte crescita. Questo stile di programmazione si basa sul concetto che tutto è un oggetto: i componenti di un programma sono oggetti che interagiscono tra di loro. Anche i messaggi che vengono inviati tra i componenti sono costituiti da oggetti. Ogni singolo oggetto è un esemplare della sua classe superiore. La classe stessa funge anche da oggetto e determina il comportamento delle istanze dell’oggetto che contiene. Gli oggetti sono composti da dati e codice: i dati organizzano l’oggetto in campi, detti anche attributi, mentre il codice determina la loro procedura.
Dalla fine degli anni 80 fino agli anni 90 sono nati moltissimi metodi e linguaggi per la rappresentazione basata su modelli di programmazione orientata agli oggetti. Come conseguenza ci si è ritrovati con una quantità ingestibile di metodi difficili da confrontare tra loro. Al fine perciò di riunificarli, tre sviluppatori, James Rumbaugh, Grady Booch e Ivar Jacobson, hanno deciso di unire diversi linguaggi esistenti in uno standard comune.
I tre avevano già creato i propri metodi di sviluppo software orientato agli oggetti:
- Il metodo Booch
- L’Object Modeling Technique (OMT)
- Il metodo di ingegneria del software orientato agli oggetti (OOSE)
Come linguaggio di modellazione, l’UML dovrebbe stabilire la semantica nel rappresentare questi metodi. A partire dal 1996, gli sviluppatori hanno lavorato con un team al completamento dell’UML con il nome di “UML Partners”. Lo hanno poi consegnato all’Object Management Group (OMG), che a propria volta nel 1997 ha adottato la versione 1.1 dell’Unified Modeling Language come standard.
Non ancora soddisfatti, gli sviluppatori hanno creato una task force con l’obiettivo di migliorare il linguaggio su due diverse versioni. Le critiche esistenti contestavano una semantica imprecisa e inutilmente complessa, la poca adattabilità e un’insufficiente standardizzazione. Pertanto è stata apportata una revisione più ampia. Il risultato è stato UML 2.0 che ha fissato il nuovo standard nel 2005. La versione 2.4.1 costituisce la base per la standardizzazione ISO 19505-1 (struttura) e quella 19505-2 (sovrastruttura) del 2012. La versione 2.5.1 di UML è stata rilasciata nel dicembre del 2017.
UML: termini importanti
L’Unified Modeling Language è considerata una lingua franca dei linguaggi di modellazione. Come accennato in precedenza, l’UML dà una rappresentazione visuale degli stati e delle interazioni tra oggetti all’interno di un sistema. Per questa diffusione deve probabilmente ringraziare anche i membri dell’OMG (inclusi IBM, Microsoft e HP). La semantica strutturata contribuisce al resto. Con i diagrammi UML si possono rappresentare i seguenti componenti di sistema:
- singoli oggetti (componenti di base);
- classi (riunisce gli elementi con le stesse proprietà);
- relazioni tra oggetti (gerarchia e comportamento/comunicazione tra oggetti);
- attività (combinazione complessa di azioni/blocchi di comportamento);
- interazioni tra oggetti e interfacce.
Metamodellazione
UML 2.0 definisce le unità linguistiche che operano a diversi livelli, attraverso le quali si esprimono la struttura e il comportamento di un sistema. Il linguaggio di modellazione utilizza alcuni elementi per definire se stessa. La metamodellazione include tutti gli elementi di UML, compresi quelli che descrivono l’UML stesso. Per fare ciò utilizza quattro livelli disposti gerarchicamente (da M0 a M3).
Il meta-metapiano M3 specifica i metadati del linguaggio di modellazione e le sue correlazioni utilizzando la Meta Object Facility (MOF), che definisce il metamodello. Inoltre abilita il trasferimento dei metadati. Il formato XMI definito dall’OMG è uno strumento pratico per condividere dati orientati agli oggetti su un meta-metalivello tra gli strumenti di sviluppo. L’Object Constraint Language (OCL), un linguaggio di programmazione dichiarativo, integra UML e regola le condizioni sulla rispettiva modellazione. Come linguaggio testuale, tuttavia, serve solo da supporto, anziché essere disponibile per la modellazione stessa.
L’immagine sopra mostra la metamodellazione di UML 2.0. Il livello M0 è quello di base e rappresenta oggetti reali e concreti nonché set di dati singoli (ad esempio un oggetto o un componente). Il livello M1 include tutti i modelli che descrivono e strutturano i dati del livello M0, che sono i diagrammi UML come il diagramma di attività o il diagramma di pacchetto (spiegato più avanti). Per definire la struttura di questo modello, i metamodelli del livello M2 stabiliscono le specifiche e la semantica degli elementi del modello.
Se volete creare un diagramma UML comprensibile dovete conoscere il metamodello UML e le sue regole. Il livello più alto, ovvero il livello M3, è un metamodello del metamodello. La menzionata Meta Object Facility lavora su un livello astratto che definisce i metamodelli. Questo livello si autodefinisce, altrimenti dovrebbero esistere ulteriori metalivelli sovraordinati.
Unità di linguaggio
UML (livello M2) stabilisce le regole per la propria semantica. Le unità linguistiche sono concetti che vengono definiti nella sovrastruttura UML 2.0. Ciò consente una rappresentazione formale che tutti gli interessati possono capire. Le unità di linguaggio, in inglese language units, astraggono in modo simile oggetti e processi costruiti e funzionanti, dando loro una forma visivamente rappresentabile. A seconda del livello gerarchico all’interno del modello gli elementi assumono ulteriori compiti specializzati o definiscono altri elementi vicini.
Classe: come unità linguistica le classi sono un aspetto fondamentale dell’UML. Esse definiscono che cosa rende tale una classe e come interagiscono tra loro le diverse classi. Questa language unit ha quattro livelli che vanno dagli elementi semplici fino alle relazioni più complesse:
- Kernel descrive gli elementi dell’infrastruttura UML 2.0 come pacchetto, nome, attributo, ecc.;
- AssociationClasses definiscono le classi di associazione;
- Interfaces definisce le interfacce;
- Powertype è una classe le cui istanze sono sottoclassi all’interno di questa classe.
Componente: i componenti sono parti costitutive che limitano il proprio contenuto dal sistema esterno. Solo attraverso interfacce o porte c’è un collegamento verso l’esterno. Un connettore di composizione si connette a un altro componente attraverso l’interfaccia. Il connettore di delega collega gli elementi interni con un’interfaccia sul confine esterno. I componenti sono modulari e intercambiabili.
Struttura di composizione: la struttura di composizione dell’unità linguistica descrive elementi che sono schermati come componenti all’interno e all’esterno. Solo le porte collegano il contenuto al sistema esterno. I cosiddetti classificatori incapsulati sono composti da elementi, le parti, che comunicano tramite connettori.
Profilo: un profilo configura UML 2.0 per esigenze specifiche. Termini astratti come attività o oggetto devono essere specificati per alcuni progetti per aumentare la comprensione. In alcuni casi è possibile personalizzare la semantica e le annotazioni su un profilo.
Modello: il modello comprende tutti gli elementi necessari a rappresentare una specifica visuale della struttura o del comportamento di un sistema. Vi appartengono anche influssi esterni come attori.
Azione: quando si tratta di rappresentare comportamenti, le azioni sono di vitale importanza, poiché registrano i valori tramite i pin di input e li inviano ai pin di output. Questi sono i gruppi tematici che l’UML imposta per le azioni:
- Manipolazione degli oggetti
- Manipolazione delle relazioni oggettuali
- Manipolazione delle caratteristiche strutturali
- Azioni di visualizzazione
- Creazione di valori
- Azioni sugli oggetti
- Ricezione di eventi
Comportamenti: il comportamento dell’unità linguistica o la descrizione comportamentale suppone la modellazione di aspetti dinamici all’interno di un sistema. Comprende tre specifiche:
- Attività: le azioni interagiscono attraverso flussi di dati e di controllo. Ciò si traduce in un complesso sistema di comportamenti, le attività.
- Interazione: questo metamodello descrive come avvengano gli scambi di messaggi tra oggetti, quando un messaggio viene mandato a un determinato oggetto e quali altri elementi ne sono influenzati.
- Diagramma di stato: in un diagramma di stato, questo metamodello modella stati (situazioni con proprietà immodificabili) e pseudo-stati (stati senza assegnazione di valore), nonché le loro transizioni. Gli oggetti in uno stato possono essere assegnati ad azioni o attività.
Distribuzione: una rete è composta da oggetti collegati tra loro in un mesh. Un caso speciale di applicazione è quando questi elementi rappresentano software eseguibili o artefatti. Queste risorse vengono eseguite su ambienti di esecuzione o dispositivi che categorizzano UML 2.0 come nodo. L’artefatto è perciò dipendente dai nodi. La distribuzione rappresenta questo rapporto di dipendenza che si verifica durante l’installazione.
Casi di applicazione (o d’uso): il caso di applicazione o d’uso (come unità linguistica) rappresenta i requisiti di sistema. L’attore (una persona o un sistema) è un elemento che descrive chi o cosa dovrebbe svolgere una determinata attività utilizzando il sistema. Il sistema può anche consistere in una classe o in un componente ed è descritto come soggetto. Il caso di applicazione (come elemento del modello) afferma solamente che è previsto un comportamento denominato che è visibile agli attori dall’esterno. Solitamente non rappresenta le azioni esatte: all’interno di una descrizione comportamentale, la modellazione associa i requisiti dettagliati al caso di applicazione.
Flussi di informazione: questa unità di linguaggio UML descrive l’unità di informazioni sugli elementi e il flusso di informazioni. Questi elementi del modello descrivono tecniche di descrizione comportamentale che possono essere particolarmente orientate ai dettagli, come attività o interazioni. Questa rappresentazione semplificata consente l’utilizzo universale di questi elementi di modellazione di tutti i tipi di diagrammi UML. L’unità di informazione non è perciò mai descritta in dettaglio attraverso attributi o incorporata in metodi, a differenza della classe. Il flusso di informazioni quindi collega anche tutti gli elementi possibili che scambiano qualsiasi tipo di informazione.
Diagrammi UML: aree di applicazione e breve introduzione
Il linguaggio di modellazione stabilisce 14 tipi di diagrammi divisi in due categorie. La struttura e il comportamento delle categorie principali sono i concetti di base che rappresentano i diagrammi UML. All’interno del gruppo di diagrammi comportamentali, l’UML specifica la sottocategoria dei diagrammi di interazione. Esiste una quarta sotto-specifica a partire dall’UML 2.0, che determina la configurazione degli schemi del modello.
Diagrammi strutturali
I diagrammi strutturali rappresentano i singoli elementi di un sistema, pertanto sono particolarmente adatti per la rappresentazione dell’architettura software. La rappresentazione statica non illustra i cambiamenti, ma stati e dipendenze in un determinato momento. I singoli elementi, o oggetti, sono correlati l’uno con l’altro. Così ad esempio un oggetto appartiene a una classe. Altri componenti possono essere i nodi di calcolo o gli artefatti (un artefatto rappresenta un risultato, ad esempio un file di script completato).
I diagrammi UML in questa categoria rappresentano un intero sistema o una sottostruttura, che, ad esempio, aiuta a chiarire in dettaglio la struttura. Con UML 2.x il linguaggio assegna alla categoria struttura sette tipi di diagrammi:
- Diagramma di classi: se gli oggetti condividono un comportamento comune o hanno la stessa struttura, possono essere classificati o assegnati a una classe. La classe è quindi un elemento semplificativo, un’astrazione, ai fini della rappresentazione visuale. Classi e oggetti sono collegati tra loro attraverso interfacce. Tutti questi componenti, così come le loro relazioni reciproche, rappresentano il diagramma di classe: il diagramma rappresenta le classi con un rettangolo e il nome della classe è in grassetto, come mostrato di seguito.
- Diagramma degli oggetti: il diagramma degli oggetti ha una struttura simile al diagramma delle classi. Dove il nome appare nel diagramma delle classi (vedi sopra: persona), il diagramma degli oggetti specifica il nome dell’istanza insieme al nome del classificatore/categoria. Secondo le specifiche, vanno sottolineate (ad esempio Laura: persona)
- Diagramma dei componenti: un componente è un modulo isolato dal sistema esterno che interagisce con altri componenti attraverso interfacce definite. È un sottotipo della classe. Pertanto le caratteristiche strutturali come operazioni e attributi definiscono in modo più specifico il componente. Il componente include diversi elementi, che possono essere a propria volta componenti, ma anche classi, sottosistemi o parti. Durante la modellazione ci sono due opzioni di visualizzazione, se necessario: la black box (dove il contenuto è nascosto) e la white box (dove il contenuto è visibile).
- Diagramma di struttura composta: gli oggetti appartengono a classi che possono a propria volta essere classificate. Nell’UML queste metaclassi si chiamano classificatori. Il diagramma della struttura di composizione rappresenta le parti e i connettori di un classificatore. Le parti sono sempre una componente dell’intero, anche se non sono per forza necessarie al completamento del classificatore. I connettori sono le connessioni tra le parti. Le funzioni o i servizi, che richiedono componenti al di fuori del classificatore, inviano parti tramite un’interfaccia.
- Diagramma del pacchetto: un pacchetto (package) comprende elementi come interfacce o classi in uno spazio di nomi. I pacchetti inoltre possono unirsi con altri pacchetti (package merge), importarli (package import) o contenere altri pacchetti (sottopacchetti). I pacchetti organizzano i contenuti del grafico in modo gerarchico come in un diagramma ad albero. Il diagramma del pacchetto trova applicazione, ad esempio, nel metamodello di UML 2. Nei sistemi software rappresenta le sottounità in modo modulare; in base alle specifiche, un pacchetto è costituito da un header e dal contenuto.
Uno spazio dei nomi (namespace) è un elemento del metamodello UML 2. I componenti devono avere un nome e possedere uno dei seguenti attributi di visibilità: package, private, protected o public. Il pacchetto è un caso particolare dello spazio dei nomi.
- Diagramma di distribuzione: il diagramma di distribuzione modella la distribuzione fisica degli artefatti sui nodi. I nodi (nodes) sono hardware (device nodes), che possono fornire uno spazio di archiviazione o software (execution environment nodes), che forniscono un ambiente per i processi in esecuzione. Sono raffigurati come un parallelepido rettangolare. Gli artefatti sono disegnati come rettangoli. All’interno è scritto il nome del file. Per distinguerlo da una classe, aggiungete lo stereotipo <<artefatto>>. Il diagramma è utile per rappresentare le dipendenze tra nodi e artefatti, le cosiddette relazioni di distribuzione.
- Diagramma di profilo: i diagrammi di profilo si utilizzano al livello del metamodello. Servono ad assegnare uno stereotipo a una classe o un profilo a un pacchetto. Su un metalivello avete così la possibilità di personalizzare il modello per una piattaforma o un dominio diversi. Ad esempio, se si limita la semantica UML all’interno di un profilo, questa eredita le specifiche alle classi subordinate.
Diagrammi di comportamento
I diagrammi di comportamento (behavioral diagrams) coprono le restanti specifiche sull’UML. A differenza dei diagrammi strutturali, essi non sono statici, ma rappresentano processi e situazioni dinamiche. I diagrammi di comportamento includono anche i diagrammi di interazione (vedi sotto).
- Diagramma dei casi d’uso: il diagramma dei casi d’uso (use case diagram) mostra quale comportamento ci si aspetta successivamente da un sistema. Questa modellazione non è adatta solo per i sistemi software, ma anche ad esempio per esecuzioni prefissate nei processi aziendali. Il caso d’uso coinvolge un attore (uomo o sistema) con uno scopo. Il diagramma di solito prende il nome dall’obiettivo che ci si prefigge di ottenere. I diversi casi d’uso all’interno del sistema soddisfano l’obiettivo dell’attore.
Il diagramma dei casi d’uso rappresenta l’UML con un rettangolo con l’etichetta “use case”. Il mittente è l’attore (rappresentato come una figura umana stilizzata, anche nel caso in cui si tratti di un sistema). L’attore associa un rapporto di dipendenza (mostrato con un trattino) con il caso d’uso (ellisse con un’etichetta) all’interno di un sistema (rettangolo con etichetta <<sistema>> e nome del sistema).
- Diagramma delle attività: le attività consistono in una rete di azioni correlate ai flussi di dati e di controllo. Mentre il diagramma dei casi d’uso rappresenta i requisiti di sistema, il diagramma delle attività mostra come procedono questi casi di applicazione. In questo tipo di diagramma è importante ad esempio il token: nei processi paralleli è un marcatore che definisce quali processi abbiano la priorità e debbano quindi ricevere risorse (come ad esempio la memoria).
- Diagramma di stato: un automa a stati finiti rappresenta un insieme finito di stati in un sistema. Se una condizione specificata è soddisfatta nel sistema (cioè viene attivato un trigger), si verifica una situazione corrispondente, che può includere attività o interazioni. Su UML 2.0 uno stato rappresenta questa situazione. Gli stati sono considerati vertici (inglese: vertices) e sono rappresentati come rettangoli con angoli arrotondati. Inoltre il diagramma di stato modella le transizioni (inglese: transitions) da uno stato (vertice di partenza) all’altro (vertice di destinazione). UML modella le transizioni di stato come spigoli. Le azioni sono l’ultimo pilastro e assegnano le specifiche del comportamento allo stato.
Il comportamento è collegato a situazioni o a eventi specifici. Il diagramma di stato UML conosce quattro specifiche:
- Comportamento di entrata (entry behavior)
- Comportamento di stato (doActivity)
- Comportamento in caso di un evento (event behavior)
- Comportamento di uscita (exit behavior)
Inoltre uno stato può essere interrotto e fatto riprendere dallo stesso punto. Questa proprietà si chiama stato della cronologia.
Diagrammi di interazione
I diagrammi di interazione sono una sottospecie dei diagrammi di comportamento. Quindi rappresentano anche situazioni dinamiche. In particolare sono utili per la modellazione di comportamenti nei quali gli elementi si scambiano informazioni. I diagrammi definiscono il ruolo degli oggetti coinvolti. Inoltre assegnano un nome e una priorità ai messaggi inviati tra gli oggetti. I diagrammi di interazione mostrano inoltre come questi messaggi influenzino gli elementi comportamentali: ad esempio possono avviare o mettere in pausa le attività.
- Diagrammi di sequenza: essendo un diagramma di interazione, il diagramma di sequenza raffigura lo scambio di messaggi tra oggetti, che sono modellati dal tipo di diagramma UML come una cosiddetta linea di vita. In questo senso è simile ad altri diagrammi di comportamento come il diagramma delle attività. Tuttavia, a differenza di questi, il diagramma di sequenza non è utilizzato per avere una panoramica sul comportamento di un sistema, ma per rappresentare in dettaglio un comportamento possibile tra molti. Inoltre prescrive una cronologia, dove una linea tratteggiata rappresenta il corso del tempo.
UML 2.0 rappresenta messaggi sincroni (UML: freccia con punta piena) e asincroni (UML: freccia con punta aperta). I messaggi sincroni sono quelli che tengono occupato un canale fino a quando non ricevono una risposta dall’oggetto di destinazione, determinando le caratteristiche comportamentali sotto forma di operazioni sincrone. I messaggi asincroni, invece, controllano l’oggetto sorgente e includono operazioni asincrone e segnali (pacchetti di dati inviati tra azioni).
- Diagramma di comunicazione: simile al diagramma di sequenza, il diagramma di comunicazione modella un trasferimento di messaggi. Ancora una volta vengono utilizzate linee di vita. Tuttavia questo diagramma UML non usa linee tratteggiate per la temporizzazione, ma numera le sequenze con numeri e lettere. Questi cosiddetti termini di sequenza si trovano su una freccia la cui punta va in direzione del destinatario. I numeri rappresentano l’ordine in cui vengono inviati i messaggi, mentre le lettere indicano il livello gerarchico (come mostrato nella figura seguente):
- Diagramma temporale: il diagramma temporale consente di mostrare dettagliatamente il comportamento dei sistemi in termini di sequenziamento temporale. Ad esempio i sistemi in tempo reale devono completare determinati processi entro un certo tempo. Per poter meglio rappresentare il livello temporale, UML 2.0 modella il diagramma temporale (inglese: timing diagram) come un diagramma bidimensionale con asse x e asse y. In questa sottospecie del diagramma di sequenza, gli stati degli oggetti si trovano sull’asse y, mentre le sequenze temporali a loro attribuite giacciono sull’asse x.
- Diagramma panoramico delle interazioni: il diagramma di interazione appena aggiunto in UML 2.0 aiuta a presentare un sistema molto complesso in uno schema approssimativo, poiché un normale diagramma di interazione diventerebbe troppo complicato e confuso. Per una rappresentazione dettagliata è ad esempio più adatto un diagramma di sequenza. Il diagramma UML viene rappresentato, similmente al diagramma delle attività, con dei nodi e rappresenta i flussi di controllo tra le interazioni. La differenza con il diagramma delle attività consiste nel fatto che all’interno dei nodi che rappresentano le attività si può annidare un intero diagramma. Questi annidamenti possono essere mostrati direttamente nel diagramma (inline) o rimandati al modello (parola chiave: ref, dall’inglese reference), che viene mostrato in dettaglio altrove.
Diagrammi UML: una panoramica
Nella tabella seguente potete vedere le categorie e gli usi possibili dei singoli tipi di diagramma in breve. Se volete rappresentare visivamente un sistema software orientato al modello o un caso di applicazione nell’economia, è necessario innanzitutto selezionare uno dei tipi di diagramma UML, come raccomandato dalla stessa task force UML. Soltanto allora vale la pena scegliere uno dei tanti tool UML, poiché questi ultimi a volte richiedono un particolare metodo. Successivamente potete creare il diagramma UML.
| Categoria | Tipo di diagramma | Applicazione |
| Struttura | Diagramma di classi | Visualizzare classi |
| Struttura | Diagramma degli oggetti | Visualizzare lo stato di un sistema in un determinato momento |
| Struttura | Diagramma dei componenti | Strutturare i componenti e mostrare le dipendenze |
| Struttura | Diagramma di struttura composta | Suddividere componenti o classi nelle loro parti costitutive ed esplicare le relazioni |
| Struttura | Diagramma del pacchetto | Riunisce le classi in pacchetti, raffigura una gerarchia e le strutture dei pacchetti |
| Struttura | Diagramma di distribuzione | Distribuzione dei componenti sui nodi del computer |
| Struttura | Diagramma del profilo | Illustra i contesti di utilizzo attraverso stereotipi, requisiti, ecc. |
| Comportamento | Diagramma dei casi d’uso | Rappresenta diversi casi di applicazione |
| Comportamento | Diagramma delle attività | Descrive il comportamento di processi diversi (paralleli) in un sistema |
| Comportamento | Diagramma di stato | Documenta come un oggetto passa da uno stato a un altro a causa di un evento |
| Comportamento: interazione | Diagramma di sequenza | Successione temporale delle interazioni tra oggetti |
| Comportamento: interazione | Diagramma di comunicazione | Distribuzione dei ruoli degli oggetti all’interno di un’interazione |
| Comportamento: interazione | Diagramma temporale | Limite temporale per eventi che portano a un cambio di stato |
| Comportamento: interazione | Diagramma panoramico delle interazioni | Interazioni tra sequenze e attività |
L’Object Modeling Group assegna certificati UML. Se volete approfondire il vostro know-how al riguardo, potete consultare i tutorial UML sul sito web della task force.