Home

Federica EU

1/28

Sergio Di Martino » 7.UML: I Sequence Diagrams ed i Class Diagrams

Obiettivi della lezione

Richiami su:

Sequence Diagrams
Class Diagrams

Software Lifecycle Activities

Sequence Diagram

Mostra la sequenza temporale dei messaggi che gli oggetti si scambiano per portare a termine una funzionalità.
E’ un diagramma di interazione: evidenzia come una funzionalità è realizzata tramite la collaborazione di un insieme di oggetti.
E’ uno dei principali input da fornire ai programmatori per l’implementazione di uno scenario.
E’ utilizzato in analisi e poi ad un maggior livello di dettaglio in design.

Sequence Diagrams

Il formalismo dei Sequence Diagrams.

Sequence Diagrams (segue)

La ricezione di un messaggio determina l’attivazione di un metodo

L’attivazione è rappresentata da un rettangolo sulla linea della vita, da cui altri messaggi possono prendere origine.
La lunghezza del rettangolo rappresenta il tempo durante il quale l’operazione è attiva.

La vita degli oggetti

Il tempo procede verticalmente dal top al bottom.
Al top del diagramma si trovano gli oggetti che esistono prima del 1° messaggio inviato.
Oggetti creati durante l’interazione sono illustrati con il messaggio <<create>>.
Oggetti distrutti durante l’interazione sono evidenziati con una croce.
La linea tratteggiata indica il tempo in cui l’oggetto può ricevere messaggi.

Messaggi nei Sequence Diagrams

Opzioni e Cicli

Si indicano con una cornice intorno ad una parte del Sequence, per indicare che quella sezione è opzionale o viene ripetuta.
Rappresentazioni:

if -> OPT [condition]
if/else -> ALT [condition], separati da linea orizzontale tratteggiata
cicli -> LOOP [condition o items su cui cicclare]

Linking sequence diagrams

Se un Sequence è troppo complesso o fa riferimento ad un altro Sequence, si può utilizzare il REF, con:

Un rettangolo con label REF, col nome dell’altro diagramma;
Una freccia che punta a tale rettangolo;
Una eventuale condizione per specificare quando si fa il riferimento.

Analisi e Sequence Diagram

Durante l’analisi i Sequence Diagram sono usati per individuare:

nuovi oggetti;
comportamenti mancanti.

Disegnare Sequence Diagram è un’attività laboriosa, quindi:

Occorre dare priorità a quelle funzionalità problematiche o non ben specificate;
Per le parti ben definite può essere utile solo per evitare di posticipare alcune decisioni chiavi.

Convenzioni per utilizzare i Sequence Diagrams in fase di Analisi:

La colonna più a sinistra rappresenta l’attore che inizia lo use case.
La seconda colonna -> oggetto Boundary con cui l’attore interagisce per iniziare lo use case.
La terza colonna -> oggetto Control che gestisce il resto dello use case.
Le altre colonne possono rappresentare qualunque oggetto che interviene nel caso d’uso.
- Gli oggetti Control creano altri oggetti Boundary/Entity e possono interagire con altri oggetti.
Oggetti Control accedono ad altri oggetti Entity e Boundary.
Gli oggetti Entity non accedono mai agli oggetti Control e Boundary: ciò rende più facile condividere oggetti Entity tra più use case.

Class Diagrams

Descrive:

Classi
Relazioni tra classi:
- associazione (uso);
- generalizzazione (ereditarietà);
- aggregazione (contenimento).

Definisce la visione statica del sistema.
È il modello principe di UML, perché definisce gli elementi base del sistema sw da sviluppare.

Un class diagram può essere definito a livello:
1. concettuale (o di Analisi):

studia i concetti propri del dominio sotto studio, senza preoccuparsi della loro successiva implementazione;
è una sorta di Dizionario Visuale del dominio.

2. di specifica implementativa:

studia il software da un punto di vista implementativo, specificando come va sviluppato il sistema;
è un raffinamento del precedente.

Classe (di oggetti)

Un oggetto ha due principali tipi di proprietà:

attributi (o variabili di istanza), che descrivono lo stato;
operazioni (o metodi), che descrivono il comportamento.

Una classe rappresenta un’astrazione di oggetti simili: oggetti che hanno le stesse proprietà: attributi e operazioni.
I termini oggetto e istanza (di classe) sono interscambiabili.

In UML una classe è composta da tre parti:

nome;
attributi (lo stato);
metodi o operazioni (il comportamento).

Rappresentazione di una classe.

Attributi

Un attributo è una proprietà di un oggetto:

nome, età, peso sono attributi della classe Persona;
colore, peso, anno, modello sono attributi della classe Auto.

Un attributo contiene un valore per ogni istanza:

l’attributo Docente ha il valore “Sergio Di Martino” nell’oggetto “Corso di Ing Sw 1″;
i nomi degli attributi devono essere unici all’interno di una classe;
il valore di un attributo non ha identità (non è un oggetto);
tutte le occorrenze di “24″ sono indistinguibili.

