Illustrazione del processo di analisi, progettazione e

sviluppo in riferimento a un caso di esempio(Agenzia turistica)

Prima scrittura: ottobre 2006Ultima Revisione 6 settembre 2011

Scopo del documento

Lo scopo di questo documento e illustrare un metodo per l’intero processo di analisi, progettazione e sviluppodi 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 duratagiornaliera e (per semplicita) 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 optionalpossibili sono tre: pranzo, merenda, visita a un sito. I tipi di optional associati a una data escursione possonodifferire da caso a caso. Per esempio: la gita in barca del giorno x puo prevedere il pranzo e la merenda, la gitain barca di due giorni dopo puo prevedere il solo pranzo, l’escursione del giorno y puo non prevedere optional.

Il prezzo degli optional e fisso ed e determinato solo dal tipo. Invece, ogni singola escursione ha un suoprezzo. Ogni escursione prevede un numero massimo di partecipanti. I prezzo di una escursione, il limite aipartecipanti e tutto cio che corrisponde alla definizione dell’escursione stessa viene fissato all’atto della suaimmissione nel programma dell’agenzia. Questi dati possono anche essere modificati, in corso di esercizio, dopoche 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, lascelta di eventuali optional; calcolare il costo dell’escursione comprensivo degli optional.

3. Cancellare un partecipante gia iscritto da una data escursione.

4. Aggiungere o eliminare un optional relativamente a un dato partecipante e una data escursione; calcolareil nuovo prezzo dell’escursione.

1.1 Osservazione

Una specifica come quella precedente e quanto un ingegnere del software puo aspettarsi nella pratica del mestiere.Un esame anche superficiale della medesima mostra che essa e molto approssimata e certamente incompleta.

Per esempio si afferma che e possibile eliminare o modificare una escursione gia a programma. In un contestoreale l’eliminazione di una escursione avrebbe conseguenze non trascurabili: avvisare gli iscritti, rimborsarli diquanto pagato, tenere conto della restituzione del danaro nella contabilita, ecc. Si tratta di funzionalita chein un contesto reale non possono essere trascurate. Lo scopo dell’analisi e proprio quello della loro completaidentificazione. Risulta evidente che l’analista deve coinvolgere in questo processo il committente e gli utentifinali del sistema. Piu 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]. Piu specificatamente esso prevedei seguenti passi.

1

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 responsabilita (operazioni) alle classi

4. Realizzazione

3 La specifica dei requisiti funzionali

Con il termine “requisiti” si intende l’insieme delle proprieta che un prodotto deve possedere per soddisfare alproprio 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 didefinire esattamente cosa il sistema fara (non come come lo fara).

Lo standard IEEE 830 (ultima edizione 1998)[1] definisce i criteri (e il formato) secondo cui deve essereredatta una specifica dei requisiti. Essenzialmente, lo standard prevede l’elencazione dei requisiti funzionali epropone alcuni metodi secondo cui essi devono essere descritti. Purtroppo lo standard in questione e piuttostovecchio e non contempla il ricorso ai casi d’uso, che, almeno da quando si e diffuso UML, costituiscono la tecnicapreferita per specificare il “cosa”.

Il metodo delineato al Paragrafo 2 e 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 infattiche sia comunque utile stendere un elenco ordinato e strutturato dei requisiti, in forma testuale. Del resto, nellapratica professionale, l’elencazione dei requisiti e sempre il passaggio iniziale attraverso cui l’analista software eil 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 tuttele caratteristiche che il sistema deve possedere. E un processo che dovrebbe coinvolgere analista, committentee utente finale.

Dopo le fasi di raccolta dei requisiti e di analisi dei casi d’uso e buona norma incrociare i requisiti con i casid’uso, individuando da quali casi d’uso sono “coperti” i vari requisiti, in modo di poter verificare se niente estato tralasciato.

La parte seguente costituisce dunque una sintetica SRS.1 Con riferimento allo standard IEEE 830, essa estrutturata in tre paragrafi che identificano lo scopo, i vincoli e i requisiti funzionali.

• Scopo. La corretta identificazione dello scopo e importante in fase di analisi, in quanto ci aiuta a capirequali sono le entita da modellare e come vanno modellate (evidentemente la scelta deve cadere su entitache hanno senso rispetto allo scopo che il sistema si prefigge).

• Vincoli. Il vincoli sono condizioni o proprieta di carattere generale che il sistema deve rispettare.

• Requisiti funzionali. Funzionalita che il sistema deve esibire, elencate in modo ordinato e non ambiguo.

1Data la semplicita del nostro problema, la specifica del Paragrafo 1 e quasi sufficiente a rappresentare i requisiti. Abbiamotuttavia osservato che la essa e incompleta e ambigua. I requisiti riportati al Paragrafo 3.1 hanno lo scopo di eliminare le ambiguitarilevate.

2

3.1 Specifica dei requisiti

ScopoLo scopo del sistema e la gestione delle prenotazioni dell’agenzia.

Vincoli

• Il sistema viene realizzato come installazione unica, per funzionare all’interno di una agenzia avente unasola sede.

• Tutte le operazioni vengono effettuate dal solo personale dell’agenzia e non c’e necessita di distinguere idifferenti impiegati. Cio 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 qualunquemomento.

R1.1 Ogni escursione e 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 personeinscrivibili sono stabiliti all’atto dell’inserimento e possono variare da escursione a escursione. Purei 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 indipen-dentemente dall’escursione cui vengono associati.

R2 Il sistema deve permettere in qualunque momento la modifica o l’eventuale eliminazione di ogni singolaescursione.

R3 Il sistema deve permettere di registrare un partecipante ad una data escursione, consentendo, nel casosiano previsti, la scelta di eventuali optional; deve calcolare il costo dell’escursione comprensivo deglioptional.

R3.1 Un partecipante e caratterizzato attraverso il suo codice fiscale, nome cognome e indirizzo.

I dati di un partecipante devono essere registrati alla prima prenotazione e non piu cancellati dalsistema, 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 dataescursione sia l’eventuale modifica del numero e del tipo di optional scelti; nel caso di modifica deglioptional 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 casodi cancellazione di una escursione occorrerebbe produrre gli avvisi per gli iscritti, rimborsarli du quanto pagato,ecc.. In altre parole, e necessario stabilire ulteriori vincoli.

Vincoli ulteriori

• Per semplicita si assume di trascurare le implicazioni e gli effetti indotti dalla modifica o dalla cancellazionedelle escursioni.

• Per semplicita si assume di trascurare le implicazioni e gli effetti indotti dalla cancellazione di un parte-cipante a una escursione o dal cambio degli optional scelti.

• Per semplicita non si distingue tra escursioni gia tenute (antecedenti la data corrente) e escursioni future,nel senso che tutto puo essere modificato.

3

4 Il modello di dominio

Come indicato al Paragrafo 2, il metodo seguito prevede che la costruzione del modello del dominio applicativopreceda l’analisi dei casi d’uso.

Non e questa una scelta convenzionale. Infatti, in larga parte della letteratura si propone di far precedere lacostruzione del modello di dominio dall’analisi dei casi d’uso. Cio puo portare alla stesura di casi d’uso troppoastratti, non collegati allo specifico problema, di poca utilita per il programmatore [2].

In questa fase non e necessario che costruire un modello di dominio dettagliato in ogni suo aspetto, bensıcostruire un modello che evidenzi le principali relazioni tra le entita applicative. Quanto dettagliare il modelloe una questione di sensibilita e di utilita. Conviene limitarsi agli aspetti strutturali (le relazioni tra le classi),utili nella fase di robustness analysis, senza addentrarsi troppo nella definizione degli attributi ne tantomenodei 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 formadi classe o in forma di attributo. Per esempio, il sostantivo “escursione” e certamente deputato a rappresentareuna classe del modello, mentre termini come “costo” e “numero massimo di partecipanti” sono manifestamenteattributi della stessa escursione.

I seguenti punti illustrano il processo iniziale di costruzione del modello:

• Il testo dice che c’e un programma (dell’agenzia) del quale fanno parte le escursioni. Si deve quindiprevedere la classe Programma e la classe Escursione, con la prima che aggrega elementi della seconda.

• Un’escursione puo, ovviamente, avere piu partecipanti, mentre un partecipante puo essere iscritto a piuescursioni. Occorrera quindi una associazione tra le classi Partecipante e Escursione.

• Il testo dice che un’escursione puo prevedere piu optional. In realta, se si legge bene il testo, ci si convinceche il significato e che un’escursione puo prevedere piu “tipi di optional”, nel senso che il partecipantesceglie quel tipo di optional (il pranzo) NON uno specifico optional. In altre parole si deve tenere tracciadel fatto che un partecipante sceglie uno o piu 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”, distintoda quello scelto da altri. Per esempio: potrebbe essere il caso che, tra l’agenzia e il ristorante a cui vengonoportati i partecipanti a una data gita, ci sia un accordo che prevede che l’agenzia comunichi in anticipo ildettaglio delle scelte, in modo che il ristorante possa procedere all’acquisto dei prodotti commestibili ingiusta misura. Allora, per ogni partecipante che sceglie l’optional pranzo si dovrebbe istanziare l’oggettoPranzo, con un numero adeguato di attributi quali: primo piatto (minestra, spaghetti, lasagne, ..), sec-ondo piatto (carne, pesce, ...), dessert (gelato, dolce...), ecc., in modo che l’agenzia presenti un quadroesatto di quel che viene richiesto.Nel caso in esame un optional e caratterizzato da suo tipo (“Pranzo”, “Merenda” o “Visita”) e dal relativocosto che e determinato solo dal tipo. Dunque un dato tipo di oggetto optional e una sorta di “costante”,nel senso che esso e 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, ridenom-inandola TipoOptional.

Per come e specificato il problema ogni escursione aggreghera fino a un massimo di 3 tipi di optional.

Si ottiene cosı il diagramma di Figura 1.Si noti che in Figura 1 e stata indicata la molteplicita generica agli estremi dell’associazione tra “Escur-

sione” e “Partecipante”; inoltre, mentre questa associazione e stata fatta navigabile in entrambe le direzioni,l’aggregazione delle escursioni e navigabile solo in un verso. Questo indica l’ovvio fatto che dal programmasi vuole risalire alle escursioni, mentre non interessa l’inverso. Nel caso in cui fossero previsti piu program-mi avrebbe senso rendere l’aggregazione navigabile in entrambi i versi. Si noti anche che e stato fissata lamolteplicita dei tipi di optional nella misura prevista dalla specifica.

Alcuni autori sostengono che questo genere di considerazioni dovrebbe essere rimandato alla fase successivadi rifinitura del modello di dominio (Paragrafo 11.1). Tuttavia, siccome le considerazioni appena fatte sonovenute in modo del tutto naturale nello stendere il diagramma di Figura 1, non avrebbe nessun senso tenerle

