I casi d uso corrispondono ai compiti che l attore (che può essere una persona fisica e non) può svolgere.

Transcript

1 UML e i Casi d USO I casi d uso specificano una sequenza di azioni che producono un risultato visibile agli attori del sistema. Essi nascono per fornire descrizioni delle capacità del sistema. I casi d uso possono essere inseriti nel documento di analisi al fine di migliorarlo, riscontrarne eventuali lacune e delimitare i confini entro i quali il sistema deve agire. I casi d uso corrispondono ai compiti che l attore (che può essere una persona fisica e non) può svolgere. Esistono vari modi per guardare un sistema, ma per identificare i casi d uso bisogna guardare il sistema dal punto di vista degli utilizzatori. DIAGRAMMA UML DEI CASI D USO È un diagramma che mostra gli attori relazionati ai casi d uso, cioè relazionati alle funzionalità del sistema. Le relazioni che possono sussistere sono: generalizzazione tra attori, estensione e inclusione tra casi d uso. È bene esplicitare le differenze tra attori e utenti del sistema software. Gli utenti del sistema sono i soggetti (o oggetti) fisici che accedono al sistema, ogni utente può assumere il ruolo di diversi attori. Gli attori accedono al sistema con una determinata prospettiva d uso. TIPI DI RELAZIONI 1. Gli attori possono essere relazionati tra loro tramite la relazione di generalizzazione; un attore specializzato eredita la partecipazione a tutti i casi d uso con i quali l attore specializzante comunica. 2. Gli attori possono essere in relazione con i Casi d Uso mediante associazione; tale relazione esprime la partecipazione di uno o più attori ad un caso d uso. 3. Infine i Casi d Uso possono essere relazionati tra loro mediante tre diversi tipi di relazioni: Estensione; Inclusione; Generalizzazione

2 ESTENSIONE Una relazione di estensione da un caso d uso A ad un caso d uso B indica che un istanza del caso d uso B può essere maggiorata, sotto determinate condizioni specificate nell estensione, dal comportamento di A

3 INCLUSIONE Una relazione di inclusione da un caso d uso A(base) ad un caso d uso B(incluso) indica che le funzionalità del caso d suo B saranno sempre presenti in un istanza del caso d uso A. Le differenze tra inclusione ed estensione sono chiare negli esempi appena riportati. Una relazione di inclusione : A include B indica che ogni istanza del caso d uso A include sempre il comportamento di B. Una relazione di estensione: A estende B indica che al verificarsi di opportune condizioni (condizioni di guardia) il comportamento di B può essere esteso dal comportamento di A. GENERALIZZAZIONE La relazione di generalizzazione tra un caso d uso B e un caso d uso A indica che A è una specializzazione di B. in questa relazione gioca un ruolo fondamentale il principio di ereditarietà. Un caso d suo specializzato eredita le caratteristiche, le estensioni e le associazioni del caso d uso che lo ha generato. Oltre ad ereditare il tutto, il nuovo caso d uso può aggiungere funzionalità o ridefinirne altre, quest ultima pratica conosciuta con il nome di Override. La specializzazione di un caso d uso esclude l esecuzione del caso d uso generale.

4 Descrizione testuale di un Caso d Uso Ogni descrizione di un caso d uso è caratterizzata dalla descrizione di informazioni di base che permettono di specificare il contesto, chi utilizza il caso d suo, cosa succede allo stato del sistema prima e dopo l attivazione del caso d uso ed uno o più scenari di interazione. A loro volta gli scenari di interazione si suddividono in: 1. Base, quando il caso d uso esegue il suo compito correttamente andando opportunamente a modificare lo stato del sistema. 2. Alternativi, quando il caso d uso termina con esiti positivi, con complicazioni o va incontro ad errori, cioè fallisce il suo compito.

5 Va notata l importanza del campo Pre Condizioni, il caso d uso non viene eseguito se non risulta verificata la Pre Condizione. ESEMPIO DI INFORMAZIONE DI BASE

6 ESEMPIO DI SCENARI BASE E ALTERNATIVI ERRORI COMUNI Per la determinazione dei casi d uso non esiste una pratica standard da seguire, giocano un ruolo fondamentale l esperienza e la buona conoscenza del dominio applicativo, tuttavia è bene tener a mente alcune cose DA NON FARE per non incorrere in errori abbastanza comuni: 1. Usare i casi d uso per descrivere funzionalità interne del sistema Esempio: funzioni elementari di creazione, lettura, aggiornamento ed eliminazione di ogni entità del sistema 2. Frammentare i casi d uso in modo eccessivo Eccessivo uso delle relazioni di inclusione, estensione, generalizzazione 3. Assegnare un eccessiva importanza ai diagrammi 4. Separare i comportamenti sulla base del tipo di architettura del sistema Esempio: in un applicazione client server, distinguere i comportamenti operanti sul lato server e quelli sul lato client.

7 Questa guida è stata creata da wais87 prendendo in considerazione gli appunti presi a lezione e I documenti resi disponibili dai docenti del corso di ingegneria informatica