1 LABORATORIO DI INFORMATICA Ingegneria Informatica a.a. 2002-2003 -2° Ciclo Unified Modeling...

1

LABORATORIO DI INFORMATICA Ingegneria Informatica

a.a. 2002-2003 -2° Ciclo

Unified Modeling Language

2


Metodi e Modelli

La necessità di utilizzare metodi di progettazione software deriva dal fatto che i progettisti devono considerare di:

• capire come fare il loro lavoro

• spiegare il loro lavoro ad altri

• capire quando l’altrui lavoro gli viene spiegato

In generale un metodo per lo sviluppo del software descrive come modellare e costruire i sistemi software in modo affidabile e riproducibile. Esso cioè permette la costruzione di modelli a partire da elementi di modelli che costituiscono i concetti fondamentali per rappresentare i sistemi.

3


I metodi di progettazione software hanno seguito due strade:

• Metodi Funzionali

• Metodi Object Oriented

Negli ultimi anni il secondo approccio è stato quello più seguito ed ha portato alla definizione di un linguaggio universale per la costruzione di modelli Object Oriented detto Unified Modeling Language (UML). Questo linguaggio è stato sottoposto a standardizzazione da parte dell’ente Object Management Group (OMG).

4


Il metodo object Oriented esegue la decomposizione di un sistema in oggetti collaboranti.

Un modello costituisce una unità di base per lo sviluppo: esso è altamente auto consistente ed è debolmente legato ad altri modelli attraverso i link di navigazione.

Di norma un modello è relativo ad una specifica fase dello sviluppo ed è costituito da elementi di modelli.

I modelli definiti in UML sono elencati di seguito.

5


• Il modello delle classi che cattura la struttura statica

• Il modello degli stati che esprime l’ambiente dinamico di un oggetto

• Il modello dei casi d’uso che descrive i requisiti dell’utente

• Il modello delle interazioni che rappresenta gli scenari ed i passaggi di messaggi

• Il modello dell’implementazione che mostra le unità di lavoro

• Il modello di distribuzione che fornisce dettagli che riguardano come processare l’allocazione.

6

Unified Modeling LanguageMolte prospettive differenti possono essere costruite per un modello di base, ciascuna delle quali mostra tutto o parte del modello e ciascuna ha uno o più corrispondenti diagrammi. UML definisce nove tipi di diagrammi:

• Diagrammi delle sequenze

• Diagrammi delle collaborazioni

• Diagrammi degli oggetti

• Diagrammi delle transizioni di stato

• Diagrammi delle attività

• Diagrammi delle classi

• Diagrammi dei casi d’uso

• Diagrammi dei componenti

• Diagrammi delle allocazioni

7


Meccanismi comuni

UML definisce un piccolo numero di meccanismi comuni che possono essere utilizzati in tutti i diagrammi. Questi meccanismi sono:

• Gli Stereotipi

Ciascun elemento di modello può avere uno o più stereotipi quando la semantica di base dell’elemento non è più sufficiente. Uno stereotipo di un elemento si ottiene aggiungendo all’elemento la definizione che ne permette l’estensione tra le parentesi << e >>, come in: <<uses>>, <<extends>>, ..

• I Valori Etichettati (Tagged Values)

Un valore etichettato è una coppia (nome, valore) che descrive una proprietà di un elemento di modello. Un valore etichettato modifica la semantica dell’elemento.

8


• Note

Una nota è un commento applicato ad uno o più elementi di modello. Una nota può essere trasformata in una costrizione usando uno stereotipo.

• Costrizioni (Constraints)

Una costrizione è un qualsiasi tipo di relazione semantica tra elementi di modello. UML non definisce una sintassi ad eccezione del fatto che esse devono apparire tra parentesi graffe.

• Dipendenze

La relazione di dipendenza definisce una relazione di uso unidirezionale tra due elementi di modello, riferiti, rispettivamente, come la sorgente e l’obiettivo della relazione.

9


• Dicotomia Tipo/Istanza e Tipo/Classe

Molti elementi di modello presentano le suddette dicotomie. Nella prima il tipo caratterizza l’essenza dell’elemento e l’istanza, con i suoi valori, è una manifestazione di quel tipo. Nella seconda si ha una suddivisione tra la specifica di un elemento che è descritta dal tipo e l’implementazione della specifica che è fornita dalla classe.

• Tipi di dato

I tipi di dato sono tipi primitivi senza sottostrutture. In UML sono:

Boolean (true, false), Expression, Multiplicity (0..1, 1..10, 0..*, ..), Name (simple_name{‘.’composite_name}, package_name{‘::’ simple_name}), Integer, String, Time, Uninterpreted.

10

Unified Modeling LanguagePackages

Il package fornisce un meccanismo generale per suddividere i modelli e raggruppare gli elementi dei modelli. Un package si rappresenta come un folder:

Ciascun package corrisponde ad un sottoinsieme di un modello e contiene gli elementi del diagramma associato. Un package può contenere altri package. Ad un dato livello un package può contenere sia altri package che altri elementi del modello.

11