4

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 essecostituiscono concetti essenziali alla comprensione del modello stesso, concetti che potranno rivelarsi utili nellefasi successive dello sviluppo.

Per quanto si riferisce invece al fatto che la specifica afferma che le escursioni sono di due tipi: in barcao 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’ereditarieta. Cio non aggiungerebbe molto alla strutturadel modello e rischierebbe di introdurre dettagli soggetti a essere rivisti in fase di progettazione. Pertantoconviene 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 tipidi optional abbia scelto un partecipante in riferimento a una data gita. Si faccia caso che non si puo stabilireuna associazione diretta tra Partecipante e Optional, infatti il partecipante x puo avere scelto l’optionalPranzo per l’escursione e1 e gli optional Merenda e Visita a sito per l’escursione e2. In altre parole si trattadi una relazione ternaria che richiede una classe di associazione. Il problema e che questa classe non puo essereEscursione, in quanto essa svolge una funzione differente dal rappresentare il legame tra Partecipante eOptional. Occorre introdurre una nuova classe, con funzione di associazione tra Partecipante e Optional inriferimento a una data escursione. Chiameremo Scelta questa classe. Essa e relativa (dipende) da una (singola)Escursione. Si ha cosı il diagramma di Figura 2. Notare che nel diagramma non si e usata la notazione UMLche indica dipendenza (tra Scelta e Escursione),cio perche nel caso specifico la dipendenza di Scelta daEscursione consiste proprio nel riferimento a Escursione.

Figura 2: Il modello di dominio aggiornato.

C’e pero un problema: se un partecipante si iscrive a una escursione e poi si cancella dall’escursione, per ilrequisito R2.1 i suoi dati devono restare nel sistema. Con modello di Figura 2 la cancellazione del partecipanteda una escursione porta all’eliminazione delle associazioni che il partecipante ha con l’escursione e con gli

5

optional. A questo punto il partecipante risulterebbe scollegato dalle escursioni e rappresenterebbe un oggettoa se stante.2

Delle due l’una:

• Si cambia il requisito R2.1 nel modo seguente: I dati di un partecipante devono essere registrati allaprima prenotazione. I dati del partecipante vengono mantenuti nel sistema fintantoche egli risulta iscrittoalmeno ad una escursione, in caso contrario del partecipante non si tiene piu traccia.

• Si mantiene il requisito R2.1, ma in questo caso occorre aggiungere un ulteriore oggetto in modo che essacontenga direttamente tutte le persone che almeno una volta si sono iscritte. Tale oggetto puo esserel’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 inFigura 3.

Si noti che l’aggiunta della classe Agenzia ha anche l’ovvia conseguenza di poter accedere all’insieme deipartecipanti in modo diretto. E fin troppo ovvio prevedere che tra le funzionalita del sistema ce ne sarannoalcune che si svolgeranno proprio a partire dalla conoscenza del partecipante. Con lo schema di Figura 3 pertrovare un partecipante basta cercare nell’insieme dei partecipanti, con lo schema di Figura 2 per trovare unpartecipante occorre passare per le escursioni.

Figura 3: Il modello di dominio reso piu flessibile.

A questo punto osserviamo che il modello di Figura 3 assume che l’agenzia abbia piu programmi (stagionali).Il modello e stato sviluppato tenendo conto del testo del problema.

Nei requisiti del Paragrafo 3.1 non c’e traccia di come debba essere trattato il concetto di programma “Pro-gramma”. Facciamo percio 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. Taleassunzione deve essere aggiunta ai “vincoli ulteriori” di pagina 3 il seguente vincolo:

• Per semplicita si suppone che l’agenzia abbia un unico programma indifferenziato, indipendente dallastagione o altro.

Si deve pero osservare che con questo ulteriore assunzione la classe Programma di Figura 3 e del tuttosuperflua, 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 entita che vi compaiono hanno un nome preciso (e un ruolo appena delineato).

Definire significato dei termini e il modo migliore per evitare le ambiguita di interpretazione. La costruzionedel modello di dominio produce il glossario dei termini.

La parte che segue rendera evidente il vantaggio dell’aver fatto precedere la definizione del modello di dominioall’analisi dei casi d’uso (Cfr. Paragrafo 11.1).

2Nel senso che per raggiungerlo occorrerebbe un riferimento preciso allo specifico partecipante. Ovviamente cio non ha sensoquando si ha una gran quantita di oggetti; in tal caso gli oggetti devono essere tenuti in un qualche “contenitore” e individuatiattraverso i propri attributi. Con lo schema di Figura 2 i partecipanti si trovano attraverso le escursioni che a loro volta si trovanoattraverso il programma. In Java, se si recide il riferimento al partecipante in escursione (assumendo che nel sistema non vi sianoaltri riferimenti al partecipante), il partecipante e perso.

6

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 – cioe il possibile partecipante a una o piu escursioni – non e un attore. Lo sarebbe seegli stesso avesse accesso al sistema (per esempio via web), ma nel caso specifico cio non e previsto e dunque ilcliente dell’agenzia non ha nessuna interazione diretta col sistema. Per l’unico attore (l’agente) il cliente e un“dato” da inserire nel sistema.

Le specifiche del Paragrafo 3 identificano gia i casi d’uso, anche in modo assai dettagliato. Per come sonoorganizzati, i requisiti sembrano indicare 4 casi d’uso, corrispondenti ai requisiti R1-R4. Tuttavia, per quantola cancellazione di una escursione o la modifica dei suoi dati siano state raggruppate assieme, conviene, almenoin prima istanza, considerarle come casi separati. Il prosieguo dell’analisi dira se essi sono da ritenere distinti oda 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 e in Figura 5.Il diagramma dei casi d’uso serve a fornire una visione intuitiva d’insieme; pero, 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 vienedata una descrizione dettagliata in Tabella 1.

7

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

8

