Illustrazione del processo di analisi, progettazione e sviluppo in riferimento a un caso di esempio

Transcript

1 Illustrazione del processo di analisi, progettazione e sviluppo in riferimento a un caso di esempio (Agenzia turistica) Prima scrittura: ottobre 2006 Ultima Revisione 6 settembre 2011 Scopo del documento Lo scopo di questo documento è illustrare un metodo per l intero processo di analisi, progettazione e sviluppo di un sistema software in riferimento a un caso applicativo concreto, per quanto semplificato. 1 Il caso di studio Un agenzia turistica avente sede in un luogo vacanziero organizza escursioni. Le escursioni hanno durata giornaliera e (per semplicità) sono di due tipi: gite in barca e gite a cavallo. Per ogni escursione sono previsti alcuni optional acquistabili dall eventuale partecipante. I tipi di optional possibili sono tre: pranzo, merenda, visita a un sito. I tipi di optional associati a una data escursione possono differire da caso a caso. Per esempio: la gita in barca del giorno x può prevedere il pranzo e la merenda, la gita in barca di due giorni dopo può prevedere il solo pranzo, l escursione del giorno y può non prevedere optional. Il prezzo degli optional è fisso ed è determinato solo dal tipo. Invece, ogni singola escursione ha un suo prezzo. Ogni escursione prevede un numero massimo di partecipanti. I prezzo di una escursione, il limite ai partecipanti e tutto ciò che corrisponde alla definizione dell escursione stessa viene fissato all atto della sua immissione nel programma dell agenzia. Questi dati possono anche essere modificati, in corso di esercizio, dopo che essi sono stati immessi. Si deve realizzare un sistema in grado di gestire le prenotazioni. A tal fine il sistema deve: 1. Consentire di inserire, eliminare, modificare le escursioni nel programma stagionale dell agenzia. 2. Permettere di registrare un partecipante ad una data escursione, consentendo, nel caso siano previsti, la scelta di eventuali optional; calcolare il costo dell escursione comprensivo degli optional. 3. Cancellare un partecipante già iscritto da una data escursione. 4. Aggiungere o eliminare un optional relativamente a un dato partecipante e una data escursione; calcolare il nuovo prezzo dell escursione. 1.1 Osservazione Una specifica come quella precedente è quanto un ingegnere del software può aspettarsi nella pratica del mestiere. Un esame anche superficiale della medesima mostra che essa è molto approssimata e certamente incompleta. Per esempio si afferma che è possibile eliminare o modificare una escursione già a programma. In un contesto reale l eliminazione di una escursione avrebbe conseguenze non trascurabili: avvisare gli iscritti, rimborsarli di quanto pagato, tenere conto della restituzione del danaro nella contabilità, ecc. Si tratta di funzionalità che in un contesto reale non possono essere trascurate. Lo scopo dell analisi è proprio quello della loro completa identificazione. Risulta evidente che l analista deve coinvolgere in questo processo il committente e gli utenti finali del sistema. Più avanti, attraverso l analisi dei requisiti preciseremo meglio le specifiche precedenti. 2 Il metodo seguito Il metodo di analisi, progettazione e sviluppo si ispira a quello descritto in [2]. Più specificatamente esso prevede i seguenti passi. 1

2 1. Analisi dei requisiti Specifica dei requisiti funzionali Costruzione del modello di dominio Analisi dei casi d uso Validazione requisiti casi d uso 2. Analisi/Progetto preliminare Analisi di robustezza Rifinitura dei casi d uso e eventuali aggiornamenti al modello di dominio 3. Progetto dettagliato Diagrammi di sequenza Assegnazione delle responsabilità (operazioni) alle classi 4. Realizzazione 3 La specifica dei requisiti funzionali Con il termine requisiti si intende l insieme delle proprietà che un prodotto deve possedere per soddisfare al proprio scopo di uso. Tradizionalmente i requisiti di un prodotto software vengono raccolti in un documento denominato SRS (specifica dei requisiti software, ovvero software requirement specification). Talo documento ha lo scopo di definire esattamente cosa il sistema farà (non come come lo farà). Lo standard IEEE 830 (ultima edizione 1998)[1] definisce i criteri (e il formato) secondo cui deve essere redatta una specifica dei requisiti. Essenzialmente, lo standard prevede l elencazione dei requisiti funzionali e propone alcuni metodi secondo cui essi devono essere descritti. Purtroppo lo standard in questione è piuttosto vecchio e non contempla il ricorso ai casi d uso, che, almeno da quando si è diffuso UML, costituiscono la tecnica preferita per specificare il cosa. Il metodo delineato al Paragrafo 2 è fortemente influenzato dall analisi dei casi d uso. Tuttavia, esso prevede, come fase iniziale, la stesura delle specifiche in forma testuale, secondo tradizione consolidata. Si ritiene infatti che sia comunque utile stendere un elenco ordinato e strutturato dei requisiti, in forma testuale. Del resto, nella pratica professionale, l elencazione dei requisiti è sempre il passaggio iniziale attraverso cui l analista software e il committente arrivano a concordare cosa ci si aspetta dal sistema. Spesso si parla di raccolta dei requisiti, proprio per evidenziare che si tratta di un processo tramite il quale si cerca di ottenere, rendere manifeste tutte le caratteristiche che il sistema deve possedere. È un processo che dovrebbe coinvolgere analista, committente e utente finale. Dopo le fasi di raccolta dei requisiti e di analisi dei casi d uso è buona norma incrociare i requisiti con i casi d uso, individuando da quali casi d uso sono coperti i vari requisiti, in modo di poter verificare se niente è stato tralasciato. La parte seguente costituisce dunque una sintetica SRS. 1 Con riferimento allo standard IEEE 830, essa è strutturata in tre paragrafi che identificano lo scopo, i vincoli e i requisiti funzionali. Scopo. La corretta identificazione dello scopo è importante in fase di analisi, in quanto ci aiuta a capire quali sono le entità da modellare e come vanno modellate (evidentemente la scelta deve cadere su entità che hanno senso rispetto allo scopo che il sistema si prefigge). Vincoli. Il vincoli sono condizioni o proprietà di carattere generale che il sistema deve rispettare. Requisiti funzionali. Funzionalità che il sistema deve esibire, elencate in modo ordinato e non ambiguo. 1 Data la semplicità del nostro problema, la specifica del Paragrafo 1 è quasi sufficiente a rappresentare i requisiti. Abbiamo tuttavia osservato che la essa è incompleta e ambigua. I requisiti riportati al Paragrafo 3.1 hanno lo scopo di eliminare le ambiguità rilevate. 2

