Ingegneria del software1 Casi d’uso. Ingegneria del software2 Sommario Definizione Caratteristiche dei casi d’uso Casi d’uso e UML Diagramma dei casi.

Presentazione sul tema: "Ingegneria del software1 Casi d’uso. Ingegneria del software2 Sommario Definizione Caratteristiche dei casi d’uso Casi d’uso e UML Diagramma dei casi."— Transcript della presentazione:

1 Ingegneria del software1 Casi d’uso

2 Ingegneria del software2 Sommario Definizione Caratteristiche dei casi d’uso Casi d’uso e UML Diagramma dei casi d’uso Definizione, proprietà, notazione Attori Relazioni Errori comuni

3 Ingegneria del software3 Definizione Una sequenza di transazioni di un sistema, il cui compito è di produrre un risultato di valore misurabile per uno o più attori del sistema (Ivar Jacobson et al. 1995) La descrizione di un caso d’uso definisce cosa accade nel sistema in seguito all’evento di attivazione

4 Ingegneria del software4 Definizione Un caso d'uso rappresenta una particolare funzionalità fornita da una specifica entità* e descritta sia dalla serie di messaggi scambiati tra l’entità stessa e Gli attori, sia dalla sequenze di azioni svolte (definizione UML 1.5) * entità: sistema, sottosistema, classe

5 Ingegneria del software5 Utilità dell’utilizzo dei casi d’uso Fornire delle descrizioni di utilizzo di un sistema che siano facilmente leggibili comprensibili validabili anche da chi, (spesso il committente e gli utilizzatori), non ha alcuna competenza informatica

6 Ingegneria del software6 Caratteristiche I caso d’uso devono essere specificati sotto forma di testo; a corredo di tali specifiche possono esserci delle rappresentazioni grafiche possono essere integrati con l’Analisi di un sistema, per aiutare a scoprire il comportamento che i suoi utenti si aspettano e quindi a rilevare eventuale lacune ed incoerenze dell’Analisi modellano i requisiti di un sistema per come esso appare all’esterno (vista black-box) definiscono molto chiaramente i confini del sistema e gli attori, umani e non

7 Ingegneria del software7 Caratteristiche sono 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)

8 Ingegneria del software8 Identificare i casi d’uso A seconda della parti interessate Committente Commerciale Analista Progettista Implementatore Manutentore Utilizzatore … esistono diversi modi di “guardare” un sistema Per identificare i casi d’uso è necessario assumere il punto di vista degli utilizzatori!

9 Ingegneria del software9 Esempio di identificazione dei casi d’uso Gestione della posta elettronica protocolli TCP/IP algoritmi criptaggio/decriptaggio meta-informazioni di ogni e-mail interessano il progettista ed il manutentore inserire, inoltrare, cancellare una e-mail usare i filtri, creare una propria firma interessano l’utilizzatore

10 Ingegneria del software10 UML ed i Casi d’Uso UML prevede una divisione del sistema in viste* Vista casi d’uso Vista Strutturale Classi Oggetti Vista Implementativa componentii Vista comportamentale Sequenza Collaborazione Stati Attività Vista Ambientale Configurazione

11 Ingegneria del software11 Vista dei Casi d’uso … 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, ossia gli utenti idealizzati del sistema *insieme di costrutti e concetti che rappresentano uno stesso aspetto di un sistema

12 Ingegneria del software12 Vista dei Casi d’uso … Proiezioni Statica fornisce una mappa degli utilizzi del sistema, i.e. l’insieme di tutti i casi d’uso, relazioni ed elementi che interagiscono con il sistema è rappresentata mediante i Diagrammi dei casi d’uso Dinamica illustra la sequenza di interazioni tra gli elementi del sistema al fine di eseguire un caso d’uso o una parte di esso è rappresentata mediante uno o più dei seguenti diagrammi: Stato, Sequenza, Collaborazione

