Diagramma UML: definizioni, tipi e impieghi principali

 [nascondi] 

• 1 Storia
• 1.1 Prima di UML 1.x
• 1.2 UML 1.x
• 1.3 UML 2.x
• 2 Design
• 2.1 Metodi di sviluppo del software
• 2.2 Modellazione
• 3 Diagrammi
• 3.1 Diagrammi di struttura
• 3.2 Diagrammi di comportamento
• 3.2.1 Diagrammi di interazione
• 4 Metamodellazione
• 5 Adozione
• 6 Critiche
• 6.1 Critica di UML 1.x

Storia dei metodi e della notazione orientati agli oggetti

UML si è evoluto dalla seconda metà degli anni '90 e ha le sue radici nei metodi orientati agli oggetti sviluppati alla fine degli anni '80 e nei primi anni '90. La timeline (vedi immagine) mostra i punti salienti della storia dei metodi di modellazione orientata agli oggetti e della notazione.

È originariamente basato sulle notazioni del metodo Booch, la tecnica Object-modeling (OMT) e l'ingegneria del software orientata agli oggetti (OOSE), che ha integrato in un unico linguaggio. ^[5]

Prima di UML 1.x[modifica fonte | modifica]

La Rational Software Corporation assunse James Rumbaugh dalla General Electric nel 1994 e da allora l'azienda divenne la fonte di due dei più popolari approcci di modellazione orientata agli oggetti dell'epoca:^{[6] la} tecnica Object-modeling di Rumbaugh (OMT) e il metodo di Grady Booch. Furono presto assistiti nei loro sforzi da Ivar Jacobson, il creatore del metodo di ingegneria del software orientato agli oggetti (OOSE), che si unì a loro alla Rational nel 1995.^[1]

Sotto la guida tecnica di questi tre (Rumbaugh, Jacobson e Booch), un consorzio chiamato UML Partnerswas organizzato nel 1996 per completare la specifica Unified Modeling Language (UML), e proporla all'Object Management Group (OMG) per la standardizzazione. La partnership conteneva anche altre parti interessate (per esempio HP, DEC, IBM e Microsoft). La bozza UML 1.0 degli UML Partners fu proposta all'OMG nel gennaio 1997 dal consorzio. Durante lo stesso mese gli UML Partners formarono un gruppo, progettato per definire l'esatto significato dei costrutti del linguaggio, presieduto da Cris Kobryn e amministrato da Ed Eykholt, per finalizzare la specifica e integrarla con altri sforzi di standardizzazione. Il risultato di questo lavoro, UML 1.1, fu presentato all'OMG nell'agosto 1997 e adottato dall'OMG nel novembre 1997.^[1][7]

UML 1.x[modifica fonte | modifica]

Dopo il primo rilascio fu formata una task force^[1] per migliorare il linguaggio, che rilasciò diverse revisioni minori, 1.3, 1.4, e 1.5.^[8]

Gli standard che ha prodotto (così come lo standard originale) sono stati notati come ambigui e incoerenti. ^[9][10]

UML 2.x[modifica fonte | modifica]

La revisione principale UML 2.0 ha sostituito la versione 1.5 nel 2005, che è stata sviluppata con un consorzio allargato per migliorare ulteriormente il linguaggio e riflettere le nuove esperienze sull'uso delle sue caratteristiche. ^[11]

Anche se UML 2.1 non fu mai rilasciato come specifica formale, le versioni 2.1.1 e 2.1.2 apparvero nel 2007, seguite da UML 2.2 nel febbraio 2009. UML 2.3 fu formalmente rilasciato nel maggio 2010.^[12] UML 2.4.1 fu formalmente rilasciato nell'agosto 2011.^[12] UML 2.5 fu rilasciato nell'ottobre 2012 come versione "In process" e fu ufficialmente rilasciato nel giugno 2015.^[12]

Ci sono quattro parti nella specifica UML 2.x:

1. La sovrastruttura che definisce la notazione e la semantica per i diagrammi e i loro elementi del modello
2. L'infrastruttura che definisce il metamodello di base su cui si basa la sovrastruttura
3. Il linguaggio OCL (Object Constraint Language) per definire regole per gli elementi del modello
4. L'UML Diagram Interchange che definisce come vengono scambiati i layout dei diagrammi UML 2

