Il diagramma dei casi d'uso - cs.unibo.it · Il diagramma dei casi d’uso Laboratorio di Sistemi e...

Il diagramma dei casi d’uso

Laboratorio di Sistemi e Processi OrganizzativiGian Piero Favini

A.A. 2006-2007

Lab Sistemi e Processi Organizzativi () Il diagramma dei casi d’uso A.A. 2006-2007 1 / 34

Tassonomia dei diagrammi UML 2

Structure diagrams show the static structure of the objects in a system. That is, they depict those elements in a

specification that are irrespective of time. The elements in a structure diagram represent the meaningful concepts of an

application, and may include abstract, real-world and implementation concepts. For example, a structure diagram for an

airline reservation system might include classifiers that represent seat assignment algorithms, tickets, and a credit

authorization service. Structure diagrams do not show the details of dynamic behavior, which are illustrated by behavioral

diagrams. However, they may show relationships to the behaviors of the classifiers exhibited in the structure diagrams.

Behavior diagrams show the dynamic behavior of the objects in a system, including their methods, collaborations,

activities, and state histories. The dynamic behavior of a system can be described as a series of changes to the system over

time. Behavior diagrams can be further classified into several other kinds as illustrated in Figure A.5.

Please note that this taxonomy provides a logical organization for the various major kinds of diagrams. However, it does

not preclude mixing different kinds of diagram types, as one might do when one combines structural and behavioral

elements (e.g., showing a state machine nested inside an internal structure). Consequently, the boundaries between the

various kinds of diagram types are not strictly enforced.

The constructs contained in each of the thirteen UML diagrams is described in the Superstructure chapters as indicated

below.

• Activity Diagram - “Activities” on page 307

• Class Diagram - “Classes” on page 21

• Communication Diagram - “Interactions” on page 477

• Component Diagram - “Components” on page 147

• Composite Structure Diagram - “Composite Structures” on page 167

• Deployment diagram - “Deployments” on page 201


Che cos’è e a cosa serve

Si tratta di un diagramma che esprime un comportamento,offerto o desiderato, sulla base dei suoi risultati osservabili.L’oggetto esaminato è solitamente un sistema o una suaparte.Individua chi o che cosa ha a che fare con il sistema(attore) e che cosa viene fatto (caso d’uso).Si tratta tipicamente del primo tipo di diagramma ad esserecreato in un processo o ciclo di sviluppo, nell’ambitodell’analisi dei requisiti.Modella i requisiti funzionali di un sistema.


Requisiti funzionali

I requisiti funzionali specificano cosa deve essere fatto.Sono indipendenti dalla tecnologia, dall’architettura, dallapiattaforma, dal linguaggio di programmazione.I requisiti non-funzionali specificano vincoli aggiuntivi, adesempio:

I performanceI scalabilitàI tolleranza ai guastiI dimensione degli eseguibili

I casi d’uso sono particolarmente utili se la maggior partedei requisiti sono funzionali.


Pitfalls

Questo diagramma specifica cosa va fatto, non come vafatto. Spetta alle fasi successive capire come realizzare icasi d’uso, la fase dei requisiti deve solo specificarli.Evitare riferimenti a tecnologie specifiche nei casi d’uso, perquanto possibile.Scegliere il giusto livello di dettaglio:

I una granularità troppo fine rischia di sconfinare nellaprogettazione

I una troppo grossa rischia di generare ambiguità nelle fasisuccessive

Tenere in mente la leggibilità, questo diagramma dovrebberisultare comprensibile anche a un non-esperto:

I in particolare il cliente (è uno strumento per chiarirsi)


Desiderata

I desiderata sono ciò che il cliente desidera.Formalizzare i desiderata in requisiti è una delle piùimportanti sfide aperte dell’ingegneria del software.La specifica errata o incompleta delle richieste del cliente èuna delle cause principali del fallimento dei progettisoftware.Il diagramma e la modellazione dei casi d’uso aiutanol’interazione con il cliente.


Desiderata: esempio (1)

Cliente:vorrei vendere i manufatti che realizzo...non vorrei solo un mercato locale...mi piacerebbe che gli acquirenti potessero visionare uncatalogo da cui scegliere...vorrei gestire gli ordini da qualunque posto perché viaggiomolto...

Che cosa viene fatto? Da chi?


Desiderata: esempio (2)

Cliente:vorrei avere la possibilità di creare un catalogo dei mieimanufatti...vorrei un catalogo liberamente consultabile da chiunque...vorrei organizzare i manufatti raccogliendoli in categorie...vorrei che gli interessati all’acquisto potessero inviarmi unordine, che io provvederò ad evadere previa una qualcheforma di registrazione...

Desiderata riformulati in maniera migliore.