13 Ingegneria del software13 Diagrammi dei Casi d’Uso 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

14 Ingegneria del software14 Attore Definizione un ruolo o un insieme di ruoli che qualcuno o qualcosa, esterno al sistema, svolge nell’interagire con il sistema Esempi di Attori una classe di persone fisiche (es. fornitore, manager, studente, lettore, …) un altro sistema software (es. sistema di contabilità, sistema informativo) un dispositivo hardware (es. scanner)

15 Ingegneria del software15 Attori: esempi L'icona dello stereotipo standard di un attore è uno "stickman" (uomo stilizzato), con al di sotto di esso indicato il nome dell'attore ManagerSistemaLegacyStudenteUniversitario Segreteria DBMSSitoE-CommerceClienteScanner

16 Ingegneria del software16 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

17 Ingegneria del software17 Caso d’uso: notazione Un caso d'uso è rappresentato mediante un ellisse all'interno del quale dovrebbe essere indicato il nome del caso d'uso. A volte, per convenzione del tool, il nome del caso d'uso è indicato al di sotto dell'ellisse. Al di sopra del nome può essere indicato, opzionalmente, lo stereotipo del caso d'uso. Al di sotto del nome può essere presente, opzionalmente un elenco delle proprietà del caso d'uso. NomeCasodUso

18 Ingegneria del software18 Tipi di Relazioni Elementi relatiRelazioneFunzioneNotazione AttoriGeneralizzazioneun attore, specializzato, eredita la partecipazione a tutti i casi d’uso con i quali l’attore specializzante comunica Attore - caso d’uso AssociazioneEsprime la partecipazione di uno o più attori ad un caso d’uso Casi d’uso EstensioneIl comportamento di un caso d’uso base può, opzionalmente, essere esteso dal comportamento definito da un altro caso d’uso InclusioneIl comportamento di un caso d’uso di base incorpora, sempre, il comportamento dei casi d’uso di inclusione GeneralizzazioneUn caso d’uso generale ed uno o più specifici casi d’uso che ne ereditano ed aggiungono caratteristiche

19 Ingegneria del software19 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 Attore genericoAttore specializzato Notazione

20 Ingegneria del software20 Generalizzazione tra attori Caso d’uso1 Caso d’uso 2 Caso d’uso 4 Caso d’uso 3 Caso d’uso 4 Caso d’uso 1 Caso d’uso 2 Caso d’uso 3 Attore B Attore C Attore A Attore B Attore C Attore A

21 Ingegneria del software21 Generalizzazione: esempio (1) Guest Administrator CrearePassword EliminarePassword ModificareSistema EliminareAccount CreareAccount InstallareSoftware ControlloAccesso

22 Ingegneria del software22 Generalizzazione: esempio (2) Venditore Supervisore InserireOrdine RicercareProdotto AnnullareOrdine ValidareVenditore InserireOrdine RicercareProdotto AnnullareOrdine ValidareVenditore Venditore Supervisore

23 Ingegneria del software23 Associazione Definizione partecipazione di un attore ad un caso d’uso, i.e. istanze dell’attore e istanze del caso d’uso comunicano l’una con l’altra 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

24 Ingegneria del software24 Associazione: esempi Cliente SincronizzareVendite EffettuareIscrizione NotificareIscrizione AcquistareLibro Cliente > 11..* Comunicazione bi-direzionale Comunicazione caso d’uso-attore Comunicazione attore-caso d’usoIndicazione della molteplicità e dello stereotipo. La direzione della comunicazione non è specificata Un’associazione è mostrata da una linea continua tra l’attore e il caso d’uso. Possono essere indicate, opzionalmente, la molteplicità, la direzione o lo stereotipo. Assumiamo che la direzione indichi chi innesca l’interazione.

25 Ingegneria del software25 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

