Introduzione. UP: Influenza tra elaborati

Transcript

1 Luca Cabibbo Analisi e Progettazione del Software Casi d uso Capitolo 6 marzo 2013 Il primo passo indispensabile per ottenere dalla vita ciò che si vuole: decidere che cosa si vuole. Ben Stein 1 *** AVVERTENZA *** I lucidi messi a disposizione sul sito del corso di Analisi e progettazione del software NON sostituiscono il libro di testo 2

2 Introduzione I casi d uso sono storie scritte che descrivono il funzionamento del sistema che deve essere realizzato utili per identificare e registrare requisiti ruolo rilevante anche nell analisi e progettazione a oggetti ad esempio, il processo UP è guidato dai casi d uso possono essere applicati anche nello sviluppo basato su componenti possono essere applicati anche in altri contesti diversi analisi di processi di business progettazione di interfacce grafiche definizione di test di sistema produzione di manuali e guide utente... 3 UP: Influenza tra elaborati 4

3 6.1 Esempio I casi d uso sono storie scritte che raccontano come gli utenti (attori) possono raggiungere i loro obiettivi usando il sistema Elabora Vendita: Un cliente arriva alla cassa con alcuni articoli da acquistare. Il cassiere usa il sistema POS per registrare ogni articolo acquistato. Il sistema mostra il totale e i dettagli per ogni articolo. Il cliente inserisce informazioni sul pagamento, che il sistema convalida e registra. Il sistema aggiorna l inventario. Il cliente riceve dal sistema una ricevuta e poi se ne va con gli articoli acquistati. un caso d uso è una storia scritta non un diagramma una storia che descrive come il sistema può essere usato per far raggiungere degli obiettivi ai suoi utenti requisiti funzionali Attori, scenari, casi d uso Un attore è qualcosa o qualcuno dotato di comportamento e che interagisce con il sistema persone con un ruolo, sistemi informatici, organizzazioni ad es., Cassiere oppure Sistema esterno per la contabilità Uno scenario (istanza di caso d uso) è una sequenza specifica di azioni e interazioni tra il sistema e alcuni attori descrive una particolare storia nell uso del sistema ad es., un acquisto con pagamento in contanti scenari di successo e di fallimento ad es., un fallito acquisto per pagamento con carta di credito non autorizzato Un caso d uso è una collezione di scenari correlati, di successo e fallimento, che descrivono un attore che usa un sistema per raggiungere un obiettivo 6

4 Esempio (in formato informale) Elabora Vendita Scenario principale di successo: Un cliente arriva alla cassa con alcuni articoli da acquistare. Il cassiere usa il sistema POS per registrare ogni articolo acquistato.... Scenari alternativi: Se il codice identificativo dell articolo non viene trovato nel sistema, allora il sistema avvisa il cassiere e suggerisce l inserimento manuale del codice (può darsi che sia danneggiato). Se il cliente chiede al cassiere di eliminare un articolo dall acquisto, allora il cassiere inserisce il codice di quell articolo ed il sistema lo elimina e visualizza il totale aggiornato della vendita. Se il sistema rileva un fallimento nella comunicazione con il sistema esterno di gestione della contabilità, allora 7 Casi d uso Una definizione alternativa [RUP] un caso d uso è un insieme di istanze di casi d uso, in cui ciascuna istanza è una sequenza di azioni che un sistema esegue per produrre un risultato osservabile e di valore per uno specifico attore enfasi: l uso del sistema fornisce all utente un valore osservabile e gli permette di raggiungere degli obiettivi 8

5 6.3 Casi d uso e Modello dei casi d uso Il Modello dei casi d uso è l elaborato di UP che contiene l insieme dei casi d uso i casi d uso sono documenti di testo non diagrammi la modellazione dei casi d uso è un atto di scrittura di testi non di disegno di diagrammi In UP ci sono anche altri elaborati per i requisiti il Modello dei casi d uso può contenere diagrammi dei casi d uso indice visuale per l insieme dei casi d uso diagramma di contesto Perché i casi d uso Vantaggi dei casi d uso strumento semplice per descrivere i requisiti funzionali direttamente comprensibile dagli utenti permettono di coinvolgere gli utenti enfasi sul valore fornito agli utenti scalabilità nel livello di dettaglio e nella (in)formalità basati su scenari requisiti nel contesto base per la guida per l utente del sistema base per i test di sistema... Limiti non sono sempre applicabili 10

6 6.5 Casi d uso e requisiti funzionali I casi d uso sono requisiti principalmente requisiti funzionali possono riportare anche requisiti non funzionali definiscono una promessa o un contratto del comportamento del sistema uno stile più moderno rispetto a una più antiquata elencazione di funzioni e caratteristiche funzionali il sistema deve Tre tipi di attori Un attore è qualcosa o qualcuno dotato di comportamento e che interagisce con il sistema, compreso il Sistema in discussione (SuD) coloro che compaiono nei passi di un caso d uso ruoli svolti da persone, organizzazioni, software, sistemi Tre tipi di attori attore primario raggiunge degli obiettivi usando il SuD perché vanno identificati? per trovare gli obiettivi degli utenti attore di supporto (sistema o organizzazione che) offre servizi al SuD perché? interfacce esterne e protocolli attore fuori scena ha interesse nel comportamento del SuD perché? parti interessate e interessi 12

7 6.7 Formati comuni per i casi d uso I casi d uso possono essere scritti in vari formati, a secondo delle esigenze, con un grado variabile di formalità e dettaglio formato breve (brief) formato informale (casual) formato dettagliato (fully dressed) 13 Caso d uso in formato breve Elabora Vendita: Un cliente arriva alla cassa con alcuni articoli da acquistare. Il cassiere usa il sistema POS per registrare ogni articolo acquistato. Il sistema mostra il totale e i dettagli per ogni articolo. Il cliente inserisce informazioni sul pagamento, che il sistema convalida e registra. Il sistema aggiorna l inventario. Il cliente riceve dal sistema una ricevuta e poi se ne va con gli articoli acquistati. 14

