UMLFuggetta

CEFRIEL
Centro per la Formazione e la Ricerca in Ingegneria dellInformazione
Politecnico di Milano
Principi di Ingegneria del Software

Unified Modeling Language
Alfonso Fuggetta Politecnico di Milano e CEFRIEL

Alfonso.Fuggetta@polimi.it http://www.cefriel.it/~alfonso
2000 - Software Engineering Area
Indice
Introduzione Caratteristiche di UML Diagrammi UML Class e Object Diagram Interaction Diagram
Sequence Diagram Collaboration Diagram
Statechart Diagram Activity Diagram Component Diagram Deployment Diagram Use Case Diagram Alcuni strumenti CASE di supporto
Unified Modeling Language -2 2000 - Software Engineering Area

E un insieme di linguaggi che, utilizzati congiuntamente, consentono di descrivere/modellare aspetti diversi di un sistema con un approccio O-O
Struttura statica Comportamento dinamico Interazioni fra i diversi componenti del sistema
Notazione grafica Linguaggio semi-formale Standard OMG per la modellizzazione di sistemi Object-Oriented sin dal 1997
Origine di UML
Unifica le notazioni e metodologie precedentemente elaborate dai suoi stessi autori quando operavano singolarmente
G. Booch J. Rumbaugh (OMT) I. Jacobson
Incorpora miglioramenti e suggerimenti provenienti da altre fonti e autori E il risultato della cooperazione di diverse persone ed organizzazioni
Digital, HP, IBM, Microsoft, Oracle, Rational, TI, Unisys, ...
Situazione
UML 1.0 gennaio 97 Sottomissione a OMG gennaio 97 UML 1.1 settembre 97 UML 1.3 giugno 1999 Dove trovare informazioni costantemente aggiornate:
http://www.rational.com http://www.omg.org internet newsgroup comp.object
-5-
Caratteristiche
Non proprietario
chiunque lo pu usare chiunque pu sviluppare strumenti di supporto
Elimina le differenze (spesso inessenziali) presenti tra le notazioni precedenti Semi-formale

lenfasi sulla definizione della notazione c peraltro un meta-modello semantico cui i tool dovranno fare riferimento la semantica non comunque rigorosamente definita in tutti i casi (da cui la semi-formalit)
Si considerato il problema dello scambio di dati tra tool diversi (XMI, CDIF, ...)
Indice
I class diagram
Forniscono una vista strutturale (statica) del sistema in termini di
classi
attributi operazioni
relazioni tra classi (associazioni, generalizzazioni, ...)
Un class diagram rappresenta uno schema concettuale

se una classe A in relazione con una classe B, allora ogni istanza di A sar in relazione con unistanza di B
-8-
Similitudini
Entit / Relazioni
E una estensione dei diagrammi Entit / Relazioni. Introduce classificazione, istanziazione e aggregazione. Definisce non solo gli attributi, ma anche le operazioni.
Altri modelli OO (Booch, OMT)

Differenze sintattiche
-9-
Classi
Una classe descrive un gruppo di oggetti con caratteristiche comuni
attributi comportamento
Gli oggetti (istanze) di una stessa classe differiscono tra loro per i valori degli attributi e per le relazioni che li legano ad altri oggetti.
- 10 -
Notazione generale per le classi

