Analisi dei requisiti
•Il primo passo di “qualsiasi” processo di sviluppo è la
definizione dei requisiti
Definizione del Business Model
Solitamente informale e in linguaggio naturale
•Jacobson propone una notazione particolare che è confluita in
UML
USE CASE DIAGRAMS
Caso d'Uso (def. Jacobson)
• “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.” (Jacobson 1995)
Use Case -definizioni preliminari
• Descrive una particolare funzionalità fornita dal sistema
o da una sua parte dal punto di vista dell’utilizzatore.
• Mostra le unità coinvolte nella fornitura del sistema
(attori e sistema)
• Uno use case:

Rappresenta le funzionalità visibili dall’utente

Può avere differenti granularità

Rappresenta un obiettivo specifico per l’utente
• In generale, gli use case vengono ricavati sulla base di
colloqui con diversi profili di utenti che utilizzeranno il
sistema
Use Case -notazione
Actor: è qualcuno (utente) o qualcosa (sistemi esterni hardware) che:
•Controlla le funzionalità
•Fornisce input o riceve output dal sistema
Use Case: è un’unità funzionale parte
del sistema
Use Case -attori

Attore: entità esterna al sistema che interagisce con esso assumendo un ruolo

Diversi attori con lo stesso ruolo e diversi ruoli con lo stesso attore

Diversi attori possono esercitare uno use case e diversi use case che possono essere esercitati da
un attore

Non è detto che un attore corrisponda a una o più persone (es. sistema esterno)

Gli attori possono essere il mezzo per individuare gli use case (individuo una lista di attori)

Gli use case rappresentano le funzionalità ai morsetti del sistema
Relazione tra attori e use-case
•Può capitare che una funzione esista perché di interesse di un attore
che non partecipa all’azione stessa
•Azione indotta da altre iniziative del sistema e ha come destinatario un
attore fuori dal contesto operativo
•Es. notifica ordine di pagamento ad un compratore dopo 2 mesi
dall’acquisto
•Un attore, nei confronti di uno use case può esserne il beneficiario, il
controllore, informato,…
Relazione casi d'uso come interazioni
• i casi d’uso possono essere descritti sotto forma di scenario di
interazione (dialogo) tra gli utilizzatori e il sistema:
– 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 va rivolta all’interazione, non alle attività interne al
sistema
Relazioni principali
Associations identificano relazioni semplici tra attori e casi
Include fattorizza proprietà comuni. A includes B
Extend identifica comportamenti simili (varianti). A può essere visto come una
variante di B
Generalization si applica sia ad attori che a use case. A eredita il comportamento di
B. A può essere sostituito ad ogni occorrenza di B
Esempio di associazione
(Ufficio Postale)
•Il primo Use Case diagram definisce il contesto del
modello
•Scelte diverse possono imporre
Attori diversi e Use case diversi
Esempio diagramma dei casi d'uso
Diagramma dei casi d'uso: vendita per corrisponde
effettua ordine
Venditore
verifica stato avanzamento
Customer
attore: un utilizzatore del
sistema (essere umano,
altro sistema, …)
caso d'uso:
particolarità di uso
del sistema
Esempio di associazione
(Registrazione corsi)
Generalizzazione (1)
•Lo use case figlio
Eredita tutti gli attributi, scenari… definiti nello use case padre
Partecipa a 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 ridefinirne alcuni Padre
•Uno use case
Può ereditare da n altri use cases
Può essere il padre di n altri use case
Generalizzazione (2)
Inclusione
•Esistono use case che rappresentano attività ricorrenti condivise da use
case più complessi
•Per evitare di ripetere in ogni use case la descrizione dell’attività comune
la si mette a fattor comune indicando che viene inclusa in use case più
complessi
•La funzionalità individuata viene inclusa in un punto specifico o nella sua
interezza nella sequenza di interazioni che caratterizza lo use case base.
•Analogie con
Chiamata a sottoprocedura in un linguaggio di programmazione
•Stereotipo : <<include>>
Punti Estensione
Estensione
•Viene specificato in che modo sotto quali condizioni il comportamento
individuato dallo use case estensione può essere incorporato nello use case base
•E’ necessario specificare sempre i punti estensione
•Quando si verifica la condizione di estensione lo use case estensione viene
inglobato nello use case base
•Stereotipo: <<extend>>
Esempio di inclusion
(Immobiliare)
Esercizio
(livello 0)
Raffinamento use-case
(livello 1)
Modellazione flussi di eventi
•Flusso di eventi principali: corrisponde allo scenario di esecuzione ideale
L’attore non compie e non genera errori
Un flusso di eventi principale è sempre presente
•Flusso di eventi eccezionale
Cammino percorso in presenza di errori
Cammino percorso con bassa frequenza
Un caso d’uso presenta molto spesso eventi eccezionali
Modellazione flussi di eventi
• scenario base: è (di solito) quello che prevede il successo del
caso d’uso, ed uno svolgimento lineare
• scenari alternativi: possono essere di successo o fallimento,
con complicazioni varie
• non è necessario (e sarebbe molto costoso) analizzare in
dettaglio tutti i possibili scenari di un caso d’uso (combinazioni di
varianti)
• è invece necessario individuare le singole possibili varianti che
possono portare al fallimento del caso d’uso, o che comportano
trattamenti particolari
esempio: apertura conto corrente
1 il cliente si presenta in banca per aprire un nuovo c/c
2 l’addetto riceve il cliente e fornisce spiegazioni
3 se il cliente accetta fornisce i propri dati
4 l’addetto verifica se il cliente è censito in anagrafica
5 l’addetto crea il nuovo conto corrente
6 l’addetto segnala il numero di conto al cliente
Varianti:
3 (a) se il cliente non accetta il caso d’uso termina
3 (b) se il conto va intestato a più persone vanno forniti i dati di tutte
4 (a) se il cliente (o uno dei diversi intestatari) non è censito l’addetto
provvede a registrarlo
Use case
(Processo)
•Il processo di definizione degli use case è iterativo
Si inizia identificando il comportamento più semplice
Si descrivono i comportamenti alternativi e più complessi
•Quando smettere?
Un buon livello di dettaglio facilità tutte le attività successive
Troppi dettagli
- Complicherebbero inutilmente la descrizione
- Introdurrebbero prematuramente scelte progettuali
- Precluderebbero la visione d’insieme