8 Caso d uso in formato informale Elabora Vendita Scenario principale di successo: Un cliente arriva alla cassa con alcuni articoli da acquistare. Il cassiere usa il sistema POS per registrare ogni articolo acquistato.... Scenari alternativi: Se il codice identificativo dell articolo non viene trovato nel sistema, allora il sistema avvisa il cassiere e suggerisce l inserimento manuale del codice (può darsi che sia danneggiato). Se il cliente chiede al cassiere di eliminare un articolo dall acquisto, allora il cassiere inserisce il codice di quell articolo ed il sistema lo elimina e visualizza il totale aggiornato della vendita. Se il sistema rileva un fallimento nella comunicazione con il sistema esterno di gestione della contabilità, allora Un caso d uso in formato dettagliato Possibile modello (template) di un caso d uso in formato dettagliato nome del caso d uso portata (scope) livello attore primario parti interessate e interessi pre-condizioni garanzia di successo scenario principale di successo estensioni requisiti speciali elenco delle varianti tecnologiche e dei dati frequenza di ripetizione varie 16

9 Un caso d uso in formato dettagliato Possibile modello (template) di un caso d uso in formato dettagliato nome del caso d uso portata (scope) livello attore primario parti interessate e interessi pre-condizioni garanzia di successo scenario principale di successo estensioni requisiti speciali elenco delle varianti tecnologiche e dei dati frequenza di ripetizione varie la sezione più importante del caso d uso: una sequenza di passi che costituisce il percorso tipico di successo che soddisfa gli interessi delle parti interessate 17 Un caso d uso in formato dettagliato Possibile modello (template) di un caso d uso in formato dettagliato nome del caso d uso portata (scope) livello attore primario parti interessate e interessi pre-condizioni garanzia di successo scenario principale di successo estensioni requisiti speciali elenco delle varianti tecnologiche e dei dati frequenza di ripetizione varie le estensioni descrivono per differenza dallo scenario principale tutti gli altri scenari che compongono il caso d uso 18

10 Un caso d uso in formato dettagliato Possibile modello (template) di un caso d uso in formato dettagliato nome del caso d uso portata (scope) livello attore primario parti interessate e interessi pre-condizioni garanzia di successo scenario principale di successo estensioni requisiti speciali elenco delle varianti tecnologiche e dei dati frequenza di ripetizione varie il preambolo scritto prima dello scenario principale contiene informazioni (opzionali) che può essere utile leggere prima dello scenario principale 19 Un caso d uso in formato dettagliato Possibile modello (template) di un caso d uso in formato dettagliato nome del caso d uso portata (scope) livello attore primario parti interessate e interessi pre-condizioni altre sezioni garanzia di successo scenario principale di successo estensioni requisiti speciali elenco delle varianti tecnologiche e dei dati frequenza di ripetizione varie 20

11 Elabora Vendita Caso d uso UC1: Elabora Vendita (Process Sale) Portata: Applicazione POS NextGen Livello: obiettivo utente Attore primario: Cassiere Parti interessate e interessi: - Cassiere: Vuole un inserimento dei dati preciso e rapido. Non vuole errori nei pagamenti, perché gli ammanchi di cassa vengono detratti dal suo stipendio. - Addetto alle vendite: Vuole che le commissioni sulle vendite siano aggiornate. 21 Elabora Vendita - Cliente: Vuole effettuare acquisti e fruire di un servizio rapido, nel modo più semplice possibile. Vuole una visualizzazione chiara degli articoli inseriti e dei loro prezzi. Vuole una prova d acquisto per una eventuale restituzione o sostituzione. - Azienda: Vuole registrare accuratamente le transazioni effettuate e soddisfare gli interessi dei clienti. Vuole che vengano registrati i pagamenti da riscuotere tramite il Servizio di Autorizzazione di Pagamento. Vuole una certa tolleranza ai guasti per consentire di effettuare vendite anche se alcuni componenti del server (per esempio, l autorizzazione remota di pagamento con credito) non sono disponibili. Vuole un aggiornamento automatico e rapido della contabilità e dell inventario. 22

12 Elabora Vendita - Direttore: Vuole essere in grado di eseguire rapidamente operazioni di sovrascrittura, e risolvere in modo semplici i problemi del Cassiere. - Enti governativi fiscali: Vogliono riscuotere le imposte su ciascuna vendita. Possono essere più enti: nazionale, regionale e provinciale. - Servizio di Autorizzazione di Pagamento: Vuole ricevere le richieste elettroniche di autorizzazione nel formato e nel protocollo corretto. Vuole una contabilità dettagliata dei suoi debiti verso il negozio. 23 Elabora Vendita Pre-condizioni: Il Cassiere è identificato e autenticato. Garanzia di successo (Post-condizioni): La vendita viene registrata. Le imposte sono calcolate correttamente. La contabilità e l inventario sono aggiornati. Le commissioni sono registrate. Viene generata una ricevuta. Le approvazioni alle autorizzazioni di pagamento sono registrate. 24

13 Elabora Vendita Scenario principale di successo (o flusso di base): 1. Il Cliente arriva alla cassa POS con gli articoli e/o i servizi da acquistare. 2. Il Cassiere inizia una nuova vendita. 3. Il Cassiere immette il codice identificativo dell articolo. 4. Il Sistema registra la riga di vendita per l articolo e mostra la descrizione dell articolo, il suo prezzo e il totale parziale. Il prezzo è calcolato in base a un insieme di regole di prezzo. Il Cassiere ripete i passi 3-4 fino a che non indica che ha terminato. 5. Il Sistema mostra il totale, con le imposte calcolate. 6. Il Cassiere riferisce il totale al Cliente, e richiede il pagamento. 7. Il Cliente paga e il Sistema gestisce il pagamento. 8. Il Sistema registra la vendita completata e invia informazioni sulla vendita e sul pagamento ai sistemi esterni di Contabilità (per la contabilità e le commissioni) e di Inventario (per l aggiornamento dell inventario). 9. Il Sistema genera la ricevuta. 10. Il Cliente va via con la ricevuta e gli articoli acquistati. 25 Elabora Vendita Estensioni (o flussi alternativi): *a. In qualsiasi momento, il Direttore chiede di eseguire un operazione di sovrascrittura: 1. Il Sistema passa alla modalità autorizzata Direttore. 2. Il Direttore o il Cassiere esegue un operazione nella modalità Direttore, per esempio, riprendere una vendita sospesa su un altro registratore di cassa, annullare una vendita, cambiare la chiusura di cassa, e così via. 3. Il Sistema torna alla modalità autorizzata Cassiere. 26