Estrarre i requisiti

Chi interagisce con il sistema (attori)?ClientiAmministratori del negozio onlineReparto ordini

Cosa fanno (casi d’uso)?Il cliente si registra, consulta il catalogo ed effettua acquistiL’amministratore organizza il catalogo, che è diviso incategorieIl reparto ordini riceve ordini da evadere


Elementi del diagramma: attore

Cliente Admin Resp. Ordini

Un attore specifica un ruolo assunto da un utente o altraentità che interagisce con l’argomento del diagrammanell’ambito di un’unità di funzionamento (caso d’uso).Un attore è esterno all’argomento (sistema) oggetto deldiagramma.Non è necessariamente umano: oggetti fisici, agenti ecomponenti software, condizioni ambientali, ...Una singola entità o parte di entità può assumere moltiruoli, e una collezione di entità può essere rappresentata daun unico attore.


Elementi del diagramma: caso d’uso (1)

Consulta catalogo

Un caso d’uso specifica un insieme di azioni che produconoun risultato osservabile per uno o più attori.Si tratta di un’unità coerente di funzionamento che ilsistema fornisce ad uno o più utenti.La descrizione all’interno dovrebbe essere basata su unverbo o su un sostantivo esprimente un avvenimento.


Elementi del diagramma: caso d’uso (2)

Un caso d’uso è sempre iniziato da un attore: in UML, unevento è sempre legato all’entità che lo ha generato.L’attore che inizia un caso d’uso è detto primario, gli altriattori che interagiscono nell’ambito di quel caso d’uso sonosecondari.Un caso d’uso è un classificatore dotato di comportamento:può essere specificato da diagrammi di stato, interazione,sequenza, avere pre- e post-condizioni, ...Può ammettere al suo interno varianti al comportamentoprincipale.


Elementi del diagramma: sistema

Applicazione web

Acquista prodotto

Organizza catalogo

Consulta catalogo

Delimita l’argomento del diagramma, specificando i confinidel sistema.


Elementi del diagramma: associazione (1)

Cliente

Consulta catalogo

Collega gli attori ai casi d’uso.Un attore si può associare solo a casi d’uso, classi ecomponenti.Un caso d’uso non si può associare ad altri casi d’usoriguardanti lo stesso argomento.Entrambi supportano solo associazioni binarie.


Elementi del diagramma: associazione (2)

Ufficiale

Lancia missile nucleareesecutore

2

lancio

0..1proceduraLancio

Alcune caratteristiche opzionali comuni a tutte leassociazioni in UML:

I nomeI molteplicitàI ruoli


Elementi del diagramma: generalizzazione

Acquista orologio

Impiegato Persona

Acquista prodotto

Collega un attore o caso d’uso ad un altro più generale.Il figlio può sostituire il genitore dovunque questi appaia.In UML, elementi astratti (che non possono essereistanziati) hanno il nome in corsivo.


Elementi del diagramma: include

Acquista prodotto

Effettua pagamento

Consulta catalogo

<<include>>

<<include>>

Una dipendenza tra casi d’uso; il caso incluso fa parte delcomportamento di quello che lo include.L’inclusione non è opzionale ed avviene in ogni istanza delcaso d’uso.La corretta esecuzione del caso d’uso che include dipendeda quella del caso d’uso incluso.Non si possono formare cicli di include.Usato anche per riutilizzare parti comuni a più casi d’uso.


Elementi del diagramma: extend

Acquista prodotto Registra account

<<extend>>

Una dipendenza tra casi d’uso (notare il verso della freccia).Il caso d’uso che estende (client) specifica un incremento dicomportamento a quello esteso (supplier).Si tratta di comportamento supplementare ed opzionale chegestisce casi particolari o non standard.Diverso da una generalizzazione tra casi d’uso:

I in una generalizzazione, entrambi i casi d’uso sonougualmente significativi

I in un extend, il client non ha necessariamente senso sepreso da solo


Extension points

Account non registrato

Extension Points

Acquista prodotto

Registra account<<extend>>

Un caso d’uso raggiunto da almeno un extend puòopzionalmente visualizzare i propri extension points.Specifica i punti e/o condizioni dell’esecuzione in cui ilcomportamento viene esteso.Se gli extension points sono molti, alcuni tool possonosupportare la rappresentazione a rettangolo (i casi d’usosono classificatori).


include vs. extend

Include specifica comportamento obbligatorio.Extend specifica comportamento supplementare.Nell’include la freccia va dal caso d’uso che include versoquello incluso.Nell’extend la freccia va dal caso d’uso che estende versoquello esteso.Sono entrambi costrutti utili, ma non se ne deve abusare, ola leggibilità ne risente.


Esempio diagramma

