Analisi dei requisiti Il primo passo di “qualsiasi” processo di sviluppo è la definizione dei requisiti  Definizione del Business Model  Solitamente.

Presentazione sul tema: "Analisi dei requisiti Il primo passo di “qualsiasi” processo di sviluppo è la definizione dei requisiti  Definizione del Business Model  Solitamente."— Transcript della presentazione:

1

2

3 Analisi dei requisiti Il primo passo di “qualsiasi” processo di sviluppo è la definizione dei requisiti  Definizione del Business Model  Solitamente informale e in linguaggio naturale Jacobson propone una notazione particolare che è confluita in UML USE CASE DIAGRAMS

4 Caso d'Uso (def. 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)‏

5 Use Case -definizioni preliminari Descrive una particolare funzionalità fornita dal sistema o da una sua parte dal punto di vista dell’utilizzatore. Mostra le unità coinvolte nella fornitura del sistema (attori e sistema)‏ Uno use case:  Rappresenta le funzionalità visibili dall’utente  Può avere differenti granularità  Rappresenta un obiettivo specifico per l’utente In generale, gli use case vengono ricavati sulla base di colloqui con diversi profili di utenti che utilizzeranno il sistema

6 Use Case -notazione Actor: è qualcuno (utente) o qualcosa (sistemi esterni - hardware) che: Controlla le funzionalità Fornisce input o riceve output dal sistema Use Case: è un’unità funzionale parte del sistema

7 Use Case -attori Attore: entità esterna al sistema che interagisce con esso assumendo un ruolo Diversi attori con lo stesso ruolo e diversi ruoli con lo stesso attore Diversi attori possono esercitare uno use case e diversi use case che possono essere esercitati da un attore Non è detto che un attore corrisponda a una o più persone (es. sistema esterno) Gli attori possono essere il mezzo per individuare gli use case (individuo una lista di attori) Gli use case rappresentano le funzionalità ai morsetti del sistema

8 Relazione tra attori e use-case Può capitare che una funzione esista perché di interesse di un attore che non partecipa all’azione stessa Azione indotta da altre iniziative del sistema e ha come destinatario un attore fuori dal contesto operativo Es. notifica ordine di pagamento ad un compratore dopo 2 mesi dall’acquisto Un attore, nei confronti di uno use case può esserne il beneficiario, il controllore, informato,…

9 Relazione casi d'uso come interazioni i casi d’uso possono essere descritti sotto forma di scenario di interazione (dialogo) tra gli utilizzatori e il sistema: –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 va rivolta all’interazione, non alle attività interne al sistema

10 Relazioni principali Associations identificano relazioni semplici tra attori e casi Include fattorizza proprietà comuni. A includes B Extend identifica comportamenti simili (varianti). A può essere visto come una variante di B Generalization si applica sia ad attori che a use case. A eredita il comportamento di B. A può essere sostituito ad ogni occorrenza di B

11 Esempio di associazione (Ufficio Postale)‏ Il primo Use Case diagram definisce il contesto del modello Scelte diverse possono imporre Attori diversi e Use case diversi

12 Esempio diagramma dei casi d'uso caso d'uso: particolarità di uso del sistema attore: un utilizzatore del sistema (essere umano, altro sistema, …)‏

13 Esempio di associazione (Registrazione corsi)‏

14 Generalizzazione (1) Lo use case figlio Eredita tutti gli attributi, scenari… definiti nello use case padre Partecipa a tutte le relazioni in cui è coinvolto lo use case padre Lo use case figlio può prevedere nuovi scenari non previsti nello use case padre o ridefinirne alcuni Padre Uno use case Può ereditare da n altri use cases Può essere il padre di n altri use case

15 Generalizzazione (2)‏

16 Inclusione Esistono use case che rappresentano attività ricorrenti condivise da use case più complessi Per evitare di ripetere in ogni use case la descrizione dell’attività comune la si mette a fattor comune indicando che viene inclusa in use case più complessi La funzionalità individuata viene inclusa in un punto specifico o nella sua interezza nella sequenza di interazioni che caratterizza lo use case base. Analogie con Chiamata a sottoprocedura in un linguaggio di programmazione Stereotipo : >

17 Punti Estensione

18 Estensione Viene specificato in che modo sotto quali condizioni il comportamento individuato dallo use case estensione può essere incorporato nello use case base E’ necessario specificare sempre i punti estensione Quando si verifica la condizione di estensione lo use case estensione viene inglobato nello use case base Stereotipo: >

19 Esempio di inclusion (Immobiliare)‏

20 Esercizio (livello 0)

21 Raffinamento use-case (livello 1)‏

22 Modellazione flussi di eventi Flusso di eventi principali: corrisponde allo scenario di esecuzione ideale  L’attore non compie e non genera errori  Un flusso di eventi principale è sempre presente Flusso di eventi eccezionale  Cammino percorso in presenza di errori  Cammino percorso con bassa frequenza  Un caso d’uso presenta molto spesso eventi eccezionali

23 Modellazione flussi di eventi 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

24 esempio: apertura conto corrente 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: 3 (a) se il cliente non accetta il caso d’uso termina 3 (b) se il conto va intestato a più persone vanno forniti i dati di tutte 4 (a) se il cliente (o uno dei diversi intestatari) non è censito l’addetto provvede a registrarlo

25 Use case (Processo)‏ Il processo di definizione degli use case è iterativo  Si inizia identificando il comportamento più semplice  Si descrivono i comportamenti alternativi e più complessi Quando smettere?  Un buon livello di dettaglio facilità tutte le attività successive  Troppi dettagli - Complicherebbero inutilmente la descrizione - Introdurrebbero prematuramente scelte progettuali - Precluderebbero la visione d’insieme