In UML, per ciascun attributo si può specificare il tipo ed un eventuale valore iniziale:

tipicamente il nome di un attributo è composto da una o più parole;
usare il maiuscolo per la prima lettera di ciascuna parola, lasciando minuscola la lettera iniziale del nome (Camel Case).

Esempi di rappresentazione di Attributi.

Operazioni

Un’operazione è un’azione che un oggetto esegue su un altro oggetto e che determina una reazione.
Le operazioni operano sui dati incapsulati dell’oggetto.

Tipi di operazione

Selettore (query): accedono allo stato dell’oggetto senza alterarlo (es. “lunghezza” della classe coda).
Modificatore: alterano lo stato di un oggetto (es. “append” della classe coda).

Operazioni di base per una classe di oggetti (realizzate con modalità diverse a seconda dei linguaggi).

Costruttore: crea un nuovo oggetto e/o inizializza il suo stato.
Distruttore: distrugge un oggetto e/o libera il suo stato.

Per ciascuna operation si può specificare il solo nome o la sua signature, indicando il nome, il tipo, parametri e, in caso di funzione, il tipo ritornato.
Stesse convenzioni dette per gli attributi (Camel Case).

Esempi di rappresentazione di Operazioni.

Visibilità di features

E’ possibile specificare la visibilità di attributi e operazioni.
In UML è possibile specificare tre livelli di visibilità:

+ (public): qualsiasi altra classe con visibilità alla classe data può usare l’attributo/operazione (di default se nessun simbolo è indicato);
# (protected): qualsiasi classe discendente della classe data può usare l’attributo/operazione;
- (private): solo la classe data può usare l’attributo/operazione.

Esempi di rappresentazione di visibilità di Features.

Stringhe di Proprietà

E’ possibile definire una “stringa di proprietà” per specificare particolari caratteristiche delle features di una classe. Si indica tra parentesi graffe affianco alla definizione della feature. Per gli attributi, property-string può assumere uno dei seguenti 3 valori:
1- changeable: nessuna limitazione per la modifica del valore dell’attributo (default);
2- addOnly: per attributi con molteplicità maggiore di 1 possono essere aggiunti ulteriori valori, ma una volta creato un valore non può essere né rimosso né modificato;
3- readonly: il valore non può essere modificato.

Per i metodi, property-string può assumere uno dei seguenti valori:
1- isQuery: l’esecuzione dell’operazione lascia lo stato del sistema immutato
2- sequential: i chiamanti devono coordinare l’oggetto dall’esterno in modo che vi sia un sol flusso per volta verso l’oggetto; in presenza di più flussi di controllo, non è garantita la semantica e l’integrità dell’oggetto
3- guarded: la semantica e l’integrità dell’oggetto è garantita in presenza di flussi di controllo multipli dalla sequenzializzazione di tutte le chiamate a tutte le operation guarded dell’oggetto;
4- concurrent: la semantica e l’integrità dell’oggetto è garantita in presenza di flussi di controllo multipli trattando la operation come atomica. Chiamate multiple da flussi di controllo concorrente possono presentarsi contemporaneamente ad un oggetto o ad una sua operation concurrent ed essere eseguite correttamente con corretta semantica

Le ultime tre proprietà riguardano la concorrenza di una operation esono rilevanti solo in presenza di più processi o threadS.

Sintassi finale di features

Attributi:
visibilità nome: tipo molteplicità = default {property-string}
Es: – titolo : String [1] = "Sw Engineering" {ReadOnly}

Metodi:
visibilità nome (elenco parametri): tipo di ritorno{property-string}
Es: + getSaldo(data: Date): double {isQuery}

Relazioni tra classi

In UML, le interconnessini tra oggetti/classi sono rappresentate attraverso “relazioni”.

UML definisce 3 tipi di relazioni:

Associazioni
Generalizzazioni/Specializzazioni
Dipendenze

Associazioni

Un sistema OO è costituito da classi che collaborano tra loro scambiandosi messaggi.
Quando è in esecuzione un sistema OO è popolato da istanze di classi.
Quando un’istanza di classe passa messaggi a un’altra classe si sottintende l’esistenza di un’associazione tra le due classi.

Indicano relazioni tra classi

Possono essere Riflessive
Possono essere n-arie (raro)

Adornments:

Nome: non obbligatorio; può avere un verso di lettura;niente a che vedere con la “navigabilità”, che pure esiste in UML.
Ruolo: per ciascuna classe coinvolta.
Cardinalità: come negli E-R.
Aggregazioni: un tipo particolare di associazione che specifica un rapporto aggregato-componente.
Composizioni: aggregazione in cui ogni componente partecipa ad un solo aggregato.

Esempio di Associazione.

Molteplicità delle associazioni

La molteplicità indica