Le versioni attuali di questi standard seguono: UML Superstructure versione 2.4.1, UML Infrastructure versione 2.4.1, OCL versione 2.3.1, e UML Diagram Interchange versione 1.0.^[13] Continua ad essere aggiornato e migliorato dalla task force di revisione, che risolve qualsiasi problema del linguaggio. ^[14]

L'Unified Modeling Language (UML) offre un modo per visualizzare i progetti architettonici di un sistema in un diagramma (vedi immagine), includendo elementi come:^[5]

• Qualsiasi attività (lavori)
• Componenti individuali del sistema
• E come possono interagire con altri componenti software.
• Come funzionerà il sistema
• Come le entità interagiscono con altre (componenti e interfacce)
• Interfaccia utente esterna

Sebbene originariamente inteso solo per la documentazione di progettazione orientata agli oggetti, il linguaggio di modellazione unificato (UML) è stato esteso per coprire un insieme più ampio di documentazione di progettazione (come elencato sopra),^[15] ed è stato trovato utile in molti contesti. ^[16]

Metodi di sviluppo del software[modifica fonte | modifica]

UML non è un metodo di sviluppo di per sé; ^[17] tuttavia, è stato progettato per essere compatibile con i principali metodi di sviluppo del software orientato agli oggetti del suo tempo (per esempioOMT, metodo Booch, Objectory) e specialmente con RUP che era originariamente destinato ad essere usato quando il lavoro è iniziato alla Rational Software Inc.

Modellazione[modifica fonte | modifica]

È importante distinguere tra il modello UML e l'insieme dei diagrammi di un sistema. Un diagramma è una rappresentazione grafica parziale del modello di un sistema. L'insieme dei diagrammi non deve necessariamente coprire completamente il modello e cancellare un diagramma non cambia il modello. Il modello può anche contenere documentazione che guida gli elementi del modello e i diagrammi (come i casi d'uso scritti).

I diagrammi UML rappresentano due diverse viste di un modello di sistema:^[18]

• Vista statica (o strutturale): enfatizza la struttura statica del sistema usando oggetti, attributi, operazioni e relazioni. La vista strutturale include diagrammi di classe e diagrammi di struttura composita.
• Vista dinamica (o comportamentale): enfatizza il comportamento dinamico del sistema mostrando le collaborazioni tra gli oggetti e i cambiamenti agli stati interni degli oggetti. Questa vista include diagrammi di sequenza, diagrammi di attività e diagrammi di macchine a stati.

I modelli UML possono essere scambiati tra strumenti UML usando il formato di interscambio XML Metadata Interchange (XMI).

UML 2 ha molti tipi di diagrammi che sono divisi in due categorie. ^[5] Alcuni tipi rappresentano informazioni strutturali, e il resto rappresenta tipi generali di comportamento, compresi alcuni che rappresentano diversi aspetti delle interazioni. Questi diagrammi possono essere classificati gerarchicamente come mostrato nel seguente diagramma di classe:^[5]

Questi diagrammi possono tutti contenere commenti o note che spiegano l'uso, il vincolo o l'intento.

Diagrammi di struttura[modifica fonte | modifica]

I diagrammi di struttura enfatizzano le cose che devono essere presenti nel sistema che viene modellato. Poiché i diagrammi di struttura rappresentano la struttura, sono usati ampiamente nella documentazione dell'architettura dei sistemi software. Per esempio, il diagramma dei componenti che descrive come un sistema software è diviso in componenti e mostra le dipendenze tra questi componenti.

• Diagramma dei componenti
• Diagramma di classe

Diagrammi di comportamento[modifica fonte | modifica]

I diagrammi di comportamento enfatizzano ciò che deve accadere nel sistema che viene modellato. Poiché i diagrammi di comportamento illustrano il comportamento di un sistema, sono usati ampiamente per descrivere la funzionalità dei sistemi software. Come esempio, il diagramma di attività descrive il business e le attività operative passo dopo passo dei componenti di un sistema.

• Diagramma di attività
• Diagramma dei casi d'uso

Diagrammi di interazione[modifica fonte | modifica]

I diagrammi di interazione, un sottoinsieme dei diagrammi di comportamento, enfatizzano il flusso di controllo e di dati tra le cose nel sistema modellato. Per esempio, il diagramma di sequenza mostra come gli oggetti comunicano tra loro in termini di una sequenza di messaggi.

• Diagramma di sequenza
• Diagramma di comunicazione

Articolo principale: Struttura Meta-Object

Illustrazione della struttura Meta-Object

L'Object Management Group (OMG) ha sviluppato un'architettura di metamodellazione per definire l'Unified Modeling Language (UML), chiamata Meta-Object Facility (MOF). ^[19] La Meta-Object Facility è progettata come un'architettura a quattro livelli, come mostrato nell'immagine a destra. Fornisce un modello meta-meta al livello superiore, chiamato livello M3. Questo modello M3 è il linguaggio usato da Meta-Object Facility per costruire metamodelli, chiamati modelli M2.

L'esempio più evidente di un modello Layer 2 Meta-Object Facility è il metamodello UML, il modello che descrive l'UML stesso. Questi modelli M2 descrivono elementi del livello M1, e quindi modelli M1. Questi sarebbero, per esempio, modelli scritti in UML. L'ultimo strato è lo strato M0 o strato dati. È usato per descrivere istanze runtime del sistema. ^[20]

Il meta-modello può essere esteso usando un meccanismo chiamato stereotipia. Questo è stato criticato come insufficiente/insostenibile da Brian Henderson-Sellers e Cesar Gonzalez-Perez in "Uses and Abuses of the Stereotype Mechanism in UML 1.x and 2.0". ^[21]

UML è stato trovato utile in molti contesti di progettazione,^{[16] tanto} che è diventato quasi onnipresente nella comunità IT. ^[22]

È stato trattato, a volte, come un proiettile d'argento per la progettazione, il che ha portato a problemi nel suo utilizzo. L'uso improprio include un uso eccessivo (progettare ogni piccola parte del codice del sistema con esso, che non è necessario) e supporre che chiunque possa progettare qualsiasi cosa con esso (anche coloro che non hanno programmato). ^[23]

È visto come un grande linguaggio, con molti costrutti al suo interno. Alcuni (tra cui Jacobson) ritengono che ce ne siano troppi e che questo ne ostacoli l'apprendimento (e quindi l'uso). ^[24]

