I. UML: Unified Modeling Language
1.1 Cenni storici
L’UML è stato sviluppato presso la Rational Software Corporation da Grady Booch, Jim Rumbaugh e Ivar Jacobson, tuttavia questi non hanno il copyright su UML e questo è sviluppato dal consorzio OMG (Object Management Group).
L’OMG (Object Management Group) è un consorzio no-profit che produce e mantiene specifiche per l’industria software che ha come mercato la produzione di applicazioni integrate per le imprese e le aziende. L’OMG è stato fondato nell’aprile del 1989 da undici compagnie tra cui 3Com, American Airlines, Canon, Data General, Hewlett-Packard, Philips Telecommunications N.V., Sun Microsystems e Unisys. Oggi OMG ha centinaia di soci e quindi si avvale del contributo di molti metodologi e delle più importanti società di software mondiali. E’ proprio questo consorzio che ha fatto dell’UML uno standard e la sua evoluzione è a carico dell’OMG stesso ed è soggetta a procedure ben definite per ogni cambiamento. Allo stato attuale lo sviluppo dell’UML è affidato alle varie “task force” appartenenti all’OMG, le RTF (Revision Task Force). Obiettivo di tale gruppo è accogliere ed analizzare suggerimenti provenienti dalle industrie, correggere inevitabili imperfezioni, colmare eventuali lacune, e così via. Di seguito possiamo schematizzare la preistoria di UML con la figura 1.1 tratta da [Com].
Figura 1.1 - Preistoria di UML.
Successivamente, nel dicembre 1998, uscì la versione 1.2, nel giugno 1999 quella 1.3, mentre la versione attuale di UML è la 1.4 (settembre 2001), ma è di prossima uscita la versione 2.0.
1.2 UML: metamodello
Lo UML è un linguaggio che permette di costruire un modello di un sistema da analizzare o da progettare, ovvero permette di realizzare una rappresentazione astratta di un sistema basata su alcuni concetti fondamentali, come classi, associazioni, ecc.. Ad esempio, se si dovesse analizzare un sistema del mondo reale come una biblioteca, si dovrebbero evidenziare le caratteristiche più rilevanti
che distinguono i libri in essa contenuti, se tali libri sono presenti o prestati e se prestati a chi. Ne vengono fuori tre concetti da analizzare: libro, utente libreria, prestito. Se poi si analizzano le qualità che caratterizzano un libro si delineano delle nuove entità, come quella dell’autore e dell’editore. Questa analisi può andare avanti fino al livello di dettaglio che si ritiene necessario per estrapolare uno schema logico che descriva in modo soddisfacente il sistema “biblioteca”. Ma finora non sono state fatte che descrizioni in linguaggio naturale di questo sistema, quindi si è espresso un sistema in un modo che può essere ambiguo, non rigoroso, non seguendo uno standard. Invece lo UML definisce un linguaggio che permette di costruire un modello standard e rigoroso di qualsiasi sistema che si voglia descrivere o progettare. Per il sistema “biblioteca” si possono quindi costruire i due diagrammi in figura 1.7 e 1.8 che esprimono tale modello attraverso le classi e le associazioni fra di esse (questi elementi sono fondamentali nello UML).
I concetti base dello UML vengono usati anche per descrivere la semantica del linguaggio stesso. Si ha quindi un modello per un linguaggio di modellazione, cioè un metamodello. Ad esempio si possono consultare i diagrammi delle figure 1.22 – 1.26 che descrivono la struttura principale del linguaggio UML, cioè la parte principale del suo metamodello.
Quindi nasce il problema di rendere standard la definizione di altri linguaggi di modellazione, ognuno dei quali avrà il suo metamodello. Tra i metodologi si è ritenuto opportuno definire un linguaggio comune denominato MOF (Meta Object
Facility) [MOFS] per descrivere diversi metamodelli attraverso dei meta-metamodelli (ad esempio XMI, che è il formato standard di scambio di modelli tra applicazioni di diverse piattaforme, è definito attraverso MOF).
Lo UML possiede una definizione rigorosa di metamodello, istanza del meta-metamodello definito anch’esso attraverso il MOF. Si tratta di concetti molto eleganti e affascinanti, ad elevato livello di astrazione. Il metamodello dello3 UML è descritto per mezzo dello UML stesso. Si tratta indubbiamente di una scelta molto elegante, ma ha per inconveniente che ad una prima lettura della specifica si può avere una certa confusione.
Un metamodello è un modello a sua volta istanza di un meta-metamodello, fruibile per esprimere una istanza di modello: l’UML (metamodello) permette di realizzare diversi modelli Object-Oriented (modelli definiti dall’utente). Il metamodello dello UML definisce la struttura dei modelli UML. Un metamodello non fornisce alcuna regola su come esprimere concetti del mondo Object-Oriented, quali ad esempio classi, interfacce, relazioni e così via, ma esso rende possibile avere diverse notazioni che si conformano al metamodello stesso.
Così come avviene nella relazione che lega le classi agli oggetti, una volta definita una classe si possono avere svariate istanze della stessa (oggetti), analogamente è possibile progettare un numero infinito di varianti dello “UML” (istanze del metamodello).
3
La restante trattazione sul metamodello fino alla fine del paragrafo e le figure 1.2 e 1.3 sono tratte da [Vet01] e da [Vet03].
Nelle sue prime apparizioni ufficiali lo UML era composto “semplicemente” da una notazione grafica, fruibile per rappresentare modelli di sistemi Object-Oriented. Quando poi è giunto il momento della presentazione allo OMG, per il conferimento del riconoscimento ufficiale di standard (Gennaio 1997), si è reso necessario conferirgli una veste più formale. Così , a partire dalla versione 1.1, lo UML definisce rigorosamente un metamodello e la notazione atta alla formulazione di modelli Object-Oriented conformi ad esso.
Riassumendo, un meta-metamodello è un modello che definisce un linguaggio per esprimere un metamodello. La relazione tra il meta-metamodello ed il metamodello è paragonabile a quella esistente tra il metamodello ed un modello.
Lo UML è definito in termini del meta-metamodello denominato MOF: Meta Object Facility [MOFS]. Nella figura 1.2 viene illustrato graficamente quanto emerso fino a questo punto: relazioni esistenti tra il meta-metamodello, il metamodello ed il modello dell’utente.
Figura 1.2 - Meta-metamodello, metamodello e modello UML.
Scorrendo il diagramma dall’alto verso il basso si assiste ad una graduale diminuzione del livello di astrazione; se si fosse deciso di visualizzare un ulteriore livello si sarebbero trovate entità, istanze delle classi del modello dell’utente, cioè oggetti.
Se, per esempio, si realizzasse un prototipo di un sistema di commercio elettronico, a livello del modello realizzato dall’architetto, si troverebbero classi (opportunamente relazionate tra loro) del tipo: Categoria, SottoCategoria, Prodotto, Utente, Profilo, e così via. Se poi si volesse visualizzare il livello inferiore, l’istanza dello user model, bisognerebbe inserire oggetti, istanze di tali classi, come per esempio il prodotto di codice X, avente prezzo Y, della categoria
Z, e così via. Per avere un’idea più chiara si consulti il diagramma riportato nella figura 1.3.
Figura 1.3 - Esempio delle relazioni ai vari gradi di astrazione tra i modelli UML.
Come si può notare, nel modello di analisi compare una classe denominata “Ordine” appartenente al dominio del problema. La classe è un’istanza della metaclasse Class, presente nel package UML metamodello, e contiene attributi ed operazioni che, a loro volta, sono istanze rispettivamente delle metaclassi
Attribute ed Operation. Se anche in questo caso si fosse deciso di visualizzare un ulteriore livello si sarebbero trovate le istanze delle classe Ordine, ossia oggetti del tipo: 00000312 : Ordine.
Appare che il livello di meta-metamodello ha la stessa struttura del livello di metamodello: questo fatto è causato dalla stretta relazione che c’è fra MOF e UML. Infatti, a quanto si legge nella specifica ufficiale di OMG (“Meta Object Facility (MOF) Specification” [MOFS]), si potrebbe avere in futuro una fusione tra i meta-metamodelli di MOF e il metamodello di UML: nel frattempo rimangono due entità distinte.
In sintesi, lo UML è basato su un metamodello integrato, composto da numerosi elementi collegati fra loro secondo regole precise. Utilizzando gli elementi del metamodello è possibile creare i modelli per i sistemi da rappresentare e la maggior parte degli elementi stessi hanno un’icona definita dalla notazione dello UML che li rappresenta graficamente. Gli elementi del metamodello possono comparire in diagrammi di diverso tipo e le regole sintattiche permettono di verificare la correttezza.
1.3 UML: diagrammi
In questo paragrafo si vogliono introdurre i principali diagrammi e la loro notazione. Per una conoscenza più dettagliata si rimanda alla specifica ufficiale di UML ver. 1.4. La notazione UML include dieci tipi di diagrammi, divisi in cinque categorie. La tabella 1.1 mostra le categorie e i diagrammi corrispondenti.
Categoria Diagrammi (Diagram)
Diagrammi per analisi dei requisiti Diagrammi dei casi d'uso (use case) Diagrammi dei package
Diagrammi delle classi (class) Diagrammi di struttura statica
Diagrammi degli oggetti (object) Diagrammi di sequenza (sequence) Diagrammi d'interazione
Diagrammi di collaborazione (collaboration) Diagrammi di stato (statechart)
Diagrammi di stato
Diagrammi di attività (activity)
Diagrammi dei componenti (component) Diagrammi di implementazione
Diagrammi di dislocamento (deployment)
Tabella 1.1: Classificazione dei diagrammi UML.
1.3.1 Diagrammi dei casi d'uso
Un diagramma dei casi d'uso è un grafo che mostra le interazioni tra un utente e un caso d'uso di un sistema. Risulta particolarmente utile durante la fase di specifica dei requisiti.
Figura 1.4 - Struttura tipica di un diagramma dei casi d'uso.
Gli elementi che compongono un diagramma dei casi d'uso sono due:
• attori: un attore è un ruolo che un utente di un caso d'uso può impersonare
interagendo con esso. Gli attori non sono necessariamente delle persone: possono essere, ad esempio, un sistema esterno che richiede delle informazioni al sistema che si sta progettando;
• casi d'uso: un caso d'uso è una classe che definisce una funzionalità o un
servizio offerto dal sistema. La figura 1.4 mostra la struttura tipica di un diagramma dei casi d'uso. La freccia <<extends>> rappresenta una relazione tra use case che lega 3 a 1 ed indica che un’istanza di 1 (soggetta a condizioni specificate nella estensione 3) può essere modificata dal comportamento specificato nel 3. Tale comportamento è inserito nel contesto definito dal punto di estensione di 1, che è riferito dalla relazione <<extends>>. Invece la freccia <<uses>> indica che 1 richiede la presenza di 2 per il proprio funzionamento o per la propria implementazione.
Figura 1.5 - Un diagramma dei casi d'uso4.
Quindi un caso d’uso (use case) rappresenta la modalità di utilizzo del sistema da parte di uno o più utilizzatori (attori) e descrive la loro interazione senza rivelare l’organizzazione interna del sistema stesso. Il comportamento richiesto al sistema per ciascun caso d’uso viene espresso in forma testuale ed è quindi comprensibile anche per i non “addetti ai lavori”. I casi d’uso possono essere definiti a livelli diversi (sistema o parti del sistema) e ragionare sui casi d’uso aiuta a scoprire i requisiti.
1.3.2 Diagrammi di struttura statica
I diagrammi di struttura statica vengono utilizzati durante la fase di analisi e specifica di un sistema per descrivere la sua architettura e, se viene adottato un
4
livello di dettaglio più fine, possono essere usati anche in fase di progetto del sistema: per esempio, in tale fase si possono specificare precisamente il numero ed i tipi degli argomenti di operazioni di cui, in fase di specifica, si era dato solo il nome. Questa categoria include i diagrammi dei package, delle classi e degli oggetti.
Diagrammi dei package
Un diagramma dei package può mostrare l'organizzazione delle classi in determinati moduli e le dipendenze (dependencies) tra di essi. Una dipendenza tra due elementi è rappresentata come una freccia tratteggiata che parte dall’elemento denominato client e arriva sull’elemento denominato supplier. Una dipendenza tra due elementi indica che un cambiamento dell’elemento supplier richiede un cambiamento dell’elemento client della dipendenza.
Un sistema software complesso da un punto di vista architetturale consiste di un numero decisamente elevato di classi in relazione tra esse. I diagrammi dei package forniscono uno strumento per dominare questa complessità, poiché consentono di organizzare le classi in unità logiche differenti e permettono di ottenere viste differenti a diversi livelli di astrazione.
Un package quindi è un raggruppamento di elementi del modello. I package stessi possono essere annidati in altri package. Tutti gli elementi del modello UML possono essere organizzati in package. Da notare che i package possiedono gli elementi del modello e quindi sono la base per il controllo della configurazione del modello e per il controllo dell’accesso. Infatti ogni elemento può essere
posseduto direttamente da un solo package: in tal modo la gerarchia dei package è un albero. Tuttavia gli elementi dei package possono riferirsi ad elementi del modello posseduti da altri package attraverso l’uso di una dipendenza di “permesso” caratterizzata dallo stereotipo di accesso («access») o da quello di importazione («import»). Altri tipi di dipendenze fra i package indicano l’esistenza di una o più dipendenze fra gli elementi contenuti nei package stessi.
La figura 1.6 mostra un esempio di diagramma dei package.
Figura 1.6 - I package e le relazioni di accesso e di importazione fra di essi5.
5
Diagrammi delle classi
Un diagramma delle classi è un grafo che descrive i tipi degli oggetti in un sistema e le diverse relazioni statiche tra di essi come le associazioni, le generalizzazioni, le dipendenze, ecc.. Una classe è una descrizione di un insieme di oggetti che condividono gli stessi attributi, operazioni, metodi, relazioni e semantica. Quindi una classe definisce la struttura dei dati degli oggetti che descrive. Ogni oggetto istanziato da una classe contiene il proprio insieme di valori corrispondenti alla struttura dati definita nella sua classe di appartenenza.
Le classi sono rappresentate da un rettangolo suddiviso in tre sezioni che indicano rispettivamente i seguenti aspetti: il nome della classe, i suoi attributi, le sue operazioni (figura 1.7).
Figura 1.7 - Diagramma delle classi6.
6
In figura 1.8 si esemplificano quali sono le associazioni e quali sono le generalizzazioni dell’esempio in fig.1.7 (la relazione di specializzazione che lega la classe padre (più generale) a quella figlio (più specializzata) è denominata generalizzazione – generalization ed è rappresentata con una linea che termina con un triangolo che punta verso la classe più generale. La classe figlio eredita tutti gli attributi, le operazioni e le relazioni della classe padre).
Figura 1.8 - Associazioni fra classi7.
La figura 1.9 mostra un ulteriore diagramma delle classi, per meglio esemplificare le caratteristiche delle associazioni, che illustra la struttura del Design Pattern “Composite”.
7
Figura 1.9 - Struttura del Design Pattern “Composite”8.
Le associazioni rappresentano astrazioni di relazioni tra istanze di classi. Ogni associazione ha due (o più) estremità (AssociationEnd), ognuna delle quali è connessa ad una classe e specifica le caratteristiche della connessione dell’associazione alla classe stessa. Un’estremità ha un nome (rolename) che rappresenta il ruolo che essa gioca nell’associazione e definisce un insieme di proprietà della connessione. Ad esempio, l'associazione tra le classi Client e Component ha due estremità: una dalla parte di Component, l'altra dalla parte di Client: in questo caso il nome del ruolo delle classi è implicito ed è specificata la sola molteplicità dell’estremità dalla parte di Component. La molteplicità di un’estremità specifica il numero di istanze della classe, che è connessa all’estremità stessa, che possono essere associate con una singola istanza della classe connessa con l’estremità opposta dell’associazione (in figura 1.9 si ha che un’istanza di Client deve essere associata ad una o più istanze di Component).
8
Due tipi particolari di associazioni sono rappresentate dalle aggregazioni e dalle composizioni. Le prime sono caratterizzate da un rombo bianco ad una delle due estremità, le seconde presentano un rombo di colore nero. Entrambe, quando poste su una estremità, che per convenzione è chiamata estremità target, specificano che la classe connessa alla estremità target è una aggregato rispetto alla classe connessa alla estremità opposta (source). Se l’associazione è un’aggregazione si stabilisce che la classe source è una parte della classe target, ma può essere contenuta anche in altri aggregati. Se l’associazione è una composizione allora la classe source è invece posseduta strettamente dalla classe target e non può essere condivisa con altre composizioni. Il diagramma delle classi in figura 1.10 mostra un'aggregazione e una composizione. Dal diagramma emerge la differenza tra composizioni e aggregazioni: l'eliminazione di un poligono (classe Polygon) implica la cancellazione di tutti i suoi punti (classe Point), ma non dello stile (classe Style) associato ad esso.
Figura 1.10 - Aggregazione e composizione9.
9
Diagrammi degli oggetti
I diagrammi degli oggetti rappresentano istanze dei diagrammi delle classi. Sono composti da due elementi: gli oggetti, che rappresentano le istanze delle classi e i link, che rappresentano le relazioni che intercorrono tra due o più oggetti (sono infatti le istanze delle associazioni che intercorrono fra le classi da cui si sono istanziati gli oggetti).
La figura 1.11 mostra un possibile diagramma degli oggetti, ottenuto istanziando il diagramma delle classi mostrato in figura 1.9.
Figura 1.11 - Un diagramma degli oggetti.
Ogni oggetto è rappresentato da un rettangolo che mostra il proprio nome e il proprio tipo di classe, entrambi sottolineati, usando la sintassi:
1.3.3 Diagrammi d'interazione
I diagrammi d'interazione sono modelli che descrivono in che modo collaborano gruppi di oggetti per compiere un determinato lavoro. Tipicamente un diagramma di interazione descrive il comportamento di un singolo caso d'uso. Come illustrato nella tabella 1.1, la categoria dei diagrammi di interazione include i diagrammi di sequenza e di collaborazione.
Diagrammi di sequenza
Un diagramma di sequenza è un grafo che mostra la sequenza di messaggi scambiati tra diversi oggetti per l'esecuzione di un compito specifico. Gli elementi che compongono un diagramma di sequenza sono:
• il ruolo di un oggetto all'interno di una interazione;
• la linea di vita di un oggetto, che rappresenta il suo tempo di vita;
• l'attivazione, ossia il tempo durante il quale un oggetto è coinvolto nel compimento di un lavoro;
• i messaggi scambiati tra gli oggetti.
Figura 1.12 - Un diagramma di sequenza10.
Diagrammi di collaborazione
Analogamente ai diagrammi di sequenza i diagrammi di collaborazione mostrano la sequenza di messaggi scambiati tra diversi oggetti. Per individuare la giusta sequenza dei messaggi essi vengono numerati. Gli elementi che partecipano ad un collaborazione sono:
• il ruolo di un oggetto all'interno di una interazione;
10
• il ruolo di associazione, ossia il ruolo svolto dalle associazioni dell'interazione;
• i messaggi scambiati tra gli oggetti.
Un esempio di diagramma di collaborazione è mostrato nella figura 1.13.
Figura 1.13 - Un diagramma di collaborazione.
1.3.4 Diagrammi di stato
I diagrammi di stato vengono utilizzati per descrivere gli stati in cui può trovarsi un certo oggetto e i cambiamenti di stato che subisce al verificarsi di determinati eventi. Comprendono i diagrammi di stato e di attività, descritti nei paragrafi che seguono.
Diagrammi di stato
Sono grafi nei quali i nodi rappresentano lo stato in cui si può trovare un oggetto, mentre gli archi rappresentano transizioni di stato. Gli elementi che compongono un diagramma degli stati sono:
• gli stati, nei quali può trovarsi un oggetto durante il suo ciclo di vita. Un oggetto si trova in un determinato stato quando sono soddisfatte determinate condizioni riguardanti l'oggetto stesso e gli altri oggetti che sono in relazione con esso. In relazione allo stato un oggetto può essere interessato da determinati eventi e non da altri.
• le transizioni, che rappresentano le relazioni tra i diversi stati in cui può trovarsi un oggetto: queste infatti indicano il passaggio di un oggetto da uno stato al successivo come conseguenza di un evento.
Figura 1.14 - Un diagramma degli stati11.
Diagrammi di attività
Rappresentano un caso particolare di diagramma di stati in cui ogni stato rappresenta una precisa azione da eseguire. Solitamente vengono utilizzati per descrivere attività che si svolgono in parallelo e possono sincronizzarsi in qualche modo. Gli elementi che costituiscono un diagramma di attività sono i seguenti:
• azioni, che rappresentano azioni atomiche solitamente corrispondenti ai passi
di un algoritmo;
• flussi di azioni, che rappresentano le relazioni tra azioni differenti;
• flussi di oggetti, che rappresentano le relazioni tra un'azione e gli oggetti
coinvolti nella sua esecuzione;
11
• corsie, sono usate per raggruppare le azioni in base ai diversi agenti (persone
od organizzazioni) che le devono eseguire.
Di seguito sono mostrati un diagramma di attività ed uno di flusso azione-oggetto.
Figura 1.15 - Un diagramma di attività12.
12
Figura 1.16 - Un diagramma di flusso azione-oggetto13.
1.3.5 Diagrammi di implementazione
Riguardano gli aspetti implementativi ed in particolare vengono utilizzati per mostrare l'organizzazione del codice sorgente e le relazioni tra componenti software e hardware. Comprendono due tipi di diagrammi: diagrammi dei componenti e di dislocamento.
13
Diagrammi dei componenti
Un diagramma dei componenti è un grafo che mostra le dipendenze e le relazioni tra i componenti di un sistema, che rappresentano moduli di codice eseguibile o sorgente. I componenti, come a livello logico le classi, possono essere raggruppati in package. Solitamente si preferisce utilizzare i diagrammi di dislocamento anziché quelli dei componenti, poiché essi mostrano le relazioni non solo tra i componenti software, ma anche tra quelli hardware. Segue un diagramma di esempio.
Figura 1.17 - Un diagramma dei componenti14.
14
Diagrammi di dislocamento
Un diagramma di dislocamento mostra la struttura run-time dei componenti, ovvero del sistema dei processi e degli oggetti presenti in essi. I nodi rappresentano un componente hardware all'interno del quale sono presenti uno o più componenti software. Gli archi indicano flussi di comunicazione tra componenti software diversi. Il diagramma di dislocamento in figura 1.18 mostra le relazioni tra i diversi componenti hardware e software che collaborano per fornire servizi di accesso ad Internet.
1.4 UML: architettura
In questo paragrafo si estraggono dalla specifica ufficiale di OMG [UMLS] i fondamenti dell’architettura dello UML che sono stati presi in esame per iniziare a progettare la libreria in C++ oggetto di questa tesi.
La specifica di UML descrive la propria semantica scomponendo l’architettura in package. All’interno di ogni package gli elementi del modello sono definiti nei seguenti termini in modo semi-formale:
• sintassi astratta: si presenta, attraverso diagrammi di classe espressi con la
notazione UML, il metamodello UML, i suoi concetti (cioè le metaclassi), le sue relazioni e vincoli (constraints). A questi si aggiungono parti di testo scritto in linguaggio naturale (inglese);
• semantica: è fornita in linguaggio naturale; comprende la descrizione degli
elementi che compongono il metamodello UML e delle loro relazioni;
• well-formedness rules: sono le regole ed i vincoli per definire modelli che
siano validi. Questi sono espressi utilizzando sia un linguaggio formale, chiamato Object Constraint Language, sia il linguaggio naturale.
1.4.1 Struttura del metamodello
La complessità del metamodello UML è gestita organizzandolo in tre package: Foundation, Behavioral Elements e Model Management (figura 1.19). I primi due sono ulteriormente decomposti in package, ognuno dei quali contiene elementi semanticamente correlati.
Figura 1.19 - Struttura dei package del metamodello di UML
Si possono riassumere le dipendenze fra i package nella tabella seguente:
Package Package prerequisiti
Data Types
Core Data Types, Extension Mechanisms
Extension Mechanisms Core, Data Types
Common Behavior Foundation
State Machines Common Behavior, Foundation Activity Graphs State Machines, Foundation Collaborations Common Behavior, Foundation
Use Cases Common Behavior, Foundation
Model Management Foundation
Dalla tabella 1.2 si evince quali sono i package che devono essere definiti prima per definire poi quelli che dipendono da essi. In conclusione è ovvio che, nella progettazione della libreria in C++ che deve supportare UML, si è partiti dall’esaminare il package Foundation.
1.4.2 Data Types
Questo package specifica i tipi di dato (data types) che sono usati per definire lo UML. Ha una struttura più semplice degli altri package perché si suppone che la semantica di questi concetti base sia ben conosciuta.
La sintassi astratta dei tipi di dato è espressa in notazione grafica nelle figure seguenti.
Figura 1.20 - Package Tipi di Dato (Data Types)15.
15
Figura 1.21 - Definizione formale del concetto di espressione16.
Nel metamodello i tipi di dato sono usati per dichiarare il tipo degli attributi delle metaclassi. Nei diagrammi appaiono come stringhe e non hanno una propria icona, in questo modo la dimensione degli stessi diagrammi risulta ridotta. Ogni occorrenza di un particolare nome di un tipo dei dati denota sempre lo stesso tipo dei dati.
Da notare che questi sono i tipi di dato che vengono usati per definire il metamodello UML e non i dati che sono usati da un utente dello UML. Questi ultimi saranno istanze delle metaclassi “DataType” definite nel metamodello.
ActionExpression
È un’espressione la cui valutazione ha come risultato un’azione.
16
AggregationKind
Definisce un’enumerazione che denota il tipo di aggregazione di una certa associazione (i valori possibili sono none, aggregate, composite).
ArgListsExpression
Definisce un’espressione che risulta in un insieme di oggetti quando viene valutata.
Boolean
Definisce un’enumerazione che denota una condizione logica (i valori possibili sono vero o falso).
BooleanExpression
Definisce un’espressione la cui valutazione fornisce un valore booleano.
CallConcurrencyKind
È un’enumerazione che denota la semantica di più chiamate concorrenti di istanze passive (i valori possibili sono sequential, guarded, concurrent).
ChangeableKind
Definisce un’enumerazione che denota come un attributo o un legame possono essere modificati (i valori possibili sono changeable, frozen, addOnly).
Expression
Definisce un’espressione che viene valutata quando eseguita in un contesto preciso. L’attributo Language contiene il nome del linguaggio nel quale è espresso il corpo (body) dell’espressione. L’attributo body contiene il testo dell’espressione.
Geometry
Descrive la forma geometrica degli oggetti.
Integer
È un elemento appartenente all’insieme dei numeri interi.
IterationExpression
Definisce una stringa che viene valutata da un costrutto iterativo.
LocationReference
Assegna una posizione all’interno di una sequenza comportamentale.
Mapping
Specifica alcune relazioni fra elementi del modello (v. [UMLS]).
MappingExpression
È un’espressione che viene valutata in un “Mapping”.
Multiplicity
Definisce un insieme non vuoto di interi non negativi.
MultiplicityRange
Definisce un intervallo di interi non negativi i cui estremi sono contenuti nei due attributi lower e upper.
Name
Definisce un simbolo che viene usato per dare un nome agli elementi del modello.
ObjectSetExpression
Definisce un’espressione che quando viene valutata restituisce un insieme di istanze.
OrderingKind
Definisce un’enumerazione che specifica se gli elementi di un insieme sono ordinati (i valori possibili sono unordered, ordered).
ParameterDirectionKind
Definisce un’enumerazione che specifica se un parametro viene usato per passare argomenti e/o restituire valori (i valori possibili sono in, out, inout, return).
ProcedureExpression
Definisce un’espressione che cambia i valori dell’ambiente dove viene valutata.
PseudostateKind
Definisce un’enumerazione che discrimina i tipi di pseudostati (i valori possibili sono choice, deepHistory, fork, initial, join, junction, shallowHistory).
ScopeKind
Definisce un’enumerazione che specifica quando una caratteristica appartiene ad un’istanza individuale o ad un intero classificatore (i valori possibili sono instance, classifier).
String
TimeExpression
Definisce un’espressione la cui valutazione fornisce il tempo nel quale avviene un evento.
TypeExpression
Definisce una stringa che corrisponde ad un tipo di un linguaggio di programmazione.
UnlimitedInteger
Definisce un tipo di dati il cui intervallo corrisponde agli interi non negativi con l’aggiunta del valore unlimited, che indica molteplicità illimitata.
Uninterpreted
È un elemento usato per descrivere il modello, ma che non appartiene alla semantica dell’UML.
VisibilityKind
Definisce un’enumerazione che denota come un elemento può essere accessibile al di fuori dell’oggetto che lo contiene (i valori possibili sono pubblica, protetta, privata, package).
1.4.3 Core
Il package Core è il sottopackage principale di quelli che, nel loro insieme, compongono il package Foundation dello UML. Questo definisce i costrutti base astratti e concreti del metamodello necessari per lo sviluppo dei modelli degli oggetti. I costrutti astratti non sono istanziabili e sono comunemente usati per descrivere costrutti chiave, strutture condivise e per organizzare il metamodello
dello UML. I costrutti concreti sono invece istanziabili e corrispondono ai costrutti che gli architetti di modelli ad oggetti usano per il proprio lavoro. I costrutti astratti definiti nel package Core comprendono il ModelElement, il GeneralizableElement, il Classifier, ecc.. I costrutti concreti del Core comprendono Class, Attribute, Operation, Association, ecc. (nei diagrammi le classi astratte hanno il nome scritto in corsivo, mentre quelle concrete in testo piano).
Il package Core specifica i costrutti chiave necessari per costruire un metamodello base e definisce uno scheletro (backbone) dell’architettura per supportare costrutti addizionali al linguaggio. Inoltre il package Core è sufficiente da solo a definire il resto della specifica UML. In altri package il Core è esteso aggiungendo metaclassi allo scheletro usando gerarchie di specializzazione e associazioni.
La sintassi astratta del package Core è espressa nelle seguenti figure con notazione grafica.
Figura 1.22 - Il package Core: scheletro (Backbone)17.
17
Figura 1.23 - Il package Core: relazioni (Relationships)18.
18
Figura 1.24 - Il package Core: dipendenze (Dependencies)19.
19
Figura 1.25 - Il package Core: classificatori (Classifiers)20.
20
Figura 1.26 - Il package Core: elementi ausiliari21.
Per quanto riguarda la semantica dettagliata del package Core si rimanda alla specifica ufficiale [UMLS].
21
