UML: un lin­guag­gio di mo­del­la­zio­ne grafico

L’Unified Modeling Language (UML), in italiano “lin­guag­gio di mo­del­la­zio­ne unificato”, è uno standard per la vi­sua­liz­za­zio­ne grafica di oggetti, stati e processi all’interno di un sistema. Il lin­guag­gio di mo­del­la­zio­ne può da un lato servire da cia­no­gra­fia per un progetto e garantire così un’ar­chi­tet­tu­ra strut­tu­ra­ta dell’in­for­ma­zio­ne; dall’altro aiuta gli svi­lup­pa­to­ri a rap­pre­sen­ta­re in modo com­pren­si­bi­le il sistema ai non spe­cia­li­sti. L’UML è prin­ci­pal­men­te uti­liz­za­to nello sviluppo di software orientati agli oggetti. In seguito ad am­plia­men­ti dello standard nella versione 2.0 si adatta anche per la rap­pre­sen­ta­zio­ne dei processi aziendali.

Prima che l’UML venisse in­tro­dot­to nello sviluppo software, il campo della pro­gram­ma­zio­ne orientata agli oggetti (OOP) era già in forte crescita. Questo stile di pro­gram­ma­zio­ne si basa sul concetto che tutto è un oggetto: i com­po­nen­ti di un programma sono oggetti che in­te­ra­gi­sco­no tra di loro. Anche i messaggi che vengono inviati tra i com­po­nen­ti sono co­sti­tui­ti da oggetti. Ogni singolo oggetto è un esemplare della sua classe superiore. La classe stessa funge anche da oggetto e determina il com­por­ta­men­to delle istanze dell’oggetto che contiene. Gli oggetti sono composti da dati e codice: i dati or­ga­niz­za­no 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 mol­tis­si­mi metodi e linguaggi per la rap­pre­sen­ta­zio­ne basata su modelli di pro­gram­ma­zio­ne orientata agli oggetti. Come con­se­guen­za ci si è ritrovati con una quantità in­ge­sti­bi­le di metodi difficili da con­fron­ta­re tra loro. Al fine perciò di riu­ni­fi­car­li, tre svi­lup­pa­to­ri, 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 in­ge­gne­ria del software orientato agli oggetti (OOSE)

Come lin­guag­gio di mo­del­la­zio­ne, l’UML dovrebbe stabilire la semantica nel rap­pre­sen­ta­re questi metodi. A partire dal 1996, gli svi­lup­pa­to­ri hanno lavorato con un team al com­ple­ta­men­to dell’UML con il nome di “UML Partners”. Lo hanno poi con­se­gna­to all’Object Ma­na­ge­ment Group (OMG), che a propria volta nel 1997 ha adottato la versione 1.1 dell’Unified Modeling Language come standard.

Non ancora sod­di­sfat­ti, gli svi­lup­pa­to­ri hanno creato una task force con l’obiettivo di mi­glio­ra­re il lin­guag­gio su due diverse versioni. Le critiche esistenti con­te­sta­va­no una semantica imprecisa e inu­til­men­te complessa, la poca adat­ta­bi­li­tà e un’in­suf­fi­cien­te stan­dar­diz­za­zio­ne. 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 co­sti­tui­sce la base per la stan­dar­diz­za­zio­ne ISO 19505-1 (struttura) e quella 19505-2 (so­vra­strut­tu­ra) del 2012. La versione 2.5.1 di UML è stata ri­la­scia­ta nel dicembre del 2017.

L’Unified Modeling Language è con­si­de­ra­ta una lingua franca dei linguaggi di mo­del­la­zio­ne. Come accennato in pre­ce­den­za, l’UML dà una rap­pre­sen­ta­zio­ne visuale degli stati e delle in­te­ra­zio­ni tra oggetti all’interno di un sistema. Per questa dif­fu­sio­ne deve pro­ba­bil­men­te rin­gra­zia­re anche i membri dell’OMG (inclusi IBM, Microsoft e HP). La semantica strut­tu­ra­ta con­tri­bui­sce al resto. Con i diagrammi UML si possono rap­pre­sen­ta­re i seguenti com­po­nen­ti di sistema:

• singoli oggetti (com­po­nen­ti di base);
• classi (riunisce gli elementi con le stesse proprietà);
• relazioni tra oggetti (gerarchia e com­por­ta­men­to/co­mu­ni­ca­zio­ne tra oggetti);
• attività (com­bi­na­zio­ne complessa di azioni/blocchi di com­por­ta­men­to);
• in­te­ra­zio­ni tra oggetti e in­ter­fac­ce.