Nel caso pi generale la notazione la seguente.
NomeClasse
nome-attributo-1: tipo-dato-1 = valore-di-default-1 nome-attributo-2: tipo-dato-2 = valore-di-default-2 .... nome-operazione-1 (lista-argomenti-1): tipo-reso-1 nome-operazione-2 (lista-argomenti-2): tipo-reso-2 ....
Persona
Nome: string Et: int CambiaLavoro CambiaIndirizzo
File
Nome: string Dimensione: int Creazione: data Stampa
Disegno
Titolo: string Altezza: int Larghezza: int Stampa Ruota(gradi: int) - 11 2000 - Software Engineering Area
Esempi di Rappresentazione di Classi, Attributi e Operazioni
Livello di dettaglio visibile
WINDOW
WINDOW {abstract}
+ size: Area =(100, 100) # visibility: Bool - xptr: Xwindow
WINDOW size: Area visibility: Bool display()
public protected private
+ display() - attachXWin(xwin:Xwindow)
E possibile in ogni momento decidere il livello di visibilit: Classi degli attributi Classi dei parametri e dei valori restituiti dai metodi di una classe Qualificatori di attributi ed operazioni
Unified Modeling Language - 12 2000 - Software Engineering Area
Classi: Implementazione
Esiste una corrispondenza tra la rappresentazione UML di una classe e limplementazione con un linguaggio O-O (Es. Java)
Fattura
+ importo: Real + data: Date + cliente: String - fatture_emesse : int = 0 Fattura() nome-operazione-1 (lista-argomenti-1): tipo-reso-1 nome-operazione-2 (lista-argomenti-2): tipo-reso-2
public class Fattura { public double importo; public Date data = new Date(); public String cliente; static private int fatture_emesse = 0; public Fattura() { fatture_emesse++; } // Altri metodi // ... }
- 13 -
Oggetti: Notazione grafica
Un oggetto unistanza di una classe Per rappresentare un oggetto si utilizza lo stesso simbolo usato per rappresentare le classi Il nome viene sottolineato per evidenziare che si tratta di un oggetto Analogamente a quanto accade per le classi possibile decidere il livello di visibilita per attributi e valori Classe
Order : Order
Istanze
MyOrder: Order number=0 amount=10000
MyOrder: Order
Unified Modeling Language - 14 -
Relazioni in UML
In un Class Diagram vengono rappresentate relazioni oltre alle classi:
Associazioni (semplici, aggregazioni, composizioni) Relazioni di generalizzazione Relazioni di dipendenza Relazioni di raffinamento
- 15 -
Associazioni
Una Associazione individua una connessione logica tra classi si traduce in una connessione fra oggetti istanze delle classi coinvolte nellassociazione Il concetto di associazione presente anche nella modellazione concettuale di database (Entity-Relationship)
Nome (opzionale) dell'associazione
Citt
Nome: string
CapoluogoDi
Regione
Nome: string
Nota: una associazione naturalmente bidirezionale.

Cardinalit nelle associazioni

Indica il numero di istanze di una classe che possono essere associate ad una singola istanza dellaltra classe Pu non essere specificata ad uno degli estremi (association-end) o a entrambi
E in questo caso non significa cardinalit pari a 1!
- 17 -
Cardinalit nelle associazioni

S2 P7 S1 S5 P1 P6 S4 P5 P2 P4 P3 S3
Situazione da descrivere Indicazione (opzionale) di molteplicit
Linea
Nome: string 0..*
IdentificataDa > < AppartieneA
Punto
2 Nome: string
- 18 -
Notazione per la cardinalit

La molteplicit si pu indicare con precisione. Persona
Nome: string Possiede 1..3, 5
Auto
Modello: string
Ogni persona pu possedere zero o al pi un'auto (magari in compropriet) Ogni auto ha 1, 2, 3 o 5 (ma non 4) comproprietari 0..1 1
Auto Auto
... zero o un'auto ... esattamente un'auto ... zero o pi auto ... zero, da 3 a 5 oppure 7 auto e oltre
- 19 2000 - Software Engineering Area
0..*
Auto
0, 3..5, 7..*
Auto
Notazione per la cardinalit(2)
Persona
Nome: string
Possiede
Auto
0..* Modello: string
Nota: Il class diagram indica che una persona pu possedere un numero qualsiasi di auto Quanti sono i proprietari di una singola auto? Il diagramma non fornisce questa informazione, dato che la cardinalit della partecipazione di Persona allassociazione risulta non specificata! Inoltre, dato che lassociazione navigabile in una sola direzione, data unauto non mai possibile risalire ai suoi (o al suo) proprietario
Associazioni n-arie
Alcune associazioni con cardinalit maggiore di due non sono riducibili a semplici associazioni binarie.
Persona UsaPer Progetto
Corretto
Linguaggio
Simbolo indicante la relazione n-aria (ternaria)
Persona 0..*
2..*
LavoraIn
Progetto 0..*
Sbagliato
LavoraCon 0..* Linguaggio 1..* UsatoIn
Se ogni persona conosce C e C++ e ogni progetto usa entrambi i linguaggi, anche se so chi ha lavorato in ciascun progetto perdo la nozione di che linguaggio ha usato in quel progetto.
- 21 -
Ruoli nelle associazioni

Una classe pu partecipare ad unassociazione con un ruolo specifico, che pu essere indicato
1..* Persona
Lavora per
0..1
Impiegato
Azienda
DatoreDiLavoro
Il ruolo (opzionale) viene indicato in stile normale
- 22 -
Ruolo obbligatorio nelle associazioni

Quando le stesse classi sono coinvolte pi volte dalla stessa associazione il ruolo diviene obbligatorio.
1 owner Utente 0..*
utente autorizzato contenuto
0..* 0..* Directory 0..*
contenente
0..1
Qui il ruolo serve a distinguere due associazioni diverse tra le stesse due classi
Qui il ruolo obbligatorio Alternativa: contiene
Associazioni: Implementazione
In generale non esiste un mapping diretto su un costrutto di un linguaggio di programmazione Possono essere implementate introducendo degli attributi ad hoc che contengono dei riferimenti (o puntatori) alle istanze delle classi associate Il riferimento a pi istanze di una classe pu essere modellato con liste, array, etc. Direzionalit In fase di implementazione si pu decidere di codificarla solo in una delle due direzioni (con un puntatore), perdendo per cos la possibilit di percorrere il link nella direzione opposta! Nota: Una associazione va modellata come tale in UML!! Nascondere le associazioni nelle classi (ad es. come attributi puntatori) porta alla costruzione di diagrammi contenenti dipendenze nascoste difficili da gestire
Implementazione delle Associazioni: Esempio

Compagnia Assicurazioni 1
compagnia
0..*
contratto
Contratto
public class Compagnia_Assicurazioni { private Vector contratti; /* In alternativa si pu usare un array: Contratto[] contratti */ /* Metodi */ ... } public class Contratto { private Compagnia_Assicurazioni compagnia; /* Metodi */ ... }
Attributi delle associazioni (Association Class)

In molti casi alcune propriet sono proprie dell'associazione piuttosto che delle classi coinvolte.
1..* 1..*
Studente
Corso
Frequenza
anno_accademico profitto
Questa la notazione per indicare che una associazione possiede alcuni attributi
Non si tratta di attributi dello studente perch cambiano da corso a corso. N sono attributi del corso (ad es. ogni corso frequentato da studenti diversi in anni diversi)
Attributi delle associazioni: consiglio

Se l'associazione 1-a-molti gli attributi dell'associazione si possono modellare come attributi della classe.
Azienda Datore di lavoro 1..1
Impiegato Persona 1..*
Modello consigliato
Lavoro Salario Incarico
Azienda Datore di lavoro 1..1
Persona Impiegato Salario 1..* Incarico
Modello sconsigliato
- 27 -
Attributi delle associazioni n-arie
Anno
*
Squadra
Stagione
*
Squadra
*
Portiere
Giocatore
Ruolino
Goal fatti Goal subiti Vinte Perse Pari
La notazione rimane la stessa delle associazioni binarie
- 28 -
Associazioni esclusive
Talvolta unassociazione pu esistere verso una classe o verso unaltra (non verso entrambe)
Persona Partita IVA {xor} Azienda
- 29 -
Il qualificatore
E` un attributo dellassociazione
per associazioni uno a molti e molti a molti distingue un oggetto tra i molti pu abbassare la molteplicit
Show
Nome
Ticket
1 0..*
Senza qualificatore
Rappresentazione Data : Date Posto: SeatNumber
qualificatore
Show Con qualificatore

Nome Data : Date Posto: SeatNumber 1
Ticket 0..1
Attributi del qualificatore

Molteplicit con qualificatore

Il qualificatore: significato
E un attributo il cui valore consente di selezionare un singolo oggetto tra tutte le istanze di oggetti interessati dalla stessa associazione
Azienda 0..* Lavora_per Incarico 1..*
Persona
Senza qualificatore
In questo esempio il qualificatore non ha l'effetto di abbassare la molteplicit

Azienda Persona
Incarico
0..*
Con qualificatore
1..*
Diagrammi delle Istanze (Object Diagram)

Descrivono singole istanze di classi (oggetti) e associazioni (links) rappresentate in un particolare class diagram Adatti a descrivere esempi o situazioni specifiche (punti di vista o fotografie delle istanze esistenti in un certo istante di tempo)
- 32 -
Link e Object Diagram

Un legame (link) una connessione fisica o concettuale fra due istanze. Mentre un'associazione connette due classi, un link connette due oggetti. I link sono istanze delle associazioni.
ricopre carica in cittadino_di
C.A.Ciampi: Persona Dario Fo: Persona
Italia: Repubblica
cittadino_di
- 33 -
Object diagram: Esempio

S2 S1 P4 P1 P2 P3 P5 S3
Linea
Nome: string 0..*
IdentificataDa > < AppartieneA 2 Nome: string
Punto
Situazione da descrivere
S1: Linea P1: Punto P2: Punto S2: Linea P3: Punto S3: Linea P4: Punto Diagramma degli oggetti
P5: Punto
Aggregazione
E un caso particolare di associazione molto comune che significa: un insieme di".
Il rombo vuoto si legge " un insieme di" 1..* Essendo un tipo particolare di associazione sempre possibile specificare la cardinalit
Poligono
Punto
Modello equivalente che usa una associazione convenzionale:

InsiemeDi
1..*
Punto
Poligono
- 35 -
Composizione
E un caso particolare di aggregazione che significa: composto da". i componenti non possono esistere senza il contenitore la propriet da parte del contenente esclusiva la molteplicit dal lato dellaggregato deve essere <=1
Pu essere qualsiasi per gli elementi componenti
Window 1 1 scrollbar 2 Slider

1 body 1 close 1 1 Panel Button

Aggregazione e Composizione
Per evitare di riempire il diagramma di linee di aggregazione possibile usare un "albero
PC
1..* Monitor UnitBase
0..1 Mouse Tastiera
1..4 HardDisk
1..2 FloppyDisk
1..4 ModuloRAM
1..2 CPU
0..1 Coprocessore
- 37 -
Relazioni di aggregazione: Semantica

Dipendenza delle parti dalloggetto composito
dipendente
indipendente
0..1
esclusiva
Propriet
condivisa
1..*
+ semantica di propagazione delle operazioni definita dallutente (necessaria)
Varianti
1
propagazione
esclusiva, dipendente, ma assenza di delle operazioni

Composizioni vs. Associazioni

L'aggregazione un caso particolare di associazione. Come distinguerle?
Contenimento fisico vs. semplice riferimento
Le parti sono fisicamente contenute nelloggetto composito Lassociazione comporta il semplice mantenimento di riferimenti tra oggetti
Ciclo di vita
Loggetto composito deve gestire la creazione e la distruzione delle parti Non c dipendenza esistenziale tra le parti nellassociazione
- 39 -
Associazioni riflessive
Una associazione o aggregazione si dice riflessiva ( o ricorsiva) se coinvolge oggetti della stessa classe una associazione ricorsiva indica che pi oggetti della stessa classe interagiscono e collaborano in qualche modo
Corso 0..* precedenza 0..*
Programma
1..* 0..* Blocco
- 40 -
Generalizzazione ed ereditariet
Generalizzazione = relazione "is-a"
Ogni istanza di una classe anche istanza di tutte le superclassi La relazione di generalizzazione pu essere utilizzata anche fra altri elementi del linguaggio UML (packages, use cases, etc.)
Ereditariet
Meccanismo attraverso il quale elementi specializzati incorporano la struttura ed il comportamento di elementi pi generali
- 41 -
Generalizzazione: Esempi (1)

Amico {simmetrica} 0..* Persona Data Nascita 0..*
Persona una generalizzazione di Uomo e di Donna Attributi, operazioni e associazioni vengono ereditati dalle sottoclassi generalizzazione
Donna Numero Gravidanze
Uomo Posizione Militare
Uomo e Donna sono sottoclassi di Persona

Esempio di Object Diagram
amico Giorgio Neri : Uomo
amico Rosa Verdi : Donna

- 42 -
Eugenio Rossi : Uomo
Generalizzazione ed ereditariet: Esempi (2)

Persona - String nome - String indirizzo + Persona(String nome, String ind) + stampa() + String nome() + String indirizzo()
la classe Studente eredita dal padre:

Un oggetto Studente pu essere trattato esattamente come un oggetto Persona
attributi metodi
Studente - int matricola - String esami[ ] - int voti[ ] + Studente(String nome, String ind, int mat) + aggiungiEsame(String nome, int voto) + int mediaVoti()
In cosa solitamente pu differenziarsi la classe erede

aggiunta di attributi e metodi i metodi possono essere ridefiniti
- 43 -
Generalizzazione: Esempi (3)

Poligono
+ Colore colore + sposta(float dx, float dy) + ruota(Punto centro, float angolo) + disegna(Schermo s)
Rettangolo
+ float diagonale()
Triangolo
VeicoloCommerciale
+ int pesoCarico + int pesoVuoto + boolean articolato
Autoveicolo
+ String targa + String modello + stampaLibretto()
VeicoloPrivato
+ int numeroPorte + int numeroPosti
- 44 -
Classi astratte
Una classe astratta una classe che non pu essere direttamente istanziata Pu (anzi deve) avere delle sottoclassi concrete e queste possono essere istanziate (se non sono astratte a loro volta)
Figura {abstract}
Classi astratte
Poligono {abstract} Cerchio
Notazione alternativa: nome della classe in corsivo
Classi concrete
Triangolo
Quadrato
Classi astratte (2)

Il termine astratto viene anche utilizzato per per descrivere una operazione per la quale non stata definita una implementazione
Le operazioni astratte di una classe si rappresentano scrivendo il nome in corsivo
Una classe astratta pu avere operazioni concrete

Almeno una operazione deve essere astratta
Tipicamente vengono usate

per mettere a fattor comune un'astrazione di un certo tipo per favorire il riuso
- 46 -
Classi astratte: Esempio
Figura +figuraPart #Position : Pos * +draw()
Gruppo_Figure 1
Poligono
Linea
* +lineaPart 1
Esempio (Implementazione)
public abstract class Figura { public abstract void draw(); protected Pos position; } public class Gruppo_Figure extends Figura { /* Una specializzazione di Vector contenente solo istanze di Figura */ public FiguraVector figuraPart; public void draw() { for(int i=0; i< figuraPart.size(), i++) figuraPart.get(i).draw(); } }
public class Poligono extends Figura { public LineaVector lineaPart; public void draw() { for(int i=0; i< figuraPart.size(), i++) lineaPart.get(i).draw(); }; }
- 48 -
Associazioni e attributi derivati

Alcune associazioni e alcuni attributi sono in realt una semplice rielaborazione di altri valori e/o legami
Persona Data Nascita : Date / Et : int
{Et = Data Corrente - Data Nascita}
Le associazioni i cui legami sono calcolabili in base ad altri legami o ai valori degli attributi sono identificati da una barra trasversale
Azienda /impiega
Gli attributi i cui valori sono calcolati in base agli altri sono identificati da una barra ( / )
1 1..* Divisione 1
- 49 -
lavora_per 1..*
Persona
Vincoli come restrizioni

Si possono porre vincoli e restrizioni sui legami e sul valore degli attributi scrivendoli tra graffe a margine della classe o dellassociazione
Campo di ammissibilit Intervallo {Non sovrapposti} Inizio : int 1..* Fine : int
Vincolo sugli attributi Vincolo sui legami {Inizio < Fine}
Impiegato Stipendio
Capo
Questo vincolo pi che sui valori un vincolo sulla evoluzione dei valori nel tempo
Ordine Priorit
{la Priorit pu solo crescere}
{Stipendio < Capo.Stipendio}

Vincoli interni sulle associazioni

In generale le associazioni "a molti" considerano gli oggetti legati ad uno come se fossero un insieme non ordinato. I vincoli permettono di fissare un certo tipo di ordinamento.
0..* Poligono HaPerVertice 3..* Punto
{in ordine ciclico}
La sequenza dei vertici lungo il perimetro

Persona Ha 1..* {in ordine} Esperienza
La sequenza cronologica nel curriculum

Vincoli relativi sulle associazioni

Le associazioni possono avere vincoli che condizionano una associazione rispetto ad unaltra.
ABordoDi 0..5 Persona 0..1 AllaGuidaDi {sottoinsieme} 0..1 Auto
Una freccia puntinata collega le associazioni soggette al vincolo e una etichetta fra parentesi graffe indica quale sia il vincolo
Vincoli relativi sulle associazioni
dipendente 0..* Persona capo 0..1
impiegato 1..*
datore di lavoro 0..1
0..1 Azienda
Persona.datore_di_lavoro = Persona.capo.datore_di_lavoro
- 53 -
Interfaccia
Linterfaccia descrive il comportamento esterno di una classe. applicabile anche ad altri elementi, oltre le classi. Evidenzia ci che viene fornito dalla classe. Pu servire a indicare linsieme minimo di servizi richiesti da una classe dipendente.
Hashable String ... IsEqual(String):Boolean Hash():Integer 0..* HashTable
Comparable <<interface>> Comparable IsEqual(String):Boolean Hash():Integer

- 54 -
<<use>>
Realization Relationship
Interfaccia: Notazioni alternative
Stereotipi
Rappresentano uno dei meccanismi attraverso i quali possibile estendere la notazione UML Vengono utilizzati per specializzare la semantica di elementi predefiniti in UML ( classi, associazioni, etc.) uno stereotipo rappresenta una sottoclasse di un elemento esistente (classe, associazione, package, use case ) ed individua un particolare uso per lelemento un elemento stereotipato pu essere utilizzato in tutte le situazioni in cui pu essere usato lelemento originale Uno stereotipo pu essere descritto in modo testuale (<<StereotypeName>>) o grafico
- 55 -
Stereotipi: Esempi
Alcuni stereotipi standard per le classi
<<entity>>
EntityClass
Entity
Classe passiva: le sue istanze non sono mai iniziatori di interazioni.
<<control>>
ControlClass
Control
Classe le cui istanze controllano le interazioni fra collezioni di altri oggetti.
<<boundary>>
BoundaryClass
Boundary
Classe posta alla periferia del sistema (comunque allinterno del sistema). Svolge il ruolo di Intermediario tra gli attori e le altre parti del sistema
Dipendenza
Relazione che indica una dipendenza di varia natura tra elementi di un modello UML
Si pu avere dipendenza tra classi, packages, use cases, etc.
Individua una connessione semantica tra due elementi, uno dei quali dipendente dallaltro
Una modifica nellelemento indipendente ha effetti su quello dipendente
- 57 -
Dipendenza tra classi

Esempi di dipendenza tra classi C1 e C2:
Un metodo di C1 ha come parametro un oggetto di classe C2 Un metodo di C1 restituisce come risultato un oggetto di classe C2 Un metodo di C1 istanzia un oggetto di classe C2 Un metodo di C1 invia un messaggio ad un oggetto di classe C2 di cui possiede il riferimento
- 58 -
Dipendenza: Esempio
Classe D Classe A Classe B <<instantiates>> <<calls>> operationZ()
Classe C
- 59 -
Esempi di relazioni di dipendenza tra classi

Alcune relazioni di dipendenza (tra classi) esplicitamente citate nella specifica UML: <<instantiates>>
Un metodo di una classe crea istanze di unaltra classe
<<calls>>
Indica che un metodo di una classe chiama un metodo di unaltra classe
<<friend>>
Indica la possibilit di accesso al contenuto di unaltra classe indipendentemente dalla visibilit prevista dalla classe target
<<usage>>
Indica che un elemento richiede la presenza di un altro per il suo corretto funzionamento (comprende <<calls>>, <<instantiates>>)
- 60 -
Costrutti di raggruppamento
Modulo: raggruppa classi, associazioni e generalizzazioni
fornisce una vista del problema diminuisce la complessit del problema
La suddivisione in moduli pu essere fatta in diversi modi.

Criterio: forte coesione, scarse connessioni
- 61 -
Packages
Forniscono un costrutto di raggruppamento per gli elementi definiti in un modello UML A volte si utilizza il termine subsystem per indicare un package E possibile definire delle relazioni (tipicamente di dipendenza, raffinamento, generalizzazione) tra packages diversi
A
A B A1 A2 B1
- 62 -
Dipendenze tra Packages

Descrivono, ad un livello di astrazione pi alto, dipendenze esistenti tra elementi contenuti nei singoli packages
dipendenze multiple dello stesso tipo tra singoli elementi (ad es. Classi) appartenenti a packages diversi vengono riassunte in una singola dipendenza tra i packages contenenti i diversi elementi
Tipologie di relazioni tra packages

Generalizzazione
Esiste almeno una relazione di generalizzazione tra elementi appartenenti a package diversi
Dipendenza
Esiste almeno una relazione di dipendenza tra elementi appartenenti a package diversi
Dipendenze tra Packages (2)

In generale, se non si esplicita una relazione di dipendenza, un package non pu accedere agli elementi contenuti in un altro package
Le relazioni di dipendenza definiscono delle permission per laccesso al contenuto di altri packages (limitatamente agli elementi con visibilit public o protected presenti nel package target)
Le relazioni di dipendenza tra packages non sono transitive

Se il package A pu vedere B e B pu vedere C, non detto che A possa vedere C
- 64 -
<<import>> e <<access>>
Dipendenza con stereotipo <<access>> Gli elementi contenuti nel package target possono essere referenziati dagli elementi contenuti nel package client (o dai sub-package in esso contenuti) Una dipendenza di tipo <<access>> non modifica il namespace del client e non crea riferimenti di alcun tipo
Garantisce solo la possibilit di creare refrences
Dipendenza con stereotipo <<import>> I nomi degli elementi presenti nel namespace del package target vengono aggiunti al namespace del package client (con le stesse regole di visibilit valide per <<access>>) Se ci sono conflitti fra i nomi importati e nomi gi presenti nel namespace del client, il modello mal formato (ill formed)
Dipendenze tra packages: Esempio
- 66 -
Indice
Interaction diagram e comportamento dinamico del sistema Sono diagrammi che descrivono come gruppi di oggetti collaborano nel mostrare un certo comportamento. Tipicamente rappresentano il comportamento di uno specifico use case
in termini di specifici oggetti e messaggi scambiati
Ci sono due tipi di interaction diagram:

Sequence diagram Collaboration diagram
- 68 -
Sequence diagram
Mostra una interazione tra oggetti come sequenza temporale di azioni.
oggetti partecipanti sequenze (temporali) di messaggi scambiati non si vedono le associazioni tra oggetti
La forma generica mostra tutte le possibili sequenze La forma distanza mostra solo una sequenza specifica (consistente con quella generica)
- 69 -
Sequence diagram
In ascissa sono disposti vari oggetti (istanze specifiche) Lordinata rappresenta il tempo
in genere la scala non importa
interessa solo la sequenza cio il rapporto di precedenza tra eventi, non la loro distanza.
ma per sistemi real-time si pu usare.
- 70 -
Sequence diagram: notazione

Oggetti
Obj1 Obj2 Obj3
Messaggi Istanti di tempo Vincolo temporale Commento Tempo

a b {b-a < 1 sec.}
This call is routed through the network do_this() do_that()
c c
Messaggio che impiega un certo tempo per essere ricevuto

Esempio 1
Caller Exchange Receiver
{b-a < 1 sec.} {c-b < 10 sec.}
a b c
lift receiver dial tone dial digit
...
This call is routed d through the network route
d {d-d < 5 sec.}

At this point the parties can talk
ringing tone
phone rings answer phone
stop tone
stop ringing
- 72 -
Esempio 2: testo
The physician powers up the ECG machine. The physician sets up for four waveforms at 25 mm/sec sweep speed. The physician sets the bradycardia alarm at 40 bpm and the tachycardia alarm at 110 bpm. The patient undergoes an asystole event. The system detects the asystole and raises the alarm. The physician provides therapy to correct the problem (external to the system boundary). The system detects the restarted heart rate to be 45 bpm and lowers the alarm. ...
Esempio 2: sequence diagram
physician
waveform controller
heart rate parameter
alarm manager
alarm display
patient
physician sets up use 4 waveforms for patient monitoring setsweep

speed(25) set bradycardia alarm set tachycardia alarm
Rate=50 Rate=47
asystole event physicians intervention
Rate=0 raise bradycardia alarm alarm text Rate=45 lower bradycardia alarm
clear alarm
- 74 -
Notazione estesa: terminologia

Oggetto preesistente
Agente
Oggetto creato da op()
lifeline delloggetto Oggetto creato da foo(x)

Obj2:C2
Obj3:C3 op() Obj1:C1

[x>=0] foo(x) [x<0] bar(x) doit(w)
condizione, equivale a if (x>=0) { Obj2=new(C2); Obj2.foo(x); } else Obj3.bar(x);

Processi concorrenti e attivazioni

Obj3:C3 Obj1:C1
[x>=0] foo(x) [x<0] bar(x)
Obj4:C4
op()
Obj2:C2
doit(z) doit(w)
more()
- 76 -
Notazione estesa: terminologia
Attivazioni Messaggi return

Obj2:C2
doit(z) doit(w)
Obj4:C4
Confluenza delle due possibili evoluzioni Attivazione ricorsiva

more()
Distruzione delloggetto
Oggetto che prosegue la sua esistenza dopo queste interazioni
Messaggi sincroni e asincroni

I messaggi possono essere sincroni (equivalenti a una chiamata di procedura) asincroni (equivalenti a qualche forma di comunicazione tra processi) in pratica indicano che chi invia il messaggio continua ad evolvere, senza aspettare la conclusione delloperazione lanciata. Notazione: comunicazione sincrona comunicazione asincrona
- 78 -
Collaboration diagram
Collaboration: interazione tra parti di un sistema per un certo scopo
si isolano parti di sistema e si trascurano le interazioni non essenziali allo scopo
Linterazione descritta in rapporto agli oggetti e alle relazioni che li legano. Non c una dimensione precisa per il tempo
le sequenze temporali sono descrivibili numerando i messaggi in modo progressivo
- 79 -
Esempio di interazione
oggetto messaggio
: OrderEntryWindow
auto-delega
1: prepare() : Order
ordine nella sequenza di messaggi
5: NeedToReorder()
2*: prepare() LineaTrenini : OrderLine
3: check() 4: [check() == true] remove() MagazzinoTrenini : Stock
6: new 7: [check() == true] new
: DeliveryItem
: ReorderItem
- 80 -
Esempio con numerazione decimale

Questo tipo di numerazione indica chiaramente quale operazione chiama quale altra
: OrderEntryWindow
1: prepare() : Order
Ad esempio,Order::prepare() chiama check, remove e new(), remove a sua volta chiama NeedToReorder e new.
1.1.2.1: NeedToReorder()
1.1*: prepare() LineaTrenini : OrderLine
1.1.1: check() MagazzinoTrenini : Stock
1.1.2: [check() == true] remove()
1.1.2.2: new 1.1.3: [check() == true] new
: DeliveryItem
: ReorderItem
Oggetti attivi
{local} job CurrentJob
Sono oggetti che possiedono un proprio thread.
: TransferJob
job
: FactoryScheduler
1: start(job) A2,B2 / 2: completed(job)
: FactoryManager
: Factory JobManager
1/B1: start(job) B2: completed(job) A2: completed(job) 1/A1: start(job)
: Robot
: Oven
Sequence e collaboration diagram: confronto

I Sequence Diagram
mettono pi enfasi sulla sequenza temporale delle operazioni indicano esplicitamente la vita degli oggetti
I collaboration diagram
indicano la connessione tra oggetti NB: non proprio statica: ad es. tra Stock e ReorderItem la relazione si crea perch Stock crea una nuova istanza di ReorderItem.
- 83 -
Indice
State diagram
Rappresentano il comportamento di una classe di oggetti, descrivendone i possibili stati e la reazione ad eventi esterni, in termini di cambiamenti di stato e/o azioni svolte. I diagrammi di stato danno un'astrazione di stati, eventi e transizioni Gli stati dei diversi oggetti evolvono concettualmente in parallelo (sincronizzati dagli eventi comuni).
- 85 -
State diagram
Similitudini
Automi a Stati Finiti
Il modello dinamico una estensione degli automi a stati finiti. Unifica il modello "output nelle transizioni" e "output negli stati (macchine di Moore e di Mealy). Introduce una nidificazione negli stati.
Reti di Petri
Permette di modellare la concorrenza. Permette di modellare gli scambi di eventi fra molti automi concorrenti.
Terminologia (e concetti) da D. Harel (Statecharts)

Concetti fondamentali: stati

E' l'insieme dei valori degli attributi e dei link posseduti da un oggetto in un certo istante Ci interessa lo stato astratto
esempio: motore acceso/spento (non ci interessa il numero di giri/min.) pu corrispondere a diverse - anche infinite combinazioni di valori degli attributi
Lo stato influenza il comportamento

L'oggetto reagisce in modo qualitativamente diverso agli eventi esterni, in funzione dello stato in cui si trova. Esempio: risultato pop dipende dallo stato della pila (vuota o no)
Concetti fondamentali: stati

Il comportamento quantitativo influenzato dal valore degli attributi, dei link e dei parametri delle operazioni Uno stato perdura nel tempo
finch un evento non fa cambiare stato alloggetto (es. un versamento fa passare un conto corrente da saldo negativo a saldo positivo)
- 88 -
Concetti fondamentali: eventi

Evento = stimolo esterno
E' istantaneo
il tempo un attributo implicito
Se due eventi sono legati da relazione causa/effetto sono ordinati nel tempo. Pu causare nell'oggetto destinatario un cambio di valore, di stato o la produzione di ulteriori eventi. Si intende che un evento ha una individualit ben definita
raggruppabili in classi di eventi (con attributi caratterizzanti)
La risposta ad uno stimolo dipende dallo stato, e pu implicare una transizione di stato
esempio del versamento su CC
Esempi
Classe di eventi Attributi della classe di eventi
ParteVoloAereo(Compagnia, ParteVoloAereo(Compagnia,NumeroVolo, NumeroVolo,Citt) Citt) MouseButtonDown(Posizione, MouseButtonDown(Posizione,StatoBottoni) StatoBottoni)

Classi di eventi e relativi attributi Classe dell'evento Valori dell'evento
ParteVoloAereo(Alitalia, ParteVoloAereo(Alitalia,AZ521, AZ521,Milano) Milano) MouseButtonDown(<124,234>, 0xFF) MouseButtonDown(<124,234>, 0xFF) ParteVoloAereo(Quantas, ParteVoloAereo(Quantas,Q1245, Q1245,Sydney) Sydney) ParteVoloAereo(TWA, ParteVoloAereo(TWA,TW874, TW874,Roma) Roma) MouseButtonDown(<078,230>, MouseButtonDown(<078,230>,0xA0) 0xA0) ParteVoloAereo(Alitalia, ParteVoloAereo(Alitalia,AZ520, AZ520,Roma) Roma) MouseButtonDown(<120,007>, 0x0F) MouseButtonDown(<120,007>, 0x0F)
Eventi e relativi valori
Generalizzazione degli eventi

Gli eventi sono organizzabili in una gerarchia di signal generalizzazione, lungo la IOevent quale gli attributi vengono time ereditati La gerarchia consente di rappresentare diversi livelli signal di astrazione user input ad esempio, alcuni stati device trattano tutti gli user input allo stesso modo, altri fanno differenza tra signal signal input da tastiera o da keyboard character mouse click mouse. character location
Identificare gli stati

Per ciascun oggetto occorre identificare tutti gli stati in cui pu trovarsi Suggerimenti
Trascurare gli attributi ininfluenti
Alcuni attributi non modificano in modo qualitativo il comportamento di un oggetto, ma al pi i valori degli eventi che l'oggetto produce. Individuare le condizioni limite Trovare tutti i confini e i limiti dello stato
Definire un corretto livello di astrazione

Granularit di stati ed eventi
Per un sistema di prenotazione la partenza di un aereo un evento, ma per il software di controllo dell'aereo sono centinaia di eventi distinti.
- 92 -
Descrizione degli stati

Si pu usare un linguaggio strutturato semi-formale per documentare gli stati
Stato: Stato:LaSvegliaStaSquillando LaSvegliaStaSquillando Descrizione: Descrizione:ililcicalino cicalinotrilla trillauna unavolta voltaal alsecondo secondoper perindicare indicareche chestato statoreggiunto reggiunto l'orario impostato. l'orario impostato. Sequeza di Sequeza dieventi eventiche chedetermina determinalo lostato: stato: ImpostaSveglia(<tempo>) ImpostaSveglia(<tempo>) Qualunque Qualunquesequenza sequenzadi dieventi eventiescuso escusoDisabilitaSveglia DisabilitaSveglia TempoCorrente TempoCorrente= =OrarioSveglia OrarioSveglia Condizioni che caratterizzano Condizioni che caratterizzanolo lostato stato Allarme = on, OrarioSveglia Allarme = on, OrarioSveglia< <TempoCorrente TempoCorrente< <OrarioSveglia+20", OrarioSveglia+20", nessun bottone premuto da OrarioSveglia in poi nessun bottone premuto da OrarioSveglia in poi Eventi Eventiaccetati accetatinello nellostato stato Evento Azione Stato Evento Azione Statoseguente seguente TempoCorrente = OrarioSveglia+20" ResetSveglia normale TempoCorrente = OrarioSveglia+20" ResetSveglia normale Bottone(<qualunque>) ResetSveglia normale Bottone(<qualunque>) ResetSveglia normale
- 93 -
Lo scenario
Uno scenario una sequenza di eventi occorsi durante una specifica esecuzione del sistema. D unidea dellordine degli eventi talune coppie indicano un ordinamento necessario, altre un ordine casuale
IlIlchiamante chiamantealza alzala lacornetta cornetta Inizia Iniziaililtono tonopronto pronto IlIlchiamante chiamantecompone componeuno uno Smette Smetteililtono tonopronto pronto IlIlchiamante chiamantecompone componequattro quattro IlIlchiamante compone quattro chiamante compone quattro IlIlchiamante chiamantecompone componeuno uno IlIlchiamante chiamantecompone componeuno uno ... ... IlIltelefono telefonochiamato chiamatoinizia iniziaa asquillare squillare Inizia il tono di libero Inizia il tono di libero IlIltelefono telefonochiamato chiamatoviene vienesganciato sganciato IlIltelefono telefonochiamato chiamatosmette smettedi disquillare squillare Smette Smetteililtono tonodi dilibero libero ... ...
- 94 -
Il tracciato degli eventi

E' il sequence diagram che lega oggetti ed eventi di uno scenario
Chiamante Linea Ricevente
Sgancia InizioTonoPronto Compone(1) FineTonoPronto Compone(4) Compone(4) Compone(1) Compone(1) InizioTonoLibero
Lo stesso oggetto pu inviare pi eventi consecutivi senza ricevere eventi in mezzo
InizioSquilli
Sgancia FineTonoLibero FineSquil AperturaConnessione AperturaConnessione li Aggancia ChiusuraConnessione ChiusuraConnessione Aggancia

- 95 -
Lo stesso oggetto pu inviare pi eventi simultanei
Ricavare il diagramma degli stati

Una collezione sufficientemente ricca di sequence diagram descrive tutte le possibili evoluzioni delloggetto considerato
il fatto di poterle descrivere tutte deriva dalla capacit di astrazione
Ad esempio, in uno scenario il chiamante riaggancia per primo, in un altro scenario il ricevente riaggancia: occorre rappresentare la reazione delloggetto ad entrambi questi eventi.
- 96 -
Diagramma degli stati
Chiamante.Aggancia
Inattivo
Chiamante.Aggancia
Chiamante.Sgancia T Tono Tono Pronto TimeOut Compone(n) Compone(n) Compos. Numero Tono Occupato Occupato T
NumNonValido Messaggio Vocale
NumValido ProntoA Connettere Instradato Tono Libero FineMessaggio
Connesso
Ricevente.Sgancia
- 97 -
Stati iniziali e finali

Alcuni oggetti hanno diagrammi degli stati ciclici, altri possono avere stati iniziali e/o finali.
Inizio
AlBianco Muovere Mossa Bianca Mossa Nera
Matto or Abbandono Stallo or Accordo Stallo or Accordo Matto or Abbandono
VinceIlNero
Patta
AlNero Muovere
VinceIlBianco
- 98 -
Condizioni
Sono funzioni booleane sui valori degli oggetti. Sono valide in un intervallo di tempo Sono utili come guardie delle transizioni di stato (non basta l'evento, deve essere verificata la condizione).
Evento
Condizione
Pronto
Verde [incrocio.stato=libero]
InCorsa
- 99 -
Operazioni
Durante la loro vita gli oggetti eseguono operazioni.
associate allo stato o alle transizioni
Le attivit hanno una durata

continue sequenziali
Le azioni sono istantanee
- 100 -
Operazioni
Azioni Sono operazioni che hanno durata istantanea (rispetto alla granularit del tempo). Tipicamente produzione di eventi. Sono associate alle transizioni di stato oppure all'ingresso o all'uscita da uno stato. Attivit Sono operazioni con durata significativa. Sono associate ad uno stato
Continue o sequenziali
Transizioni automatiche Se uno stato ha una attivit associata e una freccia senza eventi esce da questo, la freccia indica la transizione svolta automaticamente al completamento della attivit.
- 101 -
Notazione generale
StatoA In caso di ricezione dell'evento1 nello stato A viene eseguito azione3 senza cambio di stato (e quindi senza azioni di entry ed exit)
attributo1: tipo1 = val.iniziale attributo2: tipo2 = val.iniziale do: attivit1 entry / azione1 exit / azione2 event1 / azione3 event2 / azione4
Transizione causata dall'evento evento3 sotto condizione condizione1. Vengono eseguite azione2 e azione5
event3 [condizione1] / azione5
event4 [condizione2] / azione6
Transizione automatica (evento scatenante fine della attivit1)

Pseudo transizione causata dall'evento evento4 nell'ordine vengono eseguiti: azione2, azione6, azione1
Azioni consistenti nell'invio di eventi

Molto spesso le azioni consistono nell'inviare un evento ad un altro oggetto.
esempio: transazione tra stati di un oggetto Window
right-mouse-down(location) [location in window] / object:=pick-object(location); send object.highlight()
No object selected
One object selected
invio di messaggio a object (send opzionale)
- 103 -
Invio di eventi
Gli eventi possono avere attributi Il destinatario pu essere unico o un intero set di oggetti. Tutti gli oggetti riceventi che riconoscono l'evento possono accettarlo e reagire in parallelo. Attenzione alle corse critiche
- 104 -
Invio di eventi: notazione grafica
Il segnale accende o spegne Il VCR a seconda dello stato corrente power button /send VCR.togglePower
power button /send television.togglePower
- 105 -
Problemi dei diagrammi a stati piatti

Diventano poco espressivi e troppo ingarbugliati al crescere delle dimensioni del problema.
Ad esempio, il numero di collegamenti possibili tra stati quadratico nel numero di stati.
Soluzione: diagrammi strutturati

la strutturazione favorisce la descrizione sintetica di sistemi complessi
L'attivit corrispondente ad uno stato pu essere espansa in un diagramma a stati di pi basso livello, dove ogni stato rappresenta una fase dell'attivit. Generalizzazione (specializzazione delle attivit, gerarchie di ereditariet, ...)
Aggregazione (stati concorrenti)

Diagrammi a stati strutturati

Uno stato strutturato equivale ad una scomposizione OR degli stati: l'oggetto si trova, all'interno di uno stato pi generale, in un qualunque sotto-stato. I sottostati ereditano le transizioni dei loro superstati (a meno di overriding)
levaR
Folle Questa transizione, risposta all'evento ferma, viene ereditata da tutti i sottostati di MarciaAvanti Cambio Automatico
levaF levaN levaN
RetroMarcia
MarciaAvanti
ferma accelera accelera
Prima
decelera
Seconda
decelera
Terza
- 107 -
Diagramma di stato: esempio (1)
- 108 -
Diagramma di stato: esempio (2)
Login Read name entry: name prompt Name read Read password entry: password prompt Password read Verification Incorrect name or password
Name and password OK
Connection
- 109 -
Aggregazione e concorrenza
Un modello descrive un insieme di oggetti concorrenti, ciascuno col suo stato e col suo diagramma a stati. Lo stato dell'intero sistema dato dal complesso degli stati degli oggetti componenti (il cui numero pu anche cambiare dinamicamente). Il diagrammi a stati di un oggetto complesso l'aggregazione dei diagrammi di ciascun componente. L'aggregazione la "and-relationship": lo stato complessivo (aggregato) dato dallunione degli stati dei vari diagrammi.
Concorrenza in oggetti compositi

Oggetti diversi hanno dinamica intrinsecamente concorrente si ha concorrenza anche in un oggetto composto.
Serbatoio Accendino Fornello
Vuoto carica Pieno Serbatoio [gas > 0] [gas = 0]
Fornello Chiuso apri Aperto chiudi Acceso
scintilla
- 111 -
Aggregazione e concorrenza
Interazioni tra oggetti
Gli stati dei componenti possono interagire (la guardia che regola le transizioni di un oggetto dipende dallo stato di un altro oggetto).
Vuoto carica Pieno Serbatoio [gas > 0] [gas = 0]
Fornello Chiuso apri scintilla Aperto chiudi
Acceso [Serbatoio.stato == Pieno]
- 112 -
Sottostati concorrenti
- 113 -
Concorrenza di due attivit
Distratto Naturalmente Attento do: appunti noia do: sbadiglia richiamo Forzatamente Attento do: ghirigori
do: gratta
richiamo
Transazione complessa
Sincronizzazione
Suggerimenti
Rappresentare solo classi con dinamica significativa Usare "scenari" e "tracce degli eventi" Solo attributi ed eventi rilevanti Livello di astrazione adeguato
granularit di eventi e stati adatta allapplicazione
Distinguere tra attivit ed azioni Usare diagrammi strutturati dove appropriato Verificare la consistenza incrociata
attenzione agli eventi condivisi
Diagrammi delle sottoclassi indipendenti da quelli delle superclassi Occhio alle corse critiche
Indice
Activity Graph e Activity Diagram

Sono dei casi speciali di macchine a stati, in cui tutti gli stati (o quasi) contengono unazione o una attivit tutte le transizioni (o quasi) sono causate dal completamento delle azioni/attivit negli stati Un activity graph associato ad una classe, o all'implementazione di unoperazione, o ad uno use case. Un Activity Diagram un diagramma contenente un activity graph Lo scopo deglio activity graph di evidenziare levoluzione guidata dallelaborazione interna, in contrapposizione agli eventi esterni (meglio trattati negli state diagram).
- 117 -
Un Activity Graph
- 118 -
Swimlanes (corsie)
Indicano come sono distribuite le responsabilit delle diverse operazioni in una classe (unit organizzative) ogni corsia pu essere implementata da uno o pi oggetti
- 119 -
Relazioni di flusso azioni-oggetti

Le attivit operano attraverso e su oggetti:
un oggetto (o pi duno) ha la responsabilit dellazione altri oggetti forniscono dati per lazione o ne sono modificati
- 120 -
Relazioni di flusso azioni-oggetti

oggetti responsabili di azioni oggetto in ingresso o in uscita da unazione azioni stati degli oggetti
- 121 -
Stereotipi opzionali
Rappresentano esplicitamente linvio e la ricezione di segnali
eventi differiti
- 122 -
Indice
Implementation diagram
Component diagram
mostrano la struttura del codice
Deployment diagram
mostrano la struttura del sistema run-time
- 124 -
Componenti
- 125 -
Component diagram
Mostra le dipendenze tra componenti software
sorgenti, binari, eseguibili esistenti a compile-time, a link-time, a run-time
Gli elementi dei component diagram sono tipi di componenti

le istanze si vedono nei deployment diagram
- 126 -
Component diagram
dipendenze
- 127 -
Deployment diagram
Mostrano la configurazione a run-time degli elementi attivi a run-time (e dei componenti, processi e oggetti che vi vivono). Istanze di componenti software rappresentano le attivazioni a run-time delle unit di codice. Componenti che non esistono a run-time non appaiono in questi diagrammi.
- 128 -
Deployment diagram
Un grafo nodi = risorsa computazionale
possono contenere istanze di componenti e/o oggetti
archi = comunicazione
tipicamente indicano una relazione di utilizzo
- 129 -
Migrazione di oggetti tra nodi
- 130 -
Indice
Use Case
Descrive una particolare funzionalit fornita dal sistema (= un particolare uso) o da una sua parte dal punto di vista dellutilizzatore del sistema Mostra le entit coinvolte nella fornitura della funzionalit (attori e sistema) Uno use case rappresenta una funzione visibile dallutente (un servizio offerto dal sottosistema considerato ai suoi utilizzatori) pu avere granularit diverse rappresenta un obiettivo specifico (discreto, atomico) per lutente Nei casi pi semplici, gli use case sono identificati parlando con lutente e discutendo dellutilizzo che si intende fare del sistema.
Use Case: Elementi caratteristici

Uno Use case consente di individuare il comportamento (in termini di funzionalit offerte) di un sistema o di una qualsiasi altra entit semantica definita nel sistema senza entrare nel dettaglio della struttura interna dellentit Uno Use Case individua una tipologia di possibili utilizzi del sistema ha un titolo che descrive sinteticamente lo scopo del caso duso ha un inizio (azione che inizia linterazione tra attore e sistema) ha uno sviluppo intermedio ha una fine (individuata dalle condizioni di terminazione del caso duso) Descrizione
(spesso testuale)
- 133 -
Use Case: Elementi caratteristici (2)

Esempio: Sistema per la gestione delle vendite dei prodotti di una azienda
Si vuole descrivere la possibilit da parte del venditore di effettuare levasione di un ordine
Use-Case
Nome dello Use-Case
Acquisizione Ordine
Attore
Extension Points:
Richieste Addizionali: Dopo la creazione dellordine
Venditore
Lista di Extension Points (opzionale) Unified Modeling Language - 134 -
Confine del sistema (non sempre indicato esplicitamente)

Livello di dettaglio
Gli use case sono per loro natura scevri di dettagli
use case = panorama
I dettagli possono essere sempre aggiunti dopo. Comunque importante esplorare subito le eventuali ramificazioni. Certi dettagli possono nascondere importanti funzionalit del sistema, con rilevanti implicazioni architetturali.
- 135 -
Significato degli use case

Uno use case pu rappresentare:
Un obiettivo dellutente. Ad es. mantenere consistente laspetto di due documenti Uninterazione col sistema. Ad es. applica ad un documento lo stile di un altro
Gli use case si applicano ad entrambi i casi ugualmente bene.
- 136 -
Actor (attori)
Attore = Entit esterna al sistema che interagisce con il sistema assumendo un particolare ruolo
non c necessariamente corrispondenza tra attori e individui precisi possono esserci diversi utenti con lo stesso ruolo, e diversi ruoli possono essere ricoperti dallo stesso utente possono esserci diversi attori che esercitano lo stesso use case, e diversi use case possono essere esercitati dallo stesso attore non detto che un attore corrisponda a uno o pi persone: pu essere un sistema esterno
nonostante la rappresentazione iconografica
- 137 -
Funzione degli attori

Gli attori possono essere un mezzo per individuare gli use case. Spesso pi facile individuare una lista di attori, e quindi capire quali siano i loro obiettivi e di quali interazioni col sistema essi debbano essere protagonisti.
- 138 -
Quali attori?
Quando gli attori sono sistemi esterni, non sempre facile capire quando essi vadano considerati.
interazioni esterne iniziatori di interazioni richieste di funzionalit dallesterno utenti indiretti
Criterio guida:
gli use case devono indicare funzionalit fruibili dallesterno ( ai morsetti del sottosistema considerato)
- 139 -
Quando sono importanti gli attori?

Quando il sistema deve essere configurato diversamente secondo i ruoli che accedono alle funzionalit esterne. Per ricordare chi accede ad una determinata funzionalit Quando esistono conflitti nelle esigenze di diversi ruoli Per capire esigenze di sicurezza, riservatezza, ecc.
- 140 -
Relazione tra attori e use case

Talvolta accade che una funzione esista perch richiesta da (o interesse di) un certo attore che per non partecipa allazione stessa. Spesso lazione indotta da altre iniziative del sistema e ha come destinatario un attore fuori dal contesto operativo. Esempio: dopo due mesi dalla consegna al compratore di un bene viene notificato lordine di pagamento. destinatario: compratore esterno (ignaro del sistema SW) beneficiario: ufficio non coinvolto nellemissione dellordine causa immediata: funzione interna che verifica le scadenze
- 141 -
Relazioni tra attori e use case

Nei confronti di un certo use case, un attore pu:
esserne il beneficiario esserne coinvolto (come operatore-protagonista) esserne il controllore esserne informato ...
Ogni ruolo pu contribuire alla definizione dello use case, tuttavia la cosa fondamentale individuare lo use case e capirne il significato essenziale.
- 142 -
Relazioni tra attori e use case

Associazione: Identifica la partecipazione di un attore ad uno Use Case Immissione Ordine
Venditore
Generalizzazione: Il supervisore pu partecipare a tutti gli use cases cui partecipa il Venditore
Attribuzione credito
Supervisore
- 143 -
Eventi esterni e use case

Un buon modo per individuare gli use case lanalisi degli eventi esterni rilevanti per il sistema. Se un evento rilevante vuol dire che susciter qualche sorta di reazione nel sistema. Tale reazione in genere descritta attraverso uno use case. Gli utenti non sono necessariamente coinvolti nello use case.
- 144 -
Use Case Diagrams

Elencano le funzionalit esterne fornite
dallintero sistema da un generico sottosistema (ad es. un package) da una singola classe
Evidenziano le relazioni esistenti tra attori e use cases (relativamente al sottosistema considerato)
- 145 -
Use case diagram: esempio
Verifica stato ordine Cliente Venditore
Acquisizione Ordine
Attribuzione credito
Supervisore
Evasione ordine
Addetto al magazzino
- 146 -
Use Case, Use Case Instances e Scenari

Uno Use Case individua una tipologia di storie duso del sistema Una istanza dello Use Case individua una specifica storia duso
Specifica una delle possibili sequenze di azioni che possono avvenire durante lo svolgimento dello use case
Scenario: E una istanza di use case corredata da una descrizione esplicita

Il termine scenario non usato in modo sempre consistente.
Talvolta viene usato (impropriamente) come sinonimo di use case
- 147 -
Scenari
Uno scenario individua e descrive esplicitamente una particolare istanza di uno use case, ovvero una delle possibili varianti
Ad es. un ordine pu essere elaborato regolarmente, o pu mancare la merce ordinata o pu mancare il credito nei confronti dellordinante, Ciascuno di questi casi uno scenario specifico dello use case gestione ordini.
Ogni Use Case caratterizzato da uno scenario base (sequenza tipica di eventi) e da un numero, imprecisato a priori, di varianti Le varianti possono essere aggiunte nei successivi raffinamenti dello use case
Use Case e Scenari: Descrizione

Per ogni Use Case occorre realizzare un documento in cui vengono descritti gli scenari rilevanti per lo Use Case
La descrizione deve essere effettuata dal punto di vista degli Attori, dettagliando ci che il sistema deve fornire quando lo Use case viene eseguito La descrizione pu essere informale (in linguaggio naturale) o mista (descrizione testuale+ descrizione formale con altri linguaggi)
In particolare possibile utilizzare gli Interaction diagram di UML per descrivere i singoli scenari
- 149 -
Use Case e Scenari: Descrizione (2)

Contenuti tipici Descrizione della sequenza di eventi che caratterizza lo scenario base
Come lo scenario inizia e termina Descrizione dei singoli passi nello scenario
Descrizione delle sequenze di eventi relative ad eventuali scenari alternativi considerati

Ad esempio scenari che individuano situazioni eccezionali (Es. Situazioni di errore, etc.)
E opportuno corredare la descrizione di ogni scenario con Precondizioni: descrizione di ci che deve essere vero nel sistema (o nel sottosistema considerato) affinch lo scenario possa avere inizio Postcondizioni: descrizione di ci che vero nel sistema (o nel sottosistema) al termine dello svolgimento dello scenario
Realizzazioni di uno Use Case

Definiscono come gli oggetti del sistema (o sottosistema) interagiscono per fornire la funzionalit identificata dallo use case (o dal singolo scenario)
Vengono tipicamente descritte con Interaction diagram (Sequence o Collaboration Diagram)
Importante: registrare i motivi di scelta (o di rigetto) delle diverse realizzazioni.

Altrimenti si rischia di perdere memoria dei ragionamenti che hanno portato a una certa linea di sviluppo, che deve essere mantenuta per garantire coerenza al sistema.
- 151 -
Realizzazioni di uno Use Case
RealizationParticipant2
RealizationParticipant1
UseCase
(from Use Case View)
UseCase Realization
(from Use Case View)
- 152 -
Granularit degli use case

Una granularit fine facilita la pianificazione del lavoro
in modo simile ad un work breakdown structure
Tuttavia, un livello di dettaglio eccessivo pu rendere troppo complessa la descrizione, col rischio di perdere di vista il quadro complessivo e le priorit.
- 153 -
Relazioni tra Use Cases

Esistono tre tipi di relazioni possibili tra use cases: Generalizzazione
Simile alla generalizzazione tra classi
Stereotipi
Inclusione
Estensione
<<include>> Il comportamento individuato dallo use case target viene incluso nella sequenza di azioni svolta dalle istanze dello use case base Rel. Dipendenza <<extend>> Le funzionalit individuate da uno use case base vengono estese, al verificarsi di opportune condizioni, con funzionalit definite in un altro use case
Nota: E possibile definire relazioni soltanto tra use cases associati alla stessa entit semantica (intero sistema, sottosistema, package, classe)
Relazione di generalizzazione
Lo use case figlio
eredita tutti gli attributi, scenari, extension points definiti nello use case padre partecipa e tutte le relazioni in cui coinvolto lo use case padre Lo use case figlio pu prevedere nuovi scenari non previsti nello use case padre o ridefinire scenari presenti nello use case padre
Uno use case

pu ereditare da n altri use cases pu essere il padre di n altri use cases
- 155 -
Relazione <<include>>
Esistono degli use case che rappresentano attivit ricorrenti, condivise da diversi use case pi complessi. Anzich ripetere in ogni use case la descrizione dellattivit comune, la si mette a fattor comune, indicando che questa viene inclusa negli use case pi complessi. La relazione di inclusione di uno use case pu essere assimilata alla chiamata di subroutine in un linguaggio di programmazione. In UML 1.1 lo stereotipo utilizzato era <<uses>>
- 156 -
Relazione <<include>> (2)

La funzionalit individuata dallo use case target viene inclusa in un punto specifico e nella sua interezza nella sequenza di azioni che caratterizza lo use case base quando una istanza dello use case base raggiunge il punto di inclusione vengono svolte tutte le azioni previste dallo use case incluso successivamente si riprende lo svolgimento delle azioni previste nello use case base Come indicare il punto di inclusione? La specifica UML vaga in proposito (contrariamente al caso dellestensione) Intuitivamente il punto specifico di inclusione dovr essere indicato nella descrizione dei singoli scenari associati allo use case
Esempi di relazione <<include>>

La vendita di una casa o la stipula di un contratto di assicurazione implicano la valutazione dellimmobile. Diversi servizi su rete Internet condividono la realizzazione di una connessione TCP. La compilazione o il pretty printing di un file di codice implicano il parsing del documento.
- 158 -
Extension points
Vengono utilizzati nelle relazioni <<extend>> Individuano in uno use case i possibili punti in corrispondenza dei quali lo use case stesso pu essere esteso Esempio:
Acquisizione Ordine
Extension Points:
Richieste Addizionali: Dopo la creazione dellordine
- 159 -
Relazione <<extend>>
Connette uno uno use case estensione ad uno use case base e specifica in che modo e sotto quali condizioni il comportamento individuato dallo use case estensione deve essere incorporato nello use case base La relazione di estensione richiede lindicazione di una condizione che deve essere verificata affinch lestensione possa avere luogo il riferimento ad uno o pi extension points definiti nello use case che viene esteso Lo use case estensione pu essere un semplice frammento di use case (non autonomamente istanziabile) in generale consiste semplicemente in uno pi segmenti che descrivono sequenze di azioni addizionali che modificano in modo incrementale il comportamento dello use case base
ciascun segmento nello use case estensione pu essere Unified Modeling inserito Language in un punto distinto - 160 - dello use case 2000 - Software Engineering Area base
Relazione <<extend>> (2)

La relazione extend referenzia un numero extension points definiti nello use case base in quantit pari al numero dei segmenti presenti nello use case estensione Quando uno scenario associato allo use case base raggiunge uno degli extension points esplicitati nella relazione extend e la condizione per lestensione verificata, viene inglobato il comportamento previsto nel segmento interessato nello use case estensione
- 161 -
Esempi
A
Extension Points:
B
Extension Points:
<<extend>> (x)
C
<<extend>> (y)
base use case
Place Order
Customer
Extension Points:
P1: After order creation <<include>> <<include>>
<<extend>> [Order created, P1 ]
Request Catalog with Order
<<include>>
extension use case
SalesPerson Supply Customer Data Order Product Arrange Payment
Pay Cash Unified Modeling Language - 162 -
Supply Customer Data 2000 - Software Engineering Area
Indice
Alcuni strumenti CASE per UML

Nota: questi sono solo alcuni dei (molti) strumenti che supportano (o almeno affermano di supportare) lanalisi e la progettazione mediante UML. Commerciali
Rational Rose Telelogic TAU (ex COOL:Jex/Object Team) Paradigm Plus Object Domain Softeam Objecteering UML Modeler Object Technology WorkBench (OTW)
Freeware
Argo/UML
- 164 -
Rational Rose
Rose originariamente concepito per supportare la metodologia di Booch, si sta (lentamente) convertendo ad UML. non del tutto consistente con la definizione UML/OMG, tuttavia un ottimo strumento Rational Software Corporation www.rational.com produce un insieme notevolissimo di strumenti CASE Versioni demo disponibili demo 4.0 (limiti sul numero di classi, stati, use case, ecc.) demo 98 e 98i (limite temporale di utilizzo) demo 2000 (limiti temporali di utilizzo)
- 165 -
Telelogic Tau UML Suite

Telelogic Tau UML Suite (ex COOL:Jex 4.0/Object Team)
Supporto dichiarato per UML 1.3 E indicato come uno dei migliori strumenti in valutazioni indipendenti (Ovum, Hitachi)
Telelogic
http://www.telelogic.com
Evaluation Kit disponibile (previa registrazione)
- 166 -
Paradigm plus
Paradigm plus
uno dei tool pi diffusi supporta UML, OMT, Fusion, Booch, Martin/Odell, Shlaer/Mellor, Coad/Yourdon
Computer associates (ex Platinum technology)

www.platinum.com / www.cai.com
Demo disponibili
versione di valutazione utilizzabile per 30 gg.
- 167 -
Object Technology Workbench

Object Technology Workbench
Supporta UML (in modo completo), E/R Possibilit di definire ed instanziare Design Patterns
Owis Software
www.otw.de
Demo disponibili
Disponibile una Private Edition Free e non timelimited
- 168 -
Object Domain
Object Domain
nato come tool shareware si poi trasformato in un prodotto commerciale
Object Domain Systems

http://www.objectdomain.com
Versioni disponibili
disponibile la versione 3.0 (beta) anche in valutazione per 30 gg. scritta completamente in Java la versione 1.19 (shareware) ancora disponibile in valutazione per 30 gg.
- 169 -
Argo/UML
Argo/UML
Tool freeware Open Source: chiunque pu collaborare con idee, bugreports, codice ancora incompleto e instabile (tenendo conto che si tratta di una versione beta): supporta class, use case, state, activity, collaboration diagrams
Tigris
http://argouml.tigris.org/
Versioni disponibili
attualmente disponibile la versione 0.8 (beta) scritta completamente in Java
Caratteristiche degli strumenti CASE

Non completamente conformi con la specifica
Mancanza di alcuni dei diagrammi previsti dalla specifica UML Diagrammi non completamente aderenti alla specifica
Gestiscono le versioni di specifiche o progetti

attraverso lintegrazione con sistemi di configuration management
Iniziano a supportare lo sviluppo cooperativo Praticamente tutti offrono:

Code generation reverse engineering
- 171 -
Dove trovare altre informazioni

Esistono diverse collezioni di link a siti web contenenti informazioni su strumenti e prodotti vari. Ad es. www.cetus-links.org riporta una collezione estesa di riferimenti a siti sullanalisi e progettazione OO (non necessariamente UML).
- 172 -
Bibliografia: Libri
Terry Quatrani, Visual Modeling with Rational Rose and UML, Addison-Wesley Unified Modeling Language User Guide Unified Modeling Language Reference Manual H. Eriksson, M. Penker, UML Toolkit, J. Wiley M. Fowler, UML distilled, Addison-Wesley
- 173 -
URL
Rational http://www.rational.com Rational UML Resource Center http://www.rational.com/uml/index.html Object Management Group http://www.omg.org
- 174 -

UMLFuggetta

Caricato da

Informazioni sul documento

Descrizione:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Descrizione:

Copyright:

Formati disponibili

UMLFuggetta

Caricato da

Descrizione:

Copyright:

Formati disponibili

CEFRIEL

Centro per la Formazione e la Ricerca in Ingegneria dellInformazione

Principi di Ingegneria del Software

Alfonso Fuggetta Politecnico di Milano e CEFRIEL

2000 - Software Engineering Area

Unified Modeling Language

Unified Modeling Language

2000 - Software Engineering Area

Elimina le differenze (spesso inessenziali) presenti tra le notazioni precedenti Semi-formale

relazioni tra classi (associazioni, generalizzazioni, ...)

Un class diagram rappresenta uno schema concettuale

Unified Modeling Language

2000 - Software Engineering Area

Altri modelli OO (Booch, OMT)

Unified Modeling Language

2000 - Software Engineering Area

Unified Modeling Language

2000 - Software Engineering Area

Notazione generale per le classi

Esempi di Rappresentazione di Classi, Attributi e Operazioni

Unified Modeling Language

Livello di dettaglio visibile

WINDOW size: Area visibility: Bool display()

public protected private

Unified Modeling Language

2000 - Software Engineering Area

Oggetti: Notazione grafica

2000 - Software Engineering Area

Unified Modeling Language

2000 - Software Engineering Area

Nome (opzionale) dell'associazione

Nota: una associazione naturalmente bidirezionale.

Cardinalit nelle associazioni

Unified Modeling Language

2000 - Software Engineering Area

Cardinalit nelle associazioni

Situazione da descrivere Indicazione (opzionale) di molteplicit

IdentificataDa > < AppartieneA

Unified Modeling Language

2000 - Software Engineering Area

Notazione per la cardinalit

Notazione per la cardinalit(2)

Simbolo indicante la relazione n-aria (ternaria)

Unified Modeling Language

2000 - Software Engineering Area

Ruoli nelle associazioni

Il ruolo (opzionale) viene indicato in stile normale

Unified Modeling Language

2000 - Software Engineering Area

Ruolo obbligatorio nelle associazioni

0..* 0..* Directory 0..*

Qui il ruolo obbligatorio Alternativa: contiene

2000 - Software Engineering Area

Implementazione delle Associazioni: Esempio

Attributi delle associazioni (Association Class)

Unified Modeling Language

Attributi delle associazioni: consiglio

Azienda Datore di lavoro 1..1

Impiegato Persona 1..*

Azienda Datore di lavoro 1..1

Persona Impiegato Salario 1..* Incarico