Un elemento contenuto in un package può anche apparire in un altro package nella forma di elemento importato per mezzo di una relazione di dipendenza tra package.

Una relazione di dipendenza tra due package significa che almeno un elemento nel package client usa i servizi offerti da almeno un elemento del package fornitore (supplier).

L’operatore :: permette di specificare un elemento che è definito in un contesto diverso dal contesto corrente.

Ciascun elemento contenuto in un package ha un parametro che indica se l’elemento può essere visto al di fuori del package (public) o no (implementation).

12


Nota: Per ragioni di compilazione devono essere evitate le dipendenze incrociate o circolari tra package. Alcuni package, utilizzati da tutti gli altri package, sono detti globali e per essi non è necessario indicare graficamente le relazioni di dipendenza.

13


Diagramma delle Classi

Le classi sono rappresentate da rettangoli a compartimenti. Il primo compartimento contiene il nome della classe. Gli altri due compartimenti contengono rispettivamente gli attributi della classe e le sue operazioni. Ogni compartimento, ad eccezione di quello del nome della classe, può essere soppresso.

equivale a:

Nel compartimento del nome della classe possono esserci stereotipi e proprietà che alterano la semantica generale della classe. Le proprietà possono essere valori associati all’elemento del modello come attributi, associazioni e tagged value.

14


UML definisce i seguenti stereotipi di classe:

<<signal>> un evento che attiva una transizione entro una macchina a stati.

<<interface>> una descrizione di operazioni visibili.

<<metaclass>> la classe di una classe.

<<utility>> una classe ridotta al concetto di modulo e che non può essere istanziata.

15


I compartimenti dopo quello del nome della classe contengono attributi e operazioni, descritti rispettivamente con le sintassi:

Attribute_Name : Attribute_Type = Initial_Value

Operation_Name(Argument_Name :Argument_Type =Default_Value, ..) : Return_Type

E’ sempre possibile ridurre le suddette descrizioni ai soli elementi di volta in volta necessari, ad esempio limitandosi ai soli nomi di Attributi e Operazioni. Il livello di visibilità di Attributi e Operazioni può essere rappresentato facendo precedere la loro dichiarazione con i caratteri +, # e – , rispettivamente per i livelli: pubblico, protetto e privato e sottolineandoli nel caso di visibilità globale.

16

Unified Modeling LanguageUML rappresenta le interfacce usando piccoli cerchi connessi con una linea all’elemento che fornisce il servizio descritto con l’interfaccia:

Le interfacce possono anche essere rappresentate usando le classi stereotipate:

Un template di classe viene poi rappresentato come una classe in cui il parametro formale appare in un rettangolo tratteggiato, come segue:

17

Unified Modeling LanguageAssociazioni

Le associazioni rappresentano relazioni strutturali tra classi di oggetti. Le associazioni sono rappresentate da una linea che collega le classi associate.

Un’associazione può essere denominata. L’esperienza raccomanda di denominare le associazioni utilizzando una forma verbale. La direzione in cui il nome dovrebbe essere letto può essere indicata usando il simbolo > puntato verso la classe designata dal costrutto verbale.

>

Le due parti finali di un’associazione sono chiamate ruoli. Il ruolo descrive come una classe vede un’altra per mezzo dell’associazione. Un ruolo può essere denominato.

18


Molteplicità delle Associazioni

Ciascun ruolo di un’associazione ha un valore di molteplicità che indica quanti oggetti della data classe possono essere linkati ad un oggetto dell’altra classe. Questo valore può essere assegnato come segue:

1 uno e solo 1

0..1 zero o 1

M..N da M a N (interi naturali)

* da 0 ad ogni intero positivo

0..* da 0 ad ogni intero positivo

1..* da 1 ad ogni intero positivo

19

Unified Modeling LanguageCostrizioni sulle Associazioni

La costrizione {ordered} sul ruolo specifica una relazione ordinata degli oggetti linkati:

La costrizione {subset} indica che un insieme di link è incluso in un altro:

La costrizione {exclusive or} indica che per un dato oggetto solo una singola associazione di un dato gruppo è valida:

Un’associazione (riflessiva) può anche linkare una classe a se stessa:

20


Classi di Associazioni

Un’Associazione può essere rappresentata da una classe, a sua volta associabile ad altre classi, per aggiungere attributi ed operazioni all’Associazione. La notazione usa una linea punteggiata per collegare una classe ad un’Associazione:

Una associazione che contiene attributi, ma non è associata ad altre classi, è detta Associazione di Attributo e non viene identificata con un nome specifico:

>

21

Unified Modeling LanguageAssociazione N-aria

Una classe può essere linkata a più di un’altra classe. Questo si rappresenta con una figura multilato con gli spigoli puntati verso i vari componenti dell’associazione. Nel caso di una relazione tra tre classi e con una classe di associazione si ha la seguente rappresentazione:

Elevando l’Associazione a livello di classe, con in più la costrizione {ternary association} che specifica la contemporaneità dell’istanziazione dei vari rami, il caso sopra riportato può essere rappresentato come segue:

22


Qualificatori di Associazione