3 3.1 Specifica dei requisiti Scopo Lo scopo del sistema è la gestione delle prenotazioni dell agenzia. Vincoli Il sistema viene realizzato come installazione unica, per funzionare all interno di una agenzia avente una sola sede. Tutte le operazioni vengono effettuate dal solo personale dell agenzia e non c è necessità di distinguere i differenti impiegati. Ciò equivale ad assumere che ci sia un solo attore. Requisiti funzionali R1 Il sistema deve consentire l inserimento di una nuova escursione nel programma dell agenzia in qualunque momento. R1.1 Ogni escursione è caratterizzata da: data, tipo, descrizione, costo, numero massimo di partecipanti, optional possibili. R1.2 Le escursioni sono di 2 tipi: gite in barca e gite a cavallo. Costo e numero massimo di persone inscrivibili sono stabiliti all atto dell inserimento e possono variare da escursione a escursione. Pure i tipi di optional previsti da ogni escursione sono fissati all atto dell inserimento. R1.3 I possibili tipi di optional sono 3: Pranzo, Merenda, Visita. I relativi costi sono fissi indipendentemente dall escursione cui vengono associati. R2 Il sistema deve permettere in qualunque momento la modifica o l eventuale eliminazione di ogni singola escursione. R3 Il sistema deve permettere di registrare un partecipante ad una data escursione, consentendo, nel caso siano previsti, la scelta di eventuali optional; deve calcolare il costo dell escursione comprensivo degli optional. R3.1 Un partecipante è caratterizzato attraverso il suo codice fiscale, nome cognome e indirizzo. I dati di un partecipante devono essere registrati alla prima prenotazione e non più cancellati dal sistema, anche nel caso in cui un partecipante si iscriva a una sola gita e poi si cancelli. R4 Il sistema deve permettere in qualunque momento sia la cancellazione di un partecipante da una data escursione sia l eventuale modifica del numero e del tipo di optional scelti; nel caso di modifica degli optional scelti deve essere calcolato il nuovo costo risultante. Si osservi ora che i requisiti R2 e R4 in un sistema reale avrebbero delle implicazioni non trascurabili: in caso di cancellazione di una escursione occorrerebbe produrre gli avvisi per gli iscritti, rimborsarli du quanto pagato, ecc.. In altre parole, è necessario stabilire ulteriori vincoli. Vincoli ulteriori Per semplicità si assume di trascurare le implicazioni e gli effetti indotti dalla modifica o dalla cancellazione delle escursioni. Per semplicità si assume di trascurare le implicazioni e gli effetti indotti dalla cancellazione di un partecipante a una escursione o dal cambio degli optional scelti. Per semplicità non si distingue tra escursioni già tenute (antecedenti la data corrente) e escursioni future, nel senso che tutto può essere modificato. 3

4 4 Il modello di dominio Come indicato al Paragrafo 2, il metodo seguito prevede che la costruzione del modello del dominio applicativo preceda l analisi dei casi d uso. Non è questa una scelta convenzionale. Infatti, in larga parte della letteratura si propone di far precedere la costruzione del modello di dominio dall analisi dei casi d uso. Ciò può portare alla stesura di casi d uso troppo astratti, non collegati allo specifico problema, di poca utilità per il programmatore [2]. In questa fase non è necessario che costruire un modello di dominio dettagliato in ogni suo aspetto, bensì costruire un modello che evidenzi le principali relazioni tra le entità applicative. Quanto dettagliare il modello è una questione di sensibilità e di utilità. Conviene limitarsi agli aspetti strutturali (le relazioni tra le classi), utili nella fase di robustness analysis, senza addentrarsi troppo nella definizione degli attributi né tantomeno dei metodi, da rinviare alla fase di rifinitura del modello e di progettazione dettagliata. 4.1 Costruzione del modello di dominio L analisi del testo del problema permette di evidenziare un certo numero di sostantivi: escursione, programma, optional, gita in barca, costo, ecc. Essi individuano concetti che devono essere trasferiti nel modello, in forma di classe o in forma di attributo. Per esempio, il sostantivo escursione è certamente deputato a rappresentare una classe del modello, mentre termini come costo e numero massimo di partecipanti sono manifestamente attributi della stessa escursione. I seguenti punti illustrano il processo iniziale di costruzione del modello: Il testo dice che c è un programma (dell agenzia) del quale fanno parte le escursioni. Si deve quindi prevedere la classe Programma e la classe Escursione, con la prima che aggrega elementi della seconda. Un escursione può, ovviamente, avere più partecipanti, mentre un partecipante può essere iscritto a più escursioni. Occorrerà quindi una associazione tra le classi Partecipante e Escursione. Il testo dice che un escursione può prevedere più optional. In realtà, se si legge bene il testo, ci si convince che il significato è che un escursione può prevedere più tipi di optional, nel senso che il partecipante sceglie quel tipo di optional (il pranzo) NON uno specifico optional. In altre parole si deve tenere traccia del fatto che un partecipante sceglie uno o più tipi di optional tra quelli disponibili per una data escursione; gli stessi che possono essere scelti da un altro partecipante. La situazione sarebbe diversa se il partecipante potesse scegliere il proprio optional su misura, distinto da quello scelto da altri. Per esempio: potrebbe essere il caso che, tra l agenzia e il ristorante a cui vengono portati i partecipanti a una data gita, ci sia un accordo che prevede che l agenzia comunichi in anticipo il dettaglio delle scelte, in modo che il ristorante possa procedere all acquisto dei prodotti commestibili in giusta misura. Allora, per ogni partecipante che sceglie l optional pranzo si dovrebbe istanziare l oggetto Pranzo, con un numero adeguato di attributi quali: primo piatto (minestra, spaghetti, lasagne,..), secondo piatto (carne, pesce,...), dessert (gelato, dolce...), ecc., in modo che l agenzia presenti un quadro esatto di quel che viene richiesto. Nel caso in esame un optional è caratterizzato da suo tipo ( Pranzo, Merenda o Visita ) e dal relativo costo che è determinato solo dal tipo. Dunque un dato tipo di oggetto optional è una sorta di costante, nel senso che esso è unico per tutto il sistema, qualunque sia l escursione e chiunque sia a selezionarlo. Il precedente ragionamento ci convince a cambiare nome alla classe che rappresenta gli optional, ridenominandola TipoOptional. Per come è specificato il problema ogni escursione aggregherà fino a un massimo di 3 tipi di optional. Si ottiene così il diagramma di Figura 1. Si noti che in Figura 1 è stata indicata la molteplicità generica agli estremi dell associazione tra Escursione e Partecipante ; inoltre, mentre questa associazione è stata fatta navigabile in entrambe le direzioni, l aggregazione delle escursioni è navigabile solo in un verso. Questo indica l ovvio fatto che dal programma si vuole risalire alle escursioni, mentre non interessa l inverso. Nel caso in cui fossero previsti più programmi avrebbe senso rendere l aggregazione navigabile in entrambi i versi. Si noti anche che è stato fissata la molteplicità dei tipi di optional nella misura prevista dalla specifica. Alcuni autori sostengono che questo genere di considerazioni dovrebbe essere rimandato alla fase successiva di rifinitura del modello di dominio (Paragrafo 11.1). Tuttavia, siccome le considerazioni appena fatte sono venute in modo del tutto naturale nello stendere il diagramma di Figura 1, non avrebbe nessun senso tenerle 4