CU1: Inserimento di una escursione a programmaAttore: AgentePrecondizione:Il sistema e idle e sullo schermo viene presentata la finestra con il menuprincipale (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 rela-tivi all’escursione (data, barca/cavallo, descrizione, ecc.); al terminepreme il bottone “Inserisci”;

4. il sistema controlla i dati immessi; se i dati inseriti sono corretti ilsistema presenta la finestra di dialogo “Conferma Inserimento”, conla quale chiede di confermare la scelta di aggiungere l’escursione alprogramma.

(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 esegui-to, il sistema torna a presentare la schermata del punto 1, mostrandogli eventuali dati gia inseriti a video.

Invariante:A partire dal punto 1 il caso d’uso termina incondizionatamente in qualunquemomento venga premuto il bottone EsciSequenza alternativa:Se al punto 1 si verifica che i dati non sono corretti, viene presentata lafinestra di dialogo “Errore di inserimento” nella quale si indica quale campodeve essere aggiornato. Quando l’operatore preme il bottone “OK” presentetale finestra il caso d’uso riprende dal punto 1 (senza apportare modificheal contenuto dei campi gia immessi).Postcondizione:Le eventuali escursioni inserite sono state memorizzate; sullo schermo vieneripresentato il menu principale

Tabella 1: Specifica del caso d’uso “CU1: Inserimento Escursione”

9

Quello di Tabella 1 e il modo classico di rappresentare i casi d’uso. Ci sono questi ingredienti: Numerod’ordine e nome del caso d’uso, condizioni iniziali, percorso principale, eventuali percorsi alternativi, condizionidi uscita. Nel caso specifico e stato aggiunto anche un “invariante”, cioe una condizione sempre verificata apartire dal punto, caratteristica della modalita di funzionamento dell’interfaccia.3

Il caso d’uso prevede che esso contenga al suo interno possibili iterazioni del processo di inserimento delleescursioni. E’ previsto un percorso alternativo a quello principale nel caso in cui i dati immessi si rivelino nonaccettabili al controllo.

Lo schema di Tabella 1 e quello suggerito in molti libri. Esso e piuttosto pesante da scrivere e non e dettoche tutte le informazioni che esso prevede siano di effettiva utilita. Ovviamente non e obbligatorio seguire taleschema. Cio che serve e una descrizione che metta in luce il comportamento di attore e sistema, mostrando lasuccessione di passi nella forma di “azione-reazione”.

Poiche le interfacce tipo GUI sono diventate lo standard nell’interazione tra uomo e macchina, e molto piufacile spiegare un caso d’uso se si mostrano le schermate a video. Ovviamente non ci si deve perdere tropponei dettagli, che inevitabilmente sono soggetti a subire modifiche in fase realizzativa. Si tratta di dare conto dicome si svolgera il caso d’uso. In Figura 6 viene mostrato un esempio di prototipo per la schermata del casod’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 puo ancheessere ridondante. Per esempio, la precondizione e ridondante in quanto e assorbita dalla descrizione del passo 1.In altre parole, il formalismo e utile ma non e essenziale. E utile perche una rappresentazione schematica comequella di Tabella 1 e di agevole lettura e di piu immediata comprensione di una descrizione non strutturata.

Il requisito essenziale della descrizione di un caso d’uso sta nel rappresentare nel modo piu preciso possibilela sequenza di eventi, dando nome e cognome alle entita che vi partecipano. Per esempio, in Tabella 1 si e datoun nome a tutte le schermate video che possono entrare in gioco e, per rendere piu chiaro cosa succede, si ecostruito un prototipo della schermata “Inserimento Escursioni”.

5.2 Caso d’uso: Rimozione escursione

Il caso d’uso e descritto in tabella 2, mentre la schermata corrispondente e mostrata in Figura 7. La partedestra della figura mostra la dialog box che si apre dopo che e stato cliccato il bottone “Rimuovi”; la dialog

3E’ difficile trovare invarianti nei casi d’uso pubblicizzati.

10

box scompare dopo che viene premuto “Conferma”. Come si vede la schematizzazione delle schermate video emolto utile a capire il “comportamento” del sistema (la dinamica delle interazioni).

CU2: Rimozione escursioneSequenza 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 qualeviene 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” conla quale viene chiesto di confermare la scelta di eliminare l’escursioneselezionata.

(a) In caso affermativo l’escursione viene eliminata

(b) In caso contrario niente viene modificato

indipendentemente da quale dei due passi precedenti sia statoeseguito, il sistema torna a presentare la schermata del punto ??.

Invariante:A partire dal punto 1 il caso d’uso termina incondizionatamente in qualunquemomento venga premuto il bottone Esci

Postcondizione:Le escursioni per cui e 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 e stato riportato l’attore (perche ovvio),ne la condizione iniziale (perche assorbita dal primo passo).

Figura 7: Prototipo di schermata per la rimozione delle escursioni. A destra viene mostrata la dialog box chesi apre dopo che e stato cliccato il bottone “Rimuovi”; la dialog box scompare dopo che viene premuto uno deidue pulsanti. Se viene premuto “Sı” l’escursione viene effettivamente rimossa; se viene premuto “No” nienteaccade. Nota per la finestra di dialogo di conferma le Swing fanno tutto!!

11

5.3 Caso d’uso: Modifica escursione

Questo caso d’uso ha in comune ai precedenti le medesime precondizioni, il primo passo, la condizione invariantee la condizione di uscita. Tenuto conto di cio 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 sistemapresenta una schermata contenente la lista delle escursioni e i campi per inserire i dati che definisconole escursioni. L’attore seleziona una escursione dalla lista e modifica i campi; al termine cliccasul bottone “SalvaMod”. Il sistema chiede conferma e in caso affermativo aggiorna i dati relativiall’escursione selezionata. Il ciclo puo essere iterato. Il caso d’uso ha fine quando viene cliccato ilbottone “Esci”.

In Figura 8 e mostrata la schermata corrispondente.

Figura 8: Prototipo di schermata per la modifica delle escursioni. Vengono mostrati i passi dalla selezionedell’escursione fino al comando di modifica. Con riferimento alla schermata di Figura 6, la modifica consiste neltogliere l’optional “Merenda”, e cambiare il limite massimo degli inscrivibili. La figura mostra nel dettaglio unapossibile 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: vienedato il comando di salvare la modifica.

Osservazione La sequenza di Figura 8 suggerisce che la prima operazione sia quella di selezionare un’escur-sione e poi apportare le modifiche ai dati relativi. Si potrebbe anche stabilire che l’interfaccia non imponga unsimile vincolo, decidendo che l’attore possa iniziare modificando i dati (supponendo che egli sappia esattamentecosa inserire) e solo successivamente selezionare l’escursione alla quale apportare le modifiche secondo quantointrodotto. Dare una simile flessibilita impone pero che, se l’attore preme il pulsante “SalvaMod” senza chesia stata selezionata n’escursione, venga presentato un messaggio di allarme che invita l’utente a effettuare laselezione. La soluzione alternativa, anche se piu rigida, consiste nello stabilire che la prima azione che l’attorepuo fare sulla schermata “Modifica Escursioni” sia obbligatoriamente la scelta dell’escursione da modificare.Si tratta di un dettaglio che non e appropriato trattare a questo punto dell’analisi. Potra essere presa l’unao l’altra soluzione in fase di sviluppo, anche in base alle caratteristiche del framework per la costruzione delleinterfacce, e non e detto che la soluzione apparentemente piu facile (quella piu rigida) si dimostri effettivamentetale per il programmatore.

12

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”. Laschermata 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 deipulsanti di Figura 9 porta sostanzialmente alla medesima schermata. Cio suggerisce di prevedere un solobottone sul menu principale, denominato “Inserimento/Rimozione/Modifica” e rimandare la scelta di qualeazione intraprendere alla schermata che esso determina. Cio equivale a dire che il caso d’uso e unico e che hatre 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 incomune. Sembra logico che occorra prevedere un meccanismo che, a partire dalla schermata che segue il clicksul 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 GUIpotrebbe avere un’influenza determinante nella scelta dei dettagli. Tuttavia, a scopo didattico, procediamonell’approfondimento della questione, perche si possono scoprire cose interessanti.

13

Diamo anzitutto una descrizione del caso d’uso “Inserimento/Eliminazione/Modifica Escursioni” (ma non nellaforma 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”. Iprimi tre hanno la funzione di concludere i tre differenti sottocasi determinando le azioni da essipreviste; il quarto fa concludere in ogni momento il caso d’uso. I modelli della schermata del menuprincipale 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” e abilitato (e cosı resta persempre).

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 delleescursioni), 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 (quellaa cui vuole aggiungere un’escursione); a questo punto il pulsante “Inserisci” si attiva. Successiva-mente l’attore puo immettere gli altri dati relativi all’escursione da inserire. Il sottocaso si concludequando 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 vienecliccato il pulsante “Sı” l’escursione viene registrata e la sua descrizione inserita nella lista a video; seviene cliccato il pulsante “No” niente accade; in ambedue i casi viene ripresentata la schermata “In-serimento/Rimozione/Modifica escursioni” (con i tre pulsanti “Inserisci”, “Rimuovi” e “SalvaMod”disabilitati) sulla quale e 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

Se ora si passa all’esame dei due sotto casi “Rimozione” e “Modifica” di Figura 10 e facile convincersi cheessi differiscono solamente per il pulsante premuto alla fine (“Rimuovi” o “SalvaMod”). Conseguentemente sipuo pensare di raggrupparli in un unico sottocaso da cui se ne originano due. Ne consegue che il diagramma diFigura 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 “Sal-vaMod”. Successivamente l’attore puo modificare i dati relativi all’escursione scelta (se intendemodificare). Al termine l’attore clicca uno dei due bottoni “Rimuovi” o “SalvaMod”. Nel primocaso 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 escur-sioni” (con i tre pulsanti “Inserisci”, “Rimuovi” e “SalvaMod” disabilitati) sulla quale e possibileeffettuare 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.

5.4.1 Alcune osservazioni

Nel realizzare l’interfaccia si fara ricorso a qualche framework. E’ possibile che i componenti utilizzabili sul-l’interfaccia (bottoni, liste a scorrimento, calendari, ecc.) abbiano delle caratteristiche che suggeriscano diapportare variazioni a quanto siamo andati delineando.

Per esempio, e possibile che, una volta selezionata una data,e quindi entrati nel percorso di inserimento diuna nuova escursione, attivando il bottone “Inserisci”, sia possibile cambiare idea e selezionare un’escursione traquelle in lista, passando all’altro percorso, disattivando il bottone “Inserisci” e attivando i bottoni “Rimuovi” e“SalvaMod”.4

4Di fatto e quello che accadra nel nostro caso, con i componenti Swing di Java e alcuni componenti presi da librerie pubbliche.

15

Come evidenziato gia in precedenza, questi aspetti possono essere trattati piu appropriatamente in fase direalizzazione, anche se cio puo portare a qualche leggera modifica dei casi d’uso. Si tratterebbe comunque dimodifiche di nessun impatto di carattere concettuale.

Abbiamo detto che i sottocasi sono estensioni del relativo caso d’uso principale. Perche “estensioni” enon “generalizzazioni”? Perche i sottocasi aggiungono comportamenti diversi al comportamento di base. Masi potrebbe anche pensare che i tre sottocasi rappresentano differenti specializzazioni del caso generale. Sesi 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 delpartecipante e selezionando gli optional che egli intende acquistare. La descrizione del caso d’uso e in Tabella 3.

CU4: Iscrizione di un partecipanteAttore: AgentePrecondizione:Il sistema e idle e sullo schermo viene presentata la finestra con il menuprincipale (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 clientealle escursioni ”), contenente i campi che servono a descrivere ilcliente, 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 sequenzapuo non necessariamente iniziare con la selezione dell’escursione, maanche con l’immissione dei dati del cliente; in ogni caso per selezionaregli optional e necessario che l’escursione sia gia stata selezionata. In-oltre sulla stessa schermata puo essere presente un pulsante per veri-ficare (in base al codice fiscale) se il cliente e gia presente nel sistemae prelevare automaticamente i suoi dati.

4. quando l’attore preme il bottone “Registra” i dati vengono immessi.Il processo puo essere iterato.

Invariante:A partire dal punto 1 il caso d’uso termina incondizionatamente in qualunquemomento venga premuto il bottone EsciSequenza alternativa:Al punto 3 se i dati immessi non sono corretti viene presentata la finestradi dialogo “Errore nei dati immessi per il cliente” nella quale si indica qualecampo deve essere aggiornato. Quando l’operatore preme il bottone “OK”presente tale finestra il caso d’uso riprende dal punto 1 (senza apportaremodifiche ai contenuti dei campi gia immessi).Postcondizione:L’eventuale nuovo cliente e stato memorizzato. Viene ripresentato il menuprincipale

Tabella 3: Specifica del caso d’uso “CU4: Iscrizione”

In Figura 13 viene riportato il prototipo della schermata di iscrizione.

16

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 rispondepresentando i dati del partecipante e la lista delle escursioni a cui e iscritto. Per ogni escursione lalista 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 checkboxdella parte del display in cui si inseriscono gli optional riportano il segno di spunta. A questo puntol’attore puo modificare la spunta degli optional.

Se l’attore preme il pulsante “SalvaModifica” si determina il cambiamento degli optional secondo lanuova spunta. Se preme il pulsante “Cancella” il partecipante viene cancellato dall’escursione.

Il ciclo puo essere iterato e ha fine al click di “Esci”. Dopo l’uscita viene ripresentato il menuprincipale.

Percorso alternativo Se non si trova il partecipante non viene presentata alcuna lista delle escursionie 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

E 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 e stato fatto al Paragrafo 5.4.1,qui la differenza resta, in quanto l’iscrizione ha un percorso che inizia dalle Escursioni, mentre la cancellazionedel partecipante da un’escursione come pure la modifica degli optional scelti hanno un percorso che iniziadai Partecipanti. Mettere tutto a un’unica videata rischia di renderla confusa per chi la usa e complessa darealizzare. Per questo manterremo la separazione tra “Iscrizione” e “Cancellazione/Modifica”, per la quale peroprevederemo du sottocasi “Cancellazione” e “ModificaOptional” .

17

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 deglioptional scelti richiedono la conoscenza del codice fiscale del partecipante, occorre aggiungere da qualche partela funzionalita di visualizzazione del codice fiscale dei partecipanti. Si puo aggiungere un caso d’uso specifico“Visualizza Clienti” Il caso d’uso e ovvio ed evitiamo di descriverlo5. 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 casid’uso di Figura 15 e al menu principale schematizzato in Figura 16. In Figura 15 si e preferito usare la relazionedi invocazione tra caso d’uso principale e subordinati. Si faccia attenzione a come i casi d’uso principali sonoidentificati in Figura 15; useremo tale identificazione nel resto del documento.

5.8 Conclusioni

Possiamo trarre alcune conclusioni e alcuni insegnamenti da quanto abbiamo fatto.

5.8.1 Cosa rappresentano i casi d’uso

I casi d’uso dicono cosa il sistema fa. Sono una specifica del comportamento del sistema come percepito daisuoi utenti finali.

5.8.2 Quanto devono essere astratti

E bene che i casi d’uso siano concreti: casi d’uso scritti in modo astratto servono a poco o nulla. Per questomotivo devono fare riferimento a un modello di dominio. In tal modo i casi d’uso sono orientati verso le entitaalla cui manipolazione essi sono preposti. Un modello di dominio fornisce, come minimo, il significato dei terminiusati (glossario). L’impiego di termini il cui significato e chiaro riduce il rischio di specifiche ambigue.

5.8.3 Come si scrivono i casi d’uso

Dovendo rappresentare la dinamica del tipo “azione e reazione”, ovvero illustrare l’esecuzione di sequenze dipassi6, i casi d’uso devono essere espressi usando verbi al tempo indicativo presente.

Al fine di evitare ambiguita le entita devono essere menzionate con il nome univoco ad esse assegnato nelmodello di dominio. Per la stessa ragione si deve dare un nome specifico alle singole viste (videate).

5Questa funzionalita viene aggiunta soprattutto ai fini della sperimentazione col sistema. Infatti, nella realta, una persona e ingrado di fornire il proprio codice fiscale. Invece, nel fare le prove si inseriscono usualmente codici a caso, che poi sono difficili daricordare! Abbiamo deciso di prevedere un caso d’uso a parte proprio per non toccare i precedenti casi d’uso che vorrebbero esserefedeli alla realta.

6Si osservi che, diversamente dai casi d’uso, i requisiti sono espressi come clausole.

18

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 prototipodi schermata e un modo di comunicazione quasi sempre piu efficace delle parole

Prevedere sempre i possibili percorsi alternativi al percorso principale di ciascun caso d’uso.

5.8.4 Come si validano

Alla fine dell’analisi occorre fare un esame critico al fine di validare quanto fatto. Questo esame deve esserecondotto dall’analista assieme agli utenti/committenti del sistema, in modo che sia evitata la spiacevole situ-azione in cui vengono a trovarsi non pochi progetti di sviluppo software, quando, in fase avanzata, ci si accorgeche quel che fa il sistema (quello che e stato realizzato) non corrisponde a quello che il cliente/committente siaspettava.

Dopo la necessaria validazione non e detto che il lavoro sui casi d’uso sia finito: il passo successivo delprocesso, l’analisi di robustezza, puo evidenziare la necessita di tornarci sopra al fine di eliminare incoerenze edambiguita nascoste.

19

5.8.5 Ma, alla fin fine, che cosa e stato prodotto?

Se si mettessero assieme e si riorganizzassero le descrizioni dei casi d’uso (trasformando frasi come “l’attorepreme il pulsante ... il sistema mostra la finestra ...” in “premere il pulsante ... viene mostrata la finestra ...”),si otterrebbe.....il manuale utente!

Questo e 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 comportera; molto prima di darcorso alla sua realizzazione.

6 Casi d’uso e requisiti

Come e stato affermato in precedenza, e bene che i casi d’uso vengano esaminati criticamente dall’analistaassieme agli utenti/committenti del sistema.

Un aspetto importante da verificare e se tutti i requisiti sono stati considerati. A tale scopo convieneincrociare i requisiti con i casi d’uso al fine di stabilire se tutti i requisiti sono “coperti” dai casi d’uso.

Il nostro sistema e particolarmente semplice. La verifica di copertura puo essere fatta ricorrendo a un foglioelettronico come in Figura 177. Si noti che CU4, introdotto per la ricerca del codice fiscale di un cliente, noncopre nessun specifico requisito.

Figura 17: Copertura dei requisiti da parte dei casi d’uso. Non si sono riportati i sottocasi perche cio nonavrebbe aggiunto alcuna informazione in piu.

7 Un intermezzo: modellazione dell’interfaccia con le macchine astati

Nel fare l’analisi dei casi d’uso abbiamo presentato le schermate in forma anche troppo dettagliata. Comeabbiamo gia osservato al termine del Paragrafo 5.4, non vale la pena di esagerare con i dettagli, in quantoil framework impiegato nella realizzazione della GUI potra imporre scelte obbligate, contrastanti con quantoipotizzato. I prototipi delle finestre hanno lo scopo di fornire una chiara rappresentazione delle funzionalita cheesse implicano.

L’analisi aveva anche messo in mostra una certa difficolta nel descrivere il comportamento dell’interfaccia.Per questo motivo, e al fine di facilitare il successivo lavoro di analisi, conviene descrivere il comportamentodell’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 4stati in corrispondenza ai 4 casi d’uso di Figura 15. Il diagramma non ha bisogno di commenti: dallo stato S0l’interfaccia (e il sistema) passa allo stato che corrisponde all’espletamento della funzionalita richiesta. Si notiche in corrispondenza dei cambiamenti di stato vengono presentate le schermate corrispondenti.

7Alcuni strumenti Case forniscono supporto allo svolgimento di questo tipo di analisi.

20

Figura 18: Diagramma di stato dell’interfaccia.

7.2 Inserimento/Rimozione/Modifica escursioni

Il diagramma di stato corrispondente a questo macrostato e 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 puo riempire i campi della maschera a video; mentrela selezione iniziale di una escursione fa passare allo stato di rimozione/modifica. Il diagramma mostra che c’e unpassaggio tra questi due stati in base alla selezione di una data o di una escursione. A ogni passaggio il video vieneaggiornato (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

7.2.1 Iscrizione

Il diagramma di stato e in Figura 20.

Figura 20: Diagramma di stato relativo all’iscrizione.

7.3 Cancellazione da una escursione/Modifica optional

Il diagramma di stato relativo alla cancellazione da una escursione e alla modifica degli optional scelti e a sinistrain Figura 21. A destra il diagramma relativo all’elencazione dei clienti.

Figura 21: A sinistra la Cancellazione/Modifica optional; a destra l’elencazione dei clienti.

8 Analisi

Dobbiamo ora fare l’analisi del come vengono ottenute le funzionalita che il sistema deve presentare. Si trattadella cosiddetta analisi di robustezza (robustness analysis). Essa consiste, per ciascun caso d’uso nell’identificarele funzioni da svolgere e le classi del modello che intervengono. Le funzioni verranno poi allocate a eventualiclassi applicative aggiuntive e, in parte, quando sia conveniente, alle classi del modello di dominio. Lo scopodell’analisi di robustezza e collegare l’analisi dei casi d’uso alla specifica dettagliata di progetto in cui vengonodefinite le operazioni di sui e responsabile ciascuna classe.

Nel fare l’analisi seguiremo questo criterio: Inizialmente identificheremo le funzioni applicative prevedendoper ciascuna di esse uno specifico controllore, successivamente potremo accorpare piu funzioni applicative inun medesimo controllore. Nel fare l’analisi approfondiremo anche il ruolo delle classi del modello. Cio potrasuggerire (piccole, sperabilmente) variazioni al modello stesso.

L’analisi fa riferimento ai tre stereotipi (di analisi) Boundary, Controller, Entity.

22

• Entity (entita): classi di oggetti che rappresentano la semantica del dominio applicativo;

• Controller (controllori) : classi di oggetti che determinano il modo in cui lapplicazione risponde agli inputdegli attori;

• Boundary (Viste, Interfacce): classi di oggetti che rappresentano linterfaccia tra gli attori e il (resto del)sistema.

RegoleSeguiremo queste regole:

• Entita e viste possono comunicare con i controllori (e viceversa), ma non fra di loro.

• I controllori possono comunicare con entita e viste (e viceversa) e possono comunicare tra di loro.

Queste regole sono dettate dall’idea di identificare le funzioni. Piu avanti verranno rilassate.

Si tratta ora di prendere ciascun caso d’uso e tracciare per esso il relativo diagramma di analisi.

8.1 Analisi di CU1

Cominciamo con la parte a comune del caso d’uso. La Figura 22 riporta l’inizio della tracciatura del diagramma.E’ stata introdotta la funzione (il controllore) displayVP responsabile della presentazione del (video del) menuprincipale (VPrinc).

Figura 22: Primo passo nella costruzione del diagramma di robustezza del caso d’uso CU1. Il diagramma adestra mostra la situazione iniziale, prima che venga cliccato il bottone “Inserimento/Eliminazione/Modifica”.

La Figura 23 mostra il diagramma della parte comune di CU1 (cioe quanto riportato testualmente nellafigura stessa). Il click del pulsante “Inserimento/Eliminazione/Modifica” (indicato come “InsRimM” per ra-gioni di spazio) viene rilevato da ContrVPrinc, il controllore del menu principale (ovvero il controllore associatoalla vista VPrinc). E responsabilita di quest’ultimo presentare il video VIRM relativo al menu di inserimen-to/rimozione/modifica (la schermata e riportata nella parte destra di Figura 11). Poiche in questo video vienepresentato l’elenco delle escursioni gia nel programma dell’agenzia e necessario che ContrVPrinc abbia accessoal modello, ovvero alla sua interfaccia Agenzia, per prelevare l’elenco delle escursioni e presentarle. Il modoin cui ContrVPrinc acquisira l’elenco delle escursioni e un aspetto da rimandare alla fase successiva, quelladell’anali attraverso i diagrammi di sequenza, con i quali si identificheranno i metodi delle classi, ovvero le lororesponsabilita.

8.1.1 Inserimento

La descrizione testuale del sottocaso, nella sua versione finale, e stata riportata a Pagina 14 del Paragrafo5.4. Abbiamo gia osservato (Paragrafo 5.4.1) la descrizione e fin troppo dettagliata e che certe assunzioni sul

23

Figura 23: Diagramma corrispondente alla parte comune di CU1.

comportamento dell’interfaccia avrebbero potuto essere cambiate in base al comportamento del supporto perl’interfaccia grafica. Per questo motivo conviene semplificare la descrizione come in Figura 24, dove sono stateeliminate le frasi che illustrano dettagli da rimandare alla fase implementativa. Nella parte destra di Figura 24viene riportato il corrispondente diagramma di robustezza.

Si noti che VIRM (cioe il video “Programma Escursioni” a destra in Figura 11), ha il suo controlloreContrVIRM che, riferito a questo sottocaso d’uso, riconosce il click sul pulsante “Inserisci” e provvede a chiamarela funzione di controllo di errore e quella di inserimento nella base di dati della nuova escursione che esso stessocrea. Lo stesso ContrVIRM provvede ad aggiornare VIRM al termine dell’operazione.

Figura 24: Semplificazione del testo del sottocaso d’suo inserimento.

Si noti che abbiamo trascurato tutti gli aspetti relativi alla prima azione da compiere per entrare nel sot-tocaso. Abbiamo anche trascurato di entrare nei dettagli relativi all’abilitazione/disabilitazione dei pulsanti,rinviando il problema alla fase implementativa.

In Figura 24, ContrVIRM e Inserisci sono, ovviamente, rappresentati come due controllori. Ricordiamo cheessi rappresentano le funzionalita che il sistema deve implementare. Possiamo prevedere sin d’ora che la funzion-alita di controllo dell’errore dei dati immessi sia semplicemente parte del controllore ContrVIRM (potremo trarre

24

anche vantaggio dai controlli effettuati dal tool rispetto ai contenuti immessi nei campi), mentre e ragionevolepensare che “Inserisci” sia una funzionalita da assegnare a un effettivo controllore diverso da ContrVIRM.

La funzionalita di controllo di errore determina il percorso alternativo della descrizione testuale.Osserviamo anche che in Figura 24 la nuova escursione viene creata da Inserisci. Cio presuppone che a

questo controllore vengano passati da ContrVIRM i dati richiesti per la sua creazione. Puo essere ragionevole chela creazione dell’escursione sia affidata a ContrVIRM. Anche questa e una scelta che potra essere meglio definitain fase di implementazione, quando sara chiaro in che forma vengono resi i dati immessi.

8.1.2 Rimozione

In Figura 25 viene presentato il diagramma di robustezza relativo al sottocaso rimozione. Si noti che nelladescrizione testuale abbiamo rimosso alcune frasi di dettaglio.

Figura 25: Diagramma di robustezza per il sottocaso di rimozione delle escursioni. Dal testo sono state cancellatefrasi ritenute inutili a questo stadio dell’analisi.

8.2 Analisi di CU2

In Figura 26 viene presentato il diagramma relativo alla registrazione di un partecipante.

Figura 26: Diagramma relativo all’inserimento di un partecipante.

25

8.3 Continuazione

I diagrammi di robustezza relativi agli altri casi d’uso si ottengono analogamente. Si noti che nello svilupparel’analisi abbiamo seguito il criterio di mettere in evidenza le funzioni necessarie al caratterizzare l’esecuzione deicasi s’uso, evitando i dettagli inutili, per non perdere la focalizzazione sugli aspetti caratterizzanti il problema.Cio ha comportato una parziale riscrittura dei casi d’uso.

L’analisi appena conclusa avrebbe potuto mettere in mostra la necessita di apportare modifiche anche almodello di dominio e di maggiori interventi sui casi d’uso.

L’anali si conclude con la verifica che tutti i casi d’uso sono stati trattati e che le opportune modifiche sonostate apportate.

Il passo successivo e la stesura dei diagrammi di sequenza, in modo da identificare le reponsabilita delle clas-si, ovvero i metodi di interfaccia. I diagrammi possono essere stesi a partire dai diagrammi di robustezza,rappresentando le funzioni identificate come altrettanti controllori indipendenti.

Poiche nel fare l’analisi abbiamo scoperto che il nostro sistema si compone dei controllori associati alledifferenti schermate e da eventuali altri controllori che interagiscono direttamente con gli oggetti del modello,conviene prevedere sin d’ora quali saranno questi possibili controllori e allocare ad essi le funzioni applicativeidentificate (Inserisci, Rimuovi, ecc.). Tenuto conto del fatto che si hanno operazioni che vanno a manipolarele escursioni e operazioni che vanno a manipolare i partecipanti, e ragionevole prevedere sin d’ora due classiapplicative EscManager e ClientManager e allocare convenientemente ad esse le funzionalita individuate.

Stabiliamo anche (dopo aver dato uno sguardo alle Swing con cui si implementera la GUI) di affidare, ovepossibile, ai controllori delle schermate le funzioni di controllo della correttezza degli ingressi, ecc..

9 Specifica delle classi (diagrammi di sequenza)

In base alle considerazioni ora svolte la stesura dei diagrammi e piuttosto agevole.

9.1 DS1: diagramma di sequenza relativo a CU1

Il diagramma e in Figura 27.

Figura 27: Diagramma di sequenza per la parte comune di CU1.

Come si vede, il controllore del video principale, per poter presentare le escursioni chiede a EscManager

l’elenco delle escursioni. A tal fine EscManager presenta il metodo getEscursioni() la cui esecuzione rimandaall’esecuzione del metodo omonimo che deve essere previsto sull’interfaccia di Agenzia. Una volta costruito ilcontenuto da presentare a video, ContrVPrinc non fa altro che istanziare la videata VIRM con tale contenuto.

9.1.1 DS1Ins: diagramma di sequenza relativo all’inserimento di una escursione a programma

Il diagramma in questione e in Figura 28.

26

Figura 28: Diagramma di sequenza relativo all’inserimento di una escursione nel programma dell’agenzia.

Il diagramma illustra che, prima di premere il pulsante di inserimento, l’attore puo immettere i dati. Il toolStarUML, a saperlo usare bene, e in grado di rappresentare cicli. Tuttavia anche qui siamo di fronte al fattoche il modo in cui i dati verranno immessi potra dipendere dalle caratteristiche dell’interfaccia. Lo schema diFigura 28 ricorda che c’e una fase di immissione senza dare altri particolari da decidere nel seguito. In questocaso l’applicazione EscManager deve presentare il metodo inserisci(). In Figura 28 si e fatta l’ipotesi che aEscManager vengano passati i dati per istanziare la nuova escursione che poi viene aggiunta alla base dati ; atale scopo la classe Agenzia deve prevedere il metodo addEsc.

In Figura 29 viene mostrata la soluzione alternativa di far istanziare la nuova escursione da ContrVIRM.

Figura 29: Diagramma di sequenza relativo all’inserimento di una escursione nel programma dell’agenzia,modificato rispetto a quello di Figura 28 facendo istanziare l’escursione direttamente da ContrVIRM.

Si tratta di una scelta piu che legittima, in quanto ContrVIRM ha tutti i dati per istanziare l’escursione

27

appena immessa. Cosı facendo deve passare a EscManager solo l’escursione e non una lunga sequenza diparametri perche quest’ultimo possa istanziarla.

In questo caso al diagramma sono stati aggiunti alcuni commenti. Il ricorso ai commenti e utile per evitarele complicazioni relative alla rappresentazione di cicli e dei percorsi alternativi sul diagramma.

9.2 DSCU2: Diagramma di sequenza relativo all’iscrizione di un partecipante

Il diagramma in questione e in Figura 30.

Figura 30: Diagramma di sequenza relativo all’iscrizione di un partecipante. Si noti che non viene fatto il testper verificare se il cliente e o meno nel sistema. Il caso mostrato e quello in cui il cliente non e presente, per cuiesso deve essere istanziato (con i dati introdotti a video).

Si noti che il diagramma di Figura 30 non tiene conto del fatto che un partecipante deve effettuare unascelta (eventualmente nulla) relativamente agli optional. La scelta (o le scelte - per ora facciamo conto che siauna sola) richiede la sua istanziazione e il suo collegamento con il partecipante e con la relativa escursione. Ildiagramma si modifica come in Figura 31, tracciato trascurando la parte del controllo di errore di Figura 30.

Nel tracciare la figura si e fatta l’ipotesi che ClientManager abbia da ContrVreg non solo i dati relativi al(nuovo) partecipante e alla sua scelta, ma anche il riferimento all’escursione (sia la scelta che il partecipantepotrebbero essere istanziati da ContrReg).

Il diagramma di Figura 31 presuppone che quando una Scelta viene creata le venga passato il riferimentoal partecipante e all’escursione e che poi il riferimento alla scelta venga passato al partecipante attraverso ilmetodo linkScelta() di quest’ultimo.

9.3 Continuazione e commento

Per non tediare troppo il lettore ci fermiamo qui.Nei diagrammi precedenti si e dato conto solo degli aspetti principali. Relativamente al modello di dominio,

questo ci ha portato a identificare il metodo addESC() di Agenzia, il metodo addPartecip() di Escursione elinkScelta() di Partecipante.

In modo analogo si tracciano i diagrammi relativi agli altri casi d’uso –sempre con riferimento ai corrispon-denti diagramma di robustezza– e si individuano i metodi delle classi del dominio, come pure possibili, eventualimetodo aggiuntivi (a quelli trovati con l’analisi di robustezza) delle classi applicative.

28

Figura 31: Trattamento delle scelte nella registrazione di un partecipante.

10 Organizzazione

In Figura 32 viene illustrata la naturale suddivisione dei componenti in tre distinti packages corrispondenti ai trelivelli di logica del modello MVC. Nello sviluppare il sistema potrebbe essere vantaggioso individuare ulterioripackages, per esempio un package di carattere trasversale contenti classi di utilita come la Data o simili.

Figura 32: Organizzazione del software in piu package.

11 Approfondimenti

11.1 Il modello

Vediamo ora di entrare maggiormente nel dettaglio per quanto attiene le classi del modello.La prima questione che si pone e se, con riferimento al modello di Figura 4 si debba specializzare la

classe Escursione nelle due classi GitaInBarca e GitaACavallo. Valgono anche in questo caso consider-azioni analoghe a quelle fatte al Paragrafo 4.1 in riferimento agli optional. Nel nostro sistema non c’e alcunadifferenza comportamentale tra la gita in barca e la gita a cavallo, dunque non ha nessun senso prevedere dueclassi distinte. Esse si possono differenziare attraverso un semplice attributo (che chiameremo tipo). Diversosarebbe stato il caso in cui i due tipi di escursione si fossero differenziati quanto a numero di attributi e a metodi;in tal caso sarebbe stato necessario prevedere classi derivate.

Un altro aspetto importante e come si realizza la classe di associazione. Ci sono due modi:

a) prevedere che una scelta identifichi un solo optional per una data escursione tra quelli selezionati dalpartecipante. In questo caso la classe Scelta ha solo due attributi: i riferimenti agli oggetti TipoOptionale Escursione;

b) prevedere che una scelta identifichi tutti gli optional scelti dal partecipante in una data escursione. Inquesto caso la classe Scelta puo contenere fino a tre coppie dei due attributi del punto precedente;

29

La soluzione a) corrisponde al diagramma di Figura 33, mentre la soluzione b) corrisponde al diagramma diFigura 34. Notare che nelle due figure oltre a rappresentare gli attributi delle classi sono stati anche rappresentatii metodi individuati in precedenza con i diagrammi di sequenza. A questo proposito conviene fare le osservazionidel paragrafo che segue.