14 Elabora Vendita *b. In qualsiasi momento, il Sistema fallisce: Per consentire il ripristino e una gestione corretta della contabilità, bisogna garantire che tutto lo stato transazionale significativo possa essere ripristinato, a partire da qualsiasi passo dello scenario. 1. Il Cassiere riavvia il Sistema, si autentica, e richiede il ripristino dello stato precedente. 2. Il Sistema ricostruisce lo stato precedente. 2a. Il Sistema rileva delle anomalie che impediscono il ripristino: 1. Il Sistema segnala un errore al Cassiere, registra l errore, e passa in uno stato pulito. 2. Il Cassiere inizia una nuova vendita. 27 Elabora Vendita 1a. Il Cliente o il Direttore chiedono di riprendere una vendita sospesa: 1. Il Cassiere esegue l operazione di ripresa e inserisce il codice identificativo della vendita da riprendere. 2. Il Sistema visualizza lo stato della vendita ripresa, con il totale parziale. 2a. Vendita non trovata: 1. Il Sistema segnala l errore al Cassiere. 2. Il Cassiere probabilmente inizia una nuova vendita, e reinserisce tutti gli articoli. 3. Il Cassiere continua con la vendita (probabilmente inserendo altri articoli o gestendo il pagamento). 2-4a. Il Cliente dice al Cassiere di godere di un esenzione dalle imposte (per esempio, perché è anziano). 1. Il Cassiere verifica, quindi inserisce il codice per lo stato di esenzione dalle imposte. 2. Il Sistema registra lo stato, che userà nel calcolo delle imposte. 28

15 Elabora Vendita 3a. Codice identificativo dell articolo non valido (non trovato): 1. Il Sistema segnala l errore e rifiuta l inserimento. 2. Il Cassiere risponde all errore: 2a. C è un codice identificativo dell articolo leggibile: 1. Il Cassiere immette manualmente il codice dell articolo. 2. Il Sistema visualizza descrizione e prezzo. 2a. Codice identificativo non valido: Il Sistema segnala l errore. Il Cassiere prova in un altro modo. 2b. Non c è un codice dell articolo, ma c è un prezzo.... 2c. Il Cassiere esegue l operazione Aiuto Ricerca Prodotto per ottenere il vero codice identificativo dell articolo e il suo prezzo. 2d. Altrimenti, il Cassiere chiede a un dipendente di trovare il vero codice identificativo dell articolo, o il suo prezzo, e inserisce il codice o il prezzo manualmente (vedi sopra). 29 Elabora Vendita 3b. Ci sono più articoli della stessa categoria di prodotto e non è importante tenere traccia dell identità univoca dell articolo (ad es., 5 confezioni di hamburger vegetariani): 1. Il Cassiere può inserire il codice identificativo della categoria dell articolo e la quantità. 3c. L articolo richiede l inserimento manuale della categoria e del prezzo (...): 1. Il Cassiere inserisce manualmente il particolare codice della categoria, più il prezzo. 3-6a. Il Cliente chiede al Cassiere di eliminare (ovvero, di annullare) un articolo dall acquisto (...): 1. Il Cassiere inserisce il codice identificativo dell articolo da rimuovere dalla vendita. 2. Il Sistema elimina l articolo e visualizza il totale parziale aggiornato. 30

16 Elabora Vendita 3-6b. Il Cliente dice al Cassiere di annullare la vendita: 1. Il Cassiere annulla la vendita sul Sistema. 3-6c. Il Cassiere sospende la vendita: 1. Il Sistema registra la vendita in modo tale che possa essere ripresa su qualsiasi registratore POS. 2. Il Sistema presenta una ricevuta di sospensione, che comprende un elenco degli articoli inseriti e un codice identificativo della vendita, da usare per recuperare e riprendere la vendita. 31 Elabora Vendita 4a. Il prezzo dell articolo fornito dal sistema non è accettato (per esempio, il Cliente si è lamentato di qualcosa e gli viene offerto un prezzo inferiore):... 5a. Il Sistema rileva un fallimento nella comunicazione con il servizio esterno di calcolo delle imposte:... 5b. Il Cliente dice di aver diritto a uno sconto (...):... 5c. Il Cliente dice di avere un credito sul proprio conto, da applicare alla vendita:... 6a. Il Cliente dice che intende pagare in contanti, ma non ha abbastanza contanti:... 32

17 Elabora Vendita 7a. Pagamento in contanti: 1. Il Cassiere inserisce l importo in contanti presentato dal Cliente. 2. Il Sistema mostra il resto dovuto, e apre il cassetto della cassa. 3. Il Cassiere deposita il contante presentato e restituisce il resto in contanti al Cliente. 4. Il Sistema registra il pagamento in contanti. 33 Elabora Vendita 7b. Pagamento con carta di credito: 1. Il Cliente inserisce le informazioni sulla propria carta di credito. 2. Il Sistema visualizza il pagamento per la verifica. 3. Il Cassiere conferma. 3a. Il Cassiere annulla l operazione di pagamento: 1. Il Sistema ritorna alla modalità inserimento articolo. 4. Il Sistema invia una richiesta di autorizzazione al pagamento al sistema esterno di Servizio di Autorizzazione di Pagamento, per richiedere l approvazione del pagamento. 4a. Il Sistema rileva un problema nella comunicazione col sistema esterno: 1. Il Sistema segnala l errore al Cassiere. 2. Il Cassiere chiede al Cliente di pagare in altro modo. 34

18 Elabora Vendita 5. Il Sistema riceve l approvazione del pagamento, segnala l approvazione al Cassiere e apre il cassetto (...). 5a. Il Sistema riceve un rifiuto per il pagamento: 1. Il Sistema segnala il rifiuto al Cassiere. 2. Il Cassiere chiede al Cliente di pagare in altro modo. 5b. Il Sistema rileva un timeout nell attesa della risposta: 1. Il Sistema segnala il timeout al Cassiere. 2. Il Cassiere può riprovare, oppure chiedere al Cliente di pagare in altro modo. 6. Il Sistema registra il pagamento con credito, che comprende l approvazione del pagamento. 7. Il Sistema presenta meccanismo di inserimento della firma per il pagamento. 8. Il Cassiere chiede al Cliente la firma per la ricevuta del pagamento con credito. Il Cliente inserisce la firma. 9. Se la firma sulla ricevuta è cartacea, il Cassiere mette la ricevuta nel cassetto e lo chiude. 35 Elabora Vendita 7c. Pagamento con assegno: 7d. Pagamento con carta bancomat: 7e. Il Cassiere annulla l operazione di pagamento: 1. Il Sistema ritorna alla modalità immissione articoli 7f. Il Cliente presenta dei buoni:... 9b. Il Cliente richiede una ricevuta regalo (e.g., senza i prezzi):... 9c. La stampante ha esaurito la carta:... 36