5 Figura 1: Primo passo nella costruzione del modello di dominio. nascoste per non dare l impressione che stiamo andando oltre i confini dell analisi preliminare. Al contrario esse costituiscono concetti essenziali alla comprensione del modello stesso, concetti che potranno rivelarsi utili nelle fasi successive dello sviluppo. Per quanto si riferisce invece al fatto che la specifica afferma che le escursioni sono di due tipi: in barca o a cavallo e che ci sono tre tipi differenti optional, si sarebbe tentati di introdurre altre classi (per esempio GitaBarca, Pranzo ), sfruttando il meccanismo dell ereditarietà. Ciò non aggiungerebbe molto alla struttura del modello e rischierebbe di introdurre dettagli soggetti a essere rivisti in fase di progettazione. Pertanto conviene rimandare il trattamento di questi aspetti alla fase di rifinitura del modello di dominio. Resta ora da modellare le associazioni tra i partecipanti e gli optional. Si tratta di tener traccia di quali tipi di optional abbia scelto un partecipante in riferimento a una data gita. Si faccia caso che non si può stabilire una associazione diretta tra Partecipante e Optional, infatti il partecipante x può avere scelto l optional Pranzo per l escursione e1 e gli optional Merenda e Visita a sito per l escursione e2. In altre parole si tratta di una relazione ternaria che richiede una classe di associazione. Il problema è che questa classe non può essere Escursione, in quanto essa svolge una funzione differente dal rappresentare il legame tra Partecipante e Optional. Occorre introdurre una nuova classe, con funzione di associazione tra Partecipante e Optional in riferimento a una data escursione. Chiameremo Scelta questa classe. Essa è relativa (dipende) da una (singola) Escursione. Si ha così il diagramma di Figura 2. Notare che nel diagramma non si è usata la notazione UML che indica dipendenza (tra Scelta e Escursione),ciò perché nel caso specifico la dipendenza di Scelta da Escursione consiste proprio nel riferimento a Escursione. Figura 2: Il modello di dominio aggiornato. C è però un problema: se un partecipante si iscrive a una escursione e poi si cancella dall escursione, per il requisito R2.1 i suoi dati devono restare nel sistema. Con modello di Figura 2 la cancellazione del partecipante da una escursione porta all eliminazione delle associazioni che il partecipante ha con l escursione e con gli 5

6 optional. A questo punto il partecipante risulterebbe scollegato dalle escursioni e rappresenterebbe un oggetto a sé stante. 2 Delle due l una: Si cambia il requisito R2.1 nel modo seguente: I dati di un partecipante devono essere registrati alla prima prenotazione. I dati del partecipante vengono mantenuti nel sistema fintantoché egli risulta iscritto almeno ad una escursione, in caso contrario del partecipante non si tiene più traccia. Si mantiene il requisito R2.1, ma in questo caso occorre aggiungere un ulteriore oggetto in modo che essa contenga direttamente tutte le persone che almeno una volta si sono iscritte. Tale oggetto può essere l agenzia stessa, che diventa così il contenitore di tutti gli oggetti del sistema. Assumeremo di non cambiare il requisito R2.1. Pertanto il diagramma delle classi si trasforma com in Figura 3. Si noti che l aggiunta della classe Agenzia ha anche l ovvia conseguenza di poter accedere all insieme dei partecipanti in modo diretto. È fin troppo ovvio prevedere che tra le funzionalità del sistema ce ne saranno alcune che si svolgeranno proprio a partire dalla conoscenza del partecipante. Con lo schema di Figura 3 per trovare un partecipante basta cercare nell insieme dei partecipanti, con lo schema di Figura 2 per trovare un partecipante occorre passare per le escursioni. Figura 3: Il modello di dominio reso più flessibile. A questo punto osserviamo che il modello di Figura 3 assume che l agenzia abbia più programmi (stagionali). Il modello è stato sviluppato tenendo conto del testo del problema. Nei requisiti del Paragrafo 3.1 non c è traccia di come debba essere trattato il concetto di programma Programma. Facciamo perciò ora un ulteriore assunzione semplificativa, congruente con la specifica dei requisiti: supponiamo che l agenzia abbia un unico programma indifferenziato, indipendente dalla stagione o altro. Tale assunzione deve essere aggiunta ai vincoli ulteriori di pagina 3 il seguente vincolo: Per semplicità si suppone che l agenzia abbia un unico programma indifferenziato, indipendente dalla stagione o altro. Si deve però osservare che con questo ulteriore assunzione la classe Programma di Figura 3 è del tutto superflua, per cui il modello si riduce a quello di Figura 4. Conclusioni La costruzione del modello di dominio serve a dare il contesto rispetto al quale il sistema deve essere sviluppato. Le entità che vi compaiono hanno un nome preciso (e un ruolo appena delineato). Definire significato dei termini è il modo migliore per evitare le ambiguità di interpretazione. La costruzione del modello di dominio produce il glossario dei termini. La parte che segue renderà evidente il vantaggio dell aver fatto precedere la definizione del modello di dominio all analisi dei casi d uso (Cfr. Paragrafo 11.1). 2 Nel senso che per raggiungerlo occorrerebbe un riferimento preciso allo specifico partecipante. Ovviamente ciò non ha senso quando si ha una gran quantità di oggetti; in tal caso gli oggetti devono essere tenuti in un qualche contenitore e individuati attraverso i propri attributi. Con lo schema di Figura 2 i partecipanti si trovano attraverso le escursioni che a loro volta si trovano attraverso il programma. In Java, se si recide il riferimento al partecipante in escursione (assumendo che nel sistema non vi siano altri riferimenti al partecipante), il partecipante è perso. 6

