Progettazione della componente applicativa

(1)

7 Progettazione della componente applicativa

In questo capitolo illustreremo la progettazione della componente applicativa di un sistema informativo.

La metodologia da noi utilizzata sar`a basata sull’utilizzo di UML.

7.1 Introduzione

Per progettazione delle applicazioni si intendequella 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`o che tenere fortemente in considerazione le metodologie e gli strumenti tipici dell’Ingegneria del Software.

In questo settore il meta-modello di riferimento `e UML. UML, infatti, supporta in modo estrema- mente 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`u 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`e 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`a successivamente raffinata durante il secondo passo.

In realt`a, 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`a 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`a almeno un attributo, un metodo set e un metodo get per ogni attributo della corrispondente tabella. Essa avr`a, inoltre, un metodo dbInserisci, un metodo dbRimuovi e un metodo dbModifica,

(2)

• 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 `e connessi;

• executeQueryUpdate, per effettuare query di inserimento, rimozione e modifica sul database a cui ci si `e 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`a 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, `e 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` a 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.

(3)

7.3 Progettazione delle funzionalit`a e raffinamento delle classi 137

Figura 7.1.Una prima bozza della classe associata alla tabella PERSONA FISICA

Il diagramma di sequenza `e 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`a che, probabilmente, servono nuovi metodi che in precedenza non erano stati definiti. Questo porter`a ad un raffinamento delle classi costruite al passo precedente.

Anche per questa attivit`a ci fermeremo, comunque, ad un alto livello di astrazione non studiando in dettaglio i parametri dei metodi coinvolti e altre problematiche affini.

In realt`a, anche alla luce di quanto detto sopra, `e 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`u di una classe;

• la struttura raffinata, con tutti gli attributi e tutti i metodi, di ogni classe associata ad una tabella dello schema relazionale.

(4)

Figura 7.2.Una prima bozza della classe associata alla tabella AGENZIA

7.3.1 Esercizi Esercizio

Si effettuino la progettazione delle funzionalit`a 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`a 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 CRUDDocumentoFiscalecoinvolgono una sola classe e non richiedono elaborazioni sui dati. Pertanto, per questi casi d’uso, non sar`a necessario costruire i corrispettivi diagrammi di sequenza.

Il diagramma di sequenza relativo al caso d’uso InserisciPrenotazione `e riportato in Figura 7.11.

Dall’esame di questo diagramma si evince che `e necessario aggiungere i seguenti metodi alla bozza della classe definita in precedenza:

(5)

Figura 7.3.Una prima bozza della classe associata alla tabella PRENOTAZIONE

Figura 7.4.Una prima bozza della classe associata alla tabella STANZA

(6)

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)

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

(8)

Figura 7.10. La classe DBConnection

• verificaDisponibilitaalla classe Prenotazione;

• setInfoPrenotazionealla classe Prenotazione;

• addebitoPrenotazionealla classe Prenotazione;

• getInfoPersonaFisicaalla classe PersonaFisica;

• setInfoPersonaFisicaalla classe PersonaFisica;

• getInfoAgenziaalla classe Agenzia;

• setInfoAgenziaalla classe Agenzia;

• getInfoStanzaalla classe Stanza.

Il diagramma di sequenza relativo al caso d’uso RicercaPrenotazione `e riportato in Figura 7.12.

• richiestaInfoPrenotazionealla classe Prenotazione;

• getInfoPrenotazionealla classe Prenotazione;

• assemblaInfoPrenotazionealla classe Prenotazione

Il diagramma di sequenza relativo al caso d’uso ModificaPrenotazione `e riportato in Figura 7.13.

Dall’esame di questo diagramma si evince che `e necessario aggiungere il seguente metodo alla bozza della classe definita in precedenza:

• richiestaModificaPrenotazionealla classe Prenotazione.

Il diagramma di sequenza relativo al caso d’uso InserisciAssegnamento `e riportato in Figura 7.11.

• richiestaAssegnamentoalla classe Assegnamento;

• setInfoAssegnamentoalla classe Assegnamento;

• stampaSchedaNotificaalla classe Assegnamento.

Il diagramma di sequenza relativo al caso d’uso RicercaAssegnamento `e riportato in Figura 7.15.

• richiestaInfoAssegnamentoalla classe Assegnamento;

• getInfoAssegnamentoalla classe Assegnamento;

• assemblaInfoAssegnamentoalla classe Assegnamento.

Il diagramma di sequenza relativo al caso d’uso ModificaAssegnamento `e riportato in Figura 7.16.

Dall’esame di questo diagramma si evince che `e necessario aggiungere il seguente metodo alla bozza della classe definita in precedenza:

• richiestaModificaAssegnamentoalla classe Assegnamento.

(9)

Figura 7.11. Il diagramma di sequenza relativo al caso d’uso InserisciPrenotazione

Il diagramma di sequenza relativo al caso d’uso DisdettaPrenotazione `e riportato in Figura 7.17.

• richiestaDisdettaPrenotazionealla classe Prenotazione;

• stampaDocumentoFiscalealla classe Prenotazione.

Il diagramma di sequenza relativo al caso d’uso FruizioneServizioExtra `e riportato in Figura 7.18.

• richiestaAddebitoServExtraalla classe FruizioneServExtra;

• getInfoServExtraalla classe ServizioExtra;

• AddebitoFruizioneServExtraalla classe FruizioneServExtra;

• StampaDocumentoFiscalealla classe FruizioneServExtra.

(10)

Figura 7.12. Il diagramma di sequenza relativo al caso d’uso RicercaPrenotazione

Il diagramma di sequenza relativo al caso d’uso CheckOut `e riportato in Figura 7.19.

• richiestaCheckOutalla classe Assegnamento;

• getInfoFruizioneServExtraalla classe FruizioneServExtra.

Il diagramma di sequenza relativo al caso d’uso GestoreStatistiche `e 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`a, infatti, aggiungere alla classi precedentemente progettate i metodi individuati durante la progettazione

(11)

Figura 7.13.Il diagramma di sequenza relativo al caso d’uso ModificaPrenotazione

dei diagrammi di sequenza; si dovr`a, 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).

(12)

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

(13)

Figura 7.16.Il diagramma di sequenza relativo al caso d’uso ModificaAssegnamento

(14)

Figura 7.17.Il diagramma di sequenza relativo al caso d’uso DisdettaPrenotazione

(15)

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

(16)

Figura 7.20.Il diagramma di sequenza relativo al caso d’uso GestoreStatistiche

Figura 7.21.La classe PersonaFisica raffinata

(17)

Figura 7.22. La classe Agenzia raffinata

(18)

Figura 7.23. La classe Prenotazione raffinata

(19)

Figura 7.24. La classe Stanza raffinata

Figura 7.25. La classe Assegnamento raffinata

(20)

Figura 7.26. La classe Fruizione raffinata

Figura 7.27.La classe ServizioExtra raffinata

(21)

Figura 7.28. La classe DocumentoFiscale raffinata

Figura 7.29. La classe GestoreStatistiche