Figura 33: Modello di dominio per il caso a) relativamente alla classe Scelta, con evidenziazione degli attributie dei metodi.

Figura 34: Modello di dominio per il caso b) relativamente alla classe Scelta.

11.2 Quando andare a fondo con i diagrammi di sequenza?

I diagrammi di sequenza sono un ottimo strumento per capire come avvengono le interazioni tra gli oggetti.Ma non si deve pensare di poterli usare fino a “tirare fuori” ogni metodo. Cercare di definire tutti metodi delleclassi attraverso i diagrammi di sequenza sarebbe una inutile perdita di tempo. I diagrammi di sequenza devonodarci le interazioni fondamentali, i metodi di carattere secondario e di appoggio si fissano meglio al tempo diprogrammazione. Al tempo di programmazione certe funzionalita possono essere raggruppate o suddivise ospostate da una classe all’altra a seconda della convenienza. Cio porta facilmente a rimettere in discussioneeventuali scelte di dettaglio fatte a livello di diagrammi di sequenza.

Per esempio, la Figura 33 mostra il metodo addPartecipante() della classe Escursione. E’ ovvio chePartecipante dovra avere il metodo duale; tale metodo e stato chiamato addEsc() in Figura 33 e 34. Esso non faaltro che per aggiungere in Partecipante il riferimento all’escursione a cui egli viene iscritto; probabilmente talemetodo sara chiamato dal metodo addPartecipante() di Escursione (all’atto dell’iscrizione di un partecipantea una escursione), passando come parametro l’escursione stessa. Il metodo addEsc() non e stato trovatoattraverso la stesura dei diagrammi di sequenza, ma con ovvi ragionamenti sul modello. Avremmo anche

