UML - Roberta Gerboni

Transcript

TECN.PROG.SIST.INF. – UML
2016 - Roberta Gerboni
I linguaggi di modellazione
le entità che compongono un
sistema complesso
Linguaggio di
modellazione
permette di esprimere
le loro caratteristiche
le relazioni che le collegano.
Nell’ambito di un progetto, il linguaggio è normalmente distinto dal processo di
sviluppo:
• il linguaggio descrive cosa deve essere ottenuto;
• il processo descrive i passi da intraprendere per ottenerlo;
• insieme, linguaggio e processo definiscono un metodo di sviluppo.
E’ un vero e proprio linguaggio e non una semplice notazione grafica.
E’ descritto in linguaggio naturale e con l’uso di diagrammi, cerca di ridurre al minimo
le ambiguità.
Ha regole sintattiche e regole semantiche.
2
UML
E’ un linguaggio grafico (basato su diagrammi) per:
definire le specifiche
realizzare
documentare
un qualunque prodotto tangibile di un progetto (in genere progetti software): sorgenti,
eseguibili, documentazione, file di configurazione, tabelle di database, …
ma non fornisce indicazioni su come deve essere usato.
Può essere
utilizzato per: comprendere meglio
e descrivere le caratteristiche di un nuovo sistema o di uno già esistente.
• dall’ambito del progetto.
Ed è indipendente
• dal processo di sviluppo.
• dal linguaggio di programmazione (anche se progettato per
essere abbinato alla maggior parte dei linguaggi object-oriented)
3
UML
La prima versione del linguaggio di modellizzazione UML fu definita nel 1996 a
opera di Grady Booch, Jim Rumbaugh e Ivar Jacobson, noti come los tres
amigos.
1997 – novembre: La prima versione adottata da OMG (Object Management Group) UML 1.1
(con il nome ufficiale di “UML OMG 1.0”)
2005 – marzo: UML 2.0 diventa la versione ufficiale
2011 – agosto: UML 2.4.1 – variazioni minori
2015 – marzo: UML 2.5 – completa ristrutturazione della documentazione e variazioni minori
Tutta la documentazione ufficiale dell’UML si trova su www.omg.org .
4
OO Modeling languages history
OOSE: Object-Oriented Software Engineering
OMT : Object Modeling Technique
OOA / OOD : Object Oriented Analysis and Object Oriented Design
5
UML
I principali diagrammi previsti dalla versione attuale del linguaggio sono i seguenti:
6
UML
7
UML – i diagrammi
8
UML
9
UML a cosa può servire
10
11
UML- diagramma dei casi d’uso
• I casi d’uso furono proposti da Ivar Jacobson nel 1992-95
• Rappresentano i “modi” in cui il sistema può essere utilizzato (le funzionalità che il
sistema mette a disposizione dei suoi utilizzatori). Servono per chiarire cosa dovrà
fare il sistema e costituiscono il punto di partenza per la sua progettazione.
• È una modalità di rappresentazione delle funzionalità del sistema ad alto livello.
Un caso d’uso è una sequenza di transazioni in un sistema, il cui compito è di
conseguire un risultato di valore misurabile per un singolo attore del sistema.”
Esempio
Casi d’uso
• telefonare
• rispondere a una telefonata
• inviare un messaggio
• memorizzare un numero
• ….
Punto di vista:
UTILIZZATORE
Funzionalità interne
• trasmissione / ricezione
• alimentazione (batteria)
• I/O (display, tasti, ...)
• sw gestione rubrica
• …..
Punto di vista:
PROGETTISTA
12
I casi d’uso possono essere descritti sotto forma di scenari di interazione (un dialogo)
tra gli utilizzatori e il sistema:
Esempio:
– il cliente richiede l’elenco dei prodotti
– il sistema propone i prodotti disponibili
– il cliente sceglie i prodotti che desidera
– il sistema fornisce il costo totale dei prodotti selezionati
– il cliente conferma l’ordine
– il sistema comunica l’accettazione dell’ordine
• L’attenzione si focalizza sull’interazione, non sulle attività interne al sistema
Scenario
Ogni sequenza è detta scenario e
rappresenta l’interazione di entità
esterne al sistema (attori) con il
sistema stesso o sue componenti.
Attore
• Ruolo che una persona o un dispositivo hardware o un altro sistema gioca rispetto al
sistema
• Gli attori eseguono casi d’uso: prima si cercano gli attori, poi i loro casi d’uso
• Gli attori possono NON essere persone!
13
L’analisi dei casi d’uso viene impiegata durante la fase di analisi per modellare il
comportamento esterno del sistema da sviluppare, senza dover specificare come
tale comportamento viene realizzato.
Il sistema viene visto, al suo interno, come una scatola nera (black box).
Il comportamento del sistema è analizzato dal punto di vista dei suoi possibili utenti.
Per questo motivo si presta particolarmente ad essere compilato a valle di interviste
al committente.
Ogni caso d’uso descrive il comportamento del sistema
quando un attore gli invia un particolare stimolo.
Generalmente lo stimolo parte dall’attore, ma può
anche essere il sistema stesso ad iniziare il caso d’uso
(es. Produzione cedolini a fine mese, ricarico
automatico di un magazzino).
14
Gli attori sono esterni al sistema, i casi d’uso sono all’interno del sistema
Un caso d’uso corrisponde:
• ad un compito che l’attore vuole eseguire
(l’attore inizia il caso d’uso) oppure
• ad un compito che il sistema deve eseguire (il
sistema inizia il caso d’uso).
Attori e confini del sistema
15
Attori e casi d’uso
• in UML, l’associazione tra un attore e un caso d’uso indica partecipazione
• ad ogni caso d’uso partecipa almeno un attore
Regola sintattica: una relazione tra un attore e un caso d’uso può opzionalmente
includere una freccia.
Regola semantica: la freccia significa che la prima interazione si svolge nel senso
indicato dalla freccia.
16
Esempio
17
18
• La generalizzazione / specializzazione viene indicata con una linea continua con
una freccia triangolare bianca.
• Associa un caso d’uso “generale” ad uno o più casi d’uso “specializzati”.
• Il caso d’uso generale definisce una serie di passi ed ha associazioni di comunicazione
con uno o più attori.
• Ogni caso d’uso specializzato eredita le caratteristiche del caso d’uso generale e può
aggiungere nuovi passi o ridefinire quelli ereditati da quello generale (override).
• Ogni caso d’uso generale può avere più figli (casi d’uso specializzati).
• Ogni caso d’uso specializzato può avere più padri (casi d’uso generali).
19
La generalizzazione / specializzazione può essere applicata anche agli attori.
20
• L’include viene rappresentata con <<include>> e una freccia tratteggiata con la
punta aperta che va dal caso d’uso “includente” al caso d’uso “incluso” (indica una
dipendenza).
Punto di inclusione
L’inclusione riguarda un comportamento obbligatorio del caso d’uso base.
21
• Include
• Casi d’uso diversi possono avere in comune una sequenza di passi da svolgere.
In questo caso è possibile separare la sequenza comune e definirla come un
caso d’uso a se stante da “includere” nei casi d’uso originari evitando
ripetizioni.
• Ogni caso d’uso può includere un numero illimitato di altri casi d’uso e ogni caso
d’uso può essere incluso in un numero illimitato di altri casi d’uso.
22
• Relazione tra inclusione e generalizzazione/specializzazione
Se un caso d’uso generale include un altro caso d’uso, allora tutte le sue
specializzazioni “ereditano” tale inclusione.
23
• L’extend è un’associazione rappresentata con <<extend>> e una freccia
tratteggiata con la punta aperta che va dal caso d’uso “estensione” al caso d’uso
“base”.
• Permette di definire un caso d’uso “base” che può essere “esteso” con il
comportamento definito in un altro caso d’uso (indica una estensione).
• L’estensione riguarda un comportamento opzionale del caso d’uso base ed è
soggetta ad una condizione di attivazione.
• Il caso d’uso base ignora le proprie estensioni in quanto è descritto da una
sequenza di passi “già completa”, che tuttavia conterrà uno o più punti di
estensione, che sono i punti di ancoraggio ai quali si agganceranno i casi d’uso di
estensione.
24
I punti di ancoraggio ai quali si agganceranno i casi d’uso di estensione possono
essere specificati all’interno del caso d’uso tracciando una linea orizzontale
all’interno dell’ellisse e scrivendo sotto alla linea la condizione che attiva
l’estensione.
25
Esempi:
Gestione biblioteca
Web store
26
Tracciabilità requisiti- casi d’uso
È importante incrociare gli archivi dei requisiti funzionali e dei casi d’uso per verificare
la reciproca copertura:
ogni requisito deve essere coperto da almeno
un caso d’uso e viceversa
(in generale la relazione è molti-a-molti).
27
Riepilogo delle notazioni utilizzate
28
29
Specifica dei Casi d’Uso
Per ogni caso d’uso viene creato un documento
particolare (specifica del caso d’uso) che descrive
nel dettaglio, ma senza riferirsi ad una particolare
implementazione, il comportamento del sistema.
Contiene le seguenti informazioni:











Attore
Descrizione del Caso d’Uso
Precondizioni
Postcondizioni
Flusso principale
Sottoflussi
Inclusioni
Punti di estensione
Flussi alternativi
Regole
Requisiti non funzionali
Use Case Specification
<Nome caso d’uso>
Attore
...
Descrizione
….
Precondizioni
….
Postcondizioni
…
Flusso Principale
1. …
2. …
…
…
Percorsi alternativi (eventuali)
…
…
30
Esercizio
Sistema automatico di biglietteria ferroviaria
Il viaggiatore può consultare l’orario ferroviario ed
acquistare un biglietto.
Per poter consultare l’orario o acquistare un
biglietto, il viaggiatore deve scegliere la stazione
da un elenco.
Quando acquista un biglietto il viaggiatore
consulta l’orario per individuare il treno che
intende prendere.
31
Al momento dell’acquisto di un
biglietto
il
viaggiatore
può,
opzionalmente, prenotare i posti a
sedere pagando un prezzo aggiuntivo.
Prenota Posti
E’ possibile acquistare diversi tipi di
biglietto: il flusso base dell’acquisto è
sempre lo stesso, ma vi sono operazioni
particolari da effettuare per ogni
singolo caso.
32
Esercizio
Gestione conto corrente
• Il sistema usa uno sportello Bancomat
• L’utente deve poter depositare assegni
• L’utente deve poter ritirare contante
• L’utente deve poter chiedere il saldo
• L’utente deve poter ottenere una ricevuta se lo richiede. La ricevuta
riporta il tipo di transazione, la data, il numero di conto, la somma ed il
nuovo saldo
• Dopo ciascuna transazione viene visualizzato il nuovo saldo
33
Soluzione
Gestione conto corrente
• Il sistema usa uno sportello Bancomat
• L’utente deve poter depositare assegni
• L’utente deve poter ritirare contante
• L’utente deve poter chiedere il saldo
• L’utente deve poter ottenere una ricevuta se lo richiede. La ricevuta riporta il
tipo di transazione,la data, il numero di conto, la somma ed il nuovo saldo
• Dopo ciascuna transazione viene visualizzato il nuovo saldo
34
Soluzione
Use case: withdraw
Precondition: User has selected withdraw option
Main flow:
• Include (Verify user)
• Prompt user for amount to withdraw
• Check available funds of user
• Check available money of ATM
• Remove amount from account
• Give money
• (print receipt)
• Display current balance
Exceptional flow
• If not sufficient funds or money available, prompt user for lower amount
35
Soluzione
Use case: deposit
Precondition: User has selected deposit option
Main flow:
• Prompt user for amount of deposit
• Open slot
• Get check
• (print receipt)
• Display (balance + deposited amount)
Use case: withdraw with receipt
Precondition: User has selected withdraw option and print receipt option
…
Use case: deposit with receipt
Precondition: User has selected deposit option and print receipt option
...
36
Soluzione
Use case: check balance
Precondition: User has selected balanceoption
Main flow:
• Display balance
Use case: verify user
Precondition: none
Main flow:
• User enters ID card
• User enters PIN number
• System checks validity of card and number
Exceptional flow:
• If combination is not valid, reject user
37
Esercizio
Acquistare un biglietto di un’autolinea da un distributore automatico
Disegnare un diagramma di casi d’uso che risponda ai seguenti requisiti.
Un viaggiatore:
• può richiedere la visualizzazione dell’elenco delle corse tra un punto di partenza ed
una destinazione
• può acquistare un abbonamento o uno o più biglietti di una corsa, selezionata in
un elenco, tra un punto di partenza ed una destinazione
• può effettuare il pagamento in contanti o con bancomat o carta di credito
38
Acquistare un biglietto di un’autolinea da un distributore automatico
Soluzione
39
Soluzione
Caso d'uso: Acquista Biglietto Autolinea da distributore automatico
Attore:
Viaggiatore
Input:
luogo partenza e destinazione corsa, data corsa, n.ro posti
Precondizioni: il distributore automatico è attivo, i luoghi di partenza e destinazione
devono essere tra quelli serviti dalla autolinea, il n.ro di posti richiesti
deve essere non maggiore di quelli ancora disponibili per la corsa
Output:
biglietto riportante luogo partenza e destinazione corsa, data corsa,
posto, registrazione della prenotazione in archivio, aggiornamento
n.ro posti liberi rimenenti sulla stessa corsa
Postcondizioni: se prenotazione con successo, n.ro posti disponibili sulla corsa deve
essere minore di quello iniziale.
40
Soluzione
Caso d'uso: Acquista Biglietto Autolinea da distributore automatico
Precondizione: il viaggiatore ha richiesto l’acquisto di un biglietto
Flusso principale:
• Il sistema verifica che vi sia carta necessaria per la stampa del biglietto
• include (“Elenco corse selezionabili”)
• Il viaggiatore indica i luoghi di partenza e di destinazione e la data della corsa
• Il sistema verifica che esista una corsa nella data indicata e per i luoghi indicati
• Il sistema mostra gli orari delle corse soddisfacenti i criteri indicati e chiede all’utente di
selezionarne una
• L’utente seleziona una corsa e fornisce il n.ro di posti per cui vuole acquistare il biglietto
• Il sistema verifica che la corsa selezionata abbia
la disponibilità del n.ro di posti richiesti
• Presenta l’importo da pagare e chiede conferma
dell’acquisto
• Il viaggiatore conferma l’acquisto e richiede la
stampa del biglietto
• Il sistema invita il viaggiatore a scegliere la
modalità di pagamento
• include (“Pagamento”)
• Il sistema stampa il biglietto, aggiorna il numero
di posti diponibili e l’elenco delle prenotazioni
41
Esercizio
Si vuole realizzare un sistema informatico in grado di gestire in maniera automatizzata le
prove di esame tenute da un docente di un corso universitario.
Il docente registra preventivamente i dati relativi alla prova, ossia il nome del corso, la data
della prova, la durata (espressa in minuti) e l’insieme delle prove da sottoporre agli studenti.
In sede di esame, lo studente deve preventivamente iscriversi, indicando il proprio nome,
cognome, numero di matricola e indirizzo e-mail. Il sistema fornisce allo studente iscritto il
testo di una prova individuale (scegliendola dall’insieme delle prove registrate dal docente) e
calcola il tempo limite entro il quale deve essere consegnata la soluzione. Il tempo limite di
consegna è stabilito in base alla durata prevista per la prova e l’ora di assegnazione allo
studente. Il sistema dovrà registrare tutti questi dati in apposito archivio.
Lo studente deve completare il proprio elaborato e
consegnarlo tramite l’interfaccia del sistema entro il
tempo limite. Il sistema invia inoltre una mail di
conferma dell’avvenuta ricezione o di consegna
impossibile qualora il tempo limite sia scaduto.
Il docente corregge ogni compito, indicando se é
sufficiente o meno, inserendo un voto (numerico,
compreso tra 18 e 30 oppure insufficiente).
Al termine dell’inserimento dei giudizi di tutti i
compiti, un messaggio di e-mail viene recapitato ad
ogni studente, con il risultato del suo compito.
42
Soluzione
Caso d’uso: Correggi Compito
Pre-condizioni: Il docente ha registrato in precedenza una prova.
Flusso di eventi:
Percorso Principale
1. Il docente chiede al sistema i compiti consegnati dagli studenti
2. Il sistema restituisce i file contenenti le risoluzioni dei compiti
3. FOR ogni compito, il docente lo corregge assegnando un voto compreso tra 18 e
30 oppure insufficiente
4. Il sistema memorizza tali voti in un database
5. INCLUDE (Invia risultati)
43
Caso d’uso: Invia risultato
Pre-condizioni: Il docente ha corretto tutti i compiti
Flusso di eventi:
Percorso Principale
1. Il docente conferma l’autorizzazione all’invio;
2. FOR ogni compito, il sistema invia una mail contenente il voto conseguito allo
studente cui appartiene il compito.
Caso d’uso: Svolgi prova
Pre-condizioni: Il Docente ha registrato in precedenza una prova
Flusso di eventi:
Percorso Principale
1. INCLUDE (Iscrivi a prova)
2. Lo studente risolve la prova
3. IF lo studente non vuole consegnare la prova, PERCORSO ALTERNATIVO#
4. EXTENSION POINT 1: INVIA SOLUZIONE
#Percorso alternativo:
Lo studente si ritira
Il sistema memorizza l’avvenuto ritiro
44
Caso d’uso: Iscrivi a prova
Pre-condizioni: nessuna
Flusso di eventi:
Percorso Principale
1. Lo studente si identifica e chiede al sistema di iscriverlo alla prova;
2. Il sistema memorizza I dati;
3. Lo studente richiede la traccia della prova;
4. Il sistema memorizza l’orario di inizio della prova e la traccia inviata;
5. Il sistema restituisce allo studente la traccia della prova e fa partire il tempo.
Caso d’uso: Invia soluzione
Pre-condizioni: Lo studente ritiene di aver risolto la prova
Flusso di eventi:
Percorso Principale
1. Lo studente conferma l’avvenuta risoluzione della prova;
2. IF Il tempo è scaduto PERCORSO ALTERNATIVO#
3. Il sistema acquisisce la prova
#Percorso alternativo
Il sistema notifica allo studente che il tempo è scaduto e non può essere
consegnata la prova
Il sistema memorizza l’avvenuto ritiro
45
46
UML- diagramma di attività
• È una modalità di rappresentazione delle funzionalità del sistema a basso livello.
• Descrivono la logica procedurale e quindi aiutano a descrivere gli aspetti
dinamici dei casi d’uso.
• Per ciascuna delle funzioni individuate con i casi d’uso viene realizzato un flow
chart.
Alcuni elementi grafici.
Nodi azione:
specificano unità atomiche, non
interrompibili e istantanee di
comportamento.
Nodi di inizio e di fine: sono nodi speciali che
indicano l’inizio e la fine del flusso.
Nodi oggetto: sono oggetti particolarmente
importanti usati come input e
output di azioni.
Nodi controllo: descrivono il flusso dell’attività.
Un diagramma di attività mostra come ESAW
va in giro a trovare cibo
47
Per capire la semantica dei diagrammi di attività, bisogna immaginare delle entità,
dette token, che viaggiano lungo il diagramma.
Il flusso dei token definisce il flusso dell’attività.
I token possono rimanere fermi in un nodo azione/oggetto in attesa che si avveri una
condizione su una freccia, oppure una precondizione o postcondizione su un nodo.
Il movimento di un token è atomico.
Il disco nero marca l’inizio dell’attività (genera token).
Quando un token raggiunge un disco nero bordato (nodo
termine.
finale), l’attività ha
Esempi
48
Esempio
In questo caso sono mostrati più flussi in
ingresso e anche in uscita dai nodi azione.
Quando l'azione “Il cliente fornisce i
dettagli“ viene completata, vengono
prodotti due oggetti:
“Indirizzo di
spedizione" e “Dettagli carta di credito".
I due oggetti vengono elaborati da due
diversi nodi azione.
Poiché un nodo azione richiede che tutti
gli input siano disponibili prima di
iniziare, l'ultima azione “Consegna
merci” non viene avviata fino a quando
tutte le azioni che conducono a essa non
siano completate.
49
Nodi decisione
I nodi decisione(diramazione): specificano percorsi alternativi, hanno un
solo input e vari output sotto una condizione mutualmente esculsiva.
I nodi fusione: hanno vari input e un solo output, sul quale vengono
indirizzati tutti i token in ingresso.
Nodi fork
I nodi fork hanno un ingresso e varie uscite: i token in ingresso sono duplicati
su tutte le uscite.
Indicano l’inizio di una elaborazione parallela (esecuzione di più azioni
contemporanee).
Nodi join
I nodi join hanno vari ingressi e una sola uscita:
quando sono presenti token su tutti gli ingressi, viene
prodotto almeno un token in uscita.
I nodi fork dividono un’esecuzione in più flussi
concorrenti, i nodi join sincronizzano e riuniscono i
flussi.
50
Segnali ed eventi temporali
Ci sono alcuni nodi azione specializzati che
gestiscono l’invio di segnali e la ricezione di
segnali o messaggi.
L’invio di segnali o messaggi è asincrono e non
blocca l’attività, quindi va fatto seguire da un
nodo di accetta evento per fermare
momentaneamente il flusso.
Esempio
Diagramma delle attività che rappresenta il comportamento di uno studente che
vuole superare l’esame di laboratorio di ingegneria del software.
51
Esempio
L'effetto del Nodo fork (1) consiste nel dividere
il flusso in due o più flussi di azioni.
Quando l'azione di creazione ordine in
ingresso al nodo termina, possono iniziare
tutte le azioni sul lato di output del fork (azioni
parallele).
Il Nodo join (2) raggruppa flussi simultanei.
L'azione in uscita dal Nodo join non può
iniziare fino a quando tutte le azioni che
conducono al Nodo join non siano completate.
Viene usato un nodo azione invia segnale (3)
per indicare che un segnale o un messaggio di
qualche tipo viene inviato ad altre attività o
processi. Nel nodo viene scritto il nome
dell'azione per indicare che tipo di messaggio
viene inviato.
Viene utilizzato un nodo azione accetta evento (4) per indicare che l'attività attende per
un evento esterno o messaggio in ingresso. Anche in questo caso si scrive nel nodo il
nome dell'azione per indicare il tipo di evento che si attende.
52
Partizioni o corsie (swimlanes)
Suddividono il flusso dell’attività, ma non ne modificano il significato.
Sono segmenti paralleli e la suddivisione può essere orizzontale, verticale o
multidimensionale.
Esempi
53
Esempio
Il diagramma mostra alcuni casi d'uso relativi alla
ricerca di bug informatici e alla loro correzione.
Attori:
• Reporter che notifica
l’esistenza di un bug
• Updater che gestisce il
processo di correzione
del bug
• Developer che si occupa
della correzione del bug
54
Regioni interrompibili (esempio)
L’ordine è cancellato solo se un token si trova all’interno della regione al
momento della ricezione del segnale.
55
Esempio: automazione biblioteca
Scenario
Una università vuole automatizzare la propria biblioteca attraverso un nuovo Sistema
Informativo:
• Lo Studente può utilizzare il sistema per cercare e prenotare un libro;
• Il Bibliotecario utilizza il sistema per registrare prestiti e restituzioni:
 Prima del prestito vengono chiesti gli estremi dello studente
 Viene verificata la disponibilità di una copia del libro
 Uno studente non può prendere più di 3 libri in prestito