19 Elabora Vendita Requisiti speciali: - Interfaccia grafica touch screen su un monitor piatto grande. Il testo deve essere visibile da una distanza di un metro. - La risposta alle autorizzazioni di credito devono arrivare entro 30 secondi il 90% delle volte. - In qualche modo si desidera un ripristino robusto non riesce l accesso a servizi remoti, come per esempio l inventario. - Internazionalizzazione della lingua sul testo visualizzato. - Regole di business inseribili nei passi da 3 a Elabora Vendita Elenco delle varianti tecnologiche e dei dati: *a. Richiesta di sovrascrittura da parte del Direttore effettuata passando una scheda apposita in un lettore di schede, oppure inserendo il codice di autorizzazione manualmente, con la tastiera. 3a. Codice identificativo dell articolo inserito tramite lettore laser di codici a barre (se il codice a barre è presente) oppure tramite tastiera. 3b. Il codice identificativo dell articolo può essere basato su uno tra gli schemi di codifica UPC, EAN, JAN o SKU. 7a. Le informazioni sulla carta di credito sono inserite tramite lettore di schede o tramite tastiera. 7b. Firma per il pagamento con carta di credito ottenuta su ricevuta cartacea. Ma si prevede che, entro due anni, molti vorranno la cattura digitale della firma. 38

20 Elabora Vendita Frequenza di ripetizione: Potrebbe essere quasi ininterrotta. Problemi aperti: - Come variano le leggi fiscali? - Esaminare la questione del ripristino dei servizi remoti. - Quale personalizzazione è necessarie per le diverse aziende? - Il Cassiere deve estrarre e portare via il cassetto della cassa quando effettua il logout? - Il Cliente può usare direttamente il lettore di schede o lo deve fare il Cassiere? Sezioni di un caso d uso dettagliato Il preambolo (prima dello scenario principale) contiene informazioni (opzionali) che è importante leggere prima dello scenario principale Portata confini del SuD Livello spesso livello di obiettivo utente livelli più alti e più bassi Attore primario l attore principale che chiede al sistema l esecuzione dei servizi per raggiungere un obiettivo di solito è chi dà inizio all interazione con il sistema 40

21 Parti interessate e interessi Parti interessate e interessi suggerisce e limita ciò che deve fare il sistema il sistema concretizza un contratto tra le parti interessate, con i casi d uso che descrivono gli aspetti comportamentali del contratto il caso d uso, come contratto per il comportamento, cattura tutti e soli i comportamenti relativi alla soddisfazione degli interessi delle parti interessate [Cockburn] un strumento accurato per identificare i requisiti 41 Pre-condizioni e post-condizioni Pre-condizioni che cosa deve essere sempre vero prima di iniziare uno scenario del caso d uso Garanzia di successo (post-condizioni) che cosa deve essere vero quando il caso d uso (qualsiasi scenario) viene completato con successo deve soddisfare gli interessi di tutte le parti interessate Garanzia minima che cosa deve essere vero quando il caso d uso viene completato (successo o fallimento) deve proteggere gli interessi di tutte le parti interessate 42

22 Scenario principale di successo Scenario principale di successo (flusso di base) sequenza di passi che costituisce il percorso tipico di successo che soddisfa gli interessi delle parti interessate percorso felice ( happy path ) può contenere passi che vanno ripetuti ma normalmente non comprende comportamento condizionale (if-else) che è solitamente gestito dalle estensioni 43 Scenario principale di successo Scenario principale di successo (o flusso di base): 1. Il Cliente arriva alla cassa POS con gli articoli e/o i servizi da acquistare. 2. Il Cassiere inizia una nuova vendita. 3. Il Cassiere immette il codice identificativo dell articolo. 4. Il Sistema registra la riga di vendita per l articolo e mostra la descrizione dell articolo, il suo prezzo e il totale parziale. Il prezzo è calcolato in base a un insieme di regole di prezzo. Il Cassiere ripete i passi 3-4 fino a che non indica che ha terminato. 5. Il Sistema mostra il totale, con le imposte calcolate. 6. Il Cassiere riferisce il totale al Cliente, e richiede il pagamento. 7. Il Cliente paga e il Sistema gestisce il pagamento. 8. Il Sistema registra la vendita completata e invia informazioni sulla vendita e sul pagamento ai sistemi esterni di Contabilità (per la contabilità e le commissioni) e di Inventario (per l aggiornamento dell inventario). 9. Il Sistema genera la ricevuta. 10. Il Cliente va via con la ricevuta e gli articoli acquistati. 44

23 Scenario principale di successo Tre tipi di passi 1) un interazione tra attori il Sistema è considerato un attore tra un attore (utente) e il Sistema tra il Sistema e un attore (utente) tra il Sistema e altri sistemi 2) una validazione solitamente effettuata dal Sistema 3) un cambiamento di stato, da parte del Sistema Il primo passo di un caso d uso di solito non ricade in queste tipologie piuttosto, viene usato per indicare l evento che scatena l esecuzione del caso d uso Talvolta nemmeno l ultimo passo ricade in queste tipologie 45 Estensioni Estensioni (flussi alternativi) importanti costituiscono la maggior parte del testo descrivono (in modo conciso) tutti gli altri scenari (di successo o fallimento) gli scenari di estensione vanno descritti come deviazioni (condizionali) dallo scenario principale di successo Ogni estensione è formata da due parti a) condizione qualcosa che può essere rilevato da un sistema o da un attore b) gestione un singolo passo o una sequenza di passi dopo l esecuzione di un estensione, il controllo torna di solito allo scenario principale (o allo scenario che contiene l estensione) sono possibili anche estensioni di estensioni 46