Le critiche comuni all'UML da parte dell'industria includono:^[4]

• non è utile: "[non] offre loro vantaggi rispetto alle loro pratiche e rappresentazioni attuali ed evolute"
• troppo complesso, in particolare per la comunicazione con i clienti: "inutilmente complesso" e "La migliore ragione per non usare UML è che non è 'leggibile' per tutte le parti interessate. Quanto vale UML se un utente di business (il cliente) non può capire il risultato del tuo sforzo di modellazione?"
• necessità di mantenere UML e codice in sincronia, come per la documentazione in generale

Critica di UML 1.x[modifica fonte | modifica]

Notazione di cardinalità

Come per i database Chen, Bachman e i diagrammi ER ISO, i modelli di classe sono specificati per usare cardinalità "look-across", anche se diversi autori (Merise,^[25] Elmasri & Navathe[26] tra gli altri[27]⁾ preferiscono lo stesso lato o "look-here" per i ruoli e le cardinalità sia minime che massime. Ricercatori recenti (Feinerer,^[28] Dullea et. alia^[29]) hanno dimostrato che la tecnica del "look-across" usata da UML e dai diagrammi ER è meno efficace e meno coerente quando applicata a relazioni n-arie di ordine >2.

Feinerer dice "I problemi sorgono se operiamo sotto la semantica look-across come usata per le associazioni UML. Hartmann^[30] indaga questa situazione e mostra come e perché diverse trasformazioni falliscono." (Anche se la "riduzione" menzionata è spuria in quanto i due diagrammi 3.4 e 3.5 sono di fatto gli stessi) e anche "Come vedremo nelle prossime pagine, l'interpretazione look-across introduce diverse difficoltà che impediscono l'estensione di semplici meccanismi da associazioni binarie a n-arie."