UML: Use Cases Corso IS I - 2002/03

1
UML Use CasesCorso IS I - 2002/03

• Gianna Reggio
• Versione 0.0

2
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

3
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.

4
Esempio tipico (1)

• Use Case Deposit Money

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, records details of the transaction, and
informs Teller.
5
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.

6
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
  attore

7
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
  sullattività 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

8
Limiti del sistema considerato

• Quando si vuole utilizzare gli use case è
  importante aver ben chiaro i limti del sistema
  sotto considerazione

9
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 luse
  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

10
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

11
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 dellapplicazione
• 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 dellattore
  primario è raggiunto e quando no
• Che informazioni sono scambiate tra attori e
  sistema

12
Granularità degli use case

• Una proposta recente per tre livelli di use case
• summary level
• Dallaereo
• usergoal level
• a livello del mare
• Subfunction level
• da sotto lacqua

13
Granularità degli use case (2)

• Summary level UC
• possono descrivere gli scopi principali del
  sistema
• di solito ciascuno si può decomporre in vari
  usergoal 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 lattore primario di solito se
  ne va felice e contento immediatamente dopo che
  luse 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

14
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)

15
Use case diagram
16
Include

• Relazione tra use case
• Significa che un use case incorpora
  esplicitamente il comportamento di un altro use
  in un punto specificato nel primo

17
Esempio con include