Casi d uso (use cases)

Transcript

1 Casi d uso (use cases) proposti da Ivar Jacobson nel 1992 termine nuovo, ma tecnica consolidata (studio degli scenari di operatività degli utilizzatori di un sistema) sono i modi in cui il sistema può essere utilizzato (cioè le funzionalità che il sistema mette a disposizione dei suoi utilizzatori) 1 Caso d uso (definizione 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) 2 Ingegneria del Software - Prof. G. A. Di Lucca 1

2 Use Cases Strumento impiegato durante la fase di analisi per catturare il comportamento esterno del sistema da sviluppare, senza dover specificare come tale comportamento viene realizzato (sistema=black-box) Forniscono una descrizione dei modi in cui il sistema potrà essere utilizzato L analisi dei casi d uso può essere integrata con l analisi orientata agli oggetti, per aiutare a scoprire le responsabilità delle classi e le interazioni fra gli oggetti 3 Casi d uso per descrivere le interazioni utente-sistema Un caso d uso può essere descritto sotto forma di scenario di interazione (dialogo) tra gli utilizzatori ed il sistema. Esempio: 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 è rivolta all interazione, non alle attività interne al sistema 4 Ingegneria del Software - Prof. G. A. Di Lucca 2

3 Use case: Descrizione: Modifica prenotazione. L operatore riceve dal cliente o agenzia una richiesta di modifica della prenotazione. Viene attivata la gestione delle prenotazioni e richiesto al cliente il nominativo sotto il quale era stata effetuata la prenotazione ed inserito nel sistema dall operatore. Quindi verrano visualizzati i dati della prenotazione relativa e il cliente metterà l operatore a conoscenza delle modifiche che intende apportare al suo soggiorno (eliminare giorni, aumentare giorni, cambiare periodo di soggiorno). S il cliente intende modificare il periodo di soggiorno l operatore attiverà prima la cancellazione e quindi l inserimento della prenotazione. Eccezioni: Attori: Use Case Extends: Use Case Uses: Use Case Inputs: Use Case Outputs: Criterio di accettazione: Aspettative collegate: Requisiti o Use Case collegati: nn. Cliente/agenzia e operatore. nn. Inserimento prenotazione (UC-PRE.02) e cancellazione prenotazione (UC-PRE-03). Dati forniti dal cliente e nominativo. Modifica della prenotazione ed eventualmente dello stato delle stanze. Il sistema dovrà garantire che le modifiche chieste dal cliente vengano memorizzate. Effetuare le modifiche di prenotazione. F-PRE-06, UC-PRE-02, UC-PRE-03 Stato Release Priorità Stabilità Livello di comprensione Finale 1 Richiesto Stabile Piena comprensione Versione: 2.0 Data: 08/ 04/ 98 Compilato da: Danzi Francesca Note: 5 Un secondo esempio Sistema per la gestione delle vendite dei prodotti di una azienda Focus: la possibilità da parte del venditore di effettuare l evasione di un ordine 6 Ingegneria del Software - Prof. G. A. Di Lucca 3

4 Use case diagram 7 Il modello dei casi d uso Presenta una vista del sistema tramite attori, casi d uso e associazioni tra essi Attore Caso d uso Relazione di associazione 8 Ingegneria del Software - Prof. G. A. Di Lucca 4

5 Attore Un ruolo (o un insieme di ruoli) che l utente del caso d uso svolge nell interagire col sistema. E esterno al sistema Può essere: Una classe di persone fisiche (es. Fornitore) Un altro sistema software (es. Sistema di contabilità) Un dispositivo hardware esterno (es. Sensore) Un attore sollecita il sistema con qualche evento e ne riceve un output. ogni attore rappresenta una classe, cioè un insieme che può corrispondere a più elementi ES. l'attore "cliente" rappresenta la classe che comprende tutti i singoli clienti 9 Attori Gli attori possono essere un mezzo per individuare gli use case. Spesso è più facile individuare una lista di attori, e quindi capire quali siano i loro obiettivi e di quali interazioni col sistema essi debbano essere protagonisti. Quali attori? Quando gli attori sono sistemi esterni, non è sempre facile capire quando essi vadano considerati. interazioni esterne iniziatori di interazioni richieste di funzionalità dall esterno utenti indiretti Criterio guida: gli use case devono indicare funzionalità fruibili dall esterno ( 10 ai morsetti del sottosistema considerato) Ingegneria del Software - Prof. G. A. Di Lucca 5