Cliente

Web store

Evadi ordine

Modifica catalogo

Genera ordine<<include>>

Immetti dati pagamento

<<include>>

Consulta catalogo

<<include>>

Registra account

<<extend>>

Acquista prodotto

Admin

Resp. ordini

Impiegato


Modellare i casi d’uso

Se i requisiti del sistema non sono banali, nasce l’esigenzadi abbinare i diagrammi dei casi d’uso a specifiche testualipiù formali.I diagrammi dei casi d’uso non sono adatti a mostrare:

I la sequenza temporale dei comportamentiI lo stato del sistema e degli attori prima e dopo l’esecuzione

del caso d’uso

Altri diagrammi (attività, stato, interazione) si occupano diqueste viste, ma devono partire da una specifica.


Specifiche del caso d’uso

Ogni caso d’uso ha un nome e una specifica.La specifica è composta da:

I precondizioni (entry conditions): condizioni che devonoessere vere prima che il caso d’uso possa essere eseguito (sono vincoli sullo stato iniziale del sistema)

I sequenza degli eventi (flow of events): i passi checompongono il caso d’uso

I postcondizioni (exit conditions): condizioni che devonoessere vere quando il caso d’uso termina l’esecuzione


Esempio specifica caso d’uso

UML 65

Esempio: relazioni tra casi d’uso

UML 66

Modellazione dei casi d’uso

Modellazione di caso d’uso:

Una vista che concentra l’attenzione su come

viene percepito il comportamento di un

sistema sw da parte di un utente esterno.

Le funzionalità di un sistema vengono

suddivise in transazioni (casi d’uso) utili per

ciascuna delle classi di utilizzatori (attori)

UML 67

Specifiche del caso d'uso

• Ogni caso d'uso ha un nome e una specifica.

• La specifica è composta da:

– Precondizioni (entry conditions): condizioni che devono

essere vere prima che il caso d'uso possa essere

eseguito ( sono vincoli sullo stato iniziale del sistema)

– Sequenza degli eventi (flow of events): i passi che

compongono il caso d'uso

– Postcondizioni (exit conditions): condizioni che devono

essere vere quando il caso d'uso termina l'esecuzione

UML 68

Esempio

Caso d'uso: PagamentoIVA

ID: UC1

Attori:Tempo, Fisco

Precondizioni:1. Si è concluso un trimestre fiscale

Sequenza degli eventi:1. Il caso d'uso inizia quando si conclude un

trimestre fiscale.2. Il sistema calcola l'ammontare dell'IVA

dovuta al Fisco.3. Il sitema trasmette un pagamento

elettronico al Fisco.

Postcondizioni:1. Il Fisco riceve l'importo IVA dovuto.

Nome del caso d'uso

Identificatore univoco

Gli attori interessati dal casod'uso

Lo stato del sistema prima che ilcaso d'uso possa iniziare

I passi del caso d'uso

Lo stato del sistema quandol'esecuzione del caso d'uso è

terminata


Sequenza degli eventi

Un elenco di azioni che definisce il caso d’uso nella suacompletezza.Il caso d’uso si considera eseguito solo se l’esecuzionearriva fino alla fine.Un’azione è sempre iniziata da un attore oppure dalsistema (in UML, gli eventi sono sempre legati a chi li crea).Passo iniziale: 1. Il caso d’uso inizia quando<attore> <azione>...

Passi successivi: <numero>. Il <attore/sistema><azione>


Esempi

Incomincia quando si seleziona la funzione ’ordina libro’Il caso d’uso inizia quando il cliente seleziona la funzione’ordina libro’Vengono inseriti i dati del clienteIl cliente inserisce nel form il suo nome e indirizzoIl sistema verifica i dati del Cliente


Ramificazione di una sequenza

UML usa parole chiave per esprimere ramificazione,ripetizione o sequenze alternative.È bene non eccedere con le ramificazioni.Parola chiave Se: indica una ramificazione della sequenzadegli eventi.Sequenze alternative: ramificazioni che non possonoessere espresse utilizzando il Se. Ad esempio ramificazionidovute a condizioni che si possono verificare in unqualunque momento.Ripetizioni all’interno di una sequenza:

I parola chiave Per (For)I parola chiave Fintantoché (While)


Esempio ramificazione

UML 69

Sequenza degli eventi

• La sequenza degli eventi elenca i passi checompongono il caso d'uso

• Comincia sempre con un attore che fa qualcosa perdare inizio al caso d'uso

• Un buon modo per iniziare la sequenza degli eventi è:1. Il caso d'uso inizia quando un <attore> <funzione>

• Ogni passo del caso d'uso dovrebbe avere lastruttura:

<numero> Il <qualcosa> <qualche azione>