7 Figura 4: Il modello di dominio nella versione finale. 5 Analisi dei casi d uso Il testo del Paragrafo 1 e i requisiti del Paragrafo 3 indicano chiaramente che il sistema ha un solo attore: l impiegato dell agenzia che chiameremo Agente. Infatti, il cliente cioè il possibile partecipante a una o più escursioni non è un attore. Lo sarebbe se egli stesso avesse accesso al sistema (per esempio via web), ma nel caso specifico ciò non è previsto e dunque il cliente dell agenzia non ha nessuna interazione diretta col sistema. Per l unico attore (l agente) il cliente è un dato da inserire nel sistema. Le specifiche del Paragrafo 3 identificano già i casi d uso, anche in modo assai dettagliato. Per come sono organizzati, i requisiti sembrano indicare 4 casi d uso, corrispondenti ai requisiti R1-R4. Tuttavia, per quanto la cancellazione di una escursione o la modifica dei suoi dati siano state raggruppate assieme, conviene, almeno in prima istanza, considerarle come casi separati. Il prosieguo dell analisi dirà se essi sono da ritenere distinti o da considerare un unico caso. Seguendo questo ragionamento si intravvedono 6 casi d uso: Inserimento di una escursione a programma. Cancellazione di una escursione. Modifica dei dati di una escursione. Iscrizione di un partecipante. Cancellazione di un partecipante da una data escursione. Modifica della scelta degli optional da parte di un partecipante. Il corrispondente diagramma è in Figura 5. Il diagramma dei casi d uso serve a fornire una visione intuitiva d insieme; però, per capire davvero cosa succede occorre entrare nel dettaglio. 5.1 Caso d uso: Inserimento escursione Consideriamo per primo i caso d uso CU1: Inserimento (di una) escursione (a programma). Di esso viene data una descrizione dettagliata in Tabella 1. 7

8 Figura 5: Il diagramma (iniziale) dei casi d uso. 8

9 CU1: Inserimento di una escursione a programma Attore: Agente Precondizione: Il sistema è idle e sullo schermo viene presentata la finestra con il menu principale (schermata Menu Principale ). Sequenza eventi: 1. il caso d uso inizia quando l attore clicca il bottone Inserimento sul Menu Principale 2. il sistema mostra una nuova schermata ( Inserimento Escursioni ), contenente vari widgets (campi, checkbox, listbox, pulsanti ecc.), adeguati all inserimento dei dati richiesti per definire un escursione. 3. l attore agendo sugli elementi presenti sul video inserisce i dati relativi all escursione (data, barca/cavallo, descrizione, ecc.); al termine preme il bottone Inserisci ; 4. il sistema controlla i dati immessi; se i dati inseriti sono corretti il sistema presenta la finestra di dialogo Conferma Inserimento, con la quale chiede di confermare la scelta di aggiungere l escursione al programma. (a) In caso affermativo il sistema aggiunge l escursione al programma (b) In caso contrario niente viene modificato indipendentemente da quale dei due passi precedenti sia stato eseguito, il sistema torna a presentare la schermata del punto 1, mostrando gli eventuali dati già inseriti a video. Invariante: A partire dal punto 1 il caso d uso termina incondizionatamente in qualunque momento venga premuto il bottone Esci Sequenza alternativa: Se al punto 1 si verifica che i dati non sono corretti, viene presentata la finestra di dialogo Errore di inserimento nella quale si indica quale campo deve essere aggiornato. Quando l operatore preme il bottone OK presente tale finestra il caso d uso riprende dal punto 1 (senza apportare modifiche al contenuto dei campi già immessi). Postcondizione: Le eventuali escursioni inserite sono state memorizzate; sullo schermo viene ripresentato il menu principale Tabella 1: Specifica del caso d uso CU1: Inserimento Escursione 9

10 Quello di Tabella 1 è il modo classico di rappresentare i casi d uso. Ci sono questi ingredienti: Numero d ordine e nome del caso d uso, condizioni iniziali, percorso principale, eventuali percorsi alternativi, condizioni di uscita. Nel caso specifico è stato aggiunto anche un invariante, cioè una condizione sempre verificata a partire dal punto, caratteristica della modalità di funzionamento dell interfaccia. 3 Il caso d uso prevede che esso contenga al suo interno possibili iterazioni del processo di inserimento delle escursioni. E previsto un percorso alternativo a quello principale nel caso in cui i dati immessi si rivelino non accettabili al controllo. Lo schema di Tabella 1 è quello suggerito in molti libri. Esso è piuttosto pesante da scrivere e non è detto che tutte le informazioni che esso prevede siano di effettiva utilità. Ovviamente non è obbligatorio seguire tale schema. Ciò che serve è una descrizione che metta in luce il comportamento di attore e sistema, mostrando la successione di passi nella forma di azione-reazione. Poiché le interfacce tipo GUI sono diventate lo standard nell interazione tra uomo e macchina, è molto più facile spiegare un caso d uso se si mostrano le schermate a video. Ovviamente non ci si deve perdere troppo nei dettagli, che inevitabilmente sono soggetti a subire modifiche in fase realizzativa. Si tratta di dare conto di come si svolgerà il caso d uso. In Figura 6 viene mostrato un esempio di prototipo per la schermata del caso d uso CU1. Figura 6: Prototipo di schermata per il caso d uso CU1. Un esame attento della descrizione del caso d uso di Tabella 1 evidenzia che il troppo formalismo può anche essere ridondante. Per esempio, la precondizione è ridondante in quanto è assorbita dalla descrizione del passo 1. In altre parole, il formalismo è utile ma non è essenziale. È utile perché una rappresentazione schematica come quella di Tabella 1 è di agevole lettura e di più immediata comprensione di una descrizione non strutturata. Il requisito essenziale della descrizione di un caso d uso sta nel rappresentare nel modo più preciso possibile la sequenza di eventi, dando nome e cognome alle entità che vi partecipano. Per esempio, in Tabella 1 si è dato un nome a tutte le schermate video che possono entrare in gioco e, per rendere più chiaro cosa succede, si è costruito un prototipo della schermata Inserimento Escursioni. 5.2 Caso d uso: Rimozione escursione Il caso d uso è descritto in tabella 2, mentre la schermata corrispondente è mostrata in Figura 7. La parte destra della figura mostra la dialog box che si apre dopo che è stato cliccato il bottone Rimuovi ; la dialog 3 E difficile trovare invarianti nei casi d uso pubblicizzati. 10

