Analisi dei requisiti

•Il primo passo di “qualsiasi” processo di sviluppo è ladefinizione dei requisiti

Definizione del Business ModelSolitamente 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 imporreAttori diversi e Use case diversi

Esempio diagramma dei casi d'uso

verifica stato avanzamento

effettua ordine

Venditore

Customer

Diagramma dei casi d'uso: vendita per corrispondenza

caso d'uso: particolarità di uso

del sistemaattore: un utilizzatore del sistema (essere umano,

altro sistema, …)

Esempio di associazione(Registrazione corsi)

Generalizzazione (1)

•Lo use case figlioEredita tutti gli attributi, scenari… definiti nello use case padrePartecipa a tutte le relazioni in cui è coinvolto lo use case

padreLo use case figlio può prevedere nuovi scenari non previsti

nello use case padre o ridefinirne alcuni Padre

•Uno use casePuò ereditare da n altri use casesPuò 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/c2 l’addetto riceve il cliente e fornisce spiegazioni3 se il cliente accetta fornisce i propri dati4 l’addetto verifica se il cliente è censito in anagrafica5 l’addetto crea il nuovo conto corrente6 l’addetto segnala il numero di conto al clienteVarianti:3 (a) se il cliente non accetta il caso d’uso termina3 (b) se il conto va intestato a più persone vanno forniti i dati di tutte4 (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