La qualificazione di un’Associazione consiste nella selezione di un sottoinsieme degli oggetti dall’insieme degli oggetti che partecipano ad un’associazione. Questa restrizione è fatta con un attributo, detto Qualificatore, usato congiuntamente ad un oggetto della classe sorgente e rappresentato in un rettangolo alla fine dell’Associazione:

La figura che segue mostra l’effetto del Qualificatore:

A

23

Unified Modeling LanguageAggregazioni

Un’Aggregazione è un’Associazione asimmetrica in cui una delle estremità gioca un ruolo più importante dell’altra. Essa si rappresente con un piccolo rombo in corrispondenza dell’aggregato:

I criteri per preferire un’Aggregazione ad una Associazione sono:• Una classe è parte di un’altra classe• I valori degli attributi di una classe si propagano all’altra• Un’azione su una classe implica un’azione anche sull’altra• Gli oggetti di una classe sono subordinati agli oggetti dell’altra

Un’Aggregazione può avere la molteplicità dal lato della classe aggregata. Segue l’esempio di proprietà in comune:

Owner

24

Unified Modeling LanguageComposizione

La Composizione è una Aggregazione in cui gli attributi di una classe sono fisicamente contenuti nella classe aggregata. Essa è cioè un’Aggregazione per valore ed è semanticamente equivalente ad un attributo. Per questa ragione la molteplicità della classe aggregata può essere solo 0 o 1. Si utilizza quando un attributo partecipa ad altre relazioni nell’ambito del modello. Si rappresenta con un piccolo rombo nero:

Segue un esempio per il cso di un automobile:

25

Unified Modeling LanguageGeneralizzazione

La relazione di Generalizzazione esprime il fatto che un elemento di una classe è anche descritto da un’altra classe (ossia, dal tipo di un’altra classe). La Generalizzazione esprime cioè una relazione di classificazione tra un elemento generale ed uno più specifico. La relazione di Generalizzazione è rappresentata con una freccia che punta dalla classe più specializzata a quella più generale. Gli esempi che seguono rappresentano la stessa cosa:

La Generalizzazione viene spesso implementata con la relazione di ereditarietà tra classi, ma essa in UML ha un aspetto più astratto che può corrispondere ad altre implementazioni.

26


Se una classe ha più di una superclasse si può avere una Generalizzazione multipla, come nell’esempio che segue:

Una classe può essere specializzata secondo diversi simultanei criteri. Per indicare i particolari criteri di specializzazione essi vengono riportati come “discriminatore” sui rispettivi collegamenti di Generalizzazione:

27


Le relazioni di Generalizzazione possono essere caratterizzate da “costrizioni” che sono rappresentate con espressioni tra parentesi graffe direttamente allocate sulla Generalizzazione interessata o collegate a tutte le Generalizzazioni contemporaneamente interessate con una linea tratteggiata.

La relazione di Generalizzazione è per default una decomposizione esclusiva e quindi questo tipo di costrizione può non essere indicato. Altri tipi possibili di costrizioni sono di seguito indicate.

28

Unified Modeling Language{disjoint} indica che una classe discendente dalla classe A può

essere solo discendente da una delle sottoclassi di A

{overlapping} indica che una classe discendente dalla classe A appartiene al prodotto Cartesiano delle sottoclassi di A

{complete} indica che la generalizzazione è terminata e non possono essere aggiunte altre sottoclassi

{incomplete} specifica una generalizzazione estensibile

Nell’esempio che segue viene mostrato come la classe Moped (Ciclomotore) è prodotto cartesiano delle sottoclassi Engine e Land della classe Vehicle:

29


Classi Astratte

Una classe Astratta è una classe che non può essere direttamente istanziata. Essa è una specifica generale di tipo allo scopo di gestire oggetti che sono istanze di una o più di una delle sue sottoclassi. Una classe viene specificata in UML come classe astratta utilizzando la proprietà Booleana: Abstract.

Per convenzione i nomi delle classi Astratte sono scritti in corsivo.

30


Diagramma dei Casi d’Uso (Use Case)

I Casi d’Uso descrivono il comportamento di un sistema dal punto di vista dell’utente, usando azioni e reazioni e permettendo, così, la definizione delle relazioni tra il sistema e l’ambiente. Ciascun Caso d’Uso è un’immagine della funzionalità del sistema che è attivata in risposta ad uno stimolo di un attore esterno. Il modello Use Case comprende gli attori, il sistema e i casi d’uso. Gli attori sono rappresentati da sagome di persone che attivano i casi d’uso, rappresentati come ellissi contenute nel sistema:

31

Unified Modeling LanguageGli Attori

Un attore rappresenta un ruolo interpretato da una persona o cosa che interagisce con il sistema (utente). Il nome dell’attore descrive il ruolo interpretato dall’utente. La stessa persona fisica può interpretare il ruolo di più di un attore. La determinazione degli attori è molto importante e permette la specifica dei limiti del sistema in modo incrementale. Le principali categorie di attori sono:

• Attori principali persone che usano le funzioni principali del sistema

• Attori secondari persone che eseguono compiti di amministrazione o manutenzione

• Hardware esterno gli apparati che devono essere usati perché fanno parte del dominio dell’applicazione