L’immagine sopra mostra la me­ta­mo­del­la­zio­ne di UML 2.0. Il livello M0 è quello di base e rap­pre­sen­ta oggetti reali e concreti nonché set di dati singoli (ad esempio un oggetto o un com­po­nen­te). Il livello M1 include tutti i modelli che de­scri­vo­no e strut­tu­ra­no 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 me­ta­mo­del­li del livello M2 sta­bi­li­sco­no le spe­ci­fi­che e la semantica degli elementi del modello.

Se volete creare un diagramma UML com­pren­si­bi­le dovete conoscere il me­ta­mo­del­lo UML e le sue regole. Il livello più alto, ovvero il livello M3, è un me­ta­mo­del­lo del me­ta­mo­del­lo. La men­zio­na­ta Meta Object Facility lavora su un livello astratto che definisce i me­ta­mo­del­li. Questo livello si au­to­de­fi­ni­sce, al­tri­men­ti do­vreb­be­ro esistere ulteriori me­ta­li­vel­li so­vraor­di­na­ti.

UML (livello M2) sta­bi­li­sce le regole per la propria semantica. Le unità lin­gui­sti­che sono concetti che vengono definiti nella so­vra­strut­tu­ra UML 2.0. Ciò consente una rap­pre­sen­ta­zio­ne formale che tutti gli in­te­res­sa­ti possono capire. Le unità di lin­guag­gio, in inglese language units, astrag­go­no in modo simile oggetti e processi costruiti e fun­zio­nan­ti, dando loro una forma vi­si­va­men­te rap­pre­sen­ta­bi­le. A seconda del livello ge­rar­chi­co all’interno del modello gli elementi assumono ulteriori compiti spe­cia­liz­za­ti o de­fi­ni­sco­no altri elementi vicini.

Classe: come unità lin­gui­sti­ca le classi sono un aspetto fon­da­men­ta­le dell’UML. Esse de­fi­ni­sco­no che cosa rende tale una classe e come in­te­ra­gi­sco­no 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’in­fra­strut­tu­ra UML 2.0 come pacchetto, nome, attributo, ecc.;
• As­so­cia­tion­Clas­ses de­fi­ni­sco­no le classi di as­so­cia­zio­ne;
• In­ter­fa­ces definisce le in­ter­fac­ce;
• Powertype è una classe le cui istanze sono sot­to­clas­si all’interno di questa classe.

Com­po­nen­te: i com­po­nen­ti sono parti co­sti­tu­ti­ve che limitano il proprio contenuto dal sistema esterno. Solo at­tra­ver­so in­ter­fac­ce o porte c’è un col­le­ga­men­to verso l’esterno. Un con­net­to­re di com­po­si­zio­ne si connette a un altro com­po­nen­te at­tra­ver­so l’in­ter­fac­cia. Il con­net­to­re di delega collega gli elementi interni con un’in­ter­fac­cia sul confine esterno. I com­po­nen­ti sono modulari e in­ter­cam­bia­bi­li.

Struttura di com­po­si­zio­ne: la struttura di com­po­si­zio­ne dell’unità lin­gui­sti­ca descrive elementi che sono schermati come com­po­nen­ti all’interno e all’esterno. Solo le porte collegano il contenuto al sistema esterno. I co­sid­det­ti clas­si­fi­ca­to­ri in­cap­su­la­ti sono composti da elementi, le parti, che co­mu­ni­ca­no tramite con­net­to­ri.

Profilo: un profilo configura UML 2.0 per esigenze spe­ci­fi­che. Termini astratti come attività o oggetto devono essere spe­ci­fi­ca­ti per alcuni progetti per aumentare la com­pren­sio­ne. In alcuni casi è possibile per­so­na­liz­za­re la semantica e le an­no­ta­zio­ni su un profilo.

Modello: il modello comprende tutti gli elementi necessari a rap­pre­sen­ta­re una specifica visuale della struttura o del com­por­ta­men­to di un sistema. Vi ap­par­ten­go­no anche influssi esterni come attori.

Azione: quando si tratta di rap­pre­sen­ta­re com­por­ta­men­ti, le azioni sono di vitale im­por­tan­za, poiché re­gi­stra­no 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:

• Ma­ni­po­la­zio­ne degli oggetti
• Ma­ni­po­la­zio­ne delle relazioni og­get­tua­li
• Ma­ni­po­la­zio­ne delle ca­rat­te­ri­sti­che strut­tu­ra­li
• Azioni di vi­sua­liz­za­zio­ne
• Creazione di valori
• Azioni sugli oggetti
• Ricezione di eventi