6 Non sempre l attore scatena il caso d uso Esempio: dopo due mesi dalla consegna al compratore di un bene viene notificato l ordine di pagamento. destinatario: compratore esterno (ignaro del sistema SW) beneficiario: ufficio non coinvolto nell emissione dell ordine causa immediata: funzione interna che verifica le scadenze Rispetto ad un caso d uso, un attore può Nei confronti di un certo use case, un attore può: esserne il beneficiario esserne coinvolto (come operatore-protagonista) esserne il controllore esserne informato Caso d Uso Descrive il comportamento del sistema quando sollecitato da un attore, come visto da esso, fornendo un risultato osservabile all attore Il comportamento è descritto in maniera testuale, come sequenza di transazioni del sistema, il cui compito è produrre un risultato di valore misurabile per un attore del sistema. Una transazione è un insieme atomico di attività (sono completate o non sono eseguite affatto) La descrizione di un caso d uso definisce cosa accade nel sistema in seguito all evento di innesco Generalmente nasce con una richiesta da parte di un attore, ma può anche essere il sistema stesso ad iniziare il caso d uso (es. Produzione cedolini a fine mese, ricarico automatico di un magazzino) si conclude con la produzione di tutte le risposte relative alla richiesta Un caso d uso corrisponde ad un compito che l attore vuole eseguire (l attore inizia il caso d uso) o il sistema deve eseguire (il sistema inizia il caso d uso) 12 Ingegneria del Software - Prof. G. A. Di Lucca 6

7 Caso d uso e transazioni Esempio: cliente apri conto corrente Transazioni: verifica esistenza cliente in archivio anagrafico acquisizione nuove informazioni anagrafiche acquisizione firma digitalizzata registrazione nuovo conto corrente il punto di vista da adottare nella definizione dei casi d uso è quello dell attore, non quello delle funzionalità interne al sistema 13 Esempio: centralina telefonica per ufficio Trasferisci chiamata Utente Accetta chiamata Interrompe chiamata Effettua chiamata diretta Centralinista Effettua chiamata indiretta 14 Ingegneria del Software - Prof. G. A. Di Lucca 7

8 Descrizione di un caso d uso Definisce cosa accade nel sistema in seguito all evento di innesco (scenario): come e quando il caso d uso inizia chi inizia il caso d uso interazione tra attore/i e caso d uso e cosa viene scambiato come e quando c è bisogno di dati memorizzati o di memorizzare dati come e quando il caso d uso termina Sono descritti scenari normali e scenari alternativi (o eccezionali) Stili di descrizione: testuali, con un flusso chiaro di eventi da seguire diagrammatici 15 Use case, istanze e scenari Uno Use Case individua una tipologia di storie d uso del sistema Una istanza dello Use Case individua una specifica storia d uso Specifica una delle possibili sequenze di azioni che possono avvenire durante lo svolgimento dello use case Scenario: E una istanza di use case corredata da una descrizione esplicita Uno scenario individua e descrive esplicitamente una particolare istanza di uno use case, ovvero una delle possibili varianti Ad es. un ordine può essere elaborato regolarmente, o può mancare la merce ordinata o può mancare il credito nei confronti dell ordinante, Ciascuno di questi casi è uno scenario 16 specifico dello use case gestione ordini. Ingegneria del Software - Prof. G. A. Di Lucca 8

9 Casi d uso e scenari 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 le varianti possono essere aggiunte nei successivi raffinamenti dello use case 17 Esempio: Effettua chiamata interna Scenario 1: chiamata effettuata con successo L utente solleva la cornetta Il tono di libero interno suona L utente compone il numero La chiamata è inoltrata sulla rete telefonica Il telefono chiamato squilla Il tono di attesa suona L utente chiamato risponde I telefoni sono connessi Il telefono chiamato cessa di squillare Il tono di attesa finisce L utente chiamato ripone la cornetta sul telefono I telefoni sono disconnessi L utente ripone la cornetta sul telefono 18 Ingegneria del Software - Prof. G. A. Di Lucca 9