• Altri sistemi gli altri sistemi con cui il sistema deve interagire.

32


I Casi d’Uso

I casi d’uso sono determinati osservando e specificando, attore per attore, le sequenze di interazione, dette “scenari”, dal punto di vista dell’utente. Essi sono descritti in termini di informazioni scambiate e di modi di usare il sistema. I casi d’uso devono essere pensati come classi le cui istanze sono gli scenari: ogni volta che un attore interagisce con il sistema il caso d’uso istanzia una scenario.

Nota: i casi d’uso non sono solo necessari per la definizione dei requisiti di un sistema, ma sono presenti con continuità lungo tutto il ciclo di vita di un prodotto software. Da questo punto di vista i casi d’uso servono ad esempio per navigare attraverso le classi e gli oggetti che collaborano a soddisfare un requisito fino ai test che verficano che il sistema esegua i suoi compiti correttamente.

33

Unified Modeling LanguageLink

UML definisce tre tipi di link per attori e Use Case:

La relazione “Comunica”: è la sola relazione tra Attore e Casi d’Uso. E’ rappresentata con una linea continua tra Attore e Caso d’Uso:

La relazione “Usa”: descrive che una istanza del Caso d’Uso sorgente comprende anche il comportamento descritto con il Caso d’Uso di destinazione:

La relazione “Estende”: descrive che il Caso d’Uso sorgente estende il comportamento del Caso d’Uso destinazione:

34


Esempio

Quello che segue è un esempio di diagramma di Casi d’Uso in cui sono rappresentte tutte le relazioni possibili per gli Attori e i Casi d’Uso.

35

Unified Modeling LanguageDiagramma degli Oggetti

Il diagramma degli Oggetti mostra un contesto, ad esempio prima o dopo un’interazione, illustrando Oggetti e link tra Oggetti. La notazione utilizzata è derivata dal diagramma delle classi in cui gli elementi che sono istanze sono sottolineati. Un oggetto è rappresentato perciò da un rettangolo che può contenere il nome dell’oggetto, il nome dell’oggetto e della classe (separati da “:”), o, infine, solo il nome della classe (preceduto da “:”):

Il nome della classe può contenere il path completo costituito dai nomi dei vari packages contenitori separati da”:”:

36


Lo stereotipo della classe può riapparire nel compartimento dell’oggetto in forma testuale tra le parentesi << e >> sopra il nome dell’oggetto:

Infine i rettangoli che simbolizzano gli oggetti posso avere un secondo compartimento che contiene i valori degli attributi:

37


Link tra Oggetti

Gli Oggetti sono connessi attraverso Link che sono istanze delle Associazioni tra le classi degli oggetti presi in considerazione. Il diagramma degli Oggetti:

È un’istanza del diagramma delle classi:

I Link possono essere non solo binari, ma collegare più di due oggetti (ad esempio Link ternari). La molteplicità può anche essere espressa sovrapponendo più rappresentazioni leggermente sfalsate dello stesso oggetto:

38

Unified Modeling LanguageOggetti composti

Oggetti composti da sotto-oggetti possono essere rappresentati usando un oggetto composto allo scopo di ridurre la complessità del diagramma. Gli oggetti composti sono rappresentati con gli oggetti componenti che sostituiscono gli attributi:

:

Gli oggetti composti sono in genere istanze di classi composte, ossia costruite da altre classi usanti la forma più forte dell’aggregazione:

È un’istanza del diagramma delle classi:

39


Il Diagramma degli Oggetti e il relativo diagramma delle Classi

Tutte le scritte che appaiono in un diagramma delle classi (nomi delle associazioni, dei ruoli, delle composizioni, ..) possono essere mantenute nei corrispondenti diagrammi degli Oggetti, ad eccezione della molteplicità che è rappresentata direttamente dai link. Anche il valore dei qualificatori delle associazioni può essere mantenuto, come mostra l’esempio che segue:

40


Diagramma delle Collaborazioni

Questo diagramma è un’estensione del diagramma degli oggetti poiché esprime, oltre al contesto di un gruppo di oggetti (per mezzo di oggetti e link) anche le interazioni tra questi oggetti (rappresentando la diffusione dei messaggi). I messaggi sono rappresentati con scritte lungo i link che connettono gli oggetti e con frecce puntate verso chi riceve il messaggio. I messaggi possono essere numerati per indicare l’ordine di sequenza:

41

Unified Modeling LanguageI diagrammi delle collaborazioni mostrano le interazioni tra oggetti e simultaneamente le relazioni strutturali che facilitano queste interazioni. Oggetti e link che durante una interazione sono creati o cancellati possono essere rispettivamente soggetti alle “costrizioni” {new} o {deleted}. Oggetti che sono invece creati e cancellati nell’ambito della stessa interazione sono soggetti alla costrizione {transient}:

Quando un gruppo di oggetti è il destinatario di uno stesso messaggio si può usare una notazione simile a quella di molteplicità. Vedi di seguito un esempio a partire dal relativo diagramma di classe:

42