UML 70

Esempio: sequenza degli eventi

Pensiamo al caso d'uso NuovoOrdine. I seguenti passidella sequenza degli eventi sono corretti?

1. Incomincia quando si seleziona la funzione “ordinalibro”

2. Il caso d'uso inizia quando il cliente seleziona lafunzione “ordina libro”

3. Vengono inseriti i dati del cliente

4. Il cliente inserisce nel form il suo nome e indirizzo

5. Il sistema verifica i dati del Cliente

sbagliato

corretto

sbagliato

corretto

corretto

UML 71

• UML usa parole chiave per esprimere ramificazione,ripetizione o sequenze alternative

• È bene non eccedere con le ramificazioni• parola chiave Se: indica una ramificazione della

sequenza degli eventi• Sequenze alternative: ramificazioni che non possono

essere espresse utilizzando il Se. Ad esempioramificazioni dovute a condizioni che si possonoverificare in un qualunque momento

• Ripetizioni all'interno di una sequenza:

– Parola chiave Per (For)

– Parola chiave Fintantoché (While)

Ramificazione di una sequenza

UML 72

EsempioCaso d'uso: AggiornaCarrello

ID: UC2

Attori: Cliente

Precondizioni:1. Il contenuto del carrello è visibile

Sequenza degli eventi:1. Il caso d'uso inizia quando il Cliente

seleziona un articolo nel carrello.2. Se il Cliente seleziona “rimuovi articolo”

2.1 Il Sistema elimina l'articolodal carrello.

3. Se il Cliente digita una nuova quantità3.1 Il Sistema aggiorna la quantità

dell'articolo presente nel carrello

Postcondizioni:1. Il contenuto del carrello è stato aggiornato

Sequenza alternativa 1:1. In qualunque momento il Cliente

può abbandonare la pagina del carrello

Postcondizioni:


Sequenze alternative

Ad ogni passo della sequenza degli eventi principale,cercare:

I alternative all’azione eseguita in quel passoI errori possibili nella sequenza principaleI interruzioni che possono avvenire in qualunque momento

della sequenza principaleSequenze alternative abbastanza complesse possonoessere descritte separatamente.

I stessa sintassi, si sostituisce ’caso d’uso’ con ’sequenzadegli eventi alternativa’

I il primo passo può indicare il punto della sequenzaprincipale da cui si proviene


Scenari

Uno scenario rappresenta una particolare interazione trauno o più attori e il sistema.Uno scenario è un’istanza di un caso d’uso.Non contiene ramificazioni o sequenze alternative: èsemplicemente la cronaca di un’interazione vera overosimile.

I il concetto risulta più immediato pensando agli attori inmaniera concreta: non un generico cliente, ma Alice o Bob

Utili per immaginare il sistema all’opera e modellare i casi ditest.


Scenario principale e scenari secondari

Corrispondono ad esecuzioni della sequenza principale e diquelle alternative, rispettivamente.Strategie per limitare il numero, potenzialmente enorme,degli scenari secondari:

I documentare solo quelli considerati più importantiI se ci sono scenari secondari molto simili, se ne documenta

uno solo, se necessario aggiungendo annotazioni perspiegare come gli altri scenari differiscano dall’esempio.


Consigli per l’individuazione dei casi d’uso

Mantenere i casi d’uso brevi e sempliciI la descrizione non dovrebbe superare una paginaI evitare dettagli di progettazioneI non appesantirli con informazioni non essenziali

Evitare la scomposizione funzionaleI non scomporre i casi d’uso con il metodo top-down (es. caso

d’uso GestisciBiblioteca scomposto in GestioneLibri eGestionePrestiti e via via nei dettagli)

I i casi d’uso emergono dai requisiti, non bisogna cercare diorganizzarli in maniera artificiosa


Requisiti: in pratica

Analizzare il materiale contenente i requisitiCreare un glossario di progetto con parole chiave e unabreve descrizioneCapire chi sono gli attoriEstrarre i casi d’uso più evidentiCominciare ad organizzare i casi d’uso in un diagrammaModellare i casi d’uso come sequenze di eventiRaffinare progressivamente se necessario


Conclusioni

Il diagramma UML dei casi d’uso è un tool per lamodellazione del comportamento di un sistema.Descrive gli attori che interagiscono con il sistema, cosafanno, e cosa ottengono dal sistema.A questo punto non interessa sapere come il sistemafornisca il comportamento richiesto.


Il diagramma dei casi d'uso - cs.unibo.it · Il diagramma dei casi d’uso Laboratorio di Sistemi e...

Documents

Transcript of Il diagramma dei casi d'uso - cs.unibo.it · Il diagramma dei casi d’uso Laboratorio di Sistemi e...