30

potuto omettere la sua rappresentazione, in quanto dovrebbe essere un fatto che se si iscrive un partecipante auna escursione e necessario anche mettere nel partecipante il collegamento all’escursione.

Quanto si debba andare a fondo e in larga parte dettato dalla sensibilita dell’analista e dal contesto in cuiopera (quanto e esperto e capace il programmatore, se diverso dall’analista).

In fase di programmazione converra equipaggiare le classi del modello con metodi get e set degli attributi.Per esempio, il partecipante sara istanziato passando al costruttore il codice fiscale e il nome. Assumiamoche questi attributi non possano essere cambiati e quindi non prevediamo i metodi setCF() e setNome(), maprevediamo i metodi getCF() e getNome() che serviranno nel caso in cui si debba cercare un partecipante inbase al suo CF (che lo individua univocamente). Possiamo stabilire la convenzione che metodi come set()

e get() non vengano mai rappresentati nei diagrammi e che il programmatore provveda al a seconda dellenecessita al tempo di programmazione.

In altre parole, il diagramma di figura ?? e un buon punto di partenza per iniziare la programmazione, madobbiamo tenerci pronti ad aggiungere metodi alle classi del modello.

Per meglio chiarire il modo con cui si aggiungono i metodi, torniamo al diagramma di sequenza di Figura 30.Come dice la didascalia della figura, la sequenza rappresentata corrisponde al caso in cui chi si iscrive non epresente nel sistema. Questo presuppone che prima di creare il nuovo partecipante sia stata effettuata la relativaverifica (non indicata in Figura 30). La verifica puo essere effettuata prevedendo che l’interfaccia del modello(Agenzia) esponga il metodo getPartecipante(String cF), sotto riportato.

