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.

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.

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.

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.

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.

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.

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

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

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

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.