casi d' uso uml.pdf

Ingegneria del Software UML: I casi d’uso Vita Santa Barletta Danilo Caivano Antonio Piccinno  UML...

Ingegneria del Software UML: I casi d’uso Vita Santa Barletta Danilo Caivano Antonio Piccinno  UML Software Engineering Research LABoratory UML e i casi d’uso Architettura Vista Logica Vista Class Diagrams Object Diagrams dell’Implementazione... Component Diagrams Vista dei Casi d’uso Use Case Diagrams Vista dei Processi Vista di Sequence Diagrams Deployment Collaboration Diagrams Deployment Diagrams Activity Diagrams... La Vista dei Casi d’Uso cattura il comportamento del sistema così come esso appare all’esterno e partiziona le funzionalità del sistema in transazioni significative per gli attori 2 2 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Casi d’uso e scenari Scenario ❑ Sequenza di azioni caratterizzanti una particolare interazione tra uno o più attori di un sistema; tale sequenza di azioni deve produrre un risultato osservabile e significativo per tali attori Caso d’uso ❑ Un insieme di scenari che hanno in comune l’obiettivo 3 3 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Casi d’uso e scenari Proprietà ❑ Ogni scenario afferisce ad uno ed un solo caso d’uso ❑ Definisce il comportamento offerto dal sistema per produrre un risultato senza alcun riferimento alla struttura interna dello stesso ❑ Descritto in linguaggio naturale Classificazione degli scenari ❑ Base, quando termina con esito positivo ed ha uno svolgimento lineare ❑ Alternativo, quando termina con esito positivo seppur con diverse complicazioni, oppure ha esito negativo (fallisce) 4 4 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Casi d’uso e scenari Durante le attività di analisi capita di riscontrare imprecisione, rimozione o generalizzazione, e può essere utile formulare alcune domande ❑ Esattamente CHI …? ❑ Esattamente COSA …? ❑ Esattamente QUANDO …? ❑ Esattamente DOVE …? Ogni caso d’uso deve essere una dichiarazione precisa di una delle funzionalità del sistema! 5 5 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Negozio online: Esempio scenario Acquisto di un prodotto ❑ Carlo naviga nel catalogo e aggiunge gli articoli desiderati nel suo carrello della spesa. Quando Carlo desidera pagare, prima di concludere l’acquisto deve scegliere la modalità di spedizione e fornire i dati della propria carta di credito. Il sistema controlla se la carta di credito è valida e conferma l’acquisto sia immediatamente sia con un successivo messaggio di posta elettronica 1. La carta potrebbe non essere valida, in tal caso si avrebbe uno scenario separato 2. Un cliente abituale potrebbe aver già salvato un profilo con le preferenze relative alla spedizione e il numero di carta di credito: un terzo scenario 6 6 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Negozio online: Esempio di caso d’uso Acquisto di un prodotto 1. Il cliente naviga nel catalogo e seleziona gli articoli da acquistare 2. Il cliente si avvia alla cassa (check out) 3. Il cliente fornisce le informazioni relative alla spedizione (indirizzo; scelta fra consegna giornaliera o entro 3 giorni) 4. Il sistema presenta un prospetto con il conto totale, comprese le spese di spedizione 5. Il cliente riempie un modulo con le informazioni sulla carta di credito. 6. Il sistema autorizza l’acquisto 7. Il sistema conferma immediatamente la vendita 8. Il sistema invia al cliente una mail di conferma Estensioni: 3a Il cliente è abituale 3a.1 Il sistema visualizza le preferenze memorizzate riguardanti la spedizione, il pagamento e la fattura 3a.2 Il cliente può accettare il default o ridefinire le preferenze, in questo caso ritorna al passo 6 dello scenario principale 6a Il sistema non autorizza l’acquisto con carta di credito 6a.1 Il cliente può inserire nuovamente le informazioni e riprovare oppure cancellare l’acquisto 7 7 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Scenario 8 8 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory 9 Perché utilizzare i DIAGRAMMI DEI CASI D’USO ? Ingegneria del Software | UML e i casi d’uso 9  Software Engineering Research LABoratory Casi d’uso I casi d’uso nascono per fornire delle descrizioni di utilizzo di un sistema che siano facilmente ❑ comprensibili ❑ validabili anche da coloro che non hanno alcuna competenza informatica Formalizzati nel 1987 da Ivar Jacobson 10 10 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Diagrammi dei casi d’uso (1/3) Si utilizzano con diversi livelli di rigorosità ❑ Nelle prime fasi si è concentrati sul comprendere le necessità dell’utente ❑ Nelle fasi successive si è anche coinvolti nel processo di sviluppo del sistema e quindi il livello di rigorosità deve essere necessariamente elevato RIGOROSITÀ MAX RIGOROSITÀ 11 11 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Diagrammi dei casi d’uso (2/3) Definiscono molto chiaramente i confini del sistema ed evidenziano gli attori sia umani e non Evidenziano il comportamento del sistema, permettendo di evidenziare eventuali incoerenze e lacune nell’analisi dei requisiti 12 12 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Diagrammi dei casi d’uso (3/3) Permettono di realizzare un’ottima documentazione I casi d’uso opportunamente strutturati si prestano ad essere utilizzati come scenari di test 13 13 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Modellazione dei casi d’uso La modellazione dei casi d’uso prevede tipicamente i seguenti passi ❑ Individuare un potenziale confine del sistema ❑ Individuare gli attori ❑ Individuare i casi d’uso ed identificare le principali sequenze degli eventi alternativi 14 14 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Modellazione dei casi d’uso Relazione di comunicazione Confine di sistema Attore Caso d’uso Attore 15 15 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Confine del sistema (Subject) Definire cosa fa parte del sistema e cosa non ne fa parte del sistema Il confine del sistema è ❑ Definito da chi o cosa usa il sistema (gli attori) e dagli specifici benefici o funzioni che il sistema offre ai suoi attori (casi d’uso) ❑ Rappresentato da un rettangolo, etichettato con il nome del sistema ▪ Gli attori sono posizionati all’esterno del rettangolo ▪ I casi d’uso sono posizionati all’interno del rettangolo 16 16 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Attore Definizione ❑ Un ruolo o un insieme di ruoli che qualcuno o qualcosa, esterno al sistema, svolge nell’interagire con il sistema Proprietà ❑ Sempre esterno al sistema ❑ Interagisce direttamente con il sistema ❑ Rappresenta un ruolo generico che persone o altro (software, hardware,..) possono rivestire nei confronti del sistema ❑ Identificato da un nome breve, che abbia senso dal punto di vista del business ❑ Caratterizzato, sempre, da una breve descrizione 17 17 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Attore vs Utente Differenza concettuale tra ❑ Utente ▪ Soggetto/oggetto fisico che può utilizzare il sistema; ogni utente può assumere il ruolo di diversi attori per il Sistema Software ❑ Attore ▪ Ruolo che descrive una prospettiva d’uso del sistema software; lo stesso ruolo può essere svolto da uno o più utenti 18 18 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Attore Esempio di checklist per individuare gli attori ❑ Chi o cosa usa il sistema? ❑ Quale ruolo rivestono durante l’interazione con il sistema? ❑ Chi installa il sistema? ❑ Chi o cosa avvia e ferma il sistema? ❑ Chi effettua la manutenzione del sistema? ❑ Quali altri sistemi interagiscono con il sistema? ❑ Chi ottiene informazioni dal sistema e chi ne fornisce? ❑ Esistono funzioni che vengono eseguite a intervalli, orari o date prestabiliti? Dopo l’identificazione è necessario descrivere per ogni attore la prospettiva d’uso che ha del sistema 19 19 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Generalità dei casi d’uso Devono essere specificati sotto forma di testo ❑ a corredo di tali specifiche possono esserci delle rappresentazioni grafiche Modellano i requisiti funzionali di un sistema per come esso appare all’esterno (vista black-box) Definiscono i confini del sistema e gli attori, umani e non Generalmente attivati da un attore ma possono anche essere attivati dal sistema stesso ❑ (es. produzione cedolini a fine mese, ricarico automatico di un magazzino) Corrispondono a un compito che l’attore vuole svolgere (se l’attore attiva il caso d’uso) o che il sistema deve eseguire (se il sistema attiva il caso d’uso) Il più delle volte non sono esaustivi rispetto ai requisiti da soddisfare ❑ (e.g. requisiti non funzionali, condizioni da rispettare nello sviluppo) 20 20 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Esempio di checklist per identificare i casi d’uso Esempio di checklist per individuare i caso d’uso ❑ Quali funzioni si aspetta ciascun attore? ❑ Il sistema archivia e recupera informazioni? Se sì, quali attori provocano tale comportamento? ❑ Che cosa accade quando il sistema cambia stato? Esistono attori a cui è notificato tale cambio? ❑ Esistono eventi esterni che producono effetti sul sistema? Chi o cosa notifica tali eventi? ❑ Il sistema interagisce con un sistema esterno? ❑ Il sistema genera un report? Per identificare i casi d’uso è necessario assumere il punto di vista degli utilizzatori del sistema! 21 21 Ingegneria del Software | UML e i casi d’uso  Casi d’uso Software Engineering Research LABoratory DESCRIZIONE TESTUALE 22 22 Ingegneria del Software | UML e i casi d’uso  Template: Informazioni di base Software Engineering Research LABoratory Nome ID Breve descrizione Attori primari Attori secondari Precondizioni Sequenza principale degli eventi Post-condizioni Sequenza alternativa degli eventi 23 23 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Specifiche del caso d’uso (1/3) Denominazione. Non esiste uno standard di denominazione; esso deve esprimere il processo o la funzione di business che il caso d’uso modella; esprimendo un comportamento esso deve essere un verbo o un predicato verbale Identificatore. È un numero univoco che non cambia nel tempo anche quando il nome dovesse cambiare per esigenze semantiche Breve descrizione. Riassume brevemente obiettivo del caso d’uso Attori. Potrebbero esserci due tipi di attori: ❑ Primari: avviano effettivamente il caso d’uso ❑ Secondari: attori che interagiscono con il caso d’uso, dopo che è stato avviato, anche in momenti diversi Precondizioni. Specificano cosa debba essere vero prima che il caso d’uso possa essere avviato Postcondizioni. Specificano cosa debba essere vero dopo che il caso d’uso è stato eseguito 24 24 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Specifiche del caso d’uso (2/3) Sequenza principale degli eventi. Elenca i passi che compongono il caso d’uso ❑ Il caso d’uso inizia sempre con l’attore primario che fa qualcosa per avviare il caso d’uso ❑ Ogni passo è espresso con una frase strutturata come: il fa ; è un’affermazione che deve essere semplice e mai espressa in forma passiva ❑ Ramificazioni. Diramazioni semplici dalla sequenza principale; si esprimono con la parola chiave se ❑ Ripetizioni. Sequenza di eventi che deve essere ripetuta si esprimono con due tipi di parole chiavi: ▪ Per. Sintassi: Per (espressione di iterazione) ▪ Fintantoché. Sintassi: Fintantoché (espressione booleana è vera) 25 25 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Specifiche del caso d’uso (3/3) Sequenze alternative del caso d’uso. Percorsi alternativi che descrivono errori, interruzioni della sequenza principale e ramificazioni complesse. Possono: ❑ Non ritornare alla sequenza principale ❑ Ritornare alla sequenza principale ad un passo esplicitamente indicato Ogni sequenza alternativa richiede una specifica distinta con le seguenti convenzioni: ❑ Il nome deve fare riferimento a quello della sequenza principale ❑ L’identificatore è un numero composito la cui prima cifra è l’identificatore della sequenza principale ❑ Non deve avere sequenze alternative, altrimenti si creerebbe una eccessiva complessità ❑ Precondizioni e postcondizioni possono essere diverse da quelle della sequenza principale La sequenza alternativa può essere attivata: ❑ Al posto della principale essendo attivata dall’attore primario e sostituisce la sequenza principale ❑ Dopo uno specifico passo della principale esplicitamente indicato nella specifica della sequenza alternativa ❑ In qualunque momento, nel corso della principale, e deve essere esplicitamente espresso nella specifica alternativa Si esprimono le sequenze alternative significative, non quelle che non aggiungono informazioni utili alla comprensione del comportamento desiderato ❑ Ad esempio: non si definisce una sequenza alternativa per ogni errore possibile dell’attore nell’introduzione di dati 26 26 Ingegneria del Software | UML e i casi d’uso  Template Casi d’uso: Informazioni di base Software Engineering Research LABoratory Nome ID Breve descrizione Precondizioni Post-condizioni per Successo Post-condizioni per Fallimento Evento innescante Attori Primari Attori Secondari Include il caso d’uso (opzionale) Estende il caso d’uso (opzionale) Esteso dal caso d’uso (opzionale) Specializza il caso d’uso (opzionale) Generalizza il caso d’uso (opzionale) Requisiti Ingegneria del Software | UML e i casi d’uso  Esempio descrizione testuale caso d’uso (1/5) Software Engineering Research LABoratory Nome PagaIVA ID 1 Breve descrizione Pagamento dell’IVA alla fine del trimestre fiscale Attore implicito tempo Attori primari Tempo Attori secondari Fisco Precondizioni Si è concluso un trimestre fiscale Sequenza principale 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 sistema trasmette un pagamento elettronico al Fisco Post-condizioni Il Fisco riceve l’importo IVA dovuto Sequenza alternativa degli eventi Nessuna 28 28 Ingegneria del Software | UML e i casi d’uso  Esempio descrizione testuale caso d’uso (2/5) Software Engineering Research LABoratory Nome GestisciCarrello ID 2 Breve descrizione Il Cliente cambia la quantità di un articolo presente nel carrello Attori primari Cliente Attori secondari Nessuno Precondizioni Il contenuto del carrello della spesa è visibile Sequenza principale 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 del carrello 3. Se il Cliente digita una nuova quantità 3.1 Il sistema aggiorna la quantità dell’articolo presente nel carrello Post-condizioni Nessuna Sequenza alternativa degli eventi Nessuna 29 29 Ingegneria del Software | UML e i casi d’uso  Esempio descrizione testuale caso d’uso (3/5) Software Engineering Research LABoratory Nome TrovaProdotto ID 3 Breve descrizione Il sistema individua alcuni prodotti in base ai criteri di ricerca specificati dal Cliente e li mostra al Cliente Attori primari Cliente Attori secondari Nessuno Precondizioni Nessuna Sequenza principale degli eventi 1. Il caso d’uso inizia quando il Cliente seleziona “Trova Prodotto” 2. Il sistema chiede al Cliente i criteri di ricerca 3. Il Cliente inserisce i criteri di ricerca richiesti 4. Il sistema ricerca i prodotti che soddisfano i criteri specificati dal Cliente 5. Se il sistema trova uno o più prodotti 5.1 Per ogni prodotto trovato 5.1.1 Il sistema mostra l’immagine ridotta del prodotto 5.1.2 Il sistema mostra l’elenco delle caratteristiche del prodotto 5.1.3 Il sistema mostra il prezzo del prodotto 6. Altrimenti 6.1 Il sistema comunica al cliente che non sono stati trovati prodotti che soddisfano i criteri specificati Post-condizioni Nessuna Sequenza alternativa degli eventi Nessuna 30 30 Ingegneria del Software | UML e i casi d’uso  Esempio descrizione testuale caso d’uso (4/5) Software Engineering Research LABoratory Nome CreaAccount ID 4 Breve descrizione Il sistema crea un nuovo account per il cliente Attori primari Cliente Attori secondari Nessuno Precondizioni Nessuna Sequenza principale degli eventi 1. Il caso d’uso inizia quando il Cliente seleziona “Crea Account” 2. Fintantoché le informazioni del Cliente non sono valide 2.1 Il sistema chiede al Cliente di inserire le sue informazioni tra cui l’indirizzo di posta elettronica, la password e la conferma password 2.2 Il sistema valida le informazioni del Cliente 3. Il sistema crea un nuovo account per il Cliente Post-condizioni Un nuovo account è stato creato per il Cliente Sequenza alternativa degli eventi EmailNonValida PasswordNonValida Annulla 31 31 Ingegneria del Software | UML e i casi d’uso  Esempio descrizione testuale caso d’uso (5/5) Software Engineering Research LABoratory Nome CreaAccount:EmailNonValida ID 4.1 Breve descrizione Il sistema informa il Cliente che ha inserito un indirizzo di posta elettronica non valido Attori primari Cliente Attori secondari Nessuno Precondizioni Il Cliente ha inserito un indirizzo di posta elettronica non valido Post-condizioni Nessuna Sequenza alternativa degli eventi 1. La sequenza alternativa degli eventi inizia dopo il passo 2.2 della sequenza principale degli eventi 2. Il sistema informa il Cliente che ha inserito un indirizzo di posta elettronica non valido 32 32 Ingegneria del Software | UML e i casi d’uso  Casi d’uso Software Engineering Research LABoratory DIAGRAMMI 33 33 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Definizione Semantica ❑ È un diagramma che mostra attori e casi d’uso insieme alle relazioni tra questi elementi. I casi d’uso rappresentano le funzionalità di un sistema, manifestate agli attori, esterni, che con esso interagiscono Notazione ❑ È un grafico costituito da attori, casi d’uso e le relazioni tra questi elementi. Le relazioni sono associazioni tra attori e casi d’uso, generalizzazioni tra attori, generalizzazioni, estensioni e inclusioni tra casi d’uso 34 34 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Diagramma dei casi d’uso 35 35 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Notazione Attore Caso d’uso 36 36 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Tipi di Relazioni Elementi Relazione Funzione Notazione Attori Generalizzazione Un attore, eredita la partecipazione a tutti i casi d’uso con i quali l’attore specializzante comunica Attore – Caso d’uso Associazione Esprime la partecipazione di uno o più attori ad un caso d’uso Estensione Il comportamento di un caso d’uso base può, opzionalmente, essere esteso dal comportamento definito da un altro caso d’uso Casi d’uso Inclusione Il comportamento di un caso d’uso di base incorpora, sempre, il comportamento del caso d’uso di inclusione Generalizzazione Un caso d’uso generale ed uno o più specifici casi d’uso che ne ereditano ed aggiungono caratteristiche 37 37 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Generalizzazione tra attori Definizione ❑ Una generalizzazione tra un Attore A, padre, ed un Attore B, figlio, indica che (un’istanza di) B può comunicare con tutti i casi d’uso (istanze) che hanno relazione con A Proprietà ❑ Gli attori figli possiedono tutte le caratteristiche dell’attore padre e ne possono aggiungere delle altre 38 38 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Generalizzazione tra attori 39 39 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Generalizzazione tra attori relazione di Generalizzazione tra Attore A – Attore B 40 40 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Generalizzazione tra attori: Esempio Nel diagramma a sinistra si assume che l’interazione di Supervisore e Venditore con il sistema sia, esattamente, la stessa quando gestiscono un ordine La generalizzazione, nel diagramma a destra, indica che il ruolo di Supervisore copre il ruolo di Venditore 41 41 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Associazione Definizione ❑ Partecipazione di un attore ad un caso d’uso Proprietà ❑ È l’unica relazione tra attori e casi d’uso ❑ La direzione di un’associazione può essere: ▪ Bi-direzionale ▪ Uni-direzionale – da Attore a Caso d’uso – da Caso d’uso ad Attore ▪ Non specificata 42 42 Ingegneria del Software | UML e i casi d’uso  Associazione: Esempi Software Engineering Research LABoratory 43 43 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Estensione: Definizione ❑ Una relazione di estensione da un caso d’uso A (estendente) a un caso d’uso B (base o esteso) indica che un’istanza del caso d’uso B può essere accresciuta, sotto determinate condizioni specificate nell’estensione, dal comportamento specificato in A Proprietà ❑ Il punto di estensione nel caso d’uso base è etichettato con un nome di estensione ❑ Lo stesso nome è usato nel caso d’uso estendente per racchiudere il comportamento 44 44 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Punto di Estensione di un caso d’uso Definizione ❑ Riferimento a una locazione all’interno di un caso d’uso (base) in cui sequenze di azione di un altro caso d’uso (estendente) potrebbero essere inserite Proprietà ❑ Ogni punto di estensione è identificato da un nome (unico all’interno del caso d’uso); questo stesso nome, insieme alle azioni ad esso associate, è presente nel caso d’uso estendente ❑ L’estensione avviene sotto il controllo di una condizione di guardia ❑ Un caso d’uso base può avere più punti di estensione appartenenti a casi d’uso estendenti diversi 45 45 Ingegneria del Software | UML e i casi d’uso  Estensione: Flusso Software Engineering Research LABoratory Caso d’uso A --- --- Caso d’uso A “SegEstendente” di “Caso d’uso B” --- --- Fine Caso d’uso A 1 (nome segmento) SegEstendente --- --- Caso d’uso B (fine definizione di segEstendente) Fine Caso d’uso B 46 46 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Estensione: esempio di diagramma Caso d’uso di estensione Caso d’uso base Relazione “estende” 47 47 Ingegneria del Software | UML e i casi d’uso  Software Engineering Research LABoratory Estensione: esempio di descrizione testuale (1/2) Caso d’uso: RestituzioneLibro ID:9 Breve descrizione: Un utente restituisce al Bibliotecario un libro preso in prestito Attori primari: Bibliotecario Attori secondari: nessuno Precondizioni: Il Bibliotecario è stato autenticato dal sistema Sequenza degli eventi principale: 1. il Bibliotecario inserisce l’ID dell’utente che restituisce il libro 2. il sistema mostra i dettagli dell’utente che restituisce il libro, incluso un elenco di tutti i libri ancora da restituire 3. il Bibliotecario individua il libro restituito tra quelli presi in prestito punto di estensione: prestitoScaduto P.1. il Bibliotecario rimette a posto il libro …. Postcondizioni: Il libro è stato restituito Sequenze degli eventi alternative: nessuna 48 48 Ingegneria del Software | UML e i casi d’uso  Estensione: esempio di descrizione testuale (2/2) Software Engineering Research LABoratory Caso d’uso: EmissioneMulta RestituzioneLibro ID:10 punti di estensione Breve descrizione: prestitoScaduto Il Bibliotecario registra e stampa una multa Attori primari: Bibliotecario Attori secondari: il prestito è scaduto nessuno 1. il Bibliotecario inserisce i dati della multa nel sistema 2. il sistema stampa la multa Postcondizioni di segmento: 1. La multa è stata registrata nel sistema 2. il sistema ha stampato la multa EmissioneMulta Sequenze degli eventi alternative: nessuna 49 49 Ingegneria del Software | UML e i casi d’uso  Estensione: diagramma con punto di estensione e Software Engineering Research LABoratory specifica vincolo AcquistareLibro punti di estensione ScontareLibro fedeltàCliente {numacquisti