24 Estensioni Ci sono almeno tre tipi diversi di estensioni un primo tipo di estensioni l attore primario vuole far procedere il caso d uso diversamente da quanto previsto nello scenario principale di successo ciò è possibile grazie a un interazione diversa da quella prevista nello scenario principale 47 Estensioni Scenario principale di successo (o flusso di base): Il Cassiere immette il codice identificativo dell articolo.... Estensioni (o flussi alternativi):... 3b. Ci sono più articoli della stessa categoria di prodotto e non è importante tenere traccia dell identità univoca dell articolo (ad es., 5 confezioni di hamburger vegetariani): 1. Il Cassiere può inserire il codice identificativo della categoria dell articolo e la quantità. 48

25 Estensioni Un secondo tipo di estensioni si verifica qualcosa per cui il caso d uso deve procedere diversamente da quanto previsto nello scenario principale di successo di solito è il sistema che se ne accorge mentre effettua un azione o una validazione 49 Estensioni Scenario principale di successo (o flusso di base): Il Cassiere immette il codice identificativo dell articolo.... Estensioni (o flussi alternativi):... 3a. Codice identificativo dell articolo non valido (non trovato): 1. Il Sistema segnala l errore e rifiuta l inserimento. 2. Il Cassiere risponde all errore... 50

26 Estensioni Estensioni (o flussi alternativi): 3a. Codice identificativo dell articolo non valido (non trovato): 1. Il Sistema segnala l errore e rifiuta l inserimento. 2. Il Cassiere risponde all errore: 2a. C è un codice identificativo dell articolo leggibile: 1. Il Cassiere immette manualmente il codice dell articolo. 2. Il Sistema visualizza descrizione e prezzo. 2a. Codice identificativo non valido: Il Sistema segnala l errore. Il Cassiere prova in un altro modo. 2b. Non c è un codice dell articolo, ma c è un prezzo.... 2c. Il Cassiere esegue l operazione Aiuto Ricerca Prodotto per ottenere il vero codice identificativo dell articolo e il suo prezzo. 2d. Altrimenti, il Cassiere chiede a un dipendente di trovare il vero codice identificativo dell articolo, o il suo prezzo, e inserisce il codice o il prezzo manualmente (vedi sopra). 51 Estensioni Un terzo tipo di estensioni descrizione di passi concreti un passo dello scenario principale descrive un azione astratta il caso d uso contiene poi un estensione di quel passo per ciascun modo concreto di eseguire quell azione astratta nel senso che ciascun possibile modo di eseguire quell azione è descritta da un passo concreto e dunque l azione non può mai essere direttamente eseguita nel modo astratto 52

27 Estensioni Scenario principale di successo (o flusso di base): Il Cliente paga e il Sistema gestisce il pagamento.... Estensioni (o flussi alternativi): 7a. Pagamenti in contanti:... 7b. Pagamento con carta di credito:... 7c. Pagamento con assegno: 7d. Pagamento con carta bancomat: 53 * Estensioni Riassumendo, ci sono modi diversi di utilizzare le estensioni, che possono essere trovati nel caso d uso d esempio va anche osservato che le estensioni non sono estensioni in assoluto piuttosto, sono estensioni di uno dei tanti scenari del caso d uso che è stato designato come scenario principale di successo il sistema può essere utilizzato in modo diverso da quanto previsto dallo scenario principale 3b. ci sono più articoli della stessa categoria di prodotto... durante lo svolgimento di un passo, qualcosa va diversamente da quanto previsto nello scenario principale 3a. codice identificativo dell articolo non valido... nello scenario principale, un passo descrive un azione astratta mentre le estensioni descrivono i modi concreti per eseguire quell azione 7b. pagamento con carta di credito... 54

28 Altre sezioni Requisiti speciali requisiti non funzionali, qualità e vincoli, che è utile descrivere nel contesto di un caso d uso Elenco delle varianti tecnologiche e dei dati indica che ci sono diversi modi in cui qualcosa può essere fatto relativi ai meccanismi tecnologici oppure al formato dei dati non si tratta di estensioni 55 # Congratulazioni, ma... I casi d uso vanno scritti in modo incrementale e iterativo la scrittura viene fatta da analisti, utenti ed esperti del dominio l aver scritto un caso d uso non ne garantisce la correttezza è richiesta una verifica continua dei requisiti tra gli sviluppatori e gli utenti 56

29 6.10 Altri formati dei casi d uso Esistono vari modelli per la scrittura dei casi d uso alistair.cuckburn.us RUP formato a due colonne (conversazionale) 57 Formato a due colonne come prima Scenario principale di successo: Azione (o intento) dell attore 1. Il Cliente arriva alla cassa POS con gli articoli e/o i servizi da acquistare. 2. Il Cassiere inizia una nuova vendita. 3. Il Cassiere immette il codice identificativo dell articolo. Responsabilità del Sistema 4. Il Sistema registra la riga di vendita per l articolo e mostra la descrizione del prodotto, il suo prezzo e il totale parziale. Il Cassiere ripete i passi 3-4 fino a che non indica che ha finito. 58

30 Formato a due colonne Azione (o intento) dell attore 6. Il Cassiere riferisce il totale al Cliente, e chiede il pagamento. 7. Il Cliente paga. 10. Il Cliente va via con la ricevuta e i beni. Responsabilità del Sistema 5. Il Sistema mostra il totale, con le imposte calcolate. 8. Il Sistema gestisce il pagamento. Il Sistema registra la vendita completata e invia le informazioni sulla vendita e sul pagamento ai sistemi esterni di Contabilità e di Inventario. 9. Il Sistema genera la ricevuta Scrivere in uno stile essenziale Linea guida nell analisi dei requisiti, scrivi i casi d uso in uno stile essenziale ignora l interfaccia utente fai riferimento alle intenzioni degli utenti e alle responsabilità del sistema non ad azioni concrete Stile essenziale l Amministratore si identifica il Sistema autentica l identità Stile concreto l Amministratore immette ID e password in una finestra di dialogo (vedi Fig. 3) il Sistema autentica l Amministratore il Sistema mostra la finestra edit users (vedi Fig. 4) 60

31 6.12 Scrivere in modo conciso ma chiaro Linea guida scrivi i casi d uso in modo conciso ma allo stesso tempo chiaro e completo scrivi chiaramente ed esplicitamente soggetto, verbo ed eventuali frasi subordinate verbo al tempo presente e nella forma attiva Ad esempio Il Sistema autentica l Amministratore e non L Amministratore viene autenticato Casi d uso a scatola nera I casi d uso più comuni sono i casi d uso a scatola nera specificano che cosa il sistema deve fare, senza descrivere come lo fa il sistema ha delle responsabilità, e collabora con gli attori, elementi che hanno altre responsabilità non descrivono la struttura interna del sistema, né i suoi componenti o il suo progetto Stile a scatola nera il sistema registra la vendita e non il sistema memorizza la vendita in un database il sistema genera un comando SQL di tipo INSERT per memorizzare la vendita 62