Com­por­ta­men­ti: il com­por­ta­men­to dell’unità lin­gui­sti­ca o la de­scri­zio­ne com­por­ta­men­ta­le suppone la mo­del­la­zio­ne di aspetti dinamici all’interno di un sistema. Comprende tre spe­ci­fi­che:

• Attività: le azioni in­te­ra­gi­sco­no at­tra­ver­so flussi di dati e di controllo. Ciò si traduce in un complesso sistema di com­por­ta­men­ti, le attività.
• In­te­ra­zio­ne: questo me­ta­mo­del­lo descrive come avvengano gli scambi di messaggi tra oggetti, quando un messaggio viene mandato a un de­ter­mi­na­to oggetto e quali altri elementi ne sono in­fluen­za­ti.
• Diagramma di stato: in un diagramma di stato, questo me­ta­mo­del­lo modella stati (si­tua­zio­ni con proprietà im­mo­di­fi­ca­bi­li) e pseudo-stati (stati senza as­se­gna­zio­ne di valore), nonché le loro tran­si­zio­ni. Gli oggetti in uno stato possono essere assegnati ad azioni o attività.

Di­stri­bu­zio­ne: una rete è composta da oggetti collegati tra loro in un mesh. Un caso speciale di ap­pli­ca­zio­ne è quando questi elementi rap­pre­sen­ta­no software ese­gui­bi­li o artefatti. Queste risorse vengono eseguite su ambienti di ese­cu­zio­ne o di­spo­si­ti­vi che ca­te­go­riz­za­no UML 2.0 come nodo. L’artefatto è perciò di­pen­den­te dai nodi. La di­stri­bu­zio­ne rap­pre­sen­ta questo rapporto di di­pen­den­za che si verifica durante l’in­stal­la­zio­ne.

Casi di ap­pli­ca­zio­ne (o d’uso): il caso di ap­pli­ca­zio­ne o d’uso (come unità lin­gui­sti­ca) rap­pre­sen­ta i requisiti di sistema. L’attore (una persona o un sistema) è un elemento che descrive chi o cosa dovrebbe svolgere una de­ter­mi­na­ta attività uti­liz­zan­do il sistema. Il sistema può anche con­si­ste­re in una classe o in un com­po­nen­te ed è descritto come soggetto. Il caso di ap­pli­ca­zio­ne (come elemento del modello) afferma solamente che è previsto un com­por­ta­men­to de­no­mi­na­to che è visibile agli attori dall’esterno. So­li­ta­men­te non rap­pre­sen­ta le azioni esatte: all’interno di una de­scri­zio­ne com­por­ta­men­ta­le, la mo­del­la­zio­ne associa i requisiti det­ta­glia­ti al caso di ap­pli­ca­zio­ne.

Flussi di in­for­ma­zio­ne: questa unità di lin­guag­gio UML descrive l’unità di in­for­ma­zio­ni sugli elementi e il flusso di in­for­ma­zio­ni. Questi elementi del modello de­scri­vo­no tecniche di de­scri­zio­ne com­por­ta­men­ta­le che possono essere par­ti­co­lar­men­te orientate ai dettagli, come attività o in­te­ra­zio­ni. Questa rap­pre­sen­ta­zio­ne sem­pli­fi­ca­ta consente l’utilizzo uni­ver­sa­le di questi elementi di mo­del­la­zio­ne di tutti i tipi di diagrammi UML. L’unità di in­for­ma­zio­ne non è perciò mai descritta in dettaglio at­tra­ver­so attributi o in­cor­po­ra­ta in metodi, a dif­fe­ren­za della classe. Il flusso di in­for­ma­zio­ni quindi collega anche tutti gli elementi possibili che scambiano qualsiasi tipo di in­for­ma­zio­ne.

Il lin­guag­gio di mo­del­la­zio­ne sta­bi­li­sce 14 tipi di diagrammi divisi in due categorie. La struttura e il com­por­ta­men­to delle categorie prin­ci­pa­li sono i concetti di base che rap­pre­sen­ta­no i diagrammi UML. All’interno del gruppo di diagrammi com­por­ta­men­ta­li, l’UML specifica la sot­to­ca­te­go­ria dei diagrammi di in­te­ra­zio­ne. Esiste una quarta sotto-specifica a partire dall’UML 2.0, che determina la con­fi­gu­ra­zio­ne degli schemi del modello.

