Il diagramma dei casi d uso Laboratorio di Ingegneria del Software Prof. Paolo Ciancarini Dott. Sara Zuppiroli A.A. 2010/2011 Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 1 / 31
Desiderata I desiderata sono ciò che il cliente desidera. Formalizzare i desiderata in requisiti è una delle più importanti sfide aperte dell ingegneria del software. La specifica errata o incompleta delle richieste del cliente è una delle cause principali del fallimento dei progetti software. Il diagramma e la modellazione dei casi d uso aiutano l interazione con il cliente. Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 2 / 31
Requisiti funzionali I requisiti funzionali specificano cosa deve essere fatto. Sono indipendenti dalla tecnologia, dall architettura, dalla piattaforma, dal linguaggio di programmazione. I requisiti non-funzionali specificano vincoli aggiuntivi, ad esempio: performance scalabilità tolleranza ai guasti dimensione degli eseguibili I casi d uso vengono utilizzati per schematizzare i requisiti funzionali. Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 3 / 31
Che cosa sono i casi d uso Si tratta di un diagramma che esprime un comportamento, desiderato o offerto. Individua chi o che cosa ha a che fare con il sistema (attore) e che cosa l attore può fare (caso d uso). Tipicamente è il primo tipo di diagramma ad essere creato in un processo o ciclo di sviluppo, nell ambito dell analisi dei requisiti. Modella i requisiti funzionali di un sistema. Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 4 / 31
Es. Desiderata Un negozio di articoli sportivi desidera acquistare un applicazione che permetta l acquisto on-line di alcuni articoli. I clienti si dovranno registrare. Il cliente potrà scegliere gli articoli secondo alcuni parametri raccolti nel catalogo definito dall amministratore del negozio on-line. Si potranno acquistare più articoli in una sola transazione, questi articoli formeranno un carrello. Al termine dell acquisto saranno disponibili diversi metodi di pagamento. Gli ordini effettuati dovranno essere smaltiti dal reparto ordini, che dovranno inviare la merce all indirizzo desiderato. Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 5 / 31
Estrarre i requisiti Chi interagisce con il sistema (attori)? Clienti Amministratori del negozio online Reparto ordini Cosa fanno (casi d uso)? Il cliente si registra, consulta il catalogo ed effettua acquisti L amministratore organizza il catalogo, che è diviso in categorie Il reparto ordini riceve ordini da evadere Il cliente sceglie il tipo di pagamento Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 6 / 31
Elementi del diagramma: attore Cliente Admin Resp. Ordini Un attore specifica un ruolo assunto da un utente o altra entità che interagisce col sistema nell ambito di un unità di funzionamento (caso d uso). Un attore è esterno al sistema. Un attore può essere un oggetto o una persona Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 7 / 31
Come individuare gli attori Per individuare un attore è necessario individuare chi/cosa interagisce col sistema e con quale ruolo. Per individuare gli attore può essere utile rispondere alle seguenti domande: Chi/cosa usa il sistema? Che ruolo ha chi/cosa interagisce col sistema? Chi/cosa avvia il sistema? Altri sistemi interagiscono col sistema? Ci sono funzioni attivate periodicamente? /it es. backup Chi/cosa ottiene o fornisce informazioni dal sistema? Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 8 / 31
Elementi del diagramma: caso d uso (1) Consulta catalogo UML Reference Manual specifica definisce un caso d uso come: La specifica di una sequenza di azioni, incluse eventuali sequenze alternative e sequenze di errore che un sistema, un sottosistema, o una classe può eseguire interagendo con attori esterni. È qualcosa che un attore vuole il sistema faccia. Per questo: È descritto dal punto di vista dell attore È causato da un azione di un attore Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 9 / 31
Come individuare un caso d uso Individuare i casi d uso è un operazione iterativa. Per aiutare all individuazione dei casi d uso possono aiutare le seguenti domande: Ciascun attore che funzioni si aspetta? Il sistema gestisce (archivia/fornisce) informazioni? Se sì quali sono gli attori che provocano questo comportamento? Alcuni attori vengono informati quando il sistema cambia stato? Alcuni eventi esterni producono effetti sul sistema? Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 10 / 31
Elementi del diagramma: sistema Applicazione web Consulta catalogo Organizza catalogo Acquista prodotto Delimita l argomento del diagramma, specificando i confini del sistema. Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 11 / 31
Elementi del diagramma: associazione (1) Consulta catalogo Cliente Collega gli attori ai casi d uso. Un attore si può associare solo a casi d uso. Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 12 / 31
Elementi del diagramma: generalizzazione Impiegato Persona Acquista orologio Acquista prodotto Collega un attore o caso d uso ad un altro più generale. Il figlio può sostituire il genitore dovunque questi appaia. Il figlio eredita il comportamento di del padre Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 13 / 31
Elementi del diagramma: include Acquista prodotto <<include>> Consulta catalogo <<include>> Effettua pagamento È una dipendenza tra casi d uso; il caso d uso incluso è un sottoinsieme del caso d uso che lo include. Il caso d uso che include (Acquista prodotto) esegue la propria sequenza fino al punto di inclusione, quindi passa al caso d uso incluso (Consulta catalogo, Effettua pagamento). Non si possono formare cicli di include. L attore è associato al caso d uso che include È simile alla chiamata di funzione. È usato per identificare parti comuni a più casi d uso. Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 14 / 31
Elementi del diagramma: extend Acquista prodotto <<extend>> Registra account Una dipendenza tra casi d uso con stereotipo extend, la freccia va verso il caso d uso che genera l estensione. L attore è associato al caso d uso che è esteso. Il caso d uso che estende (client) specifica un incremento di comportamento da quello esteso e può accadere sotto certe condizioni. È un comportamento supplementare ed opzionale. Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 15 / 31
Extension points Acquista prodotto Extension Points Account non registrato <<extend>> Registra account Un caso d uso raggiunto da almeno un extend può opzionalmente visualizzare i propri extension points. Specifica i punti e/o condizioni dell esecuzione in cui il comportamento viene esteso. Se gli extension points sono molti, alcuni tool possono supportare la rappresentazione a rettangolo (i casi d uso sono classificatori). Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 16 / 31
include vs. extend Include specifica comportamento obbligatorio. Extend specifica comportamento supplementare. Nell include la freccia va dal caso d uso che include verso quello incluso. Nell extend la freccia va dal caso d uso che estende verso quello esteso. Sono entrambi costrutti utili, ma non se ne deve abusare, o la leggibilità ne risente. Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 17 / 31
Esempio diagramma Web store Consulta catalogo Registra account Cliente <<include>> <<extend>> Genera ordine <<include>> Acquista prodotto <<include>> Impiegato Resp. ordini Admin Evadi ordine Modifica catalogo Immetti dati pagamento Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 18 / 31
Modellare i casi d uso Se i requisiti del sistema non sono banali, nasce l esigenza di abbinare i diagrammi dei casi d uso a specifiche testuali più formali. I diagrammi dei casi d uso non sono adatti a mostrare: la sequenza temporale dei comportamenti lo stato del sistema e degli attori prima e dopo l esecuzione del caso d uso Altri diagrammi (attività, stato, interazione) si occupano di queste viste, ma devono partire da una specifica. Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 19 / 31
Specifiche del caso d uso Ogni caso d uso ha un nome e una specifica. La specifica è composta da: precondizioni: condizioni che devono essere vere prima che il caso d uso si possa eseguire sequenza degli eventi: i passi che compongono il caso d uso postcondizioni: condizioni che devono essere vere quando il caso d uso termina l esecuzione Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 20 / 31
Esempio specifica caso d uso Esempio Nome del caso d'uso Caso d'uso: PagamentoIVA Identificatore univoco Gli attori interessati dal caso d'uso Lo stato del sistema prima che il caso d'uso possa iniziare I passi del caso d'uso Lo stato del sistema quando l'esecuzione del caso d'uso è terminata ID: UC1 Attori: Tempo, Fisco Precondizioni: 1. Si è concluso un trimestre fiscale Sequenza degli eventi: 1. Il caso d'uso inizia quando si conclude un trimestre fiscale. 2. Il sistema calcola l'ammontare dell'iva dovuta al Fisco. 3. Il sitema trasmette un pagamento elettronico al Fisco. Postcondizioni: 1. Il Fisco riceve l'importo IVA dovuto. UML 68 Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 21 / 31
Sequenza degli eventi Un elenco di azioni che definisce il caso d uso nella sua completezza. Il caso d uso si considera eseguito solo se l esecuzione arriva fino alla fine. Un azione è sempre iniziata da un attore oppure dal sistema (in UML, gli eventi sono sempre legati a chi li crea). Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 22 / 31
Sequenze alternative Ad ogni passo della sequenza degli eventi principale, cercare: alternative all azione eseguita in quel passo errori possibili nella sequenza principale interruzioni che possono avvenire in qualunque momento della sequenza principale Sequenze alternative abbastanza complesse possono essere descritte separatamente. stessa sintassi, si sostituisce caso d uso con sequenza degli eventi alternativa il primo passo può indicare il punto della sequenza principale da cui si proviene Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 23 / 31
Ramificazione di una sequenza UML usa parole chiave per esprimere ramificazione, ripetizione o sequenze alternative. Parola chiave Se: indica una ramificazione della sequenza degli eventi nel caso si verifichi una condizione. È bene non eccedere con le ramificazioni. Ripetizioni all interno di una sequenza: parola chiave Per (For) parola chiave Fintantoché (While) Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 24 / 31
Esempio ramificazione definire la sequenza del caso d uso aggiorna carrello di un negozio on-line. È stato richiesto che il carrello venga aggiornato se viene inserito/eliminato/aggiornata la quantità nel carrello. Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 25 / 31
Esempio ramificazione ID: UC2 Attori: Cliente Esempio Caso d'uso: AggiornaCarrello Precondizioni: 1. Il contenuto del carrello è visibile Sequenza degli eventi: 1. Il caso d'uso inizia quando il Cliente seleziona un articolo nel carrello. 2. Se il Cliente seleziona rimuovi articolo 2.1 Il Sistema elimina l'articolo dal carrello. 3. Se il Cliente digita una nuova quantità 3.1 Il Sistema aggiorna la quantità dell'articolo presente nel carrello Postcondizioni: 1. Il contenuto del carrello è stato aggiornato Sequenza alternativa 1: 1. In qualunque momento il Cliente può abbandonare la pagina del carrello Postcondizioni: UML 72 Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 26 / 31
Scenari Uno scenario rappresenta una particolare interazione tra uno o più attori e il sistema. Uno scenario è un istanza di un caso d uso. Non contiene ramificazioni o sequenze alternative: è semplicemente la cronaca di un interazione vera o verosimile. il concetto risulta più immediato pensando agli attori in maniera concreta: non un generico cliente, ma Alice o Bob Utili per immaginare il sistema all opera e modellare i casi di test. Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 27 / 31
Scenario principale e scenari secondari Corrispondono ad esecuzioni della sequenza principale e di quelle alternative, rispettivamente. Strategie per limitare il numero, potenzialmente enorme, degli scenari secondari: documentare solo quelli considerati più importanti se ci sono scenari secondari molto simili, se ne documenta uno solo, se necessario aggiungendo annotazioni per spiegare come gli altri scenari differiscano dall esempio. Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 28 / 31
Esercizio gestione biblioteca Viene richiesto un sistema che permetta al bibliotecario e a un utente di effettuare ricerche di libri. Il bibliotecario deve poter effettuare il prestito e gestire la restituzione del libro. Un utente deve restituire il libro entro una certa data. Se il prestito risulta scaduto per la prima volta il sistema emette un avviso, se è la seconda volta il bibliotecario registra e stampa una multa. L utente a questo punto può decidere se pagare la multa subito oppure no. Il sistema deve permettere la registrazione del pagamento. Disegnare il diagramma dei casi d uso e descrivere le sequenze relative. Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 29 / 31
Esercizio gestione del personale Viene richiesto un sistema che permetta la gestione del personale di un azienda. Per accedere alle operazione bisogna autenticarsi. Le operazioni possibili saranno la modifica dei dati dell impiegato, la semplice visualizzazione dei suoi dati, e la cancellazione dei dati. Disegnare il diagramma dei casi d uso e descrivere le sequenze relative. Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 30 / 31
Esercizio Ricerca di un prodotto Una libreria ha la necessità di un sistema che le permetta di far effettuare ricerche al suo personale. All interno della libreria vengono venduti anche dvd video, e cd musicali. Disegnare il diagramma dei casi d uso e descrivere le sequenze relative. Lab di Ingegneria del Software () Il diagramma dei casi d uso A.A. 2010/2011 31 / 31