10 Esempio: Effettua chiamata interna Scenario 2: chiamata effettuata ma il telefono chiamato è occupato L utente solleva la cornetta Il tono di libero interno suona L utente compone il numero La chiamata è inoltrata sulla rete telefonica Il telefono chiamato è occupato Il tono di occupato suona L utente ripone la cornetta sul telefono 19 Esempio: apertura conto corrente scenario base: 1.il cliente si presenta in banca per aprire un nuovo c/c 2.l addetto riceve il cliente e fornisce spiegazioni 3.se il cliente accetta fornisce i propri dati 4.l addetto verifica se il cliente è censito in anagrafica 5.l addetto crea il nuovo conto corrente 6.l addetto segnala il numero di conto al cliente varianti: (3a) se il cliente non accetta il caso d uso termina (3b) se il conto va intestato a più persone vanno forniti i dati di tutte (4a) se il cliente (o uno dei diversi intestatari) non è censito l addetto provvede a registrarlo, richiede al cliente la firma dello specimen e ne effettua la memorizzazione via scanner 20 Ingegneria del Software - Prof. G. A. Di Lucca 10

11 Esempio: apertura conto corrente (ulteriore dettaglio) (5) l addetto crea il nuovo conto corrente scenario base: 1.l addetto richiede al sistema la transazione di inserimento nuovo conto 2.il sistema richiede i codici degli intestatari 3.l addetto fornisce i codici al sistema 4.il sistema fornisce le anagrafiche corrispondenti, e richiede le condizioni da applicare al conto 5.l addetto specifica le condizioni e chiede l inserimento 6.il sistema stampa il contratto con il numero assegnato al conto varianti: (3a) se il sistema non riconosce il cliente, o se fornisce un anagrafica imprevista, l addetto può effettuare correzioni o terminare l inserimento 21 Use Case e requisiti Requisiti e use case requisito (funzionale): funzionalità, o aspetto di dettaglio di una funzionalità, richiesta dal committente use case: modalità di utilizzo del sistema da parte di un utilizzatore (attore) ogni use case può soddisfare più requisiti funzionali un requisito funzionale può dare origine a più use case a ogni use case possono venire associati più requisiti non funzionali 22 Ingegneria del Software - Prof. G. A. Di Lucca 11

12 Relazioni fra casi d uso Tra gli use case possono esistere relazioni di tipo generalization, include, extend Tali relazioni sono usate per strutturare ulteriormente un modello dei casi d uso generalizzando/specializzando un caso d uso estraendo comportamenti comuni tra essi (include) distinguendo comportamenti varianti rispetto a quello base (inserendo tali comportamenti in altri use case che estendono quello base) 23 Generalizzazione fra casi d uso Un caso d uso figlio eredita il comportamento ed il significato del caso d uso padre Il figlio può aggiungere o modificare il comportamento del padre (es. Caso d uso Valida Utente) Valida utente Controlla Password Controlla Retina 24 Ingegneria del Software - Prof. G. A. Di Lucca 12

13 Relazione di Inclusione Un comportamento comune a più casi d uso diventa un caso d uso che è incluso nei casi d uso di partenza. L inclusione avviene in un punto preciso della descrizione del caso d uso includente. Il caso incluso non ha senso da solo. Rappresentato graficamente come una dipendenza stereotipata come <<include>> Descrizione di Segue iter ordinativo: Effettua ordinativo Segue iter ordinativo <<include>> <<include>> Valida utente - ottieni e verifica numero ordinativo - include (Valida utente) - per ogni parte dell ordine, interroga lo stato, quindi rapporta all utente 25 Relazione di Estensione Comportamenti alternativi o eccezionali (opzionali) di un caso d uso formano dei casi d uso che estendono il caso d uso generale nel caso d uso esteso viene inserito un punto d estensione nei sottocasi d uso si fa riferimento a questi punti caso d'uso generale <<extend>> <<extend>> sottocaso d'uso 1 sottocaso d'uso 2 26 Ingegneria del Software - Prof. G. A. Di Lucca 13