• Diagramma di di­stri­bu­zio­ne: il diagramma di di­stri­bu­zio­ne modella la di­stri­bu­zio­ne fisica degli artefatti sui nodi. I nodi (nodes) sono hardware (device nodes), che possono fornire uno spazio di ar­chi­via­zio­ne o software (execution en­vi­ron­ment nodes), che for­ni­sco­no un ambiente per i processi in ese­cu­zio­ne. Sono raf­fi­gu­ra­ti come un pa­ral­le­le­pi­do ret­tan­go­la­re. Gli artefatti sono disegnati come ret­tan­go­li. All’interno è scritto il nome del file. Per di­stin­guer­lo da una classe, ag­giun­ge­te lo ste­reo­ti­po <<artefatto>>. Il diagramma è utile per rap­pre­sen­ta­re le di­pen­den­ze tra nodi e artefatti, le co­sid­det­te relazioni di di­stri­bu­zio­ne.
• Diagramma di profilo: i diagrammi di profilo si uti­liz­za­no al livello del me­ta­mo­del­lo. Servono ad assegnare uno ste­reo­ti­po a una classe o un profilo a un pacchetto. Su un me­ta­li­vel­lo avete così la pos­si­bi­li­tà di per­so­na­liz­za­re il modello per una piat­ta­for­ma o un dominio diversi. Ad esempio, se si limita la semantica UML all’interno di un profilo, questa eredita le spe­ci­fi­che alle classi su­bor­di­na­te.

• Diagramma delle attività: le attività con­si­sto­no in una rete di azioni correlate ai flussi di dati e di controllo. Mentre il diagramma dei casi d’uso rap­pre­sen­ta i requisiti di sistema, il diagramma delle attività mostra come procedono questi casi di ap­pli­ca­zio­ne. In questo tipo di diagramma è im­por­tan­te 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 rap­pre­sen­ta un insieme finito di stati in un sistema. Se una con­di­zio­ne spe­ci­fi­ca­ta è sod­di­sfat­ta nel sistema (cioè viene attivato un trigger), si verifica una si­tua­zio­ne cor­ri­spon­den­te, che può includere attività o in­te­ra­zio­ni. Su UML 2.0 uno stato rap­pre­sen­ta questa si­tua­zio­ne. Gli stati sono con­si­de­ra­ti vertici (inglese: vertices) e sono rap­pre­sen­ta­ti come ret­tan­go­li con angoli ar­ro­ton­da­ti. Inoltre il diagramma di stato modella le tran­si­zio­ni (inglese: tran­si­tions) da uno stato (vertice di partenza) all’altro (vertice di de­sti­na­zio­ne). UML modella le tran­si­zio­ni di stato come spigoli. Le azioni sono l’ultimo pilastro e assegnano le spe­ci­fi­che del com­por­ta­men­to allo stato.

Il com­por­ta­men­to è collegato a si­tua­zio­ni o a eventi specifici. Il diagramma di stato UML conosce quattro spe­ci­fi­che:

• Com­por­ta­men­to di entrata (entry behavior)
• Com­por­ta­men­to di stato (doAc­ti­vi­ty)
• Com­por­ta­men­to in caso di un evento (event behavior)
• Com­por­ta­men­to di uscita (exit behavior)

Inoltre uno stato può essere in­ter­rot­to e fatto ri­pren­de­re dallo stesso punto. Questa proprietà si chiama stato della cro­no­lo­gia.

• Diagramma pa­no­ra­mi­co delle in­te­ra­zio­ni: il diagramma di in­te­ra­zio­ne appena aggiunto in UML 2.0 aiuta a pre­sen­ta­re un sistema molto complesso in uno schema ap­pros­si­ma­ti­vo, poiché un normale diagramma di in­te­ra­zio­ne di­ven­te­reb­be troppo com­pli­ca­to e confuso. Per una rap­pre­sen­ta­zio­ne det­ta­glia­ta è ad esempio più adatto un diagramma di sequenza. Il diagramma UML viene rap­pre­sen­ta­to, si­mil­men­te al diagramma delle attività, con dei nodi e rap­pre­sen­ta i flussi di controllo tra le in­te­ra­zio­ni. La dif­fe­ren­za con il diagramma delle attività consiste nel fatto che all’interno dei nodi che rap­pre­sen­ta­no le attività si può annidare un intero diagramma. Questi an­ni­da­men­ti possono essere mostrati di­ret­ta­men­te 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 rap­pre­sen­ta­re vi­si­va­men­te un sistema software orientato al modello o un caso di ap­pli­ca­zio­ne nell’economia, è ne­ces­sa­rio in­nan­zi­tut­to se­le­zio­na­re uno dei tipi di diagramma UML, come rac­co­man­da­to dalla stessa task force UML. Soltanto allora vale la pena scegliere uno dei tanti tool UML, poiché questi ultimi a volte ri­chie­do­no un par­ti­co­la­re metodo. Suc­ces­si­va­men­te potete creare il diagramma UML.