26 Ingegneria del software26 Punto di Estensione di un Caso d’Uso un caso d’uso base può avere più punti di estensione appartenenti a casi d’uso estendenti diversi un caso d’uso estendente può avere più segmenti di estensione

27 Ingegneria del software27 Estensione Definizione una relazione di estensione da un caso d’uso A (estendente) a un caso d’uso B ( base) 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 in A è etichettato con un nome di estensione lo stesso nome è usato nel caso d’uso estendente per racchiudere il comportamento

28 Ingegneria del software28 Estensione: esempi (1) Sulla freccia di estensione si può indicare, opzionalmente, la condizione che deve essere soddisfatta perché il caso d’uso estendente sia avviato. Cliente Richiedere Estratto Conto Effettuare Prelievo Extension points: Importo prelevato Notificare azzeramento credito Importo azzerato >

29 Ingegneria del software29 Estensione: esempio (2) Cliente Effettuare Prelievo Extension points: Importo prelevato Notificare azzeramento credito Importo azzerato > {numacquisti>15}

30 Ingegneria del software30 Estensione: Flusso Use Case A Use Case B Use case A ------------ “SegEstendente” di “Use Case B” ------------ End Use case A Use case B ------------ (Inizio Definizione di SegEstendente) (nome segmento) SegEstendente ------------ (fine definizione di SegEstendente) (definizione di SecondoSegEstendente) (nome segmento) SecondoSegEstendente ------------ (fine definizione di SecondoSegEstendente) End Use case B > 2 1

31 Ingegneria del software31 Inclusione Definizione Una relazione di inclusione da un caso d’uso A (base) ad un caso d’uso B(incluso) indica che un’istanza del caso d’uso A conterrà anche il comportamento specificato da B. Proprietà Il comportamento di B è inserito nella locazione definita in A come di inclusione. La relazione di inclusione esplicita come il caso d’uso di base incorpora il comportamento del caso d’uso di inclusione (è molto utile quando si vuole evitare il ripetersi di uno stesso flusso di sequenza)

32 Ingegneria del software32 Inclusione: Esempio Cliente Effettuare prelievo Richiedere Mutuo Verificare garanzia di copertura > Una relazione è rappresentata da una freccia, tratteggiata e con la “testa”aperta, che punta dal caso d’uso base al caso d’uso incluso

33 Ingegneria del software33 Inclusione: Flusso Use Case A Use Case B Flusso degli eventi Use case A ------------ Include UseCaseB ------------ end UseCaseA Flusso degli eventi UseCase B ------------ end Use case B > 2 1

34 Ingegneria del software34 Differenze tra Inclusione ed Estensione Relazione di Inclusione caso d’uso A include il caso d’uso B specifica che il comportamento di B include sempre il comportamento, nella sua totalità, di B Relazione di Estensione caso d’uso A estende il Caso d’uso B specifica che il comportamento di B potrebbe essere esteso da una parte o dalla totalità del comportamento di B qualora si verifichi una determinata condizione (condizione di guardia)

35 Ingegneria del software35 Generalizzazione tra i casi d’uso Definizione una generalizzazione da un caso d’uso B a un caso d’uso A indica che A è una specializzazione di B Proprietà il caso d'uso generale definisce una serie di passi, ed ha relazioni di associazione con uno o più attori ogni caso d'uso specializzato eredita le caratteristiche, i passi, gli eventuali punti di estensione e le associazioni del caso d'uso generale

36 Ingegneria del software36 Generalizzazione tra i casi d’uso il caso d'uso specializzato può aggiungere nuovi passi, oppure ridefinire i passi ereditati da quello generale (override) il caso d’uso generale non è mai eseguito l’esecuzione di un caso d’uso specializzato esclude l’esecuzione di tutti gli altri casi d’uso specializzati

37 Ingegneria del software37 Generalizzazione tra i casi d’uso: esempio Una generalizzazione è rappresentata da una freccia, continua e con la “testa” chiusa, che parte dal caso d’uso specializzato e punta al caso d’uso generale ValutareDipendente ValutazionePersonalizzata ValutazioneStandard ResponsabileCommessa