Unified Modeling LanguageLa notazione del diagramma delle collaborazioni ammette che vengano presentati nel relativo ambito anche gli attori, allo scopo di rappresentare l’avvio delle interazioni da parte di elementi esterni al sistema.

Gli oggetti che gestiscono un flusso di controllo sono detti Oggetti Attivi. In un diagramma delle collaborazioni gli Oggetti Attivi sono rappresentati con una cornice più marcata rispetto agli oggetti passivi.

43

Unified Modeling LanguageRappresentazione dei Messaggi

Finora le etichette associate ai messaggi sono state presentate in modo semplificato con casi particolari. In realtà la sintassi di un messaggio è più complicata ed ha la seguente forma generale:

synchronization sequence ‘:’ result ‘:=’ name arguments

• synchronization

La sintassi di synchronization è:

rank {‘,’ synchronization} ‘/’

Dove rank è dato da:

[integer | name of flow of execution] { ‘.’ rank}

Nell’esempio che segue il messaggio Message viene inviato quando le trasmissioni A.1 e B.3 sono state soddisfatte.

44

Unified Modeling Language• sequence

La sequence specifica il livello di nesting della diffusione del nell’ambito dell’interazione. La sintassi di sequence è:

rank [recurrence]

Dove recurrence rappresenta iterazioni o condizioni rispettivamente rappresentate con le sintassi:

‘*’ ‘[’ iteration clause ‘]’ block

‘[’ condition clause ‘]’ block

Sia iteration clause che condition clause si esprimono in formato libero e danno rispettivamente le condizioni di iterazione e le condizioni che convalidano l’invio dei messaggi nell’ambito di block.

45

Unified Modeling Language• result

result consiste in una lista di valori, espressi in formato libero, restituiti dal messaggio.

• name

Il name del messaggio spesso coincide con una operazione definita nella classe dell’oggetto destinazione del messaggio.

• arguments

Gli argomenti, scritti in pseudocode o nel linguaggio di codifica, sono una lista di parametri del messaggio. Si può usare anche la notazione sotto riportata. Nome e argomenti del messaggio identificano l’azione da attivare nell’oggetto destinazione.

46

Unified Modeling LanguageDiagramma delle sequenze

Il diagramma delle sequenze mostra le interazioni tra oggetti da un punto di vista temporale. Un oggetto viene rappresentato con un rettangolo ed una barra verticale chiamata “lifeline” (cavo di salvataggio) dell’oggetto. Gli oggetti comunicano scambiandosi messaggi, rappresentati da frecce orizzontali, tracciate dalla lifeline dell’oggetto che invia, alla lifeline dell’oggetto che riceve. L’ordine di invio dei messaggi è indicata dalla loro posizione verticale. L’asse verticale può essere etichettato per esprimere più precisamente le costrizioni temporali.

47

Unified Modeling LanguageEsistono due principali categorie di trasmissione di messagi:

• Trasmissioni sincrone, per le quali il trasmettitore è bloccato ed aspetta fino a che l’oggetto chiamato ha finito di processare il messaggio. Questa trasmissione è rappresentata con una freccia.

• Trasmissioni asincrone, per le quali il trasmettitore non si blocca e continua l’esecuzione. Questa trasmissione è rappresentata con mezza freccia.

Una freccia che rappresenta un messaggio può anche essere disegnata diagonalmente per indicare un ritardo di trasmissione non trascurabile:

48

Unified Modeling LanguageUn oggetto può anche inviare un messaggio a se stesso, generalmente per indicare l’avvio di una attività al suo interno. In questo modo si possono rappresentare le interazioni interne che coinvolgono oggetti contenuti entro un oggetto composto:

La creazione di un oggetto si rappresenta facendo cadere le freccia del messaggio che lo crea sul rettangolo che rappresenta l’oggetto. La cancellazione è rappresentata dalla lettera X:

49


L’attivazione di un oggetto, ossia il tempo durante il quale esso esegue un’azione si rappresenta con una striscia rettangolare posizionata lungo la lifeline dell’oggetto:

Tenendo conto di ciò si possono presentare vari casi di trasmissione sincrone (con ritorno implicito al trasmittente), asincrone (con ritorno da esplicitare) e asincrone dopo suicidio, che sono di seguito mostrate:

50


Il caso particolare della trasmissione di un messaggio recursivo è rappresentato con la replica della striscia rettangolare. L’oggetto appare come se fosse attivo una quantità multipla di volte:

51

Unified Modeling LanguageStruture di Controllo

I diagrammi di sequenza possono essere completati da note testuali espresse in formato libero. Il momento di emissione di un messaggio, detto transizione, può essere specificato in prossimità del punto di partenza della freccia utilizzata per rappresentare il messaggio. Questo nome può essere usato per stabilire delle condizioni temporali. Quando per un messaggio c’è un tempo di trasmissione non trascurabile i tempi di emissione e ricezione sono evidenziati con una coppia: nome, nome’.

52


L’utilizzo di pseudocode sul lato sinistro del diagramma consente la rappresentazione di cicli o salti. Le rappresentazioni che seguono indicano, in due modi, la trasmissione senza interruzione del messaggio Message finchè la condizione X è vera:

L’esempio che segue è invece relativo ad un salto condizionato:

53


Anche nel caso di scelte condizionate lo pseudocode può essere sostituito da condizioni scritte davanti al messaggio, come rappresentato di seguito:

Salti condizionati sul lato di destinazione del messaggio sono invece rappresentati raddoppiando la lifeline dell’oggetto destinazione.

54


Diagramma delle Transizioni di Stato

Il comportamento degli oggetti di una classe può essere formalmente descritto in termini di stati ed eventi usando una “macchina a stati” (State Machine) connessa alla classe in considerazione:

Ciascun oggetto segue il comportamento descritto nella macchina a stati associata alla sua classe ed è, ad un dato momento, in uno degli stati caratteristici dei suoi stati dinamici. Oggetti che non hanno un comportamento reattivo possono ritenersi sempre nello stesso stato e quindi tali che la loro classe non possieda una macchina a stati.

La macchina a stati può essere usata per descrivere il comportamento di gruppi di oggetti associando la macchina a stati ad una struttura mista, o anche ad un caso d’uso.

55

Unified Modeling LanguageStati e Transizioni

Ciascun oggetto è ad un dato istante in uno stato particolare. Gli Stati di un oggetto sono rappresentati come rettangoli con spigoli arrotondati; ciascuno stato ha un nome che lo identifica:

Uno stato è l’immagine della combinazione istantanea dei valori posseduti dagli attributi dell’oggetto e la presenza od assenza di link tra l’oggetto considerato e gli altri oggetti. Nell’esempio che segue viene riportato un diagramma delle classi, un corrispondente possibile diagramma degli oggetti e i corrispondenti possibili stati per gli oggetti della classe Person:

56


UML definisce una macchina a stati deterministica e quindi con un preciso stato iniziale. Gli stati finali possono essere invece più di uno in corrispondenza di differenti condizioni terminali, oppure nessuno nel caso di assenza di stop. Lo stato iniziale è rappresentato con un grosso punto nero, mentre uno stato finale è rappresentato da un grosso punto nero circondato da un cerchio:

Il passaggio da uno stato ad un altro è descritto da una coonnessione unidirezionale tra gli stati, detta Transizione. Essa viene attivata quando accade un determinato evento nel dominio del problema. Una transizione è rappresentata con una freccia che inizia dallo stato di partenza e termina sullo stato di arrivo:

57

Unified Modeling LanguageEventi

Un evento corrisponde al verificarsi di una determinata situazione nel dominio del problema. Un evento è usato per attivare il passaggio da uno stato ad un altro. Un oggetto che si trovi in un determinato stato attende il verificarsi di un evento per passare ad un altro stato:

La sintassi di un evento è la seguente:

Name_Of_The_Event (Parameter_Name : Type, ….)

Seguendo le suddette regole la macchina a stati della classe Person dell’esempio precedente può essere la seguente:

58


La comunicazione per eventi è sempre asincrona, atomica ed unidirezionale. Nel caso di oggetti si rappresenta come segue:

La comunicazione per eventi sincrona può essere rappresentata solo con due scambi asincroni in direzioni opposte:

La suddetta comunicazione corrisponde ad una macchina a stati come segue:

59


Guardie

Una Guardia (Guard) è una condizione Booleana che può o non può convalidare lo scatto di una transizione in seguito ad un evento. La condizione corrispondente ad una Guardia viene scritta dopo l’evento tra parentesi quadre:

Le Guardie, che devono corrispondere a condizioni mutuamente esclusive, permettono di mantenere il determinismo di una macchina a stati anche quando uno stesso evento può far scattare più di una transizione:

60

Unified Modeling LanguageOperazioni, Azioni ed Attività

Una Transizione può essere etichettata con il nome di un’azione, ossia di un’operazione definita nella specifica della classe, da eseguire quando la transizione viene fatta scattare da un evento. Il nome dell’azione, che può accedere sia ai parametri dell’evento che agli attributi dell’oggetto, è separata dal nome dell’evento con “/”:

Anche uno Stato può contenere azioni. Queste sono eseguite quando si assume lo stato (azioni descritte con la parola chiave “entry/”), quando si lascia lo stato (parola chiave “exit/”) o in seguito ad un evento che mantiene lo stato (parola chiave “Nome_Evento/”):

61

Unified Modeling LanguageUn’operazione che viene eseguita quando un oggetto è in un determinato stato ed il cui tempo d’esecuzione non può essere considerato istantaneo prende il nome di Attività e viene identificata con la parola chiave “do/”:

A differenza delle Azioni le Attività possono essere interrotte dallo scatto della transizione. In particolare le attività “cicliche” terminano solo quando scatta la transizione. Le attività “sequenziali” fanno invece scattare la transizione quando raggiungono la loro fine: questo tipo di transizione è detta Transizione Automatica.

Gli stati possono anche contenere variabili espresse come attributi. Le variabili degli stati appartengono alla classe associata alla macchina a stati, ma possono essere mostrate quando sono manipolate da azioni o attività.

62

Unified Modeling LanguageGeneralizzazione degli Stati