11 box scompare dopo che viene premuto Conferma. Come si vede la schematizzazione delle schermate video è molto utile a capire il comportamento del sistema (la dinamica delle interazioni). CU2: Rimozione escursione Sequenza eventi: 1. il caso d uso inizia quando l attore clicca sul bottone Rimozione sulla finestra del Menu Principale 2. il sistema presenta la schermata Rimozione escursioni, nella quale viene mostrata, la lista delle escursioni in programma. 3. l attore seleziona l escursione da eliminare e preme il bottone Rimuovi ; 4. il sistema presenta la finestra di dialogo Conferma rimozione con la quale viene chiesto di confermare la scelta di eliminare l escursione selezionata. (a) In caso affermativo l escursione viene eliminata (b) In caso contrario niente viene modificato indipendentemente da quale dei due passi precedenti sia stato eseguito, il sistema torna a presentare la schermata del punto??. Invariante: A partire dal punto 1 il caso d uso termina incondizionatamente in qualunque momento venga premuto il bottone Esci Postcondizione: Le escursioni per cui è stata confermata la rimozione sono state eliminate; sullo schermo viene ripresentato il menu principale Tabella 2: Specifica del caso d uso CU2: Rimozione Escursione. Non è stato riportato l attore (perché ovvio), né la condizione iniziale (perché assorbita dal primo passo). Figura 7: Prototipo di schermata per la rimozione delle escursioni. A destra viene mostrata la dialog box che si apre dopo che è stato cliccato il bottone Rimuovi ; la dialog box scompare dopo che viene premuto uno dei due pulsanti. Se viene premuto Sì l escursione viene effettivamente rimossa; se viene premuto No niente accade. Nota per la finestra di dialogo di conferma le Swing fanno tutto!! 11

12 5.3 Caso d uso: Modifica escursione Questo caso d uso ha in comune ai precedenti le medesime precondizioni, il primo passo, la condizione invariante e la condizione di uscita. Tenuto conto di ciò esso viene espresso in forma discorsiva qui di seguito: Caso d uso CU3: Modifica escursione Il caso d uso inizia quando l attore clicca il bottone SalvaMod del menu principale. Il sistema presenta una schermata contenente la lista delle escursioni e i campi per inserire i dati che definiscono le escursioni. L attore seleziona una escursione dalla lista e modifica i campi; al termine clicca sul bottone SalvaMod. Il sistema chiede conferma e in caso affermativo aggiorna i dati relativi all escursione selezionata. Il ciclo può essere iterato. Il caso d uso ha fine quando viene cliccato il bottone Esci. In Figura 8 è mostrata la schermata corrispondente. Figura 8: Prototipo di schermata per la modifica delle escursioni. Vengono mostrati i passi dalla selezione dell escursione fino al comando di modifica. Con riferimento alla schermata di Figura 6, la modifica consiste nel togliere l optional Merenda, e cambiare il limite massimo degli inscrivibili. La figura mostra nel dettaglio una possibile sequenza che porta alla modifica di un escursione: 1: viene selezionata l escursione da modificare; 2: viene tolta la spunta dall opzione Merenda ; 3: viene modificato il numero massimo degli inscrivibili; 4: viene dato il comando di salvare la modifica. Osservazione La sequenza di Figura 8 suggerisce che la prima operazione sia quella di selezionare un escursione e poi apportare le modifiche ai dati relativi. Si potrebbe anche stabilire che l interfaccia non imponga un simile vincolo, decidendo che l attore possa iniziare modificando i dati (supponendo che egli sappia esattamente cosa inserire) e solo successivamente selezionare l escursione alla quale apportare le modifiche secondo quanto introdotto. Dare una simile flessibilità impone però che, se l attore preme il pulsante SalvaMod senza che sia stata selezionata n escursione, venga presentato un messaggio di allarme che invita l utente a effettuare la selezione. La soluzione alternativa, anche se più rigida, consiste nello stabilire che la prima azione che l attore può fare sulla schermata Modifica Escursioni sia obbligatoriamente la scelta dell escursione da modificare. Si tratta di un dettaglio che non è appropriato trattare a questo punto dell analisi. Potrà essere presa l una o l altra soluzione in fase di sviluppo, anche in base alle caratteristiche del framework per la costruzione delle interfacce, e non è detto che la soluzione apparentemente più facile (quella più rigida) si dimostri effettivamente tale per il programmatore. 12

