Archivi categoria: casi d’uso

casi d'uso

Casi d’uso e scenari alternativi

Lo scenario base di un caso d’uso (descrizione funzionale) può avere numerose varianti. Alcune tra queste sono semplici, altre complesse, e possono a loro volta dare origine ad ulteriori varianti.

Come gestire le varianti di varianti? Me lo ha chiesto una studentessa di informatica, proponendo un esempio interessante, che riporto qui. Nel seguito la mia risposta, con uso degli scenari alternativi.

Buongiorno Dott. Comai,

mi chiamo xxx, studentessa di informatica.

In questi giorni sto tentando di documentare alcuni semplici casi d’uso, utilizzando il suo template:

(http://adcorsi.com/analisidisegnowp/wpcontent/uploads/2013/08/templatecasiuso.odt)

Nel descrivere i casi d’uso mi è sorto, però, un dubbio:

E’ possibile che una variante dello scenario base abbia a sua volta varianti? C’è qualche regola che lo vieta?

Ad esempio, per il caso d’uso PrelievoSoldi (molto semplice) ho il seguente scenario base:

  1. Il cliente inserisce la tessera e inserisce il pin
  2. Il sistema valida il pin
  3. Il cliente indica l’importo da prelevare
  4. Il sistema autorizza il prelievo e restituisce la tessera
  5. Il cliente ritira la tessera, il denaro e la ricevuta.

Vorrei descrivere la situazione particolare in cui il sistema non riconosce il pin (passo 2). In tal caso l’utente può effettuare altri due tentativi, se sbaglia anche l’ultimo tentativo il sistema restituisce la tessera ed il caso d’uso termina con errore.

Non so se la descrizione dell’anomalia sia meglio esprimerla in una sola variante oppure descrivere ogni tentativo come variante di variante. Di seguito le riporto le mie due soluzioni:

Soluzione con unica variante dello scenario base:

2a.Se il sistema non riconosce il cliente, il cliente deve reinserire il proprio pin. Se il sistema riconosce il pin, il cliente torna al passo 3 dello scenario base. Altrimenti, lo reinserisce ancora e se il sistema non lo riconosce nuovamente restituisce la tessera al cliente.

Soluzione con variante per ogni tentativo:

Variante 1:

2a. Il pin non è valido

      1. Il cliente inserisce di nuovo il proprio pin.

        2. Il sistema valida il pin, si ritorna al passo 3 dello scenario

            base

Variante 2: variante della variante 1

2a.2a. Il pin non è valido

        1. Il cliente inserisce di nuovo il proprio pin

         2. Il sistema valida il pin, e ritorna al passo 3 dello scenario 

             base

Variante 3: variante della variante 2

2a.2a.2a. Il pin non è valido

              1. Il sistema restituisce la tessera e termina il caso d’uso con errore.

                2. Il cliente ritira la tessera

Spero possa aiutarmi

Grazie

La soluzione è l’uso degli scenari alternativi, cioè di descrizioni di scenario ulteriori rispetto allo scenario base, anche se ad esso riconducibili. In pratica:

Prendere la variante che può avere varianti, e “promuoverla” a scenario alternativo.

Lo scenario alternativo:
1 – è una variante a cui viene attribuito un titolo (es. “Pin non valido”) e che può essere a sua volta articolata in una serie di passi
2 – referenzia il passo dello scenario base da cui parte, come una variante, quindi parte con un “se…”
3 – indica come si conclude il caso d’uso (tornando a un passo dello scenario base, o con un esito diverso)
4 – può avere proprie varianti
analisi, casi d'uso, requisiti

Casi d’uso infrastrutturali

Proseguendo nell’opera di adeguamento della tecnica dei casi d’uso (Use-cases 2.0) Jacobson propone la definizione di casi d’uso infrastrutturali, per integrare gli aspetti non funzionali – essenziali per la gestione di ogni sistema, ma “interni” – che non trovavano posto nelle versioni iniziali della sua teoria.

Dall’articolo Use-Case 2.0, apparso su Communications of the ACM, maggio 2016:

Handling all types of requirements

Although they are one of the most popular techniques for describing systems’ functionality, use cases are also used to explore non-functional characteristics. The simplest way of doing this is to capture them as part of the use cases themselves—for example, relating performance requirements to the time taken between specific steps of a use case or listing the expected service levels for a use case as part of the use case itself.

Some non-functional characteristics are subtler than this and apply to many, if not all, of the use cases. This is particularly true when building layered architectures, including infrastructure components such as security, transaction management, messaging services, and data management. The requirements in these areas can still be expressed as use cases—separate use cases focused on the technical usage of the system. These additional use cases are called infrastructure use cases, as the requirements they contain will drive the creation of the infrastructure on which the application will run.

agile, casi d'uso, requisiti, software engineering

Casi d’uso 2.0

Ivar Jacobson ha pubblicato Use-Case 2.0 White Paper, in cui propone una serie di modifiche alla teoria e alla pratica dei casi d’uso.

Lo scopo è di rendere i casi d’uso più compatibili con lo sviluppo agile, in particolare con Scrum, e con le tecniche lean tipo Kanban.

Tra le proposte, centrale il concetto di “Use Case Slice”, cioè l’idea di poter affettare un caso d’uso per poterne gestire meglio la pianificazione, lo sviluppo e il test.

casi d'uso

Casi d’uso, inclusioni, estensioni

Lascia un commento

La mia guida alla scrittura dei casi d’uso è sempre molto usata, così come la relativa template.

Periodicamente ricevo delle richieste di chiarimento su aspetti particolari, e la più recente contiene una serie di domande interessanti, che meritano risposte pubbliche.

  • La verifica della  pre-condizione per un caso d’uso è automatica, oppure è necessario inserire all’inizio dello scenario dei passi per la sua verifica?
    Non è automatica, nel senso che non viene effettuata automaticamente da uno strumento; si dà per implicita e non va descritta nel testo degli scenari.
  • Posso documentare i casi d’uso “di estensione” e quelli “di inclusione”  con lo stesso template utilizzato per documentare qualunque altro caso d’uso?
    Sì.
  • Come qualunque altro caso d’uso, quelli “di inclusione” hanno le loro pre-condizioni e trigger ( stimolo di attivazione) che devono verificarsi affinché possano partire? Oppure quando richiamati dal caso d’uso base, partono direttamente?
    I casi d’uso di inclusione non sono casi d’uso veri e propri, ma solo frammenti di caso d’uso. Quindi vengono sempre attivati da altri casi d’uso.
  • Come qualunque altro caso d’uso, quelli di “estensione” hanno le loro pre-condizioni e trigger ( stimolo di attivazione) che devono verificarsi insieme alla relazione di extend affinché possano partire? Oppure quando richiamati dal caso d’uso base, viene verificata solo la condizione di extend?
    Anche i casi d’uso di estensione sono solo frammenti di casi d’uso, ma a differenza di quelli di inclusione non vengono “richiamati”.  Il caso d’uso base ignora le proprie estensioni, definisce solo degli extension point a cui i casi d’uso di estensione fanno riferimento.
  • La verifica della condizione di extend è automatica, oppure è necessario inserire dei passi per la sua verifica, all’inizio dello scenario del caso d’uso di estensione ?
    Anche qui, la verifica non è automatica, ma si dà per implicita.
  • La precondizione e la condizione di extend possono coincidere(stessa condizione), in alcune situazioni?
    Le precondizioni vanno definite per i casi d’uso base, e specificano una condizione necessaria per raggiungere l’obiettivo del caso d’uso. Ogni caso d’uso “reale” (base) ha un obiettivo da conseguire, mentre i frammenti di caso d’uso (inclusioni, estensioni, specializzazioni) non hanno obiettivi autonomi propri, sono semplicemente porzioni di attività che si preferisce descrivere in modo separato. Quindi definire precondizioni per i frammenti di caso d’uso è una forzatura.
  • Nel documentare il caso d’uso di estensione con il template, posso aggiungere un’apposita sezione in cui riportare la condizione di extend?
    Sì, anche se io preferisco usare per questo il primo passo del relativo scenario.
  • Posso inserire all’interno di un caso di estensione più comportamenti, uno per ogni extension point del caso d’uso base?
    Ogni caso d’uso di estensione è collegato ad un unico extension point del caso d’uso base a cui si riferisce.
  • Se ho un caso d’uso di estensione con più comportamenti, dovrò utilizzare una pre-condizione per ogni scenario di comportamento oppure un unica precondizione per tutti? In altri termini la precondizione ha senso solo a livello di caso d’uso oppure anche per ogni singolo comportamento previsto all’interno del caso d’uso di estensione?
    La precondizione ha senso solo a livello di caso d’uso complessivo.
  • Cosa intende quando afferma che il caso d’uso è completo? ( paragrafo 4.3.3 e 6.2 di “Linee guida UML-Casi d’uso)
    Un caso d’uso è completo quando in caso di successo raggiunge il suo obiettivo, e quando, anche in caso di insuccesso, lascia comunque il sistema in uno stato consistente.