La complessità di un diagramma a stati può essere ridotta con la Generalizzazione degli stati. Uno stato più generale (detto superstato) è quello che raccoglie stati più specifici (detti sottostati) che ereditano dal loro superstato alcune caratteristiche come le variabili di stato e le transizioni esterne, ossia quelle che li collegano agli stati esterni al superstato:

A differenza delle transizioni esterne in uscita dal superstato solo un sottostato può ereditare dal superstato la transizione in entrata:

63


L’ultima rappresentazione, in cui una transizione collega livelli gerarchici diversi (un superstato esterno con un sottostato interno), è poco accettabile ed è preferibile sostituirla con una in cui viene definito per i superstati un (pseudo)stato iniziale:

Per evitare di entrare nel dettaglio dei sottostati può essere utilizzata la rappresentazione con “stubs” che nasconde la presenza dei sottostati esprimendone però l’esistenza:

64

Unified Modeling LanguageAggregazione di Stati

L’aggregazione di stato è la composizione di uno stato con alcuni stati indipendenti. Essendo l’aggregazione di tipo “and”, ciò vuol dire che l’oggetto deve simultaneamente essere in tutti gli stati che cosituiscono l’aggregazione. Aggregando in una macchina a stati ogni stato con un altro indipendente si ottiene che l’evoluzione degli stati dell’oggetto corrisponde a quello di due macchine a stati che operano in parallelo ed in cui gli stati aggregati sono il risultato del prodotto cartesiano degli stati delle due macchine:

65


Generalizzazione ed Aggregazione

La Aggregazione di stato e la Generalizzazione servono a semplificare la rappresentazione delle macchine a stati. La Generalizzazione semplifica per fattorizzazione, mentre l’Aggregazione semplifica per segmentazione dello spazio degli stati. In particolare la riduzione di complessità dell’Aggregazione risulta evidente dal seguente esempio: se una macchina a stati può essere ridotta a tre macchine parallele ciascuna con 100 stati, la macchina con stati non aggregati avrebbe uno spazio degli stati costituito dal prodotto cartesiano degli stati delle tre macchine e quindi con 1.000.000 di stati da considerare.

66

Unified Modeling LanguageStoria

La notazione speciale “H”, inserita in un punto qualsiasi di un superstato, permette di memorizzare l’ultimo sottostato visitato e di ritornare ad esso quando scatta la transizione che riconduce al superstato che lo comprende. Con la notazione “H*” è anche possibile memorizzare l’ultimo sottostato attivo a prescidere dal suo nesting:

H

H*

L’esempio che segue è un ciclo di lavapiatti:

HH

67

Unified Modeling LanguageComunicazioni tra Oggetti

Le trasmissioni di messaggi tra due oggetti sono rappresentate, nell’ambito del formalismo dei diagrammi a stati, con l’invio di un evento tra le macchine a stati delle classi degli oggetti considerati. La sintassi della trasmissione di un evento verso una classe assume la forma:

^ Target . Message (Arguments)

Dove Target si riferisce alla classe degli oggetti che sono obiettivo dell’evento e Message è il nome del messaggio che l’obiettivo deve acquisire. La sintessi completa di una transizione è perciò:

Event (Arguments) [Condition] / Action ^ Target . Message (Arguments)

L’esempio che segue è per un telecomando di televisore:

68

Unified Modeling LanguageCreazione e Distruzione di un Oggetto

La creazione di un oggetto è rappresentata con l’invio di un evento di creazione alla classe degli oggetti. Il nuovo oggetto comincia ad esistere con lo stato iniziale descritto nell’ambito della macchina a stati della classe. L’esempio che segue si riferisce alla registrazione di un nuovo aereo ed alla sua distruzione:

La cancellazione di un oggetto si effettua quando il flusso di controllo di una macchina a stati raggiunge, al livello gerarchico (di superstato) più alto, uno stato finale.

69

Unified Modeling LanguageTransizioni Temporizzate

Abbiamo già visto che con la keyword “do/” è possibile definire per uno stato un’attività di durata prestabilita, al termine della quale può scattare una transizione. Lo stesso meccanismo può essere rappresentato con l’uso dell’evento generico di nome “after” seguito da un parametro che specifica la durata dell’attesa. Quello che segue è un esempio di una macchina per il deposito di moneta descritto sia con l’uso di “do/” per l’attività dello stato che con l’uso di “after” per il ritardo dell’evento:

70

Unified Modeling LanguageDiagramma delle Attività

Un diagramma di Attività è una variante dei diagrammi a Stati, organizzato secondo le azioni e più orientato alla presentazione dell’implementazione di un’operazione. In un diagramma di Attività si privilegia quindi la presentazione delle Attività a scapito di Stati ed Eventi. Un’Attività è presentata come uno stereotipo di Stato per mezzo di un rettangolo con i lati minori arrotondati. Quello che segue è la rappresentazione di un’Attività con il diagramma a stati a cui essa corrisponde:

Ciascuna attività rappresenta un particolare stato nell’ambito dell’operazione che la racchiude.

71