13 5.4 Possibile rivisitazione dei primi tre casi d uso A questo punto siamo in grado di tracciare la schermata iniziale almeno per quanto riguarda i casi d uso CU1, CU2 e CU3. Si tratta semplicemente di prevedere i tre bottoni Inserimento, Rimozione e Modifica. La schermata del menu principale assumerebbe l aspetto di Figura 9. Figura 9: Il menu principale relativo all inserimento, cancellazione e modifica delle escursioni. Osserviamo ora che i tre casi d uso hanno molte cose in comune. L azionamento di uno qualunque dei pulsanti di Figura 9 porta sostanzialmente alla medesima schermata. Ciò suggerisce di prevedere un solo bottone sul menu principale, denominato Inserimento/Rimozione/Modifica e rimandare la scelta di quale azione intraprendere alla schermata che esso determina. Ciò equivale a dire che il caso d uso è unico e che ha tre sottocasi d uso, ovvero tre estensioni, come illustrato in Figura 10. Figura 10: Trasformazione del diagramma di Figura 5. Ovviamente le tre estensioni sono esclusive l una dell altra come risultato finale, ma possono avere parti in comune. Sembra logico che occorra prevedere un meccanismo che, a partire dalla schermata che segue il click sul bottone Inserisci/Elimina/Modifica, determini quale estensione abbia luogo. Si tratta di una questione che, a questo punto dell analisi converrebbe evitare di trattare troppo a fondo, rimandando il suo esame alla fase realizzativa, in quanto il framework usato per la realizzazione della GUI potrebbe avere un influenza determinante nella scelta dei dettagli. Tuttavia, a scopo didattico, procediamo nell approfondimento della questione, perché si possono scoprire cose interessanti. 13

14 Diamo anzitutto una descrizione del caso d uso Inserimento/Eliminazione/Modifica Escursioni (ma non nella forma strutturata delle Tabelle 1 e 2). Caso d uso Inserimento/Eliminazione/Modifica Escursioni Il caso d uso inizia quando l attore clicca sul bottone Inserisci/Elimina/Modifica sulla finestra Menu Principale. Il sistema presenta la schermata Inserimento/Rimozione/Modifica escursioni, sulla quale sono presenti i tre bottoni Inserisci, Rimuovi, SalvaMod e il bottone Esci. I primi tre hanno la funzione di concludere i tre differenti sottocasi determinando le azioni da essi previste; il quarto fa concludere in ogni momento il caso d uso. I modelli della schermata del menu principale e della schermata Inserimento/Rimozione/Modifica escursioni sono in Figura 11. All apertura della finestra Inserimento/Rimozione/Modifica escursioni i tre pulsanti Inserisci, Rimuovi e SalvaMod sono disabilitati, mentre il pulsante Esci è abilitato (e così resta per sempre). Il caso d uso termina in qualunque momento premendo il pulsante Esci. Figura 11: Struttura delle schermate rivisitata. A sinistra il menu principale (relativo alla sola gestione delle escursioni), a destra l interfaccia per l inserimento, l eliminazione e la modifica delle escursioni. Analizziamo ora i sottocasi. Sottocaso d uso Inserimento Percorso principale L estensione Inserimento viene presa quando l attore, come prima cosa, seleziona una data (quella a cui vuole aggiungere un escursione); a questo punto il pulsante Inserisci si attiva. Successivamente l attore può immettere gli altri dati relativi all escursione da inserire. Il sottocaso si conclude quando viene cliccato il pulsante Inserisci ; se i dati sono corretti, viene presentata la finestra - Conferma registrazione, alla quale l attore risponde cliccando sul pulsante Sì o No. Se viene cliccato il pulsante Sì l escursione viene registrata e la sua descrizione inserita nella lista a video; se viene cliccato il pulsante No niente accade; in ambedue i casi viene ripresentata la schermata Inserimento/Rimozione/Modifica escursioni (con i tre pulsanti Inserisci, Rimuovi e SalvaMod disabilitati) sulla quale è possibile effettuare un nuovo inserimento, ovvero cancellare un escursione, ovvero modificare un escursione. Percorso alternativo Se premendo il pulsante Inserisci i dati immessi non risultano accettabili (p.e., un costo negativo) viene presentata una finestra con le informazioni circa i campi da reimmettere. Al click sul pulsante OK sulla finestra, si ritorna la finestra Inserimento/Rimozione/Modifica escursioni. 14

15 Se ora si passa all esame dei due sotto casi Rimozione e Modifica di Figura 10 è facile convincersi che essi differiscono solamente per il pulsante premuto alla fine ( Rimuovi o SalvaMod ). Conseguentemente si può pensare di raggrupparli in un unico sottocaso da cui se ne originano due. Ne consegue che il diagramma di Figura 10 si modifica in quello di Figura 12. Sottocaso Rimozione/Modifica Percorso principale L estensione Rimozione/Modifica viene presa quando l attore, come prima cosa, seleziona un escursione dalla lista; a questo punto si attivano ambedue i pulsanti Rimuovi e SalvaMod. Successivamente l attore può modificare i dati relativi all escursione scelta (se intende modificare). Al termine l attore clicca uno dei due bottoni Rimuovi o SalvaMod. Nel primo caso l escursione viene rimossa, nel secondo modificata. In ambedue i casi il sistema chiede conferma. Al compimento dell azione viene ripresentata la schermata Inserimento/Rimozione/Modifica escursioni (con i tre pulsanti Inserisci, Rimuovi e SalvaMod disabilitati) sulla quale è possibile effettuare un nuovo inserimento, ovvero cancellare un escursione, ovvero modificare un escursione. Percorso alternativo Se premendo il pulsante SalvaMod i dati immessi non risultano accettabili (p.e., un costo negativo) viene presentata una finestra con le informazioni circa i campi da reimmettere. Al click sul pulsante OK sulla finestra, si ritorna la finestra Inserimento/Rimozione/Modifica escursioni. Figura 12: Aggiornamento del diagramma dei casi d uso Alcune osservazioni Nel realizzare l interfaccia si farà ricorso a qualche framework. E possibile che i componenti utilizzabili sull interfaccia (bottoni, liste a scorrimento, calendari, ecc.) abbiano delle caratteristiche che suggeriscano di apportare variazioni a quanto siamo andati delineando. Per esempio, è possibile che, una volta selezionata una data,e quindi entrati nel percorso di inserimento di una nuova escursione, attivando il bottone Inserisci, sia possibile cambiare idea e selezionare un escursione tra quelle in lista, passando all altro percorso, disattivando il bottone Inserisci e attivando i bottoni Rimuovi e SalvaMod. 4 4 Di fatto è quello che accadrà nel nostro caso, con i componenti Swing di Java e alcuni componenti presi da librerie pubbliche. 15