38 Ingegneria del software38 Descrizione Testuale di un Caso d’Uso Indicazioni UML non fornisce alcuna specifica su come definire la descrizione testuale di un caso d’uso Indicazioni generali ogni descrizione di un caso d’uso è caratterizzata da un insieme di informazioni di base:  permettono di definire:  il contesto  chi comunica e perché con il caso d’uso  cosa deve essere vero prima e dopo l’attivazione del caso d’uso, da uno o più scenari di interazione

39 Ingegneria del software39 Scenari di interazione Definizione ogni specifica esecuzione (istanza) di un caso d’uso assume il nome di scenario (di interazione) Descrizione di uno scenario sequenza di passi, in linguaggio naturale, che specifica il dialogo, costituito da stimoli e risposte, tra il sistema e gli attori coinvolti nello scenario Gli scenari sono classificati come Base: quando il caso d’uso termina con esito positivo ed ha uno svolgimento lineare Alternativi il caso d’uso termina con esito positivo, con diverse complicazioni, oppure ha esito negativo (fallisce)

40 Ingegneria del software40 Scenari e casi d’uso Distinzione netta in teoria, risulta essere molto più sfumata nella pratica; se ad un caso d’uso, infatti, corrispondono più scenari di base si potrebbe rendere ognuno di questi in un caso d’uso Osservazione qualunque sia la soluzione scelta l’insieme delle responsabilità del sistema non cambia

41 Ingegneria del software41 Scenari e casi d’uso Aggiornare Catalogo prodotti Inserire nuovo prodotto nel catalogo Aggiornare caratteristiche prodotto esistente Eliminare prodotto dal catalogo Scenari di base: Inserire nuovo prodotto nel catalogo Cancellare prodotto dal catalogo Aggiornare prodotto nel catalogo Scenari di base: Inserimento prodotto Scenari di base: Aggiornamento prodotto Scenari di base: Eliminazione prodotto Prima soluzione Seconda soluzione

42 Ingegneria del software42 Informazioni di base Descrizione Pre-Condizioni Post-Condizioni per Successo Post-Condizioni per Fallimento Evento innescante Attore Primario 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)

43 Ingegneria del software43 Pre-Condizione vs Inclusione L’esecuzione di un caso d’uso incluso implica che al termine della sua esecuzione, positiva o negativa che sia, l’interazione riprenda esattamente dal passo immediatamente successivo a quello di inclusione. La pre-condizione se non soddisfatta implica la non eseguibilità del caso d’uso compilazioni memorizzate RicaricareCellulare EffettuarePrelievo AutenticareUtente RicaricareCellulare AutenticareUtente EffettuarePrelievo ?

44 Ingegneria del software44 Esempio di Informazioni di base (1) Compilare questionario DescrizioneInserimento dei dati di un questionario compilato, del compilatore e dell’addetto all’inserimento. Tali dati saranno utilizzati per ottenere informazioni sui servizi oggetto di valutazione Pre-CondizioniIl questionario appartiene alla popolazione dei questionari progettati; il questionario non è stato “chiuso”; lo studente non ha già compilato il questionario Post-Condizioni per SuccessoI dati saranno oggetto dell’elaborazione statistica Post-Condizioni per FallimentoNessuna modifica è apportata all’insieme delle compilazioni memorizzate Evento innescanteRiportare una compilazione in formato cartaceo nel formato elettronico Attore PrimarioAddetto all’inserimento