14 Esempio: gestione ordinativi bancari <<extend>> (fissa priorità) Effettua ordinativo <<include>> Schedula ordinativi Segui iter ordinativo <<include>> Valida utente Controlla password generalization 27 Esempio: centralina telefonica <<include>> Componi numero Trasferire chiamata <<include>> <<include>> Effettua chiamata indiretta Effettua chiamata diretta <<extend>> <<extend>> Effettua chiamata interna Effettua chiamata esterna 28 Ingegneria del Software - Prof. G. A. Di Lucca 14

15 Passi per la costruzione di un modello dei casi d uso Identificazione degli attori Identificazione dei casi d uso Definizione delle associazioni fra attori e casi d uso Descrizione dei casi d uso Strutturazione dei casi d uso Identificazione degli attori Identificare le persone che interagiscono con il sistema per eseguire qualche compito persone che necessitano del sistema per svolgere qualche compito persone che il sistema richiede per svolgere qualche compito considerare sia i compiti principali che quelli di supporto al sistema, quali manutenzione ed amministrazione Raggruppare le persone identificate secondo i loro ruoli (responsabilità) rispetto al sistema Identificare altri sistemi software e dispositivi esterni che interagiscono con il sistema per svolgere qualche compito 30 Ingegneria del Software - Prof. G. A. Di Lucca 15

16 2. Identificazione dei casi d uso Per ogni attore: identificare i compiti o funzioni che l attore deve essere in grado di eseguire identificare i compiti che il sistema richiede che l attore esegua Raggruppare compiti e funzioni in casi d uso i casi d uso devono corrispondere ad un obiettivo specifico per l attore o per il sistema raggruppare funzioni che sono eseguite in sequenza o che sono innescate dallo stesso evento il caso d uso non deve essere nè troppo grande nè troppo piccolo Assegnare al caso d uso un nome significativo che sintetizzi la/le funzionalità svolta/e Definizione delle associazioni fra attori e casi d uso Ogni attore deve partecipare in almeno un caso d uso Ogni caso d uso deve avere almeno un attore con cui comunica Se due attori partecipano agli stessi casi d uso considerare la possibilità di combinarli in un unico attore 32 Ingegneria del Software - Prof. G. A. Di Lucca 16

17 4. Descrizione dei casi d uso Considerare sia lo scenario principale che scenari alternativi ed eccezionali Per ogni scenario specificare: come e quando il caso d uso inizia chi avvia il caso d uso interazione tra attore/i e caso d uso e cosa viene scambiato come e quando c è bisogno di dati memorizzati o di memorizzare dati come e quando il caso d uso termina Se due casi d uso hanno comportamenti leggermente diversi e gli stessi attori, considerare la possibilità di avere un unico caso d uso con scenari alternativi Strutturazione dei casi d uso Identificare le relazioni di estensione: specializzare i casi d uso che hanno molti scenari alternativi collegare i nuovi casi d uso a quelli di partenza mediante relazione <<extend>> Identificare le relazioni di inclusione individuare parti comuni in casi d uso diversi collegare i casi d uso che condividono una parte comune al nuovo caso d uso (rappresentante il comportamento condiviso) mediante l associazione <<include>> 34 Ingegneria del Software - Prof. G. A. Di Lucca 17

18 I casi d uso sono necessariamente OO? sono stati inventati in ambito Object Oriented descrivono il sistema dal punto di vista delle funzionalità disponibili per gli attori esterni (come i messaggi OO) non rivelano la strutturazione interna del sistema costituiscono il punto di partenza migliore per una progettazione OO...ma sono utilizzabili anche in un processo di sviluppo non-oo non è necessario conoscere la teoria OO per utilizzarli e per capirli 35 implementazione dei casi d uso requisiti casi d uso analisi e progettazione object oriented analisi e progettazione strutturate altre tecniche (a piacere) acquisto componenti componenti (file, programmi) 36 Ingegneria del Software - Prof. G. A. Di Lucca 18