16 Come evidenziato già in precedenza, questi aspetti possono essere trattati più appropriatamente in fase di realizzazione, anche se ciò può portare a qualche leggera modifica dei casi d uso. Si tratterebbe comunque di modifiche di nessun impatto di carattere concettuale. Abbiamo detto che i sottocasi sono estensioni del relativo caso d uso principale. Perché estensioni e non generalizzazioni? Perché i sottocasi aggiungono comportamenti diversi al comportamento di base. Ma si potrebbe anche pensare che i tre sottocasi rappresentano differenti specializzazioni del caso generale. Se si rinunciasse alle estensioni e alle generalizzazioni (come pure alle inclusioni) e si ricorre al solo stereotipo <<invoca>> la questione non si porrebbe nemmeno. 5.5 Caso d uso: Iscrizione L iscrizione di un partecipante ad un escursione si effettua scegliendo l escursione e introducendo i dati del partecipante e selezionando gli optional che egli intende acquistare. La descrizione del caso d uso è in Tabella 3. CU4: Iscrizione di un partecipante Attore: Agente Precondizione: Il sistema è idle e sullo schermo viene presentata la finestra con il menu principale (schermata Menu Principale ). Sequenza eventi: 1. il caso d uso inizia quando l attore clicca il bottone Iscrizione sul Menu Principale 2. il sistema mostra una nuova schermata ( Registrazione di un cliente alle escursioni ), contenente i campi che servono a descrivere il cliente, le checkbox per selezionare gli optional, ecc.. 3. l attore agendo sugli elementi presenti sul video seleziona l escursione, inserisce i dati del cliente, seleziona gli eventuali optional. La sequenza può non necessariamente iniziare con la selezione dell escursione, ma anche con l immissione dei dati del cliente; in ogni caso per selezionare gli optional è necessario che l escursione sia già stata selezionata. Inoltre sulla stessa schermata può essere presente un pulsante per verificare (in base al codice fiscale) se il cliente è già presente nel sistema e prelevare automaticamente i suoi dati. 4. quando l attore preme il bottone Registra i dati vengono immessi. Il processo può essere iterato. Invariante: A partire dal punto 1 il caso d uso termina incondizionatamente in qualunque momento venga premuto il bottone Esci Sequenza alternativa: Al punto 3 se i dati immessi non sono corretti viene presentata la finestra di dialogo Errore nei dati immessi per il cliente nella quale si indica quale campo deve essere aggiornato. Quando l operatore preme il bottone OK presente tale finestra il caso d uso riprende dal punto 1 (senza apportare modifiche ai contenuti dei campi già immessi). Postcondizione: L eventuale nuovo cliente è stato memorizzato. Viene ripresentato il menu principale Tabella 3: Specifica del caso d uso CU4: Iscrizione In Figura 13 viene riportato il prototipo della schermata di iscrizione. 16

17 Figura 13: Modello di menu per l iscrizione di un partecipante alle escursioni. 5.6 Caso d uso CU5: Cancellazione/ModificaOptional Se si ragiona come al Paragrafo 5.4 ci si convince che i due casi d uso Cancellazione e ModificaOptional delle figure precedenti si riducono ad un unico caso d uso, schematicamente così descritto: Caso d uso Cancellazione/Modifica Percorso principale Il caso uso inizia quando viene premuto il pulsante Cancellazione/ModificaOptional sul menu principale. Il sistema presenta la schermata Cancellazione/ModificaOptional. L attore deve anzitutto inserire il codice fiscale del partecipante e premere il pulsante Cerca. Se il codice immesso corrisponde effettivamente a quello di un partecipante, il sistema risponde presentando i dati del partecipante e la lista delle escursioni a cui è iscritto. Per ogni escursione la lista riporta tutti i dati di interesse, costo per il partecipante, marcamento degli optional scelti. L attore seleziona una escursione tra quelle in lista; se ci sono optional scelti le relative checkbox della parte del display in cui si inseriscono gli optional riportano il segno di spunta. A questo punto l attore può modificare la spunta degli optional. Se l attore preme il pulsante SalvaModifica si determina il cambiamento degli optional secondo la nuova spunta. Se preme il pulsante Cancella il partecipante viene cancellato dall escursione. Il ciclo può essere iterato e ha fine al click di Esci. principale. Dopo l uscita viene ripresentato il menu Percorso alternativo Se non si trova il partecipante non viene presentata alcuna lista delle escursioni e non vengono attivati i pulsanti Cancella e SalvaModifica, per cui non resta che uscire. In Figura 14 viene dato il modello del menu Cancellazione/ModificaOptional. 5.7 Riesame È logico porsi la domanda se non sia il caso di riportare i due casi d uso Iscrizione, Cancellazione/Modifica a tre sottocasi di un unico caso d uso. Tuttavia, diversamente da quel che è stato fatto al Paragrafo 5.4.1, qui la differenza resta, in quanto l iscrizione ha un percorso che inizia dalle Escursioni, mentre la cancellazione del partecipante da un escursione come pure la modifica degli optional scelti hanno un percorso che inizia dai Partecipanti. Mettere tutto a un unica videata rischia di renderla confusa per chi la usa e complessa da realizzare. Per questo manterremo la separazione tra Iscrizione e Cancellazione/Modifica, per la quale però prevederemo du sottocasi Cancellazione e ModificaOptional. 17