32 Casi d uso a scatola nera I casi d uso più comuni sono i casi d uso a scatola nera specificano che cosa il sistema deve fare, senza descrivere come lo fa il sistema ha delle responsabilità, e collabora con gli attori, elementi che hanno altre responsabilità non descrivono la struttura interna del sistema, né i suoi è analisi, componenti non o il suo progetto progettazione Stile a scatola nera il sistema registra la vendita e non analisi: quali sono le il sistema memorizza responsabilità la vendita in un del database sistema? progettazione: come vengono il sistema genera un comando SQL di tipo INSERT per allocate le responsabilità ai memorizzare la vendita componenti software? Attori e obiettivi Ciascun caso d uso ha lo scopo di fornire valore a un particolare attore i requisiti vanno scritti con riferimento agli utenti o attori del sistema chiedendosi quali sono i loro obiettivi e le loro azioni comuni bisogna capire che cosa gli attori ritengono abbia valore 64

33 6.15 Come trovare i casi d uso Strategia di base per l identificazione dei casi d uso determina i confini del sistema l applicazione software, l intero sistema HW+SW, il sistema HW+SW e la persona che lo usa, l intera organizzazione identifica gli attori primari coloro che raggiungono i propri obiettivi usando il sistema identifica gli obiettivi di ciascun attore primario definisci i casi d uso che soddisfano gli obiettivi degli utenti dagli un nome con riferimento all obiettivo 65 Passo 1: Determina i confini del sistema Nel caso del sistema POS, è l applicazione da realizzare E utile capire che cosa sta fuori dai confini del sistema ad es., il cassiere il cassiere sarà un attore primario il cliente non sarà un attore primario il sistema di autorizzazione dei pagamenti 66

34 Passo 2: Identifica gli attori primari Come identificare gli attori primari? chi avvia e arresta il sistema? chi è l amministratore del sistema? chi amministra gli utenti e la sicurezza? ci sono eventi temporali significativi? (il tempo potrebbe essere un attore primario) c è un processo che monitorizza il sistema e lo fa ripartire se fallisce? chi valuta le prestazioni del sistema? chi gestisce gli aggiornamenti del software? chi valuta i log? il sistema interagisce con sistemi informatici esterni? 67 Passo 3: Identifica gli obiettivi degli attori p. Lista degli attori-obiettivi (nella Visione) Attore Cassiere Direttore Amministratore del Sistema Obiettivo elabora le vendite elabora i noleggi gestire le restituzioni cash in cash out avviare il sistema arrestare il sistema aggiungere utenti modificare utenti 68

35 Come trovare i casi d uso Interviste per la raccolta dei requisiti che cosa fai? (quali sono i tuoi casi d uso?) quali sono i tuoi obiettivi? E preferibile il secondo tipo di domanda Intervista con un Cassiere D: Quali sono i tuoi obiettivi nell usare un sistema POS? R: Fare il login rapidamente. Registrare le vendite. D: Qual è la motivazione per fare il login? R: Mi devo identificare al sistema, in modo che il sistema possa verificare che io possa effettivamente usare il sistema per registrare le vendite e fare altre cose. D: Inoltre? A un livello più alto? R: Per prevenire la truffa, che i dati vengano sporcati, che io acceda a dati riservati. 69 Attori primari, obiettivi e confini L insieme degli attori primari dipende dai confini del sistema 70

36 Eventi esterni Un altro approccio all identificazione degli attori, obiettivi e casi d uso è basato sull analisi degli eventi che sollecitano il sistema quali sono gli eventi di interesse per il sistema? chi li genera? perché? Evento esterno Attore Obiettivo inserire una riga di vendita per un articolo inserire un pagamento Cassiere Cassiere o Cliente elabora una vendita elabora una vendita 71 Passo 4: Definire i casi d uso Solitamente va definito un caso d uso per ciascun obiettivo di ciascun utente/attore usa l obiettivo dell utente per dare un nome al caso d uso obiettivo: elaborare una vendita caso d uso: Elabora Vendita usa un verbo come prima parola del nome dei casi d uso Una eccezione comune a questa regola gli obiettivi CRUD (Create, Retrieve, Update, Delete) vengono normalmente raggruppati in un singolo caso d uso Gestisci X ad esempio, Gestisci Utenti 72

37 6.16 Utilità dei caso d uso Quali dei seguenti casi d uso sono significativi? in particolare, quali sono significativi nel contesto dell analisi dei requisiti? negoziazione di un contratto con un fornitore gestione di una restituzione autenticazione (login) muovere una pedina sul tabellone da gioco Questi casi d uso possono essere tutti significativi ma a diversi livelli in modo dipendente dai confini del sistema, dagli attori e dagli obiettivi Tre test per comprendere la significatività dei casi d uso nell analisi dei requisiti test del capo, test EBP, test della dimensione 73 Test del capo Test del capo il capo: Che fai tutto il giorno? l utente: Faccio login! Il capo è contento? sì è utile concentrarsi su questo obiettivo no potrebbe essere importante, ma come caso d uso di livello più basso 74

38 Test EBP Un processo di business elementare (EBP) è un attività svolta da una persona in un determinato tempo e luogo in risposta a un evento di business che aggiunge un valore di business misurabile e lascia i dati in uno stato consistente Un EBP è una possibile risposta alla seguente domanda stai descrivendo un sistema sei interessato a qualcuno che usa il sistema quella persona vuole qualcosa da sistema, adesso dopo averla ottenuta, può andar via e fare qualcos altro che cosa vuole quella persona dal sistema adesso? Concentrati sui casi d uso che riflettono EBP 75 Test della dimensione Test della dimensione un caso d uso dovrebbe comprendere tre-dieci passi tre-dieci pagine di testo nel formato dettagliato non una o poche azioni non troppe azioni 76

