UML: Use Cases
Corso IS I - 2002/03
Gianna Reggio
Versione 0.0
Use Cases
• Tecnica per
– esprimere requisiti/proprietà funzionali su un sistema
– descrivere dal punto di vista di chi lo usa (senza
guardare come è fatto) un sistema
* sistemi di vario genere
˚ quello softaware\hardware da sviluppare
˚ Il business da supportare con il software da sviluppare
* Ma anche una componente/un sottosistema
• Sviluppata indipendentemente da UML (e dal mondo
OO)
• Non visuale (solo testo, al più formattato in modo
standard)
• UML offre una notazione visuale per presentare alcuni
aspetti di un insieme di use case
v. 0.0
Use cases: che cosa sono
• Alcune definizioni dalla letteratura corrente
– A complete set of use cases specifies all the different
ways to use the system, and thus defines all behavior
required of the system, bounding the scope of the
system.
– User goals summarize system functions (functional
requirements) in verifiable terms of use that users,
executives, and developers can appreciate and validate
against their interests.
v. 0.0
Esempio tipico (1)
Use Case: Deposit Money
frase verbale
Scope: Bank Accounts and Transactions System
Level: User Goal
Intention in Context: The intention of the Client is to deposit
money on an account. Clients do not interact with the System
directly; instead, for this use case, a Client interacts via a Teller.
Many Clients may be performing transactions and queries at any
one time.
Primary Actor: Client
Main Success Scenario:
1. Client requests Teller to deposit money on an account,
providing sum of money.
2. Teller requests System to perform a deposit, providing deposit
transaction details.
3. System validates the deposit, credits account for the amount, v. 0.0
records details of the transaction, and informs Teller.
Esempio tipico (2)
Extensions:
2a. Client requests Teller to cancel deposit: use case ends in
failure.
3a. System ascertains that it was given incorrect information:
3a.1. System informs Teller; use case continues at step 2.
3b. System ascertains that it was given insufficient information to
perform deposit:
3b.1. System informs Teller; use case continues at step 2.
3c. System is not capable of depositing (e.g. transaction monitor of
System is down):
3c.1. System informs Teller; use case ends in failure.
v. 0.0
Attori (1)
• Alcune definizioni
– The actors represent what interacts with the system.
– An actor represents a role that an external entity such as
a user, a hardware device, or another system plays in
interacting with the system.
A role is defined by a set of characteristic needs,
interests, expectations, behaviors and responsibilities.
• In generale un attore comunica mandando
messaggi al/ricevendo messaggi dal sistema sotto
considerazione
• In generale un use case non si limita ad un solo
v. 0.0
attore
Attori (2)
• Come trovare gli attori
– Cercare le entità esterne che interagiscono con il sistema
* Quali persone interagiscono con il sistema (direttamente o
indirettamente)? Non dimenticare la manutenzione
* Il sitema interagirà con altri sistemi o sistemi legacy?
* Ci sono dei dispositivi hardaware o softaware che interagiscono
con il sistema ?
* Ci sono interafcce per presentare rapporti sull’attività o interfacce
per scopi amministrativi ?
• 2 categorie di attori
– Primari
* chi ha delle mire sul sistema
* chi guadagna qualcosa dal sistema
– Secondari
* quelli su cui il sistema ha delle mire
* chi produce qualcosa per il sistema
v. 0.0
Limiti del sistema considerato
• Quando si vuole utilizzare gli use case è
importante aver ben chiaro i limti del sistema sotto
considerazione
v. 0.0
Scenario
• Uno scenario è una sequenza ordinata di
interazioni tra un sistema ed un insieme di attori
esterni al sistema
• Uno scenario rappresenta una particolare
esecuzione di un use case (istanza), e rappresenta
un singolo cammino attraverso l’use case
• Gli scenari sono utili poichè
– Forniscono un prototipo di carta
– È più facile partire con scenari (concreti) e poi
generalizzare
– Sono usati per il testing
• Gli scenari possono essere presentati usando i
sequence diagram di UML
v. 0.0
Cosa è un use case
• Un use case cattura chi (attori) fa cosa
(interazione) con il sistema. Con quale scopo
(goal), senza consoderare 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
– Definisce scopo ed intento (non azioni concrete)
– È generale e indipendente dalla tecnologia
v. 0.0
Use Case Description
• Gli use case sono principalmente descrizioni testuali
• I passi di un use case sono scritti come narrattiva
strutturata, facile da capire, usando il vocabolario del
dominio dell’applicazione
• Gli use case sono descrizioni chiare, precise, generali, e
indipendenti dalle tecnologie
• Un use case riassume un gruppo di scenari
• Ogni scenario parte dal trigger (evento scatenante) fino al
suo completamento
• La descrizione di un use case include
– Come lo use case inizia e come finisce
– Il contesto dello use case
– Il comportamento degli attori e del sistema descritti come intenzioni
e responsabilità
– Tutte le circostanze in cui il goal dell’attore primario è raggiunto e
quando no
v. 0.0
– Che informazioni sono scambiate tra attori e sistema
Granularità degli use case
• Una proposta recente per tre livelli di use case
– summary level
* Dall’aereo
– user–goal level
* a livello del mare
– Subfunction level
* da sotto l’acqua
v. 0.0
Granularità degli use case (2)
• Summary level UC
– possono descrivere gli scopi principali del sistema
– di solito ciascuno si può decomporre in vari user–goal UC
• User-goal UC
– Descrivono un goal che un attore primario od un utente ha per
avere qualcosa fatto dal sistema o usando il sitema
– Di solito sono fatti da una persona, in un posto, ad un certo tempo;
l’attore primario di solito se ne va felice e contento immediatamente
dopo che l’use case è terminato
• Subfunction UC
– Forniscono supporto esecutivo ad user-goal UC
– Sono a basso livello e devono essere giustificati o per ragioni di
riuso o per fornire I necessari dettagli in modo strutturato
v. 0.0
UML supporto per gli use case
• Use case diagram
– Per presentare i vari use case con gli attori coinvolti
– Possibilità di definire relazioni tra use case (poco chiare,
meglio limitarsi ad usare quelle sufficientemente precise)
• Attori = tipo di classifier (stereotype)
– Quindi è possibile descriverli in un class diagram
(association, specialization…)
• Vari diagrammi di UML possono essere utilizzati
per descrivere un singolo use case (es. activity,
state chart) o uno scenario singolo (sequence,
collaboration)
v. 0.0
Use case diagram
attore partecipa
all’use case
Use case
attore
UC1
act-name3
…...
act-name1
…...
UCk
act-name2
System-name
Nome del sistema
descritto con gli use case
v. 0.0
Include
• Relazione tra use case
– Significa che un use case incorpora esplicitamente il
comportamento di un altro use in un punto specificato
nel primo
UC1
<<include>>
UC1
v. 0.0
Esempio con include
v. 0.0