Date post: | 02-May-2015 |
Category: |
Documents |
Upload: | sofia-nigro |
View: | 213 times |
Download: | 0 times |
Introduzione a UML
Perché modelliamo
Un modello è una semplificazione della realtà
I modelli ci aiutano a “visualizzare” un sistema come è o come vorremmo che
fosse ci permettono di specificare la struttura o il comportamento di un
sistema ci forniscono un “template” che ci guida nella costruzione di un
sistema documentano le decisioni che abbiamo preso
Perché modelliamo
Divide et impera: tramite i modelli ci focalizziamo su un solo aspetto alla volta
ogni modello può essere espresso a differenti livelli di precisione
per un sistema non banale: non un solo modello ma un piccolo insieme di modelli, che possono essere costruiti
e studiati separatamente, ma che sono strettamente interrelati
Unified Modeling Language
un linguaggio (e notazione) universale, per la creazione di modelli software
nel novembre ‘97 è diventato uno standard approvato dall’OMG (Object Management Group)
numerosi i co-proponenti: Microsoft, IBM, Oracle, HP, Platinum, Sterling, Unysis …..
Unified Modeling Language
è l’unificazione dei metodi: Booch-93 di Grady Booch OMT di Jim Rumbaugh OOSE di Ivar Jacobson
ha accolto inoltre le idee di numerosi altri metodologie è tuttavia indipendente dai metodi, dalle tecnologie, dai produttori
UML - linguaggio universale
linguaggio per specificare, costruire, visualizzare e documentare gli artefatti di un sistema
universale: può rappresentare sistemi molto diversi, da quelli web ai legacy, dalle tradizionali applicazioni Cobol a quelle object oriented e a componenti
UML non è un metodo
è un linguaggio di modellazione, non un metodo, né una metodologia
definisce una notazione standard, basata su un meta-modello integrato degli “elementi” che compongono un sistema software
non prescrive una sequenza di processo, cioè non dice “prima bisogna fare questa attività, poi quest’altra”
UML e Processo Software
“un unico processo universale utilizzabile per tutti gli stili di sviluppo non sembra possibile e tanto meno desiderabile”
in realtà UML assume un processo: basato sui Casi d’Uso (use case driven) incentrato sull’architettura iterativo e incrementale
i dettagli di questo processo di tipo generale vanno adattati alle peculiarità della cultura dello sviluppo o del dominio applicativo di ciascuna organizzazione
Diagrammi UMLlivello “logico”: dei casi d’uso Use Case Diagram delle classi Class Diagram di sequenza Sequence Diagram di collaborazione Collaboration Diagram di transizione di stato Statechart Diagram delle attività Activity Diagram
livello “fisico”: dei componenti Component Diagram di distribuzione dei componenti Deployment Diagram
Diagramma dei casi d’usoMostra:
• le modalità di utilizzo del sistema (casi d’uso)• gli utilizzatori e coloro che interagiscono con il sistema
(attori)• le relazioni tra attori e casi d’uso
Un caso d’uso• rappresenta un possibile “modo” di utilizzo del sistema• descrive l’interazione tra attori e sistema, non la “logica
interna” della funzione
una funzionalità dal punto di vista di chi la utilizza
Perche’ costruire modelli dei casi d’uso Primo momento nel ciclo di vita del software in cui costruiamo
delle rappresentazioni (talvolta semi-formali) del software. Motivazioni:
1. Esplicitare e comunicare a tutti gli stakeholder i requisiti funzionali del sistema– In generale, analizzare, identificare, descrivere gli usi tipici del sistema da parte dei suoi utilizzatori. Considerare anche tutta l’eventuale logica derivante dalla gestione di errori, eccezioni, flussi alternativi.
2. Validare i requisiti utente – Essendo il modello dei casi d’uso piuttosto semplice (pochi costrutti, semantica precisa, ma intuitiva), diventa un valido strumento per assicurarci di aver sviluppato un sistema software corrispondente alle vere necessita’ dell’utente.
Cosa è un use case
Un use case cattura chi (attori) fa cosa (interazione) con il sistema. Con quale scopo (goal), senza considerare ciò che è dentro il sistema
Un use case Raggiunge un singolo, discreto, completo, significativo, e ben
definito task di interesse per un attore È un pattern di comportamento tra alcuni attori ed il sistema —
una collezione di possibili scenari È scritto usando il vocabolario del dominio applicativo Definisce scopo ed intento (non azioni concrete) È generale e indipendente dalla tecnologia
Use case diagram e requisiti
I casi d’uso servono a: chiarire i requisiti del committente in termini
comprensibili trovare aspetti comuni (riuso) individuare gli attori del sistema individuare gli eventi a cui il sistema deve rispondere
Un requisito può dare origine a più casi d’uso Ad un caso d’uso possono venire associati più requisiti
Casi d’uso, attori, scenari e descrizioni Quattro concetti fondamentali:
1. Caso d’uso – rappresenta una specifica interazione tra un attore e il sistema. In UML rappresentato mediante un’ellisse etichettata col nome del caso d’uso.
2. Attore – rappresenta un ruolo che caratterizza le interazioni tra utente e sistema. L’utente non è necessariamente umano; In UML rappresentato mediante un omino.
3. Scenario – sequenza di azioni che definisce una particolare interazione tra attore e sistema.
4. Descrizione – testo che descrive lo scenario, l’ordine temporale della sequenza di azioni, l’eventuale trattamento degli errori, gli attori coinvolti.
Attori
Gli attori sono rappresentati tramite il ruolo che giocano nel caso d’uso e sono normalmente indicati tramite l’icona:
Cassiere
<<Attore>>
Relazione tra attori
• E’ possibile definire gerarchie di attori
• Associare un attore ad uno o più attori specializzati
Utente Banca
Utente Sede Centrale Utente Filiale
Diagramma dei casi d’uso
acquistare articoli
log incassierecliente
rimborsare articoli venduti
attore: un utilizzatore del sistema
caso d'uso: un "modo" di utilizzare il sistema
Template per la documentazione di un caso d’uso
object-modeling @2003-2005 Dr. Andrea Baruzzo - Strutturare i diagrammi dei casi d'uso in UML 19
Esempio di scenario: Prelievo dal Bancomat
object-modeling @2003-2005 Dr. Andrea Baruzzo - Strutturare i diagrammi dei casi d'uso in UML 20
object-modeling @2003-2005 Dr. Andrea Baruzzo - Strutturare i diagrammi dei casi d'uso in UML 21
Esempio di scenario (Cont.)
Relazioni tra casi d’uso
Relazione di inclusione «include» Relazione di generalizzazione Relazione di estensione «extend»
Poche relazioni: modello semplice, senza grossa complessità sintattica
Relazioni tra casi d’uso: inclusione
Rappresenta l’invocazione di un caso d’uso da parte di un altro.
Simile alla chiamata di una funzione Serve per scomporre casi d’uso complessi in casi
d’uso più semplici Esprime il riuso di singoli casi d’uso
Relazioni tra casi d’uso: include
<<include>> : può mostrare anche il comportamento comune a uno o più casi d’uso
prelevare visualizzare saldo
identificarsi al bancomat
<<include>> <<include>>
Booking
ReturningReturning
Service
Customer Official<<include>>
Vehicle rental system
Using
Esempio
Esempio Effettuare un ordine di acquisto include (sempre!) i
seguenti passi:1. Compilazione di un form di acquisto
2. Scelta della modalità di pagamento;
3. Conferma dell’ordine di acquisto
Cliente Effettua un Oridine
Compila Form di Acquisto Prodotto<<include>>
Scegli Modalità Pagamento<<include>>
Conferma Ordine
<<include>>
Relazioni tra casi d’uso: generalizzazione
Simile all’ereditarietà tra classi Relazione che lega un caso d’uso generico a casi d’uso che
sono particolari specializzazioni (realizzazioni) del primo Logica del caso d’uso derivato simile a (ma diversa da) quella
del caso d’uso di base Viene riscritta (specializzata) la sequenza delle azioni di base
oppure viene elaborata una sequenza alternativa
Relazioni tra casi d’uso: generalizzazione
Effettua un Ordine è un caso d’uso generale che può essere specializzato nei seguenti:1. Effettua un ordine di un cd musicale
2. Effettua un ordine di un libro
3. Effettuare un ordine di uno spartito
Cliente Effettua un Ordine
Effettua Ordine CD MusicaleEffettua Ordine Spartito
Effettua Ordine Libro
Relazioni tra casi d’uso: estensione
Rappresenta l’estensione della logica di base di un caso d’uso.
Il caso d’uso estensione continua il comportamento del caso d’uso di base inserendovi delle azioni alternative da un certo punto in poi (chiamato punto di estensione)
Il caso d’uso di base dichiara tutti i possibili punti di estensione
Simile alla gestione degli interrupt hardware (gestione eccezioni)
Relazioni tra casi d’uso: extend
<<extend>>: mostra il comportamento opzionale (alternativo o relativo al trattamento di condizioni anomale)
trattare condizioni particolari
aprire conto corrente
<<extend>>
Relazioni tra casi d’uso: estensione
Effettua un Ordine presuppone che l’utente sia già registrato nel sistema informatico
Se il cliente è al suo primo ordine e non si è precedentemente registrato? Eccezione nel caso d’uso base!
Cliente Effettua un Ordine
Aggiungi Cliente
<<extend>>
Punti di estensione:nuovo cliente
Relazioni tra casi d’uso (estensione) Effettua un Ordine prevede una procedura d’acquisto
di default che non invia la fattura E se il cliente richiede una fattura? Eccezione nel caso
d’uso base
Fattura Ordine
Punti di estensione:nuovo clientedati fattura
Cliente Effettua un Ordine
<<extend>>
Esercizio: Sportello Bancomat Il Sistema sarà eseguito su uno sportello bancomat automatico L'utente deve essere in grado di depositare assegni sul suo
conto L'utente deve essere in grado di prelevare i soldi dal suo conto L'utente deve poter interrogare il Sistema sul saldo del suo
conto Se lo richiede, l'utente deve poter ottenere la ricevuta per la
transazione. I tipi di transazione sono ritiro o deposito. La ricevuta deve indicare la data della transazione, ilnumero
del conto, il saldo precedente e successivo la transazione Dopo ogni transazione, il nuovo saldo deve essere visualizzato
all'utente
Esercizio: Soluzione
Diagramma delle classi
• è il caposaldo dell’object oriented
• rappresenta le classi di oggetti del sistema con i loro attributi e operazioni
• mostra le relazioni tra le classi (associazioni, aggregazioni e gerarchie di specializzazione/generalizzazione)
• può essere utilizzato a diversi livelli di dettaglio (in analisi e in
progettazione)
Class diagram: le classi
Automobile
marcamodellocoloretarga
cambiaTargacambiaColore
Nome
Attributi (proprietà)
Operazioni (metodi)
Una classe è una tipologia di oggetti, con propri attributi e operazioni
Rappresentazione di una classe in UML:
Class diagram: le classi
Nome: inizia con una lettera maiuscola, non è sottolineato e non contiene underscore
Attributi: proprietà i cui valori identificano un oggetto istanza della classe e ne costituiscono lo stato; iniziano con una lettera minuscola
Operazioni: insieme di funzionalità che esprimono il comportamento di un oggetto, ovvero ciò che ogni oggetto di questa classe può fare
Class diagram: associazioni
Clienti
clienteDal
getOrdini
Ordini
dataOrdinestato
calcolaTassecalcolaTotalesetStato
Articoli
codicedescrizionepesoprezzo
DettagliOrdine
quantità
calcolaPesocalcolaPrezzo
1 0..*
0..*1
1
1..*
emette
emesso da
riguarda articolo
nell’ordine
Class diagram: associazioni
Associazione: correlazione fra classi; nel diagramma è una linea continua fra due classi, con esplicita semantica nei due sensi
Molteplicità: numero di oggetti che partecipano all’associazione. Esempi di molteplicità sono:
1 Esattamente una istanza
0..* Nessun limite al numero di istanze
1..* Almeno una istanza
n..m Da n a m istanze
Class diagram: aggregazione
Aggregazione: tipo particolare di associazione; esprime concetto “è parte di ” (part of ), che si ha quando un insieme è relazionato con le sue parti.
• Si rappresenta con un diamante dalla parte della classe che e’ il contenitore
Class diagram: composizione
E’ un caso particolare di aggregazione in cui:
Il diamante si disegna pieno
1. la parte (componente) non può esistere da sola, cioè senza la classe composto
2. una componente appartiene ad un solo composto
Class diagram: aggregazione/composizione
Università
Dipartimenti
Docenti
composizione
aggregazione
Class diagram: ereditarietà
Persone
nomecognomeindirizzo
cambiaIndirizzo
Clienti
codiceClienteclienteDal
contaOrdini
PotenzialiClienti
numVisite
simbolo diereditarietà
sottoclassi
superclasse
Class diagram: esempio
Punti
xy
Poligoni
coloreRiempcoloreBordotipoBordo
Vertici
coloredimensione
setColoreBordosetColoreRiempsetTipoBordo
identifica
3..*
Class diagram: esempio
Frequenze
Corsinomedurata
Esamivotodata
Studentimatricola
Personenome
Docenti
insegnatenuto da del corso
sostieneperiodo
di
relativo a
1
1..*
1 1 *
*
*
1
Diagramma di sequenza
• è utilizzato per definire la logica di uno scenario (specifica sequenza di eventi) di un caso d’uso (in analisi e poi ad un maggior livello di dettaglio in disegno)
• è uno dei principali input per l’implementazione dello scenario • mostra gli oggetti coinvolti specificando la sequenza temporale dei
messaggi che gli oggetti si scambiano• è un diagramma di interazione: evidenzia come un caso d’uso è
realizzato tramite la collaborazione di un insieme di oggetti
Alcune definizioni
Un diagramma di sequenza è un diagramma che descrive interazioni tra oggetti che collaborano per svolgere un compito
Gli oggetti collaborano scambiandosi messaggi Lo scambio di un messaggio in programmazione ad
oggetti equivale all’invocazione di un metodo
Scambio Messaggi Sincroni (1/2)
Si disegna con una freccia chiusa
da chiamante a chiamato. La freccia è etichettata col nome del metodo invocato, e opzionalmente i suoi parametri e il suo valore di ritorno
Il chiamante attende la terminazione del metodo del chiamato prima di proseguire
Il life-time (durata, vita) di un metodo è rappresentato da un rettangolino che collega freccia di invocazione e freccia di ritorno
Scambio Messaggi Sincroni (2/2)
Life-time corrisponde ad avere un record di attivazione di quel metodo sullo stack di attivazione
Il ritorno è rappresentato con una freccia tratteggiata Il ritorno è sempre opzionale. Se si omette, la fine del
metodo è decretata dalla fine del life-time
Scambio Messaggi Sincroni sd Diagrammi di Sequenza - Scambio Messaggi Sincroni
an Order EntryWindow :Window
an Order :Order
Messaggio asincrono(invocazione di un metodo)
life-line dell 'oggetto an Order Entry Window
oggetto
life-time di prepare()
messaggio di ritorno(opzionale se void)
prepare()
return done
Scambio Messaggi Asincroni
Si usano per descrivere interazioni concorrenti Si disegna con una freccia aperta
da chiamante a chiamato. La freccia è etichettata col nome del metodo invocato, e opzionalmente i suoi parametri e il suo valore di ritorno
Il chiamante non attende la terminazione del metodo del chiamato, ma prosegue subito dopo l’invocazione
Il ritorno non segue quasi mai la chiamata
Scambio Messaggi Asincroni
sd Diagramma di Sequenza - Scambio Messaggi Asincroni
an Order EntryWindow :Window
an Order :Order
Messaggio asincrono(invocazione di un metodo)
oggetto
prepare()
Esecuzione condizionale di un messaggio L’esecuzione di un metodo può essere assoggettata ad
una condizione. Il metodo viene invocato solo se la condizione risulta verificata a run-time
Si disegna aggiungendo la condizione, racchiusa tra parentesi quadre, che definisce quando viene eseguito il metodo
Sintassi:
[cond] : nomeMetodo()
Esecuzione condizionale di un messaggio - esempio
sd Diagrammi di Sequenza - Esecuzione Condizionata
an Order Line:OrderLine
a Stock Item:StockItem
Il metodo remove() viene eseguito solo se il metodo check assegna "true" alla variabile hasStock (soddisfa la condizione hasStock=true)
hasStock = check()
[hasStock]: remove()
Esecuzione condizionata di un messaggio – esempio (un’alternativa)
sd Diagrammi di Sequenza - Esecuzione Condizionata (Alternativ a)
an Order Line:OrderLine
a Stock Item:StockItem
Il metodo remove() viene eseguito solo se i l metodo check assegna "true" alla variabile hasStock (soddisfa la condizione hasStock=true)
check()
hasStock
[hasStock]: remove()
Esecuzione condizionata di un messaggio (un’altra alternativa)
sd Diagrammi di Sequenza - Esecuzione Condizionata (Alternativ a)
an Order Line:OrderLine
a Stock Item:StockItem
Il metodo remove() viene eseguito solo se i l metodo check assegna "true" alla variabile hasStock (soddisfa la condizione hasStock=true)
il metodo actionForItemNotInStock() viene eseguito in alternativa al metodo remove(), se la condizione hasStock ha valore false
check()
hasStock
[hasStock]: remove()
[not hasStock]: actionForItemNotInStock()
Iterazione di un messaggio
Rappresenta l’esecuzione ciclica di messaggi Si disegna aggiungendo un * (asterisco) prima del
metodo su cui si vuole iterare Si può aggiungere la condizione che definisce
l’iterazione La condizione si rappresenta tra parentesi
quadre. Sintassi completa:
[cond] : * nomeMetodo()
Iterazione di un messaggio - esempio
sd Diagramma di Sequenza - Iterazione di un Messaggio
an Order :Order an Order Line:OrderLine
[for each oreder l ine]: *prepare()
Iterazione di un blocco di messaggi
Rappresenta l’esecuzione ciclica di più messaggi
Si disegna raggruppando con un blocco (riquadro, box) i messaggi (metodi) su cui si vuole iterare
Si può aggiungere la condizione che definisce l’iterazione sull’angolo in alto a sinistra del blocco
La condizione si rappresenta al solito tra parentesi quadre
Iterazione di un blocco di messaggi sd Diagrammi di Sequenza - Iterazione di più Messaggi
:Order :OrderLine
loop Prepare&Deliv er
[for each order l ine]
prepare()
done
deliver()
successful
“Auto-Chiamata” (Self-Call)
Descrive un oggetto che invoca un suo metodo (chiamante e chiamato coincidono)
Si rappresenta con una “freccia circolare”
che rimane all’interno del life time di uno stesso metodo
Auto-Chiamata” (Self-Call)sd Diagrammi di Sequenza - Self-Call
a Stock Item:StockItem
an Order Line:OrderLine
All 'interno del metodo remove(), l 'oggetto "a Stock Item" chiama il proprio metodo needsToReorder()
remove()
needsToReorder()
Costruzione di un oggetto
Rappresenta la costruzione di un nuovo oggetto non presente nel sistema fino a quel momento
Messaggio etichettato new, create,…
L’oggetto viene collocato nell’asse temporale in corrispondenza dell’invocazione nel metodo new (o create…)
Costruzione di un oggettosd Diagramma di Sequenza - Creazione di un Oggetto
an Order Line:OrderLine
:Deliv eryItem
a Stock Item:StockItem
"an Order Line" crea un istanza di DeliveryItem.Prima (o durante) l 'esecuzione di remove() l 'istanza di DeliveryItem non esisteva!
remove()
done
new
Eliminazione di un oggetto
Rappresenta la distruzione di un oggetto presente nel sistema fino a quel momento
Si rappresenta con una X posta in corrispondenza della life-line dell’oggetto
Da quel momento in poi non è legale invocare alcun metodo dell’oggetto distrutto
Eliminazione di un oggetto
sd Diagrammi di sequenza - Eliminazione di un Oggetto
an Order EntryWindow :Window
an Order :Order
l 'oggetto "an Order Entry Window" da qui in poi non èpiù accessibile
L'oggetto "an Order" vive ancora
prepare()
done
Mettiamo tutto insieme…
Costruiamo un diagramma di sequenza per il seguente use case Una finestra di tipo Order Entry invia il messaggio “prepare”
ad un Ordine (Order) L’ordine invia il messaggio “prepare” ad ogni sua linea
(Order Line) Ogni linea verifica gli elementi in stock (Stock Item) Se il controllo ha esito positivo, la linea rimuove
l’appropriata quantità di elementi in stock e crea un’unità di delivery (DeliveryItem)
Se gli elementi in stock rimanenti scendono al di sotto di una soglia di riordino, viene richiesto un riordino (ReorderItem)
Mettiamo tutto insieme… sd Diagrammi di Sequenza - La Sintassi
a Stock Item:StockItem
an Order :Orderan Order EntryWindow :Window
an Order Line:OrderLine
:ReorderItem
:Deliv eryItem
prepare()
[for each order l ine]: *prepare()
hasStock:= check()
[hasStock]: remove()
needsReorder:= needsToReorder()
[needsReorder]: new
[hasStock]: new
Alcuni suggerimenti finali
Assicurarsi che i metodi rappresentati nel diagramma siano gli stessi definiti nelle corrispondenti classi (con lo stesso numero e lo stesso tipo di parametri)
Documentare ogni assunzione nella dinamica con note o condizioni (ad es. il ritorno di un determinato valore al termine di un metodo, il verificarsi di una condizione all’uscita da un loop, ecc.)
Mettere un titolo per ogni diagramma (ad es. “sd Diagrammi di Sequenza – Eliminazione di un Oggetto” )
Alcuni suggerimenti finali
Scegliere nomi espressivi per le condizioni e per i valori di ritorno
Non inserire troppi dettagli in un unico diagramma (flussi condizionati, condizioni, logica di controllo)
Non bisogna rappresentare tutto quello che si rappresenta nel codice …
Se il diagramma è complesso, scomporlo in più diagrammi semplici (ad es. uno per il ramo if, un altro per il ramo else, ecc.)