Se l’associazione è obbligatoria oppure no.
Il numero minimo e massimo di oggetti che possono essere relazionati ad un altro oggetto.

Tipi di Molteplicità ammessi in UML 2.X.

Aggregrazione e Composizione

Aggregazione: è la relazione “parte di”. Es: un’azienda ha delle persone che vi lavorano. I vari oggetti “persona” continuano ad avere dignità ed esistenza propria anche al di là dell’oggetto azienda.

La distruzione dell’oggetto “azienda” non comporta automaticamente quella delle sue parti. La relazione di aggregazione è un’associazione speciale che aggrega gli oggetti di una classe componente in un unico oggetto della classe. La si puo’ leggere come “è fatto da” in un verso e “è parte di” nell’altro verso.

Composizione: è una relazione più forte, l’oggetto parte appartiene ad un solo tutto e le parti hanno lo stesso ciclo di vita dell’insieme.

All’atto della distruzione dell’oggetto principale si ha la propagazione della distruzione agli oggetti parte. Es: un’azienda ha dei dipendenti che vi lavorano. In tal caso, a differenza dell’esempio precedente, non ha senso che i vari oggetti “dipendente” abbiano vita propria senza un oggetto “azienda” associato. Una relazione di composizione è un’aggregazione forte. Le parti componenti non esistono senza il contenitore. Ciascuna parte componente ha la stessa durata di vita del contenitore. Una parte può appartenere ad un solo tutto per volta.

Aggregazione. Gli oggetti di tipo Persona sopravvivono alla distruzione di Azienda.

Composizione. Gli oggetti di tipo Dipendente non sopravvivono alla distruzione di Azienda.

Riassunto Associazioni

Ereditarietà

La relazione di generalizzazione rappresenta una tassonomia delle classi:

la classe generale è detta superclasse;
ogni classe specializzata è detta sottoclasse;

Può essere letta come:

“è un tipo di” (verso di generalizzazione);
“puo’ essere un” (verso di specializzazione);
ogni oggetto di una sottoclasse è anche un oggetto della sua superclasse.

Ereditarietà.

Ereditarietà (segue)

L’ereditarietà è un meccanismo di condivisione delle proprietà degli oggetti in una gerarchia di generalizzazione.
Tutte le features di una superclasse sono ereditati dalle sottoclassi:

generalizzazione ed ereditarietà godono della proprietà transitiva;
è possibile definire nuove proprietà per le sottoclassi;
è possibile ridefinire le proprietà ereditate (overriding) → polimorfismo.

Anche le relazioni di una superclasse valgono per le sottoclassi.

L’Ereditarietà consente di organizzare concetti in gerarchie:

al top della gerarchia concetti più generali;
al bottom concetti più specializzati.

Ereditarietà (segue)

Generalizzazione: attività di modellazione che identifica concetti astratti da quelli di più basso livello. Es. Stiamo facendo reverse-engineering di un sistema di gestione delle emergenze e analizzando le videate per la gestione di incidenti autostradali e incendi. Osservando concetti comuni, creiamo un concetto astratto Emergenze.
Specializzazione: attività che identifica concetti più specifici da quelli di più ad alto livello. Es. Stiamo costruendo un sistema di gestione delle emergenze e stiamo discutendo le funzionalità con il cliente: il cliente introduce prima il concetto di incidente, quindi descrive tre tipi di incidenti: disastri, emergenze, incidenti a bassa priorità.
Come risultato sia della specializzazione che della generalizzazione abbiamo la specifica di ereditarietà tra concetti.

Generalizzazione (Esempio)

Esempio sull'uso della generalizzazione in un class diagram.

Dipendenze

Relazione semantica in cui un cambiamento sulla classe indipendente può influenzare la classe dipendente.

La freccia punta verso la classe indipendente.
E’ possibile aggiungere un verbo che esplicita la dipendenza.
Implica l’esistenza di un riferimento alla classe indipendente.

Rappresentazione di una dipendenza.

Interfacce

Un’interfaccia viene modellata allo stesso modo in cui viene modellato il comportamento una classe e rappresenta un insieme di operazioni che una classe offre ad altre classi
Un’interfaccia non ha attributi ma soltanto operazioni (metodi).
In UML per rappresentare le interfacce si utilizza un rettangolo con lo stereotipo «interface» o un piccolo cerchio (notazione lollipop, “a lecca-lecca”).
La relazione tra una classe ed un’interfaccia viene definita realizzazione.
Linea tratteggiata con un triangolo largo aperto costruito sul lato dell’interfaccia o con una linea nella notazione compatta lollipop.

Le due rappresentazioni alternative delle Interfacce in un Class Diagram.

Classe Astratta

Una classe astratta definisce un comportamento “generico”.
Definisce e può implementare parzialmente il comportamento, ma molto della classe è lasciato indefinito e non implementato.
Dettagli specifici sono demandati alle sottoclassi specializzanti.
Le classi astratte sono indicate ponendo il nome in corsivo.