• La Biblioteca conserva diverse copie dello stesso libro;
56
Soluzione
Diagramma dei casi d’uso e di attività
57
Soluzione
Viene realizzato un documento che descrive
nel dettaglio il caso d’uso: Presta libro
Specifica del caso d’uso
Presta Libro
Descrizione
L’obiettivo è registrare i libri presi
in prestito dagli studenti.
Precondizioni
Lo studente deve aver prenotato il libro.
Flusso principale
L’utente specifica gli estremi dello studente
L’utente specifica gli estremi del libro
Viene registrato il prestito
Flussi alternativi
- Al punto 1, se lo studente ha già 3 libri
in prestito, esci.
- Al punto 2, se il libro richiesto è già
in prestito, esci.
…
58
Soluzione
Relativa al
Parallelizzazione
Sincronizzazione
59
60
UML- diagramma di sequenza
• Un diagramma di sequenza è un diagramma che descrive le interazioni tra oggetti
che collaborano per svolgere un compito e in quale ordine.
• Gli oggetti collaborano scambiandosi messaggi
• Lo scambio di un messaggio in OOP equivale all’invocazione di un metodo
Gli oggetti
Asse x:
Gli oggetti sono disposti orizzontalmente
Un oggetto è un’istanza di una classe nomeOggetto : NomeClasse
Asse t:
Il flusso del tempo è descritto verticalmente
61
Significato delle frecce
Simbolo
Tipo di Messaggio
Asincrono
Sincrono
Freccia circolare
Descrizione
Il chiamante non rimane in attesa della terminazione del
metodo del chiamato, ma prosegue subito dopo
l’invocazione, quindi non attende la risposta.
La freccia è etichettata col nome del metodo invocato.
Il ritorno è rappresentato con una freccia tratteggiata e
può non essere immediatamente successivo alla chiamata.
Il chiamante rimane in attesa della terminazione del
metodo del chiamato prima di proseguire, cioè della
risposta.
La freccia è etichettata col nome del metodo invocato.
Il ritorno è rappresentato con una freccia tratteggiata ed è
sempre opzionale. Se si omette, la fine del metodo è
decretata dalla fine del life-time.
Descrive un oggetto che invoca un suo metodo (chiamante
e chiamato coincidono).
Rimane all’interno del life time di uno stesso metodo
Il life-time (durata di vita) di un metodo è rappresentato da un
rettangolo verticale che collega freccia di invocazione e freccia di
ritorno.
Il life-line (linea di vita) è rappresentato da una linea tratteggiata
verticale e il verso del tempo è dall’alto verso il basso.
62
Esempio
Oggetto
Diagramma di sequenza: check Email
Scorrere del tempo
Durata di
vita
Messaggi
(metodi)
63
Esempio
Diagramma di sequenza: Ordina merce
64
1. message1() is sent only if the condition
specified in the guard (in brackets) is true.
2. A branch. Sender sends either message2() or
message3(). Guards should be exclusive. I use
«else» instead of a guard when appropriate.
3. Iteration. Sender sends message4() as long as
the condition is true.
4. "For each." If the receiver is a collection of
objects (indicated by the cardinality of the
associated role in the static model), send the
message to all of them.
5. UML 2.0 Interaction Frame. The condition
specifies a loop.
Can also use:
loop A loop, executes multiple times
opt Optional. An "if" statement.
6. As shown, an if/else structure.
Can use:
alt Execute one of the alternatives,
controlled by guards
Par Execute regions in parallel
http://www.holub.com/goodies/uml/
65
Esempio
Esempio
con i frame di interazione
ref
alt
opt
loop
par
neg
…
66
Esempio: Crea Ordine
67
Esempio
Diagramma di sequenza: Login
68
Esempio: sistema di vendita di pasti online
Deve consentire:
- ai clienti di scegliere elementi da un menu
- ai ristoranti di aggiornare il menu
Diamo una rappresentazione
diagramma di caso d’uso.
usando
un
L’ordinazione di un pasto fa parte del processo
di acquisto di un pasto, che comprende anche
il pagamento e la consegna:
69
Esempio: sistema di vendita di pasti online
Diagramma caso d’uso: ordinazione pasto
Diagramma di attività:
ordinazione pasto
Diagramma di sequenza:
ordinazione pasto
70

UML - Roberta Gerboni

Transcript

Documenti analoghi

TECN. E PROG. DI SIST. INFORM - Fossati

versione pdf - Dipartimento di Ingegneria Informatica e delle

Testo - e-Lite

Introduzione alla Gestione di un Progetto Software con UML

versione pdf - Dipartimento di Ingegneria Informatica e delle

programma pubblicato

Programma Finale: 2016-2017 - Fossati

Conceptual Modeling with UML - Dipartimento di Matematica e

Unified Modeling Language (UML) • È un linguaggio visuale di

Diagramma di Meditazione