39 Esempio Quali dei seguenti casi d uso sono significativi? negoziazione di un contratto con un fornitore gestione di una restituzione autenticazione (login) muovere una pedina sul tabellone da gioco 77 Linea guida per i casi d uso Linea guida per l identificazione dei casi d uso nell analisi dei requisiti per le applicazioni informatiche, concentrati sui casi d uso al livello EBP In alcuni casi, considera anche casi d uso di livello più basso in particolare, quelli ripetuti in diversi casi d uso (a livello EBP) log in pagamento con carta di credito 78

40 * Livello dei casi d uso Overall Project Summary Goals Advertise Order Invoice User Goals Set up Promotion Reference Promotion Monitor Promotion Place Order Create Invoice Send Invoice Identify Promotion Register User Identify Product Identity Customer Sub functions 79 * Livello dei casi d uso E utile comprendere che i casi d uso possono essere scritti a livelli diversi per ciascun caso d uso, è importante dire qual è il suo livello 80 Livelli per i casi d uso livello di obiettivo utente è il più interessante nell analisi dei requisiti corrisponde ai casi d uso EBP livello di sotto-funzione utili per mettere a fattor comune parti di casi d uso e/o per descrivere interazioni di dettaglio livello di sommario un caso d uso a questo livello comprende più casi d uso a livello di obiettivo utente la sua durata può essere ore, giorni, mesi o anche anni utile per l identificazione dei casi d uso EPB, e per comprendere/descrivere il loro contesto

41 * Livello dei casi d uso 81 * La relazione include tra casi d uso I casi d uso possono essere correlati tra loro ad es., un caso d uso Gestisci Pagamento con Carta di Credito potrebbe essere parte di altri casi d uso ad es., Elabora Vendita e Elabora Prestito la correlazione tra casi d uso semplifica l organizzazione e la gestione dei casi d uso permette di evitare duplicazioni migliora la comunicazione e la comprensione Attenzione può essere utile identificare le correlazioni tra casi d uso tuttavia, cercare di identificare tutte le correlazioni tra casi d uso può essere controproducente 82

42 * La relazione include È comune avere comportamento parziale condiviso tra più casi d uso ad es., pagamento con carta di credito nell ambito dei casi d uso Elabora Vendita e Elabora Prestito la relazione include basata sulla descrizione di caso d uso per le sottofunzioni e loro inclusioni consente di evitare di duplicare il testo Linea guida usa la relazione include quando ti stai ripetendo in due o più casi d uso diversi e vuoi evitare la ripetizione per decomporre casi d uso molto complessi e lunghi 83 * La relazione include: Esempio Caso d uso UC1: Elabora Vendita Scenario principale di successo: 7. Il Cliente paga e il Sistema gestisce il pagamento. Estensioni: 7b. Pagamento con carta di credito: Gestisci Pagamento con Carta di Credito 7c. Pagamento con assegno: Gestisci Pagamento con Assegno Caso d uso UC7: Elabora Prestito... Estensioni: 6b. Pagamento con carta di credito: Gestisci Pagamento con Carta di Credito 84

43 * La relazione include: Esempio Caso d uso UC12: Gestisci Pagamento con Carta di Credito Livello: sottofunzione Scenario principale di successo: 1. Il Cliente inserisce le informazioni sulla propria carta di credito. 2. Il Sistema invia una richiesta di autorizzazione al pagamento a un sistema esterno di Payment Authorization Service, e richiede l approvazione del pagamento. 3. Il Sistema riceve l approvazione del pagamento e segnala l approvazione al Cassiere. 4. Estensioni: 2a.Il Sistema rileva un problema nella comunicazione col sistema esterno: 1. Il Sistema segnala l errore al Cassiere. 2. Il Cassiere chiede al Cliente di pagare in altro modo. 85 * Casi d uso di business I casi d uso possono essere applicati sia alla specifica dei sistemi software che alla modellazione dei processi di business questo avviene quando, come portata del sistema, non viene scelto il sistema software ma piuttosto il sistema enterprise o il sistema ufficio, reparto o altro ancora i casi d uso (casi d uso di business) possono infatti essere applicati alla modellazione di attività o processi di business di un organizzazione gli attori possono essere clienti esterni dell organizzazione l organizzazione può corrispondere, nella sua interezza, al sistema in discussione (analisi a scatola nera) oppure i vari uffici dell organizzazione possono essere rappresentati da attori diversi (analisi a scatola trasparente) la modellazione può essere usata sia per descrivere i processi esistenti che per descrivere dei futuri processi di business 86

44 6.17 UML: Diagrammi dei casi d uso I diagrammi dei casi d uso di UML sono una notazione grafica per mostrare i nomi dei casi d uso e degli attori, e le loro relazioni i diagrammi dei casi d uso non consentono di esprimere ciò che può essere espresso (ed è importante esprimere!) mediante il testo dei casi d uso i diagrammi dei casi d uso sono pertanto secondari nella lavorazione dei casi d uso possono complementare la lista attori-obiettivi permettono di descrivere il contesto di un sistema e i suoi confini il diagramma di contesto 87 Diagramma dei casi d uso di contesto (parziale) system boundary NextGen POS communication Customer Process Sale Handle Returns Payment Authorization Service alternate notation for a computer system actor actor Cashier «actor» Tax Calculator Manager Cash In «actor» Accounting System «actor» Sales Activity System Analyze Activity «actor» HR System Manage Security System Administrator Manage Users... use case 88

45 Diagrammi dei casi d uso: suggerimenti For a use case context diagram, limit the use cases to user-goal level use cases. Show computer system actors with an alternate notation to human actors. NextGen Cashier Process Sale... «actor» Payment Authorization Service primary actors on the left supporting actors on the right 89 Diagrammi dei casi d uso: notazioni alternative 90

46 * Diagrammi dei casi d uso: relazione include 91 Diagrammi dei casi d uso: linee guida Linee guida (riguardo all uso dei diagrammi dei casi d uso) disegna un semplice diagramma dei casi d uso insieme a una lista attori-obiettivi attento a non passare troppo tempo a disegnare diagrammi dei casi d uso discutere sulle relazioni tra casi d uso 92