45 Ingegneria del software45 Esempio di Scenari di base ed alternativi (1) Scenario di base 1. L’addetto all’inserimento inserisce le informazioni relative all’intestazione del questionario 1.3 nome studente 1.4 cognome studente 1.5 numero di matricola 1.6 giorno di sottomissione del questionario 2. L’addetto all’inserimento inserisce le risposte 3. L’addetto all’inserimento avvia la registrazione del questionario compilato 4. Il sistema registra la compilazione Scenario alternativo 1 2. Il sistema notifica che alcuni dati inseriti sono errati 2.1 L’addetto all’inserimento può correggere i dati, o terminare il caso d’uso annullando l’inserimento Scenario alternativo 2 3. L’addetto all’inserimento inserisce risposte non riconosciute come valide 3.1 Il sistema visualizza un messaggio che informa l’utente di quali risposte non sono valide 3.2 L’addetto all’inserimento modifica le risposte non valide, o terminare il caso d’uso annullando l’inserimento

46 Ingegneria del software46 Esempio di Informazioni di base (2) RicaricareSchedaTelefonica DescrizionePermettere ad un ClientePostamat di ricaricare la propria scheda telefonica selezionando l’importo desiderato e la compagnia fornitrice del servizio telefonico Pre-CondizioniLa card ed il PIN del ClientePostamat sono stati riconosciuti come validi Post-Condizioni per SuccessoIl sistema invia un sms, al numero indicato da ricaricare, che notifica l’avvenuta ricarica e l’importo della ricarica Post-Condizioni per FallimentoIl sistema non registra l’operazione Evento innescanteIl ClientePostamat richiede di effettuare una ricarica telefonica Attore PrimarioClientePostamat

47 Ingegneria del software47 Esempio di Scenari di base ed alternativi (2) Scenario di base 1. Il sistema visualizza l’insieme delle compagnie fornitrici del servizio telefonico 2. L’utente seleziona la compagnia 3. Il sistema richiede l’inserimento del prefisso telefonico 4. L’utente digita il prefisso telefonico quindi conferma il suo inserimento 5. Il sistema richiede l’inserimento del numero telefonico 6. L’utente digita il numero telefonico, quindi conferma il suo inserimento 7. Il sistema espelle la card 8. L’utente preleva la card 9. Il sistema visualizza gli importi ricaricabili 10. L’utente opera una scelta e la conferma 11. Il sistema visualizza la scelta operata e ne chiede conferma 12. L’utente conferma la scelta operata 13. Il sistema emette lo scontrino SCENARIO ALTERNATIVO 1 4 L’utente immette un prefisso telefonico inesistente 4.1 Il sistema impedisce la digitazione di un prefisso inesistente 4.2 Il caso d’uso termina se l’utente sbaglia, consecutivamente, la digitazione per cinque volte SCENARIO ALTERNATIVO 2 8. L’utente impiega più di cinque minuti per operare una scelta 9. Il sistema avvisa l’utente, informandone della causa, che interromperà l’operazione 10. Il caso d’uso termina SCENARIO ALTERNATIVO 3 (insuccesso) 4 o 6 o 10 L’utente annulla l’operazione Il caso d’uso termina

48 Ingegneria del software48 Casi d’uso: errori comuni usare i casi d’uso per descrivere le funzionalità interne del sistema Esempio: funzioni elementari di creazione, lettura, aggiornamento ed eliminazione di ogni entità del sistema frammentare i casi d’uso in modo eccessivo eccessivo uso delle relazioni di inclusione, estensione, generalizzazione assegnare un’eccessiva importanza ai diagrammi i diagrammi di per sé non sono sufficienti per comprendere e validare le modalità di utilizzo del sistema

49 Ingegneria del software49 Casi d’uso: errori comuni fornire delle descrizioni improprie estrema sinteticità descrizione di una funzionalità in termini astratti descrizione della logica interna di funzionamento del sistema indicazioni di livello tecnico relative ai singoli campi di input e output, ai relativi data type, ai controlli da effettuare, alla specifica di algoritmi separare i comportamenti sulla base del tipo di architettura del sistema Esempio: operare, in un’applicazione client-server, delle distinzioni tra i comportamenti operanti sul lato client e quelli sul lato server