Unified Modeling LanguageLe attività sono linkate da transizioni automatiche rappresetate con frecce. Quando un’attività termina la transizione scatta e parte l’attività successiva, per cui non è necessario denominare la transizione:

Le transizioni tra attività possono essere sottoposte a “guardie” con condizioni Booleane mutuamente esclusive riportate in prossimità della transizione di cui convalidano lo scatto. La stessa cosa può essere rappresentata con lo stereotipo “decision” disegnato con un rombo da cui escono le transizioni:

72


I diagrammi di Attività rappresentano le sincronizzazioni tra flussi di controllo mediante le barre di sincronizzazione. Le transizioni relative all’output di una barra di sincronizzazione scattano tutte simultaneamente. Viceversa una barra di sincronizzazazione può essere attraversata solo quando tutte le transizioni in input alla barra sono scattate:

73


Per evidenziare le responsabilità nell’ambito dell’operazione descritta, i diagrammi di attività possono essere organizzati in settori verticali paralleli, detti swimlane:

74


In un diagramma di Attività un oggetto può essere rappresentato con linee verticali uscenti da esso e le attività possono apparire lungo la sua “lifeline”. Se poi un oggetto è manipolato da più attività, esso può apparire più volte nell’ambito del diagramma. I flussi verso gli oggetti sono rappresentati con frecce punteggiate. Queste frecce mettono cioè in relazione l’oggetto con l’attività che lo crea e con le attività che lo coinvolgono.

75


I diagrammi di Attività possono anche contenere Stati ed Eventi, rappresentati nello stesso modo in cui essi sono rappresentati nei diagrammi di stato. Per le transizioni inoltre le trasmissioni e le ricezioni di segnali possono essere rappresentate con pentagoni, rispettivamente convessi e concavi, collegati con una freccia rispettivamente all’oggetto che riceve e a quello che trasmette:

76

Unified Modeling LanguageDiagrammi dei Componenti

I componenti rappresentano tutti i tipi di elementi che riguardano il risultato di un raggruppamento di applicazioni software: essi possono essere semplici file o librerie caricate dinamicamente. Un componente viene rappresentato per mezzo della sua “specifica” (ad esempio l’interfaccia, o il file .h, di una classe) e del suo “body” (l’implementazione, o il file .cpp, nel caso di una classe) utilizzando il simbolo che segue:

Le relazioni di dipendenza tra componenti, rappresentate con frecce tratteggiate che vanno dal body del client alla specifiction del supplier, indicano che il client fa riferimento a servizi (in genere dipendenze di compilazione) offerti dal supplier:

77

Unified Modeling LanguageProcessi

I Processi sono oggetti che hanno un loro flusso di controllo (o thread). I Processi possono essere contenuti nell’ambito dei Componenti. Gli stereotipi <<process>> e <<thread>> sono predefiniti in UML:

Subsystem

Per accelerare la realizzazione di applicazioni, vari componenti possono essere raggruppati nell’ambito di packages in base a criteri logici ed essere stereotipati come <<subsystem>>.

78


I Subsystem, che possono contenere componenti o altri Subsystem, organizzano la vista implementativa di un sistema: i Subsystem dovrebbero essere visti come i grossi mattoni per la costruzione del sistema.

La decomposizione in Subsystem non è una decomposizione funzionale. Dal punto di vista dell’utente le funzioni del sistema si esprimono nell’ambito della vista dei Casi d’Uso. I Casi d’Uso sono tradotti in interazioni tra Oggetti le cui Classi sono esse stesse incapsulate in Categorie. Gli Oggetti che implementano le interazioni sono distribuiti nelle varie categorie: il codice corrispondente è memorizzato in moduli e Subsystem.

79


Diagrammi delle Allocazioni

I diagrammi delle Allocazioni mostrano la struttura fisica dei vari componenti hardware (nodi) che compongono un sistema e contemporaneamente la distribuzione dei programmi eseguibili su questo hardware. Ciasuna risorsa hardware è rappresentata da un cubo:

La natura di un apparato può essere specificata usando uno stereotipo. Se necessario l’utente ha la possibilità di definire altri stereotipi:

80

Unified Modeling LanguageI vari nodi che appaiono in un diagramma di allocazioni sono connessi tra di loro con linee che rappresentano le infrastrutture, implicitamente bidirezionali, di comunicazione. La natura di queste infrastrutture può essere specificata con uno stereotipo. I nodi corrispondenti a processori mantengono il nome dei processi che contengono. Il nome dei processi facilita il collegamento tra il diagramma delle allocazioni e quello dei componenti. Ciascun processo nominato nel diagramma delle allocazioni esegue un programma main con lo stesso nome di quello descritto nel diagramma dei componenti.

81


I diagrammi di allocazioni possono mostrare classi di nodi o istanze di nodi: la differenza grafica è che le istanze sono sottolineate.

1 LABORATORIO DI INFORMATICA Ingegneria Informatica a.a. 2002-2003 -2° Ciclo Unified Modeling...

Documents

Transcript of 1 LABORATORIO DI INFORMATICA Ingegneria Informatica a.a. 2002-2003 -2° Ciclo Unified Modeling...