18 Figura 14: Prototipo di schermata per la cancellazione dalle escursioni o per la modifica degli optional scelti. Avendo ipotizzato (Figura 14 che la cancellazione di un partecipante da un escursione o la modifica degli optional scelti richiedono la conoscenza del codice fiscale del partecipante, occorre aggiungere da qualche parte la funzionalità di visualizzazione del codice fiscale dei partecipanti. Si può aggiungere un caso d uso specifico Visualizza Clienti Il caso d uso è ovvio ed evitiamo di descriverlo 5. Esso comporta il bottone Lista Clienti sul menu principale. Mettendo assieme di ragionamenti del Paragrafo 5.4.1, con i precedenti si arriva al diagramma finale dei casi d uso di Figura 15 e al menu principale schematizzato in Figura 16. In Figura 15 si è preferito usare la relazione di invocazione tra caso d uso principale e subordinati. Si faccia attenzione a come i casi d uso principali sono identificati in Figura 15; useremo tale identificazione nel resto del documento. 5.8 Conclusioni Possiamo trarre alcune conclusioni e alcuni insegnamenti da quanto abbiamo fatto Cosa rappresentano i casi d uso I casi d uso dicono cosa il sistema fa. Sono una specifica del comportamento del sistema come percepito dai suoi utenti finali Quanto devono essere astratti È bene che i casi d uso siano concreti: casi d uso scritti in modo astratto servono a poco o nulla. Per questo motivo devono fare riferimento a un modello di dominio. In tal modo i casi d uso sono orientati verso le entità alla cui manipolazione essi sono preposti. Un modello di dominio fornisce, come minimo, il significato dei termini usati (glossario). L impiego di termini il cui significato è chiaro riduce il rischio di specifiche ambigue Come si scrivono i casi d uso Dovendo rappresentare la dinamica del tipo azione e reazione, ovvero illustrare l esecuzione di sequenze di passi 6, i casi d uso devono essere espressi usando verbi al tempo indicativo presente. Al fine di evitare ambiguità le entità devono essere menzionate con il nome univoco ad esse assegnato nel modello di dominio. Per la stessa ragione si deve dare un nome specifico alle singole viste (videate). 5 Questa funzionalità viene aggiunta soprattutto ai fini della sperimentazione col sistema. Infatti, nella realtà, una persona è in grado di fornire il proprio codice fiscale. Invece, nel fare le prove si inseriscono usualmente codici a caso, che poi sono difficili da ricordare! Abbiamo deciso di prevedere un caso d uso a parte proprio per non toccare i precedenti casi d uso che vorrebbero essere fedeli alla realtà. 6 Si osservi che, diversamente dai casi d uso, i requisiti sono espressi come clausole. 18

19 Figura 15: Diagramma finale dei casi d uso Figura 16: Prototipo finale del menu principale Allegare alla descrizione testuale di un caso d uso i prototipi delle schermate che esso prevede. Un prototipo di schermata è un modo di comunicazione quasi sempre più efficace delle parole Prevedere sempre i possibili percorsi alternativi al percorso principale di ciascun caso d uso Come si validano Alla fine dell analisi occorre fare un esame critico al fine di validare quanto fatto. Questo esame deve essere condotto dall analista assieme agli utenti/committenti del sistema, in modo che sia evitata la spiacevole situazione in cui vengono a trovarsi non pochi progetti di sviluppo software, quando, in fase avanzata, ci si accorge che quel che fa il sistema (quello che è stato realizzato) non corrisponde a quello che il cliente/committente si aspettava. Dopo la necessaria validazione non è detto che il lavoro sui casi d uso sia finito: il passo successivo del processo, l analisi di robustezza, può evidenziare la necessità di tornarci sopra al fine di eliminare incoerenze ed ambiguità nascoste. 19

20 5.8.5 Ma, alla fin fine, che cosa è stato prodotto? Se si mettessero assieme e si riorganizzassero le descrizioni dei casi d uso (trasformando frasi come l attore preme il pulsante... il sistema mostra la finestra... in premere il pulsante... viene mostrata la finestra... ), si otterrebbe...il manuale utente! Questo è il risultato di maggior rilievo, riassumibile nell equazione Analisi dei casi d uso = Stesura del manuale utente Fare l analisi dei casi d uso vuol dire definire esattamente come il sistema si comporterà; molto prima di dar corso alla sua realizzazione. 6 Casi d uso e requisiti Come è stato affermato in precedenza, è bene che i casi d uso vengano esaminati criticamente dall analista assieme agli utenti/committenti del sistema. Un aspetto importante da verificare è se tutti i requisiti sono stati considerati. A tale scopo conviene incrociare i requisiti con i casi d uso al fine di stabilire se tutti i requisiti sono coperti dai casi d uso. Il nostro sistema è particolarmente semplice. La verifica di copertura può essere fatta ricorrendo a un foglio elettronico come in Figura Si noti che CU4, introdotto per la ricerca del codice fiscale di un cliente, non copre nessun specifico requisito. Figura 17: Copertura dei requisiti da parte dei casi d uso. Non si sono riportati i sottocasi perché ciò non avrebbe aggiunto alcuna informazione in più. 7 Un intermezzo: modellazione dell interfaccia con le macchine a stati Nel fare l analisi dei casi d uso abbiamo presentato le schermate in forma anche troppo dettagliata. Come abbiamo già osservato al termine del Paragrafo 5.4, non vale la pena di esagerare con i dettagli, in quanto il framework impiegato nella realizzazione della GUI potrà imporre scelte obbligate, contrastanti con quanto ipotizzato. I prototipi delle finestre hanno lo scopo di fornire una chiara rappresentazione delle funzionalità che esse implicano. L analisi aveva anche messo in mostra una certa difficoltà nel descrivere il comportamento dell interfaccia. Per questo motivo, e al fine di facilitare il successivo lavoro di analisi, conviene descrivere il comportamento dell interfaccia attraverso i diagrammi di stato. 7.1 Diagramma di stato aggregato In Figura 18 viene data la rappresentazione del diagramma di stato in forma aggregata. Sono stati previsti 4 stati in corrispondenza ai 4 casi d uso di Figura 15. Il diagramma non ha bisogno di commenti: dallo stato S0 l interfaccia (e il sistema) passa allo stato che corrisponde all espletamento della funzionalità richiesta. Si noti che in corrispondenza dei cambiamenti di stato vengono presentate le schermate corrispondenti. 7 Alcuni strumenti Case forniscono supporto allo svolgimento di questo tipo di analisi. 20

21 Figura 18: Diagramma di stato dell interfaccia. 7.2 Inserimento/Rimozione/Modifica escursioni Il diagramma di stato corrispondente a questo macrostato è in Figura 19. Si osservi che la selezione iniziale della Figura 19: Esplosione dello stato aggregato SIRMEsc di Figura 18. data fa passare allo stato di inserimento, nel quale l attore può riempire i campi della maschera a video; mentre la selezione iniziale di una escursione fa passare allo stato di rimozione/modifica. Il diagramma mostra che c è un passaggio tra questi due stati in base alla selezione di una data o di una escursione. A ogni passaggio il video viene aggiornato (in particolare vengono attivati/disattivati i pulsanti Inserisci oppure Rimuovi e SalvaMod. Al click su un di questi pulsanti avviene la memorizzazione/aggiornamento dei dati e l aggiornamento del video. Da ogni stato si esce al click Esci. 21