47 6.18 UML: Diagrammi di attività I diagrammi di attività di UML sono una notazione grafica per descrivere flussi di lavoro o processi di business complementari al testo dei casi d uso utili specialmente per descrivere processi di business Fulfillment start Customer Service Partitions. Show different parties involved in the process Finance Object Node. An object produced or used by actions. This allows us to model data flows or object flows. Order Fill Order Receive Video Order Send Invoice Action. It does something. There is an automatic transition on its completion. A transition supports modeling of control flow. Fork. One incoming transition, and multiple outgoing parallel transitions and/or object flows. Invoice Deliver Order Receive Payment Join. Multiple incoming transitions and/or object flows; one outgoing transition. The outgoing continuation does not happen until all the inputs arrive from all flows. Close Order end of activity Requisiti nel contesto I casi d uso permettono di rappresentare i requisiti nel contesto degli obiettivi degli attori primari e degli scenari di uso del sistema I casi d uso sono preferibili alle liste, dettagliate e di basso livello, delle caratteristiche funzionali (features) Ma il sistema deve i requisiti non sono raggruppati per funzionalità, sono spesso disordinati e non coesi replicano i contenuti dei casi d uso i casi d uso non permettono di rappresentare tutti i requisiti in alcuni casi non sono lo strumento più adeguato 94

48 Caratteristiche funzionali di alto livello Le principali funzionalità del sistema possono essere riassunte nella Visione una decina di caratteristiche funzionali di alto livello Sommario delle caratteristiche funzionali del sistema cattura delle vendite autorizzazioni di pagamento (credito, debito, assegno) amministrazione del sistema con utenti, sicurezza, interfacciamento con sistemi esterni prodotti da terzi, come inventario, contabilità, imposte, servizi di autorizzazione di pagamento elaborazione fuori linea delle vendite se i sistemi esterni falliscono definizione ed esecuzione di regole di business personalizzate inseribili Esempio: Monopoly Caso d uso UC1: Gioca il gioco del Monopoly Portata: Applicazione Monopoly Game System Livello: obiettivo utente Attore primario: Osservatore Parti interessate e interessi: - L Osservatore vuole osservare facilmente la simulazione del gioco. Scenario principale di successo (o flusso di base): 1. L Osservatore richiede l inizio di un nuovo gioco, e inserisce il numero dei giocatori. 2. L Osservatore avvia il gioco. 3. Il Sistema visualizza la traccia del gioco per la successiva mossa di un giocatore (vedi le regole di dominio e traccia di gioco nel glossario per i dettagli sulla traccia). Ripetere il passo 3 fino a che un giocatore vince oppure l Osservatore annulla la simulazione. 96

49 Gioca il gioco del Monopoly Estensioni: *a. In qualsiasi momento, il Sistema fallisce: (Per consentire il ripristino, il Sistema registra ogni mossa completata) 1. L Osservatore riavvia il Sistema. 2. Il Sistema rileva il guasto precedente, ricostruisce lo stato ed è pronto a continuare. 3. L Osservatore decide di continuare (dall ultimo turno di gioco completato). Requisiti speciali: - Fornire per la traccia del gioco sia una modalità grafica che una modalità testuale. 97 Diagramma di contesto per il MGS 98

50 6.21 Casi d uso nei processi iterativi I casi d uso sono centrali in UP e in altri processi iterativi UP incoraggia lo sviluppo guidato dai casi d uso i requisiti sono registrati principalmente nel Modello dei casi d uso altri requisiti sono secondari i casi d uso hanno un ruolo importante della pianificazione iterativa la progettazione è guidata dalla realizzazione dei casi d uso i casi d uso influenzano l organizzazione dei manuali d uso i test funzionali e di sistema possono essere basati su scenari di casi d uso la UI può contenere wizard per gli scenari più comuni 99 Requisiti nello sviluppo iterativo Disciplina Elaborato Ideaz. (1 sett.) Elab. 1 (4 sett.) Elab. 2 (4 sett.) Elab. 3 (3 sett.) Elab. 4 (3 sett.) Requisiti Modello dei casi d'uso 2 giorni di raccolta dei requisiti. Identificati i nomi di molti casi d'uso, descritti in formato breve. 10% dei casi d'uso descritti in dettaglio. 2 giorni di raccolta dei requisiti verso la fine dell'iterazione. Feeback dall'iterazione precedente. 30% dei casi d'uso descritti in dettaglio. Ripeti. 50% dei casi d'uso descritti in dettaglio. Ripeti. 70% dei casi d'uso descritti in dettaglio. Ripeti. 80% dei casi d'uso descritti in dettaglio. Solo una piccola frazione sono stati realizzati; il resto verrà fatto durante la costruzione. Progettazione Modello di progetto Progettazione relativa a un piccolo insieme di requisiti di Ripeti. rischio alto e significativi dal punto di vista architetturale. Ripeti. Ripeti. I rischi maggiori e gli aspetti architetturali significativi sono stabilizzati. Implementazione Modello di implementazione Implementa. Ripeti. 5% del sistema completato. Ripeti. 10% del sistema completato. Ripeti. 15% del sistema completato. Gestione del progetto Piano di sviluppo del software Stime vaghe. Le stime iniziano a essere significative. un po' meglio un po' meglio Stime dell'intero progetto. 100

51 Elaborati nello sviluppo iterativo Disciplina Modellazione del business Requisiti Progettazione Elaborato Modello di dominio Ideaz. (I1) Elab. (E1..En) Modello dei casi d'uso s r Visione s r Specifiche supplementari s r Glossario s r s Costr. (C1..Cn) Modello di progetto s r Documento dell'architettura software Modello dei dati s r s Trans. (T1..T2) Implementazione Modello di implementazione s r r Gestione del progetto Piano di sviluppo software s r r r Test Modello di test s r Infrastruttura Scenario di sviluppo s r 101 Studio di caso: POS NextGen Casi d uso per il sistema POS NextGen durante l ideazione in formato dettagliato Elabora Vendita Gestisci Restituzione in formato informale Elabora Noleggio Analizza Dati sulle Vendite Gestisci la Sicurezza in formato breve Cash In Cash Out Avvia il Sistema 102

52 Contesto e ambiente 103 * Linee guida Alcune linee guida (e commenti) da Writing effective use cases di Alistair Cockburn scrivi in modo leggibile un caso d uso ben scritto è facile da leggere imparare a scrivere bene i casi d uso è difficile lavora dapprima in ampiezza, prosegui aumentando via via il livello di precisione livello 1 attore primario e obiettivo livello 2 scenario principale di successo livello 3 condizioni di estensione livello 4 passi di gestione delle estensioni 104