Il metodo restituisce il partecipante se gia presente nel sistema, restituisce null se il partecipante nonesiste. Con riferimento al modello di Figura 33, avendo chiamato partecipanti la collezione di partecipanti inAgenzia, il metodo prenderebbe questa forma:

public Partecipante getPartecipante(String cF){

Iterator<Partecipante> it = partecipanti.iterator();

while(it.hasNext()){

Partecipante p = it.next();

if (p.getCF() == cF) return p}

}

}

return null;

}

Il ClientManager di Figura 30 si sincera dell’esistenza del partecipante, il cui codice fiscale e “RBRTGR56..”,in questo modo

Partecipante p = agenzia.getPartecipante("RBRTGR56..");

if (p== null) p = new Partecipante("RBRTGR56..");

11.3 Altre divagazioni sul modello

Torniamo sulla questione degli optional. Abbiamo osservato che essi sono delle costanti usate sia da Escursioneche da Scelta (Cfr. Paragrafo 11.1). Si potrebbe pensare di modificare li classi Escursione e Scelta come inFigura 35, dove:

• La classe Escursione ha ora 3 campi di tipo boolean (ovviamente da inizializzare all’atto dell’istanzi-azione) che dicono quali sono gli optional previsti

• La classe Scelta ha pure 3 campi di tipo boolean che dicono se un dato optional e stato scelto.

Naturalmente lo schema di Figura 35 presuppone che i tre attributi rappresentino ordinatamente i tre possibilitipi di optional, il cui prezzo e fisso ed e descritto altrove, per esempio come un vettore che riporta il costo (edeventualmente il nome) per ciascun elemento.

Lo schema di Figura 35 e apparentemente piu semplice, ma presenta qualche inconveniente. In particolaresupponiamo che ora si voglia prevedere un ulteriore tipo di optional. A tal fine occorre modificare (cioe ricom-pilare!) le classi Escursione e Scelta,oltre al vettore che descrive gli optional (oltre naturalmente a modificarel’interfaccia prevedendo una ulteriore checkbox per i nuovo optional. Il programma ricompilato non sarebbe piucompatibile con gli oggetti creati in precedenza, ovvero, se ci fosse una base di dati, occorrerebbe convertireanche la base di dati. Dunque, la soluzione appena prospettata e senz’altro da scartare.

31

Figura 35: Modifica al modello di dominio, per rappresentare gli optional non come oggetti .

Si potrebbe risolvere il problema della necessita di ricompilare prevedendo che gli optional, sia in Escursione

che in Scelta anziche attributi di tipo scalare fossero strutture dati, per esempio un vettore, o meglio ancorauna struttura tipo Collection di Java. Ma allora non conviene davvero che le componenti di queste strutture(questi aggregati) siano di tipo boolean (che rimandano in modo implicito, cioe non manifesto nel modello,alla definizione degli optional, con tutte le complicazioni pratiche per il programmatore, che deve ricordarsi chicorrisponde a chi). Conviene che questi aggregati rimandino direttamente, in modo visibile nel modello e senzaconvenzioni per il programmatore, ai tipi di optional. Ma questa e proprio la nostra soluzione!

Notare che se vogliamo che il programma sia espandibile nel modo detto, l’aggregato optional di Figura 33e 34 non deve avere una molteplicita limitata a {0..3} ma deve essere generale {*}. Lo stesso si dovrebbe direper il corrispondente aggregato in Scelta di Figura 34.

Si noti che con le modifiche appena dette, l’aggiunta di un nuovo tipo di optional richiede solo che vengaistanziato il nuovo oggetto. Cio introdurrebbe un nuovo caso d’uso, cui corrisponderebbe lo svolgimento dellafunzione applicativa che istanzia, il nuovo tipo di optional (selezionabile attraverso l’interfaccia). Per quantoriguarda quest’ultima, essa andrebbe modificata nel senso di rimpiazzare le 3 checkbox con una lista da cuiselezionare.

Si lascia al lettore l’esame di quale sia preferibile tra il modello di Figura 33 e quello 34.

Una prima realizzazione

Quanto abbiamo fatto ci consente di passare alla realizzazione di un prototipo senza il supporto della memo-rizzazione, ovvero come sistema in cui gli oggetti sono tutti in memoria centrale. Per non rompere il flusso diesposizione degli aspetti concettuali, relativi alla realizzazione di un effettivo sistema, capace di trattare datipersistenti, rinviamo all’Appendice A per la realizzazione del prototipo di soli oggetti in memoria.

32

12 La persistenza

Fino a questo punto abbiamo prestato attenzione al modello a oggetti come sei il sistema funzionasse solo inmemoria centrale. E evidente che in un applicazione come questa i dati devono essere persistenti, nel senso cheessi devono sopravvivere allo spegnimento/accensione del sistema. In altre parole i dati devono essere persistenti,ovvero memorizzati permanentemente sulla memoria ausiliaria. Questo introduce il problema di come mapparegli oggetti del modello sui dati persistenti e viceversa. La Figura 36 schematizza la natura del problema: daun lato il mondo “vivo” degli oggetti in memoria (entita con comportamento), dall’altro il mondo “morto” deidati (record, tabelle, ecc.).

Figura 36: Il problema della persistenza.

Nelle cosiddette “applicazioni enterpise” di cui la nostra, nel suo piccolo, e un esempio, la permanenza egestita in forma di base di dati (relazionale). La Figura 37 mostra il classico modello a livelli di un qualunquesistema. EIS sta per Enterprise Information System, la base di dati; il livello di persistenza e quello cheinterfaccia il modo a oggetti dell’applicazione con la base di dati.

Figura 37: Schematizzazione a livelli di un sistema Enterprise. Il Domain layer va inteso come il livello checontiene gli oggetti del (nostro) modello di dominio e gli oggetti che realizzano la logica applicativa.

In Figura 38 il livello di dominio e stato suddiviso in modo da separare gli oggetti del modello dagli oggettiapplicativi (ad ambedue e stata data una nuova denominazione).

12.1 Una tecnica elementare

Un modo semplice per realizzare la persistenza consiste nel ricorrere al concetto di “workspace”. In altre parolequando il programma viene messo in esecuzione esso legge da memoria di massa i dati salvati alla sedutaprecedente e costruisce il grafo dei data objects in memoria. Alla chiusura del sistema, l’intero grafo dei dataobjects viene salvato su file.

Questo e il modo tipico di lavorare di programmi anche complessi ma che non abbiano come missionefondamentale quella di costituire una base di dati.

33

Figura 38: A sinistra la schematizzazione UML del sistema a livelli (Figura 37); a destra l’esplosione del livellointermedio. Si noti che questo livello si compone di service object, i nostri oggetti che implementano la logicaapplicativa, e data objects, gli oggetti del nostro modello di dominio.

Java fornisce la serializzazione. Meglio ancora si puo fare ricorso a librerie di pubblico dominio comeXStream.

12.2 Persistenza e basi di dati

Nelle cosiddette applicazioni Enterprise la soluzione del paragrafo precedente non puo essere ovviamente usata.Questi sistemi infatti sono caratterizzati da una operativita non stop ed hanno come fondamento l’esistenza diuna base di dati, normalmente di tipo relazionale.

In Figura 39 viene schematizzato il problema della mappatura tra il mondo a oggetti e quello relazionale.In estrema sintesi, i metadati di mappatura servono al mapper per svolgere queste funzioni:

• trasformare il contenuto delle tabelle del data base negli attributi dei corrispondenti oggetti;

• trasformate i valori degli attributi degli oggetti nei valori dei campi delle (righe delle) tabelle della basedi dati relazionale.

Figura 39: Mappatura tra oggetti e relazioni (Object Relational Mapping, ORM).

In Figura 40 viene rappresentato il problema della mappatura in riferimento al cosiddetto impedance mis-match tra mondo relazionale e mondo a oggetti, ovvero al fatto che due rappresentazioni sono diverse non soloperche gli oggetti hanno un comportamento contrariamente alle righe delle tabelle, ma anche perche i legamitra oggetti si esprimono in diverso rispetto ai legami tra (righe nelle) tabelle.

12.3 Mappatura

La mappatura puo essere:

• Manuale: quando il codice SQL per l’accesso ai dati viene prodotto manualmente dal programmatore eintegrato nell’applicazione

34

Figura 40: Il problema della mappatura: l’impedance mismatch tra modo relazionale e mondo a oggetti.

• Automatica: quando il livello di persistenza, attraverso i metadati di mappatura, provvede ad accederedirettamente ai dati (genera automaticamente il codice SQL necessario). Si tratta evidentemente dellasoluzione schematizzata in Figura 39.

• Trasparente: quando il modello di dominio non e sottoposto ad alcun vincolo dovuto allo strato dipersistenza;

• Invasiva: quando il modello di dominio deve implementare e/o estendere classi e interfacce dello strato dipersistenza per poter usufruire del servizio di mappatura, per esempio dotando i data objects con i metodiper salvarli, caricarli, ecc., come schematizzato in Figura 41, dove alla classe Knight sono stati aggiunti imetodi save(), load(), ecc.. Spetta a questi metodi effettuate le corrispondenti operazioni in termini dichiamate a JDBC.

Figura 41: Aggiunta dei metodi per gestire la persistenza (esempio).

12.3.1 Connessione alla base di dati

Per l’accesso da parte dei programmi alle basi di dati si usa ODBC (Open Data Base Connectivity), unaAPI attraverso la quale i programmi possono inviare stringhe SQL alla base di dati senza conoscerne le APIproprietarie del DBMS (cio richiede uno specifico driver tra ODBC e l’effettivo DBMS). JDBC e la versioneODBC per Java.

Schematicamente, per accedere a una base di dati relazionale da un programma Java, occorre:

• Aprire una connessione verso la base di dati (istanziando l’oggetto con).

• Preparare uno statement SQL (istanziando l’oggetto stmt).

• Eseguire la query (tramite il metodo executeQuery() di stmt), in modo da ottenere un result set.

Per esempio, se ipotizziamo che nella base di dati ci sia la tabella PARTECIPANTE con gli statementseguenti si ottiene un result set corrispondente alla tabella Partecipante.

35

Statement stmt = con.createStatement();

ResultSet rs = stmt.executeQuery("select * from PARTECIPANTE");

Il result set ha, inizialmente, il cursore posizionato in posizione antecedente la prima riga: il metodo next()

porta il cursore a puntare alla prima riga; successive esecuzioni di next() fanno avanzare il cursore. Sul result setdi Java e definita una varieta di operazioni. Ad esempio, il metodo getString(String columnName) restituiscein forma di stringa il contenuto della colonna indicata per la riga individuata dal cursore.

12.4 Mappatura manuale, invasiva e non trasparente

Con riferimento a quanto detto al termine del Paragrafo 11, consideriamo la ricerca di un partecipante. As-sumiamo di non vole cambiare in alcun modo il ClientManager mantenendo la classe Agenzia, in modo che leapplicazioni non siano in alcun modo influenzate dalla presenza della base di dati.

Agenzia avra ancora il metodo getPartecipante(String cF), solo che questa volta l’oggetto, se non e giain memoria perche ci e stato portato in precedenza, deve essere costruito a partire dalle informazioni nella basedati. Schematicamente, il metodo si trasforma in questo modo:

public Partecipante getPartecipante(String cF){

Statement stmt = con.createStatement();

ResultSet rs = stmt.executeQuery("select * from PARTECIPANTE");

while (rs.next()){

String cFx = rs.getString("CF");

if (cFx == cF) {

Partecipante p = new Partecipante(cF);

p.setName(rs.getString("NAME"));

return p;

}

}

return null;

}

Abbiamo assunto che la tabella PARTECIPANTE abbia le colonne CF e NOME. Se nella tabella si trova ilpartecipante, allora viene costruito l’oggetto Partecipante usando lo stesso codice fiscale e dandogli il nomeche si ricava sempre dalla base di dati. E’ ovvio che se l’oggetto da costruire ha molti attributi occorronoaltrettante operazioni set().

Nell’esempio che abbiamo fatto l’Agenzia ricostruisce il partecipante dalla base di dati e quindi deve averecompleta cognizione di quali sono i suoi attributi. Se ora un altro oggetto effettua un’analoga ricerca anchequesto deve avere cognizione di tutti gli attributi del partecipante. E molto meglio ipotizzare che e lo stessooggetto partecipante che preleva dalla base di dati (dal result set) i valori dei suoi attributi. Analogamente,quando un oggetto deve essere salvato e meglio che sia esso stesso a scrivere nella base di dati i valori dei suoiattributi, in modo da evitare di distribuire ovunque la conoscenza (non necessaria) della sua struttura interna.Questo e il motivo per cui in Figura 41 i metodi per la persistenza sono stati messi entro gli oggetti del dominio.

L’architettura risultante per la mappatura manuale e invasiva e schematizzata in Figura 42 dove l’interfacciafornita da JDBC e indicata come sql. Ovviamente niente vieta che alla medesima interfaccia abbiano accessoanche gli oggetti applicativi, anche cio porta necessariamente alla loro modifica.

.

12.5 Mappatura manuale trasparente

Se vogliamo evitare di modificare gli oggetti del dominio occorre incapsulare a parte gli aspetti relativi allapersistenza. Cio si ottiene con il concetto di DAO (Data Access Object). Un DAO e semplicemente un oggettoche espone un’interfaccia per le operazioni legate alla persistenza, nascondendo i dettagli al suo interno.

Il ruolo del DAO e illustrato dalla Figura 43. Gli oggetti applicativi usano i DAO per ottenere gli oggettio per memorizzare gli oggetti. I DAO nascondono la sorgente dei dati e implementano tutte le funzionalitaper accedere alla base di dati e/o per costruire gli oggetti. C’e un DAO per ciascuna classe, il quale forniscemetodi come load(), store(), update(), ecc.. Forniranno anche metodi meno generali; ad esempio, il DAO dellaclasse Escursione potrebbe presentare il metodo getByPartecipante(Partecipante p) che restituisce la lista

36

Figura 42: La persistenza gestita in modo manuale e invasivo.

delle escursioni cui e iscritto p, oppure getByDate(Date d) che restituisce la lista delle escursioni alla data d.Ovviamente i DAO vengono programmati come sopra, ma nascondono agli oggetti applicativi gli aspetti legatialla gestione della persistenza ed evitano di sporcare i data objects.

La presenza dei DAO comporta (almeno per quanto riguarda le funzioni di ricerca, salvataggio, ecc.) qualchemodifica alle classi applicative che si avevano nel modello senza persistenza.

Figura 43: Uso dei DAO per la mappatura tra oggetti e contenuto della base di dati.

E interessante rilevare che con lo schema di Figura 43 gli oggetti applicativi hanno nei DAO l’interfaccia peraccedere agli oggetti del modello. Dunque l’oggetto Agenzia, che nel puro modello a oggetti aveva esattamentequesta funzione, diventa del tutto inutile e puo essere eliminato.

12.6 Framework ORM

Negli anni recenti, in considerazione dell’affermarsi della programmazione orientata agli oggetti e del consolidarsidel modello relazionale per i dati, sono cominciati ad apparire sistemi di mappatura che eliminano la necessitadi ricorrere alla programmazione in sql per DAO. Uno di questi sistemi e Hibernate. Si tratta di un sistema chegestisce in modo automatico la mappatura, appoggiandosi su “metadati” che descrivono oggetti e tabelle e leloro relazioni. I metadati sono raccolti in un file XML.

In Figura 44 viene data una schematizzazione dell’architettura risultante dall’impiego di Hibernate. Attraver-so l’interfaccia session (ovvero attraverso il concetto di sessione o transazione) gli oggetti applicativi chiedono

37

a Hibernate di prelevare/salvare/ecc. gli oggetti. Hibernate usa i metadati di mappatura per creare/salvare glioggetti. I data objects non sono in alcun modo “sporcati”.

Figura 44: Schematizzazione dell’impiego di Hibernate per la mappatura.

Hibernate ha un suo linguaggio per accedere alla base di dati, denominato HQL, che permette di inserireall’interno delle query anche le classi (cioe non solo stringe, interi, long, ecc. cone in SQL).

A titolo di esempio si riporta il seguente tratto di codice (che stara ovviamente entro un oggetto applicativo).All’inizio viene creata una sessione e avviata una transazione. Successivamente viene ricercato un partecipanteattraverso il suo “id”. A questo punto viene effettuata una query per avere tutte le escursioni la cui lista diiscritti contiene il partecipante p. Si noti che la stringa di query contiene il parametro :partecipante che,attraverso il metodo setEntity() viene sostituito con l’oggetto p all’atto della query.

Session session = sessionFactory.getsCurrentSession() ;

session.beginTransaction() ;

Partecipante p = session.load(Partecipante.class, id) ;

String queryStr = "from Escursione as e where :partecipante in elements(e.iscritti)";

Query query = session.createQuery(queryStr).setEntity("partecipante ", p );

Come si vede Hibernate scherma notevolmente rispetto alla base di dati. Se si vuole una completa schermatu-ra si puo ricorrere anche in questo caso ai DAO, secondo lo schema di Figura 45. Ovviamente, i DAO sono imple-mentati attraverso le funzionalita provviste da Hibernate, come quelle appena illustrate. Vorra dire che ci sara unDAO per la classe Escursione, dotato del metodo public List<Escursione> getByPartecipante(Partecipante

p); che sostanzialmente corrisponde al codice che abbiamo appena commentato.

38

Figura 45: Uso dei DAO a fronte di Hibernate. I DAO provvedono un’interfaccia standardizzata per gli usidegli oggetti applicativi e vengono implementati attraverso le funzionalita di Hibernate.

13 Appendice A

Illustriamo ora la realizzazione del sistema con riferimento al caso del puro sistema a oggetti (cioe senzapersistenza e con tutti gli oggetti in memoria) e senza interfaccia grafica.

Mancando l’interfaccia grafica, occorre simulare il comportamento di attore e interfaccia attraverso un pro-gramma, il programma principale che viene cosı anche ad assumere il ruolo di programma di test funzionalecomplessivo del sistema (senza interfaccia), nel senso che tale programma ha la funzione di esercitare il sistema,saltando il passaggio attraverso attraverso l’interfaccia. Chiameremo Simulatore la corrispondente classe esimulatoreAttore il package che la contiene (di esso faranno parte altre classi). La Figura 46 evidenzia il fattoche il Simulatore ha la funzione di esercitare il sistema. Si noti che tutto cio che si richiede e che il simulatoresi adegui alle interfacce delle classi applicative.

Figura 46: Uso di un programma di simulazione. Si noti che la classe Simulatore equivale a un programma ditest funzionale che esercita il sistema generando le chiamata ai metodi dell’applicazione.

Con riferimento a Eclipse, si avra dunque la struttura dei package di Figura 47. Si sono aggiunti il package

39

test per raccogliere le classi di test JUnit e il package common per le classi di uso comune (la sola classe Data).Inoltre, e stata prevista la classe Builder che serve a popolare con qualche elemento il modello, per evitare didoverlo fare solo tramite il simulatore.

Figura 47: Struttura dei package sotto Eclipse. Si noti che del package simulatoreAttore fa parte la classeBuilder con la quale viene inizialmente popolato il modello.

Le classi di Figura 47 vengono allegate a questo documento. Il lettore e invitato a consultarle. Per comoditariportiamo pezzi di codice.

40

13.1 Alcune parti del programma

13.1.1 Il package common

Il package common contiene la sola classe Data usata da piu parti. La classe Data qui sotto riportata non trattal’anno. Di norma, per la data o altre funzioni di carattere generale conviene servirsi delle librerie Java. Il codiceseguente serve soprattutto a illustrare la definizione dell’operazione di uguaglianza.

package common;

public class Data { // non si tiene conto dell’anno

public int mese;

public int giorno;

public Data(int giorno, int mese){

this.giorno = giorno;

this.mese = mese;

}

public boolean uguale(Data d){

if ((this.giorno == d.giorno ) & (this.mese == d.mese ) ) return true;

else return false;

}

public int getGiorno(){

return giorno;

}

public int getMese(){

return mese;

}

}

13.1.2 Il package modello

La classe Agenzia

package modello;

import java.util.ArrayList;

import java.util.Iterator;

import common.Data;

public class Agenzia {

ArrayList<Partecipante> partecipanti; //lista dei partecipanti

ArrayList<Escursione> escursioni;

/*

* SINGLETON

*/

private static Agenzia instance;

private Agenzia() {

}

public static Agenzia getInstance() {

if (null == instance) {

instance = new Agenzia();

instance.setEscursioni();

instance.setPartecipanti();

}

return instance;

}

/*

* Il metodo clear() ci vuole per eliminare l’agenzia quando si

* fa una test suite. Infatti, essendo l’agenzia un sigleton, dopo

41

* che e stata creata non viene cancellata dal tearDown degli

* unit test. Col risultato che l’esecuzione di uno unit test

* che da solo funziona puo dar luogo a malfunzionamento se

* esso prova a reistanziare il singleton, perche nel sistema

* resta quello di prima.

* Non e chiaro se questo comportamento di Junit e voluto o

* se e una sua deficienza.

*/

public void clear(){

instance = null;

}

private void setEscursioni() {

escursioni = new ArrayList<Escursione>();

}

private void setPartecipanti() {

partecipanti = new ArrayList<Partecipante>();

}

public ArrayList<Escursione> getEscursioni(){

return escursioni;

}

public ArrayList<Partecipante> getClienti() {

return partecipanti;

}

public Partecipante getCliente(String cF){

Iterator<Partecipante> ip = partecipanti.iterator();

while (ip.hasNext()){

Partecipante p = ip.next();

if (p.getCF()== cF) return p;

}

return null;

}

public void addEscursione(Escursione e){

escursioni.add(e);

}

public void addCliente(Partecipante p){// pe cf e controllare

partecipanti.add(p);

}

public Escursione getEscursione(Data d, String t){

// Assume che non ci siano due escursioni dello stesso

// tipo lo stesso giorno

Iterator<Escursione> it = escursioni.iterator();

while(it.hasNext()){

Escursione e= it.next();

if(e.getData().uguale(d) && e.getTipo()==t) return e;

}

System.out.println("L’escursione alla data " +d.giorno+"/"+

d.getMese()+ " non esiste!");

return null;

}

public void removeEsc(Escursione e){

Iterator<Escursione> it = escursioni.iterator();

while(it.hasNext()){

Escursione ex= it.next();

if(ex.uguale(e)) {

Iterator<Partecipante> ip = e.getPartecipanti().iterator();

while(ip.hasNext()){

ip.next().unlink(e);

42

}

it.remove();

return;

}

}

}

}

La classe Escursione

package modello;

import java.util.*;

import common.Data;

public class Escursione {

protected String tipo = ""; //GitaBarca, GitaCavallo, ..

protected int id;

protected double costo;

protected int MaxNpartec; //Numero massimo di partecipanti consentito

protected Data data;

protected ArrayList<TipoOptional> optional; //Optional possibili

protected ArrayList<Partecipante> partecipanti; //partecipanti iscritti

protected int nIscritti = 0; //numero partecipanti correntemente iscritti

//si poteva derivare esaminando Partecipante[]

public Escursione(Data d, String t){

if ((t != "Gita in barca") && (t!= "Gita a cavallo")){

System.out.println("\nTipo Escursione incognito: " +

"e stata creata un’escursione fasulla (Data=null e tipo vuoto).");

return;

}

data = d;

tipo = t;

if (tipo == "Gita in barca"){

MaxNpartec = 6;

costo = 10.;

}

else if (tipo == "Gita a cavallo"){

MaxNpartec = 4;

costo = 40.;

}

optional = new ArrayList<TipoOptional>();

partecipanti = new ArrayList<Partecipante>();

}

public boolean uguale(Escursione e){

if ((this.data == e.getData() ) & (this.tipo == e.getTipo() ) ) return true;

else return false;

}

public int getNIscritti() {

return nIscritti;

}

public double getCost(){

return costo;

}

public String getTipo(){

return tipo;

}

43

public Data getData(){

return data;

}

public ArrayList<Partecipante> getPartecipanti(){

return partecipanti;

}

public void setOptional(TipoOptional t){

if (optional.contains(t)){

System.out.println("Optional "+t.getTipo()+ " gia presente per l’escursione del "+

this.getData().getDay()+"/"+this.getData().getMese());

return;

}

optional.add(t);

}

public boolean hasOptional(TipoOptional o){

if (optional.contains(o)) return true;

else return false;

}

public void addPartecipante(Partecipante p){

Iterator<Partecipante> it = partecipanti.iterator();

while (it.hasNext()){

if (it.next().getCF() == p.getCF()){

System.out.println("Partecipante CF "+ p.getCF()+

" nome " + p.getNome()+" gia iscritto!");

return;

}

}

if (nIscritti < MaxNpartec){

partecipanti.add(p);

nIscritti++;

p.link2Escursione(this);

}

else {System.out.println("Escursione" + tipo + " del " +

data.giorno + "/" + data.mese + " completa. " + p.getNome()+ " non e stato iscritto");

}

}

public ArrayList<TipoOptional> getOptional(){

return optional;

}

public void removePartecipante(Partecipante p){

Iterator<Partecipante> ip = partecipanti.iterator();

while (ip.hasNext()){

Partecipante pp = ip.next();

if (pp.getCF()==p.getCF()) { //rimozione partec e sue scelte

Iterator<Scelta> is = p.getScelteTutte().iterator();

while (is.hasNext()){ //rimozione scelta

// dalle scelte per questa escursione

if (is.next().getEscursione() == this) is.remove();

}

ip.remove(); //rimozione partecipante dall’escursione

nIscritti--;

p.unlink(this);

return;

}

}

44

System.out.println("Il partecipante non esiste");

}

La classe TipoOptional

package modello;

public class TipoOptional { // realizzata il Singleton in tre versioni in base al tipo

String tipo;

double costo;

private static TipoOptional pranzo = null;

private static TipoOptional merenda = null;

private static TipoOptional visita = null;

private TipoOptional(String t){

tipo = t;

if (t== "Pranzo") costo = 5.;

else if (t== "Merenda") costo = 2.;

else if (t== "Visita") costo = 1.;

else System.out.println("Impossibile: le chiamate sono sotto!!");

}

public static TipoOptional getIstancePranzo(){

if(pranzo == null)

pranzo = new TipoOptional("Pranzo");

return pranzo;

}

public static TipoOptional getIstanceMerenda(){

if(merenda == null)

merenda = new TipoOptional("Merenda");

return merenda;

}

public static TipoOptional getIstanceVisita(){

if(visita == null)

visita = new TipoOptional("Visita");

return visita;

}

public String getTipo(){

return tipo;

}

public double getCost(){

return costo;

}

}

13.2 Il package simulatoreAttore

La classe Simulatore

Riportiamo solo un piccolo tratto.

package simulatoreAttore;

import applicazione.ClientManager;

import applicazione.EscManager;

import modello.*;

import common.*;

45

public class Simulatore {

/*

* Il Main simula l’Agente e il video

*/

public static void main(String[] args) {

Agenzia a;

ClientManager cM; //Il gestore dei partecipanti

EscManager eM; //il Manager Escursioni

Escursione e; //generica escursione

Partecipante p; //generico partecipante

a = Builder.build(); //inizializza come richiesto

//build() e un metodo statico

cM = ClientManager.getClientManager();

cM.setAgenzia(a);

eM = EscManager.getEscManager();

eM.setAgenzia(a);

System.out.println("Versione con Agenzia, EscManager e ClientManager Singleton \n");

System.out.println("================================================" +

"\nLista escursioni dopo inizializzazione");

eM.stampaListaEscursioni();

cM.stampaListaCompletaClienti();

System.out.println("================================================");

e = eM.getEscursione(new Data(5,7), "Gita in barca");

p = cM.getPartecipante("1" );

if (p==null) System.out.println("Main: Il partecipante con CF = 1 non esiste nel sistema" +

"\n=====================================");

Il lettore e invitato a esaminare il testo del Simulatore, del ClientManager e di Escmanager allegatocercando di capire quali azioni svolgono.

Peraltro scoprira che Builder ha un solo metodo statico che restituisce l’agenzia popolata con qualcheescursione, partecipante, ecc.. Non c’e bisogno di istanziare Builder, in quanto esso e una pura funzione. Perquesto basta un metodo statico. Nel caso specifico anche ClientManager e Escmanager sono pure funzioni equindi i loro metodi avrebbero potuto essere dichiarati statici, senza bisogno di istanziare mai le due classi.Se si guarda il relativo codice si scopre che queste due classi non hanno attributi interni che possono variare;dunque gli eventuali oggetti da esse istanziati non avrebbero un proprio stato interno. Poiche le due classi ciservono solo per implementare le funzionalita ad esse associate, si poteva fare a meno di istanziarle.

Riferimenti bibliografici

[1] IEEE. Ieee recommended practice for software requirements specifications. Technical report, 1998.

[2] D. Rosenberg and M. Stephens. Use Case Driven Object Modeling with UML - Theory and Practice. Apress,2007.

46