Sistemi Informativi SPECIFICA DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti UML Use Case Esercizi Obiettivi Nelle lezioni precedenti abbiamo modellato il dominio business e i dati L obiettivo di oggi é: Comprendere cosa sia una specifica dei requisiti. Acquisire gli strumenti (i.e. imparare un linguaggio) per disegnare i requisiti funzionali. 2
Sistemi Informativi SPECIFICA DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti UML Use Case Esercizi Modello di riferimento 4
Flusso di lavoro di modellazione Raccolta Requisiti IT 5 Cosa vuol dire modellare i requisiti? L analisi dei processi aziendali porta ad una loro maggiore comprensione. Dalla definizione fino al livello di attività è possibile arrivare, attraverso una procedura di selezione detta mappatura dei requisiti, a determinare quali attività devono essere supportate da un sistema informativo e in che modo. La mappatura dei requisiti consente dunque di determinare, successivamente alla analisi di processo, quali sono le caratteristiche, dal punto di vista dell utente, che un sistema informativo deve avere per supportare adeguatamente un dato processo. Questo porta alla specifica dei requisiti del sistema informativo. 6
Requisiti funzionali Il requisiti funzionali definiscono che cosa un sistema informativo deve fare (i.e. le funzionalità), a prescindere dalla sua implementazione informatica, cioè dal come Lo scopo è descrivere le operazioni (i.e. le funzionalità) che un utente può effettuare con il sistema 7 Requisiti funzionali vs requisiti non funzionali I requisiti non funzionali descrivono altre caratteristiche che il sistema deve possedere a prescindere dalle funzionalità, per esempio: o Qualità (e.g. tempo di risposta del sistema, tempo di aggiornamento dei valori); o Facilità d uso (e.g. tempo di addestramento per gli utilizzatori, numero di maschere di aiuto); o Affidabilità (e.g. Tempo medio di malfunzionamento del sistema, disponibilità del sistema); o Robustezza (e.g. Percentuale di eventi causante malfunzionamenti, Tempo per il riavvio dopo un malfunzionamento); o Altri (e.g. sicurezza) I requisiti non funzionali sono fuori ambito 8
Raccolta e descrizione dei requisiti I requisiti possono essere descritti da asserzioni in linguaggio naturale, e.g. ATM Il sistema deve mettere a disposizione le funzioni di prelievo, deposito, trasferimento fondi. Il sistema deve essere accessibile a persone portatori di Handicap, deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 con sistema operativo compatibile con quello della Banca. Le operazioni di prelievo devono richiedere autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze bancarie 9 Raccolta e descrizione dei requisiti - funzionali I requisiti possono essere descritti da asserzioni in linguaggio naturale, e.g. ATM Il sistema deve mettere a disposizione le funzioni di prelievo, deposito, trasferimento fondi. Il sistema deve essere accessibile a persone portatori di Handicap, deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 con sistema operativo compatibile con quello della Banca. Le operazioni di prelievo devono richiedere autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze bancarie 10
Raccolta e descrizione dei requisiti non funzionali I requisiti possono essere descritti da asserzioni in linguaggio naturale, e.g. ATM Il sistema deve mettere a disposizione le funzioni di prelievo, deposito, trasferimento fondi. Il sistema deve essere accessibile a persone portatori di Handicap, deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 con sistema operativo compatibile con quello della Banca. Le operazioni di prelievo devono richiedere autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze bancarie 11 Sistemi Informativi SPECIFICA DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti UML Use Case Esercizi
Perchè UML? L utilizzo del linguaggio naturale nella descrizione delle specifiche dei requisiti porta spesso ad incomprensioni e ad una scarsa organizzazione dei requisiti stessi, mentre l uso di notazioni diverse in fase di progettazione non consentiva un efficace comunicazione tra tutti coloro che dovevano leggere il progetto e renderlo realtà traducendolo in effettivo codice sorgente. L UML (Unified Modeling Language) nasce come unione di diverse modalità di diagrammazione e descrizione volte a rendere più chiare ed efficaci le fasi di stesura delle specifiche dei requisiti e della progettazione dei sistemi The Three Amigos (Jacobson, Raumbaugh, Booch) sono considerati i fondatori dell UML 13 Il problema del linguaggio 14
UML views La versione base dell UML si occupa di fornire un linguaggio comune per la specifica dei requisiti IT e per la progettazione, il collaudo e la manutenzione del software che implementa questi requisiti. Per la specifica delle funzionalità di un sistema si utilizza il diagramma dei casi d uso User View 15 Use case - definizione Un caso d uso rappresenta un insieme di azioni compiute da un sistema che porta ad un risultato osservabile di valore per uno o più attori esterni al sistema o Il sistema deve prevedere la funzione di prelievo. They are used to capture the requirements of a system, that is, what a system is supposed to do UML Superstructure Specification, v2.3, OMG Proposti da Ivar Jacobson nel 1992 all interno di Objectory. 16
Use case diagram - Attori Actors Rappresenta un utente esterno al sistema che ne utilizza le funzionalità ( NON è obbligatorio che sia un umano) Ruolo che una persona o un dispositivo hardware o un altro sistema gioca rispetto al sistema Gli attori eseguono casi d uso Prima si cercano gli attori, poi i loro casi d uso Gli attori ottengono valore dal caso d uso o vi partecipano L attore scambia informazioni col sistema Un attore può essere contenitore di informazioni Un attore può anche rappresentare un altro sistema 17 Use case diagram Use Cases Use cases Rappresenta una funzionalità, ovvero un comportamento richiesto al sistema Rappresenta uno scenario di interazione (un 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 si focalizza sull interazione, non sulle attività interne al sistema Subject Rappresenta il sistema in esame al quale si applicano i casi d uso Subject Use Case 18
Flusso degli eventi Ogni caso d uso Ha una sequenza di transizioni normale o di base Può avere varie sequenze alternative Ha varie sequenze di transazioni eccezionali per la gestione di situazioni erronee 19 Use Case - Descrizione Un caso d uso descrive l interazione tra un attore e un sistema. Per ogni caso d uso è necessario allegare una descrizione semistrutturata tra l attore e il sistema o L utente fa. o Il sistema fa 20
Use Case Esempio 0 CU 3: INSERIMENTO CONFERMA D ORDINE [CU3.1] Il commerciale riceve da un cliente una conferma d ordine o un ordine [CU3.2] Il commerciale apre la finestra di Conferma ordinativo per un dato cliente [CU3.3] Il commerciale carica le previsioni effettuate da se stesso per un determinato articolo e periodo temporale [CU3.4] Il sistema evidenza se l articolo viene prodotto in make oppure in buy [CU3.5] Il sistema evidenza il prezzo standard dell articolo e il tempo medio di realizzazione [CU3.5.1] Se presenti, il commerciale carica le previsioni effettuate ed inviate dal cliente, per un determinato articolo e periodo temporale [CU3.6] Il commerciale inserisce i dati di conferma ordinativo pervenuti dal cliente per un determinato articolo [CU3.6.1] Se i dati sono corrispondenti a una previsione, è sufficiente inserire i dati di conferma e trasformare la previsione in un impegno [CU 3.6.2] Se i dati non sono corrispondenti a una previsione, si inseriscono tutti i dati necessari e si crea un impegno 21 Esempio 1 Il sistema deve mettere a disposizione le funzioni di prelievo, deposito, trasferimento fondi. Il sistema deve essere accessibile a persone portatori di Handicap, deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 con sistema operativo compatibile con quello della Banca. Le operazioni di prelievo devono richiedere autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze bancarie 22
Use case diagram esempio 1 Il subject (sistema) è rappresentato da un rettangolo che visibilmente contiene i propri casi d uso Il caso d uso si rappresenta con una ellisse, con il nome del caso d uso segnato all interno oppure sotto la forma L actor si rappresenta con lo stickman, è sempre esterno al sistema ed è associato ai casi d uso che può attivare 23 Use Case Diagram - Associazioni Generalizzazione o Una associazione di generalizzazione (verso l alto) o specializzazione (verso il basso) rappresenta la relazione di IS-A tra gli elementi (i.e. padre e figlio) Inclusione o Una relazione di inclusione definisce che un caso d uso contiene il comportamento di un altro caso d uso Estensione o Una relazione di estensione specifica come e quando il comportamento di uno use case modifica il comportamento di un altro use case 24
Use case diagram - generalizzazione Una associazione di generalizzazione (verso l alto) o specializzazione (verso il basso) rappresenta la relazione di IS-A tra gli elementi Il figlio eredita il comportamento del padre e può aggiungere o modificarne il comportamento Il figlio può essere sostituito in qualsiasi punto appaia il genitore Una associazione di generalizzazione può riguardare sia due actors sia due use cases Si rappresenta con la freccia vuota Padre Figlio 25 Esempio 2 L amministratore di sistema, oltre ad avere accesso alle funzioni base dell ATM, deve essere in grado di registrare l ATM presso una specifica banca. Inoltre, deve aver accesso ai log del sistema per operare in caso di guasti 26
Use case diagram esempio 2 L Administrator eredita tutte le associazioni di Customer 27 Use case diagram - inclusione Definizione Una relazione di inclusione definisce che una caso d uso contiene il comportamento di un altro caso d uso Si usa per non descrivere più volte lo stesso flusso di eventi, inserendo il comportamento comune in un caso d uso a parte Evita di copiare parti di descrizione di casi d uso Notazione Si rappresenta con una freccia tratteggiata e lo stereotype <<include>> Use case indipendente Card Identification 28
Esempio 3 Il sistema deve mettere a disposizione le funzioni di prelievo, deposito, trasferimento fondi. Il sistema deve essere accessibile a persone portatori di Handicap, deve garantire un tempo di risposta inferiore al minuto, e deve essere sviluppato su architettura X86 con sistema operativo compatibile con quello della Banca. Le operazioni di prelievo e trasferimento fondi devono richiedere autenticazione tramite un codice segreto memorizzato sulla carta. Il sistema deve essere facilmente espandibile, e adattabile alle future esigenze bancarie 29 Use case diagram esempio 3 30
Use case diagram - estensione Definizione Una relazione di estensione specifica come e quando il comportamento di uno use case modifica il comportamento di un altro use case Utile per specificare delle varianti dello use case Utilizzo Cattura il caso d uso di base Per ogni passo del flusso base chiedersi Cosa potrebbe andar male? Come potrebbe funzionare in modo diverso? Scrivere ogni variante come estensione del caso d uso 31 Use case diagram - estensione Notazione Si rappresenta con una freccia tratteggiata e lo stereotype <<extend>> Use case indipendente Perform ATM Transaction Specificare Extension Point Use Case Variante 32
Esempio 4 [ ] L utente deve poter ottenere una ricevuta se lo richiede. La ricevuta riporta il tipo di transazione, la data, il numero di conto, la somma ed il nuovo saldo 33 Use case diagram esempio 4 w/ Receipt 34
Confronto <<extend>> e <<include>> Scopo diverso <<include>> Fattorizza comportamento comune Spesso nessun attore è associato al caso d uso comune Sono possibili attori diversi per i casi d uso chiamanti <<extend>> Distingue le varianti Gli attori associati eseguono il caso d uso e tutte le estensioni L attore è collegato al caso base 35 Use Case Diagram - Osservazioni 1. Il diagramma dei casi d uso non dà informazione sulla sequenzialità degli use cases o Withdraw non avviene prima di Transfer Funds 2. Il diagramma serve a consolidare e razionalizzare i requisiti del sistema 3. Il diagramma serve a descrivere i requisiti ad alto livello di un sistema quindi deve essere comprensibile da tutti gli stakeholders 36
Use case - Osservazioni 1. Un caso d uso modella una funzionalità completa (flusso principale di esecuzione, flussi alternativi eventuali, condizioni di eccezione). Ricordarsi che l attore sta cercando di raggiungere il suo obiettivo 2. Un caso d uso è una funzionalità visibile esternamente dall utente e come tale da esso percepita, interagendo con il sistema/software 3. E eseguibile indipendentemente (i casi d uso possono condividere oggetti durante l esecuzione, ma ciascuna esecuzione è indipendente dalle altre) 4. Un caso d uso rappresenta una funzionalità che è iniziata da un attore (una volta iniziato, il caso d uso può poi interagire con altri attori) oppure da un evento che notifica un attore; è possibile che un attore riceva semplicemente i risultati di un caso d uso iniziato da un altro attore 5. Un caso d uso è produce sempre al termine dell esecuzione un risultato significativo e percepibile come tale esternamente da un altro attore 37 Esercizio Descrivere gli use cases evidenziati seguendo lo schema. Use Case: Main flow: Exceptional/alternative flow: w/ Receipt 38
Use case: Withdraw Main flow: Soluzione 1 Include (Card Identification) The system prompts user for amount to withdraw The user inputs the amount to withdraw The system checks the available funds of user The system checks the available money of ATM The system gives the money The system removes the amount from the account (print receipt) The system prints the current balance Exceptional flow If not sufficient funds or money available, prompt user for lower amount 39 Use case: Deposit Money Main flow: Soluzione 2 The system prompts user for amount of deposit The user inputs the amount of deposit and the bank account number The system opens the slot The system gets the cash (print receipt) The system prints the balance + the deposited amount Exceptional flow If the deposited cash is different from the declared amount, return the cash to the user 40
Use case: Card Identification Main flow: Soluzione 3 The user inserts the card The system prompts user for PIN number The user inputs the PIN number The system checks the validity of the card and the PIN number Exceptional flow If card or PIN is not valid, reject user 41 Esercizio TreniVeloci Il canale di vendita si appoggia ad un sistema per creare biglietti per i treni. Ogni soluzione puo avere un numero arbitrario di viaggiatori. Deve essere possibile visualizzare soluzioni alternative nel caso i posti siano terminati. 42
Use case: Crea Nuovo Biglietto Soluzione Precondition: Lo scenario di business è attivato quando si esprime l interesse ad acquistare una soluzione di viaggio, precedentemente selezionata. Main flow: 1. L attore specifica il numero di viaggiatori e la classe. 2. Il sistema visualizza i prezzi/tariffe disponibili (per i quali sono presenti un numero di posti pari al numero di viaggiatori selezionati), su quel treno/treni. 2 (a) Il sistema, qualora ci fosse disponibilità di posti a prezzi promozionali in soluzioni di viaggio contigue temporalmente a quella selezionata, le visualizza in modo propositivo (si veda il caso in cui il sistema riconosca il cliente fidelizzato). 3. Se lo scenario può richiedere la prenotazione di uno o più posti o servizi. (Prenotare posto o servizio). 4 Il sistema crea una nuova istanza di biglietto digitale in cui sono inseriti gli estremi del viaggio. Al biglietto creato è associato un codice identificativo univoco. 4 (a) Se richiesto dall utente, il biglietto può essere nominativo Exceptional flow 2 (b) Nel caso di indisponibilità di posti per la soluzione selezionata il sistema propone soluzioni contigue. 43 Errori tipici - Grafici <<extend>>: La freccia va dal caso variante al caso standard SI NO <<include>>: la freccia va dal caso più esterno al caso comune SI NO 44
Errori tipici - Scenario Mancata connessione alla rappresentazione grafica Se i casi d uso sono connessi allora la descrizione testuale deve denotare questo fatto: <<include>> include (Indentificazione Carta) <<extend>> extend(stampa ricevuta)... 45 Errore grave Diagrammi di flusso invece di casi d uso: un caso d uso è una sequenza di azioni, non una singola azione 46
Use Case specifica di Jacobson Attori Flusso eventi Precondizioni Eccezioni Criticità Caso d uso Descrizione Flussi alternativi Postcondizioni Frequenza Attori: attori afferenti o efferenti al caso Descrizione: frase che sintetizza la natura del caso Flusso Eventi: elenco numerato dei sottorequisiti che compongono il caso. Flussi Alternativi: modalità alternative di esecuzione del caso. Pre Condizioni: asserzioni che devono essere verificate perché il caso possa essere iniziato (si usa per stilare i piani di collaudo) Post Condizioni: asserzioni che devono essere verificate alla fine dell esecuzione del caso d uso (per i piani di collaudo) Eccezioni: possibili errori che devono essere rilevati nel sistema, di eventi che possono causare una esecuzione del caso d uso non lineare/corretta (per i piani di collaudo) Frequenza stimata di utilizzo (per decidere le priorità nel piano di sviluppo) Criticità (per stimare il rischio legato al requisito) 47 Caso d uso: specifica - esempio 1.1.1 [CU3]: Inserimento Conferma d Ordine 1.1.1.1 Attori Commerciale 1.1.1.2 Breve Descrizione Permette di visualizzare le previsioni di ordine per cliente e articolo, inserire un ordine e confrontare la previsione con l ordine effettivo. 1.1.1.3 Flusso di Eventi 1.1.1.3.1 Flusso Base [CU3.1] Il commerciale riceve da un cliente una conferma d ordine o un ordine. [CU3.2] Il commerciale apre la finestra di Conferma ordinativo per un dato cliente. [CU3.3] Il commerciale carica le previsioni effettuate da se stesso per un determinato articolo e periodo temporale [CU3.4] Il sistema evidenzia se l articolo è make or buy [CU3.5] Il sistema evidenzia il prezzo standard dell articolo e il tempo medio di realizzazione. [CU3.6] Se presenti, il commerciale carica le previsioni inviate dal cliente [CU3.7] Il commerciale inserisce i dati di conferma ordine pervenuti dal cliente. [CU3.8]Se i dati della conferma ordine sono corrispondenti alla previsione, è sufficiente inserire i dati di conferma e trasformare la previsione in un impegno. [CU3.9] Se i dati non sono corrispondenti a una previsione, si inseriscono i dati e si crea un impegno. 1.1.1.3.2 Flussi Alternativi [CU3.10] Il commerciale decide di non inserire l impegno perché l ordine è sensibilmente difforme alla previsione venditore. [CU3.11] Il commerciale decide di non inserire l impegno perché l ordine è sensibilmente difforme alla previsione cliente. [CU3.12] Il commerciale decide di non inserire l ordine perché il prezzo concordato è sensibilmente difforme al prezzo standard. 1.1.1.4 Pre Condizioni Al commerciale perviene un ordine da trasformare in impegno. 1.1.1.5 Post Condizioni E stato inserito un impegno a fronte dell ordinativo, oppure non si è in alcun modo modificata la situazione precedente. 1.1.1.6 Eccezioni Dati inseriti non validi 1.1.1.7 Frequenza Stimata di Utilizzo (bassa, media, alta) ALTA 1.1.1.8 Criticità (bassa, media, alta) ALTA 48
Esempi di documenti di specifica dei requisiti Standard IEEE/ANSI 830-1998 49 Sistemi Informativi SPECIFICA DEI REQUISITI FUNZIONALI Obiettivi Specifica dei Requisiti UML Use Case Esercizi
Esercizi EX1 BivioMare 51 www.dilbert.com 52