7 Progettazione della componente applicativa In questo capitolo illustreremo la progettazione della componente applicativa di un sistema informativo. La metodologia da noi utilizzata sarà basata sull utilizzo di UML. 7.1 Introduzione Per progettazione delle applicazioni si intende quella fase della progettazione di un sistema informativo che si occupa di progettare l insieme dei programmi ad esso associati. Trattandosi di progettazione di programmi, questa fase della progettazione di un sistema informativo non può che tenere fortemente in considerazione le metodologie e gli strumenti tipici dell Ingegneria del Software. In questo settore il meta-modello di riferimento è UML. UML, infatti, supporta in modo estremamente preciso e rigoroso sia la progettazione orientata agli oggetti che la progettazione basata sui componenti, che rappresentano le tecniche di programmazione di gran lunga più utilizzate attualmente nel contesto della produzione del software. Utilizzando UML come meta-modello di riferimento, la progettazione delle applicazioni di un sistema informativo consiste nei seguenti passi: Definizione del diagramma delle classi: a partire dalla progettazione dei dati, dall analisi dei requisiti funzionali del sistema e dall analisi dei casi d uso si costruisce un diagramma delle classi e, per ciascuna classe, si determinano gli attributi, i metodi get e set nonchè i metodi specifici. Progettazione delle funzionalità e raffinamento delle classi: per ciascuna funzionalità individuata durante l analisi dei requisiti si procede con la sua progettazione utilizzando il diagramma di sequenza di UML. Nel fare ciò probabilmente si individueranno delle modifiche da fare alle classi precedentemente progettate; pertanto si dovrà procedere con un raffinamento delle stesse. Questi passi verranno illustrati in dettaglio nelle prossime sezioni. 7.2 Definizione del diagramma delle classi Durante questo passo viene costruita una prima bozza di diagramma delle classi per il sistema di interesse; questa bozza verrà successivamente raffinata durante il secondo passo. In realtà, per i nostri scopi, non ci serve definire un vero e proprio diagramma delle classi, bensì la struttura delle singole classi che accedono al database. Inoltre, essendo questa un attività di progettazione ad alto livello di astrazione, non ci serve definire i parametri dei vari metodi progettati. Un secondo livello, più dettagliato, di progettazione, che comprenda, tra l altro, le attività di cui sopra diventa necessario prima di avviare le attività di implementazione. Questo, però, esula dagli scopi del corso. Le classi da progettare in questo passo sono almeno una per ogni tabella. Ciascuna di queste classi avrà almeno un attributo, un metodo set e un metodo get per ogni attributo della corrispondente tabella. Essa avrà, inoltre, un metodo dbinserisci, un metodo dbrimuovi e un metodo dbmodifica,
136 7 Progettazione della componente applicativa per gestire, rispettivamente, gli inserimenti, le rimozioni e le modifiche nella corrispondente tabella. Essa avrà, infine, un metodo statico dbricerca, per effettuare le ricerche di tuple nella corrispondente tabella. Chiaramente, in questo momento, stiamo considerando una progettazione ad alto livello di astrazione per cui non ci preoccupiamo dei parametri e delle problematiche più implementative. Ad esempio, è probabile che, raffinando questa progettazione, saranno necessari più metodi di ricerca, uno per ogni chiave di ricerca che si vuole consentire. Analogamente, è probabile che dbinserisci, in una progettazione più dettagliata, venga esploso in più metodi di inserimento. Questo tipo di analisi, però, esula dagli scopi del presente corso. Oltre alle classi corrispondenti alle tabelle, è buona abitudine progettare un ulteriore classe DBConnection che si occupa della gestione, della connessione e dell interrogazione al database sottostante. Tale classe dovrà avere almeno i seguenti attributi: connection, per gestire i dettagli della connessione; dbdriver, per specificare il driver utilizzato per la connessione (ad esempio, JDBC); dburl, per specificare l URL del database a cui connettersi; username, per specificare, sul database, lo username dell utente che si sta connettendo; password, per specificare, sul database, la password dell utente che si sta connettendo. e almeno i seguenti metodi: getproperties, per conoscere gli attributi associati alla connessione corrente; setconnection, per effettuare il setting degli attributi associati alla connessione corrente; startconnection, per aprire una connessione; executequeryselect, per effettuare query di ricerca sul database a cui ci si è connessi; executequeryupdate, per effettuare query di inserimento, rimozione e modifica sul database a cui ci si è connessi; stopconnection, per chiudere una connessione. In pratica, DBConnection ha lo scopo di fare da ponte tra il modello relazionale (tipico dei database) e il paradigma orientato agli oggetti (tipico della programmazione). Questa attività prende il nome di Object Relational Mapping e, nei grossi sistemi software, viene realizzata con strumenti ad hoc, quali Hibernate. 7.2.1 Esercizi Esercizio Si effettui la progettazione delle classi per il sistema informativo per la gestione di un hotel descritto in dettaglio nella Sezione 5.9.1. Esercizio Si effettui la progettazione delle classi del sistema informativo per la gestione di un agenzia immobiliare descritto in dettaglio nella Sezione 5.9.2. 7.2.2 Soluzione all esercizio della Sezione 7.2.1 Applicando le regole menzionate in precedenza, è possibile definire le classi associate a ciascuna tabella per il sistema di riferimento. Esse sono visualizzate nelle Figure 7.1-7.10. 7.3 Progettazione delle funzionalità e raffinamento delle classi Durante questo passo vengono ripresi tutti i casi d uso definiti durante la specifica e l analisi dei requisiti e, per ciascuno di essi, si costruisce il corrispettivo diagramma di sequenza in modo da individuare come lo stesso debba essere implementato.
7.3 Progettazione delle funzionalità e raffinamento delle classi 137 Figura 7.1. Una prima bozza della classe associata alla tabella PERSONA FISICA Il diagramma di sequenza è il diagramma che meglio evidenzia la filosofia della programmazione orientata agli oggetti in quanto rappresenta il modo con cui le varie classi e gli utenti coinvolti in un caso d uso comunicano per portarlo al termine. Nel costruire i vari diagrammi di sequenza si scoprirà che, probabilmente, servono nuovi metodi che in precedenza non erano stati definiti. Questo porterà ad un raffinamento delle classi costruite al passo precedente. Anche per questa attività ci fermeremo, comunque, ad un alto livello di astrazione non studiando in dettaglio i parametri dei metodi coinvolti e altre problematiche affini. In realtà, anche alla luce di quanto detto sopra, è superfluo considerare i diagrammi di sequenza per quei casi d uso che coinvolgono una sola classe e che non richiedono elaborazioni sui dati; generalmente questi casi d uso coincidono con i casi d uso CRUD. Essi, quindi, non saranno definiti. Al termine di questo passo, che coincide con la fine della progettazione delle applicazioni, si avranno: i diagrammi di sequenza per tutti i casi d uso che coinvolgono più di una classe; la struttura raffinata, con tutti gli attributi e tutti i metodi, di ogni classe associata ad una tabella dello schema relazionale.
138 7 Progettazione della componente applicativa Figura 7.2. Una prima bozza della classe associata alla tabella AGENZIA 7.3.1 Esercizi Esercizio Si effettuino la progettazione delle funzionalità e il raffinamento delle classi per il sistema informativo per la gestione di un hotel descritto in dettaglio nella Sezione 5.9.1. Esercizio Si effettuino la progettazione delle funzionalità e il raffinamento delle classi per il sistema informativo per la gestione di un agenzia immobiliare descritto in dettaglio nella Sezione 5.9.2. 7.3.2 Soluzione all esercizio della Sezione 7.3.1 Esaminando i casi d uso definiti nella Sezione 5.9.3 possiamo notare come i casi d uso CRUDAgenzia, CRUDPersonaFisica, CUDStanza, RicercaInfoStanza, CUDServizioExtra, RicercaInfoServizioExtra e CRUDDocumentoFiscale coinvolgono una sola classe e non richiedono elaborazioni sui dati. Pertanto, per questi casi d uso, non sarà necessario costruire i corrispettivi diagrammi di sequenza. Il diagramma di sequenza relativo al caso d uso InserisciPrenotazione è riportato in Figura 7.11. Dall esame di questo diagramma si evince che è necessario aggiungere i seguenti metodi alla bozza della classe definita in precedenza:
7.3 Progettazione delle funzionalità e raffinamento delle classi 139 Figura 7.3. Una prima bozza della classe associata alla tabella PRENOTAZIONE Figura 7.4. Una prima bozza della classe associata alla tabella STANZA
140 7 Progettazione della componente applicativa Figura 7.5. Una prima bozza della classe associata alla tabella ASSEGNAMENTO Figura 7.6. Una prima bozza della classe associata alla tabella FRUIZIONE
7.3 Progettazione delle funzionalità e raffinamento delle classi 141 Figura 7.7. Una prima bozza della classe associata alla tabella SERVIZIO EXTRA Figura 7.8. Una prima bozza della classe associata alla tabella ASSOCIATO Figura 7.9. Una prima bozza della classe associata alla tabella DOCUMENTO FISCALE
142 7 Progettazione della componente applicativa Figura 7.10. La classe DBConnection verificadisponibilita alla classe Prenotazione; setinfoprenotazione alla classe Prenotazione; addebitoprenotazione alla classe Prenotazione; getinfopersonafisica alla classe PersonaFisica; setinfopersonafisica alla classe PersonaFisica; getinfoagenzia alla classe Agenzia; setinfoagenzia alla classe Agenzia; getinfostanza alla classe Stanza. Il diagramma di sequenza relativo al caso d uso RicercaPrenotazione è riportato in Figura 7.12. Dall esame di questo diagramma si evince che è necessario aggiungere i seguenti metodi alla bozza della classe definita in precedenza: richiestainfoprenotazione alla classe Prenotazione; getinfoprenotazione alla classe Prenotazione; assemblainfoprenotazione alla classe Prenotazione Il diagramma di sequenza relativo al caso d uso ModificaPrenotazione è riportato in Figura 7.13. Dall esame di questo diagramma si evince che è necessario aggiungere il seguente metodo alla bozza della classe definita in precedenza: richiestamodificaprenotazione alla classe Prenotazione. Il diagramma di sequenza relativo al caso d uso InserisciAssegnamento è riportato in Figura 7.11. Dall esame di questo diagramma si evince che è necessario aggiungere i seguenti metodi alla bozza della classe definita in precedenza: richiestaassegnamento alla classe Assegnamento; setinfoassegnamento alla classe Assegnamento; stampaschedanotifica alla classe Assegnamento. Il diagramma di sequenza relativo al caso d uso RicercaAssegnamento è riportato in Figura 7.15. Dall esame di questo diagramma si evince che è necessario aggiungere i seguenti metodi alla bozza della classe definita in precedenza: richiestainfoassegnamento alla classe Assegnamento; getinfoassegnamento alla classe Assegnamento; assemblainfoassegnamento alla classe Assegnamento. Il diagramma di sequenza relativo al caso d uso ModificaAssegnamento è riportato in Figura 7.16. Dall esame di questo diagramma si evince che è necessario aggiungere il seguente metodo alla bozza della classe definita in precedenza: richiestamodificaassegnamento alla classe Assegnamento.
7.3 Progettazione delle funzionalità e raffinamento delle classi 143 Figura 7.11. Il diagramma di sequenza relativo al caso d uso InserisciPrenotazione Il diagramma di sequenza relativo al caso d uso DisdettaPrenotazione è riportato in Figura 7.17. Dall esame di questo diagramma si evince che è necessario aggiungere i seguenti metodi alla bozza della classe definita in precedenza: richiestadisdettaprenotazione alla classe Prenotazione; stampadocumentofiscale alla classe Prenotazione. Il diagramma di sequenza relativo al caso d uso FruizioneServizioExtra è riportato in Figura 7.18. Dall esame di questo diagramma si evince che è necessario aggiungere i seguenti metodi alla bozza della classe definita in precedenza: richiestaaddebitoservextra alla classe FruizioneServExtra; getinfoservextra alla classe ServizioExtra; AddebitoFruizioneServExtra alla classe FruizioneServExtra; StampaDocumentoFiscale alla classe FruizioneServExtra.
144 7 Progettazione della componente applicativa Figura 7.12. Il diagramma di sequenza relativo al caso d uso RicercaPrenotazione Il diagramma di sequenza relativo al caso d uso CheckOut è riportato in Figura 7.19. Dall esame di questo diagramma si evince che è necessario aggiungere i seguenti metodi alla bozza della classe definita in precedenza: richiestacheckout alla classe Assegnamento; getinfofruizioneservextra alla classe FruizioneServExtra. Il diagramma di sequenza relativo al caso d uso GestoreStatistiche è riportato in Figura 7.20. Dall esame di questo diagramma si evince che è necessario realizzare una nuova classe, denominata GestoreStatistiche. Questa classe avrà come attributi tutti quelli necessari per memorizzare i dati parziali relativi alle statistiche nonchè i corrispettivi metodi set e get; tutte queste informazioni si potranno reperire quando si passerà ad una progettazione ad un più basso livello di astrazione. In aggiunta, la classe possiederà almeno i seguenti metodi: RichiestaStatistiche; AssemblaDatiAgenzia; AssemblaDatiAssegnamento; AssemblaDatiAssociato; AssemblaDatiDocumentoFiscale; AssemblaDatiFruizioneServExtra; AssemblaDatiPersonaFisica; AssemblaDatiPrenotazione; AssemblaDatiServizioExtra; AssemblaDatiStanza. Chiaramente, se si desiderano delle statistiche più complesse, ad esempio statistiche che mettono insieme dati provenienti da più tabelle, sarà necessario aggiungere ulteriori metodi a questa classe. A questo punto siamo in grado di procedere alla progettazione delle classi raffinate; basterà, infatti, aggiungere alla classi precedentemente progettate i metodi individuati durante la progettazione
7.3 Progettazione delle funzionalità e raffinamento delle classi 145 Figura 7.13. Il diagramma di sequenza relativo al caso d uso ModificaPrenotazione dei diagrammi di sequenza; si dovrà, inoltre, aggiungere una classe GestoreStatistiche. Le classi raffinate sono visualizzate nelle Figure 7.21-7.29 (nelle figure non sono presenti le classi Associato e DBConnection in quanto queste non sono state modificate in alcun modo).
146 7 Progettazione della componente applicativa Figura 7.14. Il diagramma di sequenza relativo al caso d uso InserisciAssegnamento Figura 7.15. Il diagramma di sequenza relativo al caso d uso RicercaAssegnamento
7.3 Progettazione delle funzionalità e raffinamento delle classi 147 Figura 7.16. Il diagramma di sequenza relativo al caso d uso ModificaAssegnamento
148 7 Progettazione della componente applicativa Figura 7.17. Il diagramma di sequenza relativo al caso d uso DisdettaPrenotazione
7.3 Progettazione delle funzionalità e raffinamento delle classi 149 Figura 7.18. Il diagramma di sequenza relativo al caso d uso FruizioneServExtra Figura 7.19. Il diagramma di sequenza relativo al caso d uso CheckOut
150 7 Progettazione della componente applicativa Figura 7.20. Il diagramma di sequenza relativo al caso d uso GestoreStatistiche Figura 7.21. La classe PersonaFisica raffinata
7.3 Progettazione delle funzionalità e raffinamento delle classi 151 Figura 7.22. La classe Agenzia raffinata
152 7 Progettazione della componente applicativa Figura 7.23. La classe Prenotazione raffinata
7.3 Progettazione delle funzionalità e raffinamento delle classi 153 Figura 7.24. La classe Stanza raffinata Figura 7.25. La classe Assegnamento raffinata
154 7 Progettazione della componente applicativa Figura 7.26. La classe Fruizione raffinata Figura 7.27. La classe ServizioExtra raffinata
7.3 Progettazione delle funzionalità e raffinamento delle classi 155 Figura 7.28. La classe DocumentoFiscale raffinata Figura 7.29. La classe GestoreStatistiche