sviluppo di un’applicazione enterprise per la gestione di...
TRANSCRIPT
UNIVERSITA DEGLI STUDI DI FIRENZEFacolta di Ingegneria -
Tesi di laurea in Ingegneria Informatica
Sviluppo di un’ApplicazioneEnterprise per la Gestione di
Elettrodomestici
CandidatoLuca Del Tongo
RelatoreProf. Pietro Pala
Tutor AziendaleFrancesco Del Tongo
Anno Accademico 2005-2006
Indice
Introduzione v
1 Analisi dei Requisiti 11.1 Descrizione dell’applicativo . . . . . . . . . . . . . . . . . . . . 21.2 Descrizione del sistema . . . . . . . . . . . . . . . . . . . . . . 21.3 Requisiti funzionali . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3.1 Attori . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3.2 Specifiche sui dati . . . . . . . . . . . . . . . . . . . . . 51.3.3 Specifiche sulle operazioni . . . . . . . . . . . . . . . . 51.3.4 Specifiche Sistema di Archiviazione . . . . . . . . . . . 61.3.5 Business Rules . . . . . . . . . . . . . . . . . . . . . . 71.3.6 Glossario dei termini . . . . . . . . . . . . . . . . . . . 9
2 Progettazione della Base Dati 102.1 Progettazione Concettuale . . . . . . . . . . . . . . . . . . . . 10
2.1.1 Possibili Strategie di Progetto . . . . . . . . . . . . . . 102.1.2 Strategia Adottata . . . . . . . . . . . . . . . . . . . . 112.1.3 Requisiti di Qualita . . . . . . . . . . . . . . . . . . . . 15
2.2 Progettazione Logica . . . . . . . . . . . . . . . . . . . . . . . 152.2.1 Ristrutturazione Schema E-R . . . . . . . . . . . . . . 152.2.2 Traduzione Modello Relazionale . . . . . . . . . . . . . 192.2.3 Creazione Base Dati e Ricerca Indici . . . . . . . . . . 202.2.4 Funzioni di BackUp e Ripristino Informazioni . . . . . 21
3 Progettazione e Implementazione Software 233.1 Strumenti Utilizzati . . . . . . . . . . . . . . . . . . . . . . . . 233.2 Definizione Architettura . . . . . . . . . . . . . . . . . . . . . 243.3 Progettazione Domain Model . . . . . . . . . . . . . . . . . . 273.4 Business Logic Layer (BLL) . . . . . . . . . . . . . . . . . . . 303.5 Data Access Layer (DAL) . . . . . . . . . . . . . . . . . . . . 34
3.5.1 Implementazione . . . . . . . . . . . . . . . . . . . . . 35
i
INDICE ii
4 Testing dell’Applicativo ed Esempi d’Uso 424.1 Unit Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.2 Code Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . 444.3 Esempi d’Uso . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.1 Visualizzazione elettrodomestici della stessa categoria . 484.3.2 Inserimento Fornitore . . . . . . . . . . . . . . . . . . 50
5 Conclusioni e Possibili Sviluppi 53
6 Appendice A : Design Pattern 556.1 Pattern Gof . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
6.1.1 Abstract Factory . . . . . . . . . . . . . . . . . . . . . 566.1.2 Factory Method . . . . . . . . . . . . . . . . . . . . . . 576.1.3 Singleton . . . . . . . . . . . . . . . . . . . . . . . . . 57
6.2 Enterprise Pattern . . . . . . . . . . . . . . . . . . . . . . . . 586.2.1 Domain Model . . . . . . . . . . . . . . . . . . . . . . 586.2.2 Data Mapper . . . . . . . . . . . . . . . . . . . . . . . 596.2.3 Service Layer . . . . . . . . . . . . . . . . . . . . . . . 616.2.4 Special Case . . . . . . . . . . . . . . . . . . . . . . . . 62
Bibliografia 63
Elenco delle figure
1.1 Diagramma degli attori . . . . . . . . . . . . . . . . . . . . . . 31.2 Use Case Diagram Utente Generico . . . . . . . . . . . . . . . 41.3 Use Case Diagram Terminalista . . . . . . . . . . . . . . . . 4
2.1 Prima approccio e successivo raffinamento del modelloConcettuale . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2 Modello Concettuale Entita Relazione . . . . . . . . . . . . . 142.3 Diagramma ER Ristrutturato . . . . . . . . . . . . . . . . . 182.4 Vista Fisica Diagramma ER . . . . . . . . . . . . . . . . . . 21
3.1 Architettura three layer . . . . . . . . . . . . . . . . . . . . . 253.2 Architettura three layer con Service Layer . . . . . . . . . . . 273.3 Primo Approccio Domain Model . . . . . . . . . . . . . . . . 283.4 Ridefinizione Domain Model . . . . . . . . . . . . . . . . . . 293.5 Ripartizione della logica di business . . . . . . . . . . . . . . 303.6 Business Logic Layer . . . . . . . . . . . . . . . . . . . . . . 323.7 Sequence Diagram relativo alla lettura degli Elettrodomestici 333.8 Primo Approccio Data Layer . . . . . . . . . . . . . . . . . . 363.9 Data Layer Abstract Factory . . . . . . . . . . . . . . . . . . 373.10 Strato accesso ai dati Generico e relativo strato concreto per
SQLServer . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1 Grafico di Kiviat . . . . . . . . . . . . . . . . . . . . . . . . . 454.2 Screenshot Finestra Principale Applicazione . . . . . . . . . 464.3 Particolare del sottomenu Elettrodomestici come visualizzato
dal terminalista . . . . . . . . . . . . . . . . . . . . . . . . . 474.4 Particolare del sottomenu Fornitori come visualizzato dal
terminalista . . . . . . . . . . . . . . . . . . . . . . . . . . . 474.5 Screenshot Finestra Ricerca Elettrodomestici . . . . . . . . . 484.6 Screenshot Finestra Selezione Categoria di Elettrodomestico . 494.7 Screenshot Finestra Ricerca Elettrodomestici, Categoria
Accessorio . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
iii
ELENCO DELLE FIGURE iv
4.8 Screenshot Finestra Gestione Fornitori . . . . . . . . . . . . 514.9 Screenshot Pulsante Inserimento Fornitori . . . . . . . . . . 514.10 Screenshot Finestra Inserimento Fornitori . . . . . . . . . . 524.11 Screenshot Pulsante Salvataggio Fornitori . . . . . . . . . . . 52
6.1 Pattern Abstract Factory . . . . . . . . . . . . . . . . . . . . 566.2 Pattern Factory Method . . . . . . . . . . . . . . . . . . . . . 576.3 Pattern Singleton . . . . . . . . . . . . . . . . . . . . . . . . 586.4 Pattern Domain Model . . . . . . . . . . . . . . . . . . . . . 596.5 Pattern Data Mapper . . . . . . . . . . . . . . . . . . . . . . 606.6 Pattern Service Layer . . . . . . . . . . . . . . . . . . . . . . 616.7 Pattern Special Case . . . . . . . . . . . . . . . . . . . . . . . 62
Introduzione
Il Gruppo Del Tongo e una delle piu autorevoli aziende italiane nellaproduzione di cucine. Nato nel 1954 da una matrice artigianale, il Gruppotoscano si e sviluppato nell’arco di mezzo secolo assumendo una strutturaindustriale dotata di una forte carica innovativa: i significativi investimentinell’industrializzazione delle fasi di lavorazione comportano infatti l’utilizzodi tecnologie d’avanguardia, assicurando un elevato livello qualitativo. L’elevato grado di personalizzazione che la Del Tongo offre nella composizionedelle cucine si rispecchia nel notevole aumento della quantita di modelli dielettrodomestici a disposizione del cliente. E’ emersa quindi la necessitadi una gestione informatica delle informazioni degli elettrodomestici chepermetta sia la disponibilita costante delle informazioni per il personaleinterno dell’azienda sia la creazione automatica di un listino contenentegli ultimi modelli di elettrodomestici disponibili per il cliente. Il presenteprogetto di tesi, maturato da queste necessita aziendali, ha quindi comeobiettivo lo sviluppo di un’ applicazione che permetta una gestione efficace edefficiente delle informazioni relative ai modelli di elettrodomestici componentile cucine Del Tongo.
Nella prima parte verranno analizzate le specifiche sui dati e quellesulle operazioni, che sono emerse dall’analisi dei requisiti effettuata incollaborazione con il personale della ditta. Il secondo capitolo illustrainizialmente la fase di progettazione concettuale del Database conclusasi conla definizione di uno schema ER. Successivamente e stata avviata la fasedi design Object Oriented ponendo l’accento sui pattern che meglio hannosoddisfatto le specifiche di analisi. Nel terzo capitolo vengono presentati glistrumenti che il framework .NET mette a disposizione del programmatorenell’implementazione dell’applicazione di interesse. Il quarto espone lemetodologie di testing adottate nella valutazione della correttezza e dellaqualita dell’applicazione. Nel quinto ed ultimo capitolo verranno presentatele conclusioni e i possibili sviluppi della soluzione software sviluppata. Perfornire al lettore una migliore comprensione del seguente documento e statafornita un’ appendice che prende in rassegna i design pattern utilizzati.
v
Capitolo 1
Analisi dei Requisiti
In questo primo capitolo viene descritta l’attivita di analisi dei requisitinecessaria alla realizzazione di un sistema informativo per la gestione diun archivio di elettrodomestici; l’attivita di analisi, il cui scopo e stabilirecosa il sistema debba fare, rappresenta una delle prime fasi nel ciclo divita di un prodotto software. Le specifiche ottenute come risultato diquest’attivita, permettono di determinare la tecnologia e l’architettura delsistema, stimando sia i tempi che i costi di un’effettiva realizzazione; sonoinoltre sufficienti a ridurre i rischi d’errore derivati da incomprensioni qualiquelle legate alla modalita di impiego di una particolare tecnologia o quelledirettamente collegate al dominio applicativo.
Caratteristica fondamentale che contraddistingue l’attivita di analisi deirequisiti, risulta essere la stretta interazione che viene a crearsi fra l’analistae le varie figure aziendali, tra le quali spiccano:
• Un responsabile di settore in grado di fornire una buona visione diinsieme della societa e della relativa attivita economica.
• Un rappresentante degli utenti del sistema informativo con il qualedettagliare le procedure da eseguire.
• Un esperto del dominio a conoscenza delle business rules caratteristichedell’applicativo.
• Un’amministratore della base dati a conoscenza delle politiche disicurezza e backup del sistema di archiviazione.
1
CAPITOLO 1. ANALISI DEI REQUISITI
1.1 Descrizione dell’applicativo
Il sistema realizzato ha come obiettivo primario la gestione di un archivio dielettrodomestici. I modelli di elettrodomestici vengono classificati in diversecategorie in base al tipo di elettrodomestico che rappresentano (piano cottura,forno, frigo, lavatrice, etc). Gli elettrodomestici vengono acquistati daifornitori di cui si vuole tenere traccia oltre che del nome anche dei particolariaumenti e sconti consigliati. Di particolare importanza e la necessita di teneretraccia delle modifiche e aggiornamenti di ogni modello di elettrodomesticomantenendo cosı per ognuno di essi uno storico.
1.2 Descrizione del sistema
Il sistema software da realizzare utilizza hardware standard svolgendoattivita di archiviazione, elaborazione e supporto alla consultazione delleinformazioni principalmente in modalita interattiva. E’ ovviamente ritenutaindispensabile la conformita alle specifiche della rete elettrica italiana ealla norme relative all’emissione di onde elettromagnetiche, sia per quantoriguarda l’interferenza che gli effetti sulla salute. Il sistema deve poteressere utilizzato da terminalisti mediante periferiche di data-entry e videoconsultazione d’uso corrente (mouse, tastiera, video e stampante). L’utilizzodel sistema deve essere possibile da terminalisti dislocati in diverse postazionicollocate all’interno dell’azienda. Ulteriori caratteristiche desiderabili delsistema emergono dalle prospettive di future evoluzioni in cui si prevedal’suo dell’applicativo come WebService all’interno di un portale esistente dinome ProgettoPartner (vedi cap.5).
1.3 Requisiti funzionali
Per descrivere i requisiti funzionali e stato scelto di usare il linguaggio dimodellazione UML (Unified Modeling Language), in particolare i diagrammiUse Case in modalita grafica. Gli Use Case si pongono l’obiettivo dideterminare i futuri utenti del Sistema detti Attori e, per ogni attore,individuare gli obiettivi che intende raggiungere con l’uso del sistema. Perogni singolo obiettivo viene dettagliata l’interazione con l’attore (cioe uncaso d’uso che e proprio un singolo Use Case). Gli Use Case permettonodi delineare il sistema, ossia individuarne i confini e dettagliarne i compiti;inoltre possono essere utilizzati per progettare i test e per realizzare lamanualistica utente. Nella descrizione grafica di Use Case e possibile scegliereuna rappresentazione semplificata ed una estesa, a seconda del livello di
2
CAPITOLO 1. ANALISI DEI REQUISITI
familiarita con i Use Case del cliente. Nei diagrammi seguenti e statautilizzata la rappresentazione estesa che comprende i costrutti di Includeed Extend oltre all’Ereditarieta di Use Case e Attori.
1.3.1 Attori
UTENTE GENERICO TERMINALISTA
Figura 1.1. Diagramma degli attori
Attore Utente Generico: Rappresenta un generico utente da cui tutti glialtri attori sono derivati. Gli altri attori ereditano da questo attore gliobiettivi (cioe casi d’uso definiti in seguito) e gli attributi.
Attore Terminalista: E l’utente incaricato del data-entry; eseguel’inserimento, la modifica e la cancellazione degli elettrodomestici, deifornitori e delle categorie di elettrodomestico.
3
CAPITOLO 1. ANALISI DEI REQUISITI
UTENTE GENERICO
RICERCA
ELETTRODOMESTICO
Figura 1.2. Use Case Diagram Utente Generico
TERMINALISTA
INSERISCI, MODIFICA, ELIMINA
FAMIGLIA
INSERISCI, MODIFICA, ELIMINA
CATEGORIA
INSERISCI, MODIFICA, ELIMINA
FORNITORE
INSERISCI, MODIFICA, ELIMINA
ELETTRODOMESTICO
<<include>>
Figura 1.3. Use Case Diagram Terminalista
4
CAPITOLO 1. ANALISI DEI REQUISITI
1.3.2 Specifiche sui dati
Gli elettrodomestici archiviati potranno essere o meno a listino; vengonosuddivisi in diverse categorie in base al tipo di elettrodomestico cherappresentano ( piano cottura, forno, frigo, lavatrice, etc... ). Glielettrodomestici vengono forniti dalle ditte fornitrici di cui si vuolememorizzare il nome, lo sconto consigliato, l’aumento percentuale, ilmoltiplicatore sia per gli elettrodomestici che saranno presenti a listino cheper quelli che non saranno presenti; quest’ultima informazione deve esserememorizzata sia per il listino attuale che per il prossimo. Alcune categorie dielettrodomestico hanno associati dei componenti aggiuntivi (una base lavello, un gruppo frigo). Ogni categoria e composta da diverse famiglie, ognunadelle quali e rappresentata da un elettrodomestico che assume il ruolo dicapofamiglia. Per ogni elettrodomestico si vuole memorizzare (cfr. tabella1.1) il nome del fornitore, il codice esterno, il codice interno della Del Tongo,il codice interno futuro, un numerico se fornito dalla ditta fornitrice, lacategoria di appartenenza, la descrizione, il modello di elettrodomestico dacui deriva (storico), il colore, le dimensioni, la classe energetica se presente,la presenza o meno nel listino attuale e in quello futuro, il prezzo interno, ilprezzo interno futuro, la data di cessata produzione, la presenza o meno amagazzino, la data di inserimento nel sistema, la data di entrata in vigore,la presenza o meno di un mobile da incasso, l’immagine a bassa ed altarisoluzione, la scheda tecnica, la famiglia di appartenenza.
1.3.3 Specifiche sulle operazioni
Gli utenti possono usufruire delle operazioni offerte dal sistema solamentedopo aver eseguito un processo di autentificazione che richiede l’inserimentodi un nome utente e di una password. L’utente generico puo eseguireoperazioni di sola lettura mentre il terminalista ha i privilegi per eseguireanche le operazioni di scrittura. A seguito di ripetuti incontri, avvenuti siacon il responsabile degli utenti del sistema che con il responsabile di settore,e stato stabilito che l’applicazione debba supportare le seguenti operazioni:
Inserimento Nuovo Modello I dati che obbligatoriamente vanno speci-ficati sono: codice interno, codice ditta fornitrice, presenza a listinofuturo, tipo elettrodomestico, data entrata in vigore, data inserimento,moltiplicatore futuro, capofamiglia e prezzo futuro.
Visualizzazione modello L’operatore deve poter visualizzare i modelli dielettrodomestici in base a regole di ricerca da lui specificate. Questesi basano sul codice interno della Del Tongo, sul codice della ditta
5
CAPITOLO 1. ANALISI DEI REQUISITI
fornitrice, sul tipo elettrodomestico, sulla famiglia, sui modelli correnti.Per la ricerca di modelli correnti si dovrebbero fare una serie di confrontiin cui per ogni codice esterno presente nel sistema si va a selezionare ilmodello con la piu recente data di entrata in vigore.
Terminazione modello Si verifica quando la data attuale e pari o maggiorealla data presente nel campo di cessata produzione.
Aggiornamento modello esistente Si crea un nuovo modello a partire daquello modificato e se ne ereditano tutti i campi andando a modificarnequelli di interesse. Si deve identificare come storico di questo modelloil modello gia esistente.
Modifica campo modello In questo caso si vanno ad apportare dellemodifiche sul modello esistente senza creare un nuovo modello. Questemodifiche si verificano per correggere un errore commesso in fase diinserimento.
Inserimento Fornitore Le informazioni da inserire in questa operazionesono il nome, lo sconto consigliato, l’aumento percentuale e ilmoltiplicatore, sia per per gli elettrodomestici presenti a listino cheper quelli non presenti.
Eliminazione Fornitore Vengono eliminate tutte le informazioni riguar-dante un fornitore.
Modifica Fornitore Operazione che effettua una modifica dei campi diinteresse.
Inserimento Categoria Operazione che prevede l’inserimento di un nomedi una nuova categoria di elettrodomestici.
Eliminazione Categoria Operazione che prevede la cancellazione di unacategoria di elettrodomestici. Questa operazione puo essere effettuatasolamente dopo aver eliminato o modificato tutti gli elettrodomesticiappartenenti a quella categoria.
1.3.4 Specifiche Sistema di Archiviazione
La scelta del sistema di archiviazione dati da utilizzare per la memorizzazionedelle informazioni di interesse e stata influenzata da requisiti quali:
• Affidabilita e Fiducia nel contenuto informativo del dato
6
CAPITOLO 1. ANALISI DEI REQUISITI
• Privatezza delle informazioni nei confronti di utenti non autorizzati
• Efficienza in termini di tempi di risposta nell’accesso alle informazioni
• Condivisione delle informazioni tra applicazioni e utenti diversi
Questi fattori hanno fatto ricadere la nostra scelta su di un sistema digestione di basi di dati di tipo relazionale (RDBMS). Nell’incontro avvenutocon il database administrator dell’azienda, e stato evidenziato come l’aziendainternamente facesse gia utilizzo di un RDBMS, nello specifico SQLServer2000. Data la familiarita d’utilizzo acquisita dal personale della Del Tongoed i relativi costi di licensing gia sostenuti, abbiamo deciso di utilizzarel’RDBMS attivo in azienda.
1.3.5 Business Rules
La principale fonte di informazioni da cui sono state ricavate le businessrules e stata la documentazione esistente all’interno dell’azienda; leinformazioni raccolte sono state selezionate in collaborazione con gli utentiper chiarire e standardizzare le varie ambiguita e imprecisioni presenti. Dalladocumentazione finale e emersa la necessita di raggruppare, per ciascunmodello di elettrodomestico, l’insieme dei modelli che rappresentano ilmodello stesso nei diversi colori disponibili; la formalizzazione di queste regolea portato alla definizione di concetti quali quello di Famiglia e Capofamiglia:
Famiglia Insieme di modelli di elettrodomestico rappresentanti lo stessomodello nei diversi colori disponibili.
CapoFamiglia Modello di elettrodomestico che rappresenta una singolafamiglia all’interno di un listino.
Segue un elenco delle business rules di maggior rilievo:
1. La scelta del capofamiglia segue i criteri sotto elencati:
(a) Se tra gli appartenenti alla stessa famiglia ci sono elementi chesono presenti a listino attuale questi risultano essere i possibilicandidati, altrimenti la candidatura ricade su quelli non presentia listino.
(b) Trovati i possibili candidati si selezionano quelli che presentanoun’immagine corretta.
(c) Tra i candidati con immagine corretta la preferenza ricade sulmodello con finitura inox.
7
CAPITOLO 1. ANALISI DEI REQUISITI
2. La data di entrata in vigore di un elettrodomestico non puo essereantecedente alla data di inserimento dello stesso.
3. La data di terminazione di un elettrodomestico non puo essereantecedente alla data di entrata in vigore dello stesso.
4. La data di entrata in vigore dello storico di un elettrodomestico nonpuo essere successiva alla data di entrata in vigore dell’elettrodomesticostesso.
5. L’aggiornamento di un modello esistente deve essere effettuato qualoraper il modello sotto esame si vada a modificarne il prezzo.
6. Il prezzo al pubblico viene calcolato, dai rivenditori Del Tongo, comeprodotto fra il prezzo interno, il moltiplicatore (selezionato opportuna-mente in base alla presenza o meno a listino dell’elettrodomestico) e losconto consigliato.
8
CAPITOLO 1. ANALISI DEI REQUISITI
1.3.6 Glossario dei termini
Tabella 1.1. Data DictionaryTermine DescrizioneSconto consigliato Percentuale di sconto consigliata al rivenditore
nei confronti del cliente finaleAumento percentuale Percentuale che va ad incrementare il prezzo
dell’elettrodomesticoMoltiplicatore a listino Percentuale che viene applicata per il calcolo del
prezzo dell’elettrodomestico a listinoMoltiplicatore non a listino Percentuale che viene applicata per il calcolo
del prezzo dell’elettrodomestico non presente alistino
Famiglia Insieme di modelli di elettrodomestici che hannole stesse caratteristiche ma diverse finiture
Capofamiglia Modello di elettrodomestico rappresentante unafamiglia
Codice esterno Codice che viene fornito per ogni elettrodome-stico dalla ditta fornitrice
Codice interno Codice Del Tongo di ogni elettrodomesticoCodice interno futuro Codice Del Tongo di ogni elettrodomestico che
potra essere o meno nel prossimo listinoStorico Memorizza per ogni modello quale sia il relativo
predecessoreNumerico Codice opzionale indicato dal fornitore, rap-
presenta un’ alternativa al codice esterno; for-nisce informazioni maggiori, quali il tipo diimballaggio del prodotto
9
Capitolo 2
Progettazione della Base Dati
In questo capitolo verranno illustrati gli aspetti dello sviluppo del sistemainformativo che riguardano da vicino il progetto della base dati, rimandandoal capitolo successivo l’attivita di progettazione rivolta all’implementazionedell’architettura software; progettare una base dati significa definirnestruttura, caratteristiche e contenuto. Per realizzare un prodotto di qualitaabbiamo adottato una metodologia di riferimento articolata in tre fasi: laprogettazione concettuale, la progettazione logica e la progettazione fisica.Ogni fase verra presentata in dettaglio nelle due sezioni che compongono ilcapitolo.
2.1 Progettazione Concettuale
Permette la rappresentazione dei dati della realta di interesse in termini di unmodello formale ad alto livello, indipendente dai criteri di rappresentazioneutilizzati nei sistemi di gestione di basi di dati. In questa fase abbiamo cercatodi rappresentare il contenuto informativo della base dati, senza preoccuparcidell’efficienza del programma che usera queste informazioni. Il prodotto diquesta fase viene chiamato schema concettuale (schema Entita-Relazione) efa riferimento ad uno schema concettuale dei dati.
2.1.1 Possibili Strategie di Progetto
Lo sviluppo di uno schema concettuale, a partire dall’analisi dei requisitieffettuata precedentemente, e stato affrontato seguendo un vero e proprioprocesso di ingegnerizzazione composto da una serie di strategie diprogetto, utilizzate successivamente anche in fase di progettazione software.
10
CAPITOLO 2. PROGETTAZIONE DELLA BASE DATI
Esaminiamo brevemente le strategie di progetto candidate alla modellazionedella base dati, mostrando successivamente lo soluzione adottata.
- Strategia Top-Down: In questa strategia, lo schema concettualeviene prodotto mediante una serie di raffinamenti successivi a partireda uno schema iniziale che descrive tutte le specifiche con pochi concettimolto astratti. Lo schema viene poi raffinato in maniera iterativa finoa raggiungere il giusto livello di dettaglio dei vari concetti. Il vantaggiodella strategia top-down e che il progettista descrivendo da subito tuttele specifiche dei dati, possiede sin dall’inizio di una visione globale delloschema finale.L’applicazione di questa strategia e possibile solo avendola conoscenza di tutte le componenti del sistema,cio e estremamentedifficile in situazioni reali di una certa complessita.
- Strategia Bottom-Up: In questa strategia, le specifiche inizialivengono suddivise fino a quando descrivono un frammento elementaredella realta di interesse. Le componenti ottenute vengono rappresentateda semplici schemi concettuali che, successivamente vengono fusiintegrando le varie componenti fino al raggiungimento dello schemafinale. Rispetto alla strategia top-down, i vari concetti presenti nelloschema finale vengono introdotti nelle varie fasi. Il vantaggio dellastrategia bottom-up sta nel decomporre il problema iniziale in piusottoproblemi, facilmente risolvibili. Presenta come svantaggio, ladifficolta che il progettista incontra nell’operazione di integrazione deivari schemi concettuali.
- Strategia Inside-Out: Questa strategia rappresenta un casiparticolare della strategia bottom-up. Consiste nell’individuareinizialmente solo alcuni concetti importanti, procedendo a partire daquesti a “macchia d’olio”esplorando i concetti piu lontani da quelli dipartenza. Questa strategia ha il vantaggio di non richiedere passi diintegrazione. D’altro canto e necessario, di volta in volta, esaminaretutte le specifiche per individuare i concetti non ancora rappresentati,descrivendoli in dettaglio.
2.1.2 Strategia Adottata
La metodologia di progettazione adottata e di tipo misto: combinando ivantaggi della strategia bottom-up e top-down, consiste nel suddividere irequisiti in componenti separate e al tempo stesso definire uno schema dibase contenente a livello astratto i principali concetti dell’applicazione.
11
CAPITOLO 2. PROGETTAZIONE DELLA BASE DATI
Abbiamo quindi definito un primo schema di base evidenziando le dueentita principali Elettrodomestico e Fornitore unite dalla relazione Fornitura.Il raffinamento successivo, illustrato in figura 2.1, ha previsto l’inserimentodi una generalizzazione parziale ed esclusiva con lo scopo di modellare ladiversita fra le varie categorie di elettrodomestico. L’inserimento dellageneralizzazione e reso necessario dalla presenza, nelle varie categorie dielettrodomestico, di attributi specifici. Il maggiore livello di dettaglio delloschema ha previsto l’inserimento degli attributi di interesse per ogni entita.
ELETTRODOMESTICO
FORNITORE
ELETTRODOMESTICO
FORNITORE
FORNO FRIGO LAVELLO PURIFICATORE
FO
RN
ITU
RA
FO
RN
ITU
RA
NOME
SCONTO AUM.
PERCENTUALE
MOLT. A
LISTINO
NUMERICO
DATA
VIGORE
COD
ESTERNO
DATA
INSERIMENTO
COLORE
DATA
CESSAZIONE
MOBILE NON
PREVISTO
MAGAZZINO
GRUPPO
FRIGO
BASE
LAVELLO
Figura 2.1. Prima approccio e successivo raffinamento del modelloConcettuale
L’ultimo raffinamento effettuato, illustrato in figura 2.2, ha permessoallo schema di descrivere, tramite l’inserimento di due entita apposite (DatiAttuali e Dati Futuri), le informazioni caratterizzanti sia il listino attuale siaquello futuro. E’ stata inoltre inserita la relazione ricorsiva storico sull’entitaElettrodomestico, con il compito di associare ad ogni elettrodomestico ilproprio predecessore; data l’asimmetricita della relazione sono stati definititramite degli identificatori (nel nostro caso Successore e Predecessore) i dueruoli che l’entita coinvolta svolge nella relazione. L’inserimento dell’entita
12
CAPITOLO 2. PROGETTAZIONE DELLA BASE DATI
Famiglia e della relativa relazione Capo, e reso necessario dalla necessitadi individuare un modello di elettrodomestico che funga da capofamiglia,rappresentando la famiglia stessa nel listino attuale. Valutiamo di seguito lemotivazioni che hanno influenzato la scelta degli identificatori delle varieentita; analizzando l’entita Elettrodomestico e possibile osservare comesia stata definita una chiave primaria composta sia dalla data di entratain vigore che dal codice esterno indicato dal fornitore; questa scelta edovuta alla possibilita di avere piu modelli di elettrodomestico con lo stessocodice esterno. L’entita Famiglia, rappresentando informazioni comuni adalcuni modelli di elettrodomestici, ha definita una chiave primaria compostadalla data di entrata in vigore del capofamiglia e dal codice esterno delcapofamiglia: si ricordi infatti che il capofamiglia di un insieme di modelli dielettrodomestici e un modello stesso. Per l’entita Fornitore e stata definitauna chiave primaria basata sul nome del fornitore; questa scelta e dovuta all’impossibilita di avere fornitori con lo stesso nome. Le relazioni presenti trale varie entita sono semplici relazioni che non necessitano della definizione dialcun attributo su di esse.
13
CAPITOLO 2. PROGETTAZIONE DELLA BASE DATI
ELETTRODOMESTICO
FORNITORE
FORNO FRIGO LAVELLO PURIFICATORE
FO
RN
ITU
RA
ST
OR
ICO
NOME
SCONTO AUM.
PERCENTUALE
MOLT. A
LISTINO
NUMERICO
DATA
VIGORE
COD
ESTERNO
DATA
INSERIMENTO
COLORE
DATA
CESSAZIONE
MOBILE NON
PREVISTO
SUCCESSORE
PREDECESSORE
FAMIGLIA
DATI FUTURI
CAPOFAMIGLIA
DIMENSIONI
DESCRIZIONE
CLASSE ENERGETICA
LIS
TIN
O F
UT
UR
OL
IST
INO
CODICE INTERNO
FUTURO
LISTINO
FUTURO
PREZZO INTERNO
FUTURODATA CAPOFAMIGLIA
DATI ATTUALI
CODICE INTERNO
LISTINO PREZZO INTERNO
GRUPPO
FRIGO
BASE
LAVELLO
CA
PO
Figura 2.2. Modello Concettuale Entita Relazione
14
CAPITOLO 2. PROGETTAZIONE DELLA BASE DATI
2.1.3 Requisiti di Qualita
L’analisi di qualita costituisce un importante momento di verifica dellostato corrente del progetto nel quale e spesso necessario dover effettuaredelle ristrutturazioni. L’applicazione continuativa della metodologia diprogettazione adottata ha permesso di arrivare alla formulazione di unmodello Entita-Relazione che rispetti requisiti di qualita quali:
- Correttezza: Lo schema e risultato essere sintatticamente esemanticamente corretto
- Completezza: Tutte le informazioni di interesse sono staterappresentate.
- Leggibilita: Tramite una scelta accurata dei nomi, lo schema ottenutorisulta essere facilmente comprensibile e autoesplicativo.
- Minimalita: E’ stata raggiunta dal giusto compromesso fraeliminazione delle ridondanze superflue e mantenimento di quelledovute a precise specifiche progettuali. Tra le ridondanze eliminaterientrano tutte quelle dovute ad attributi derivabili: ad esempio ilprezzo al pubblico viene calcolato dal prodotto fra il pezzo interno,il moltiplicatore e lo sconto consigliato.
2.2 Progettazione Logica
L’obiettivo della progettazione logica e quello di costruire uno schema logicoin grado di descrivere, in maniera corretta ed efficiente, tutte le informazionicontenute nello schema Entita-Relazione prodotto nella fase di progettazioneconcettuale. La progettazione logica, costituendo la base per l’effettivarealizzazione dell’applicazione, necessita della realizzazione di due fasi bendistinte: una prima attivita di ristrutturazione dello schema E-R a cui segueun’attivita di traduzione dal modello concettuale a quello logico.
2.2.1 Ristrutturazione Schema E-R
In ingresso a questa prima fase abbiamo il modello concettuale ottenutoprecedentemente abbinato al carico applicativo previsto; in uscita ritroviamouno schema Entita-Relazione ristrutturato tenendo conto del caricoapplicativo previsto, sia in termini di dimensione dei dati che in terminidi caratteristica e frequenza delle operazioni di interesse. Abbiamo fatto usodi due parametri per la valutazione del carico applicativo:
15
CAPITOLO 2. PROGETTAZIONE DELLA BASE DATI
- Costo di una Operazione: Prevede la valutazione del numerodi entita e associazioni che mediamente devono essere visitate perrispondere ad un’ operazione sulla base dati.
- Occupazione di memoria: Prevede la valutazione della complessitaspaziale necessaria alla memorizzazione dei dati.
Per studiare questi parametri e necessaria la conoscenza, oltre che delloschema, delle seguenti informazioni:
- Volume dei dati: Informazione ricavabile dal calcolo del numero dioccorrenze di ogni entita e associazione dello schema unita unita allastima delle dimensioni di ciascun attributo.
- Caratteristiche delle operazioni: Informazione che tiene conto deltipo di operazione (interattiva o batch), della frequenza con cui vieneeseguita e dei dati che essa coinvolge (entita e/o associazioni).
Dopo semplici calcoli di media statistica abbiamo ricavato le seguentiinformazioni:
Tabella 2.1. Tabella dei VolumiConcetto Tipo VolumeElettrodomestico E 2000Famiglia E 100Dati Attuali E 2000Dati Futuri E 2000Base Lavello E 50Gruppo Frigo E 50Fornitore E 25Storico R 2000
Tabella 2.2. Tabella delle OperazioniOperazione Tipo FrequenzaVisualizzazione Modelli I 2000 al giornoVisualizzazione Fornitore I 10 a settimanaInserimento Nuovo Modello I 100 al meseModifica Modello I 400 al mese
16
CAPITOLO 2. PROGETTAZIONE DELLA BASE DATI
Una volta stimato il carico applicativo, siamo passati all’eliminazionedella generalizzazione che coinvolge l’entita Elettrodomestrico e le variecategorie di elettrodomestico (Forno, Frigo, Lavello, etc.). L’eliminazione enecessaria in quanto i tradizionali RDBMS non consentono di rappresentaredirettamente una generalizzazione, vincolando il progettista a trasformarequesto costrutto in entita e o associazioni. Nell’affrontare questo passo, inriferimento al modello di figura 2.2 sono stati analizzati diversi metodi dieliminazione delle generalizzazioni:
Accorpamento delle figlie nel padre Le entita figlie (Forno, Frigo,Lavello, etc.) vengono eliminate e le loro proprieta vengono aggiunteall’entita padre (Elettrodomestico). A tale entita viene aggiuntoun ulteriore attributo “tipo”per distinguere le varie categorie dielettrodomestico.
Accorpamento del padre nelle figlie L’entita padre viene eliminata e,rispettando l’ereditarieta, i suoi attributi, il suo identificatore e lerelazioni a cui partecipava, vengono aggiunte alle figlie.
Sostituzione della generalizzazione con associazioni La generalizza-zione si trasforma in un numero di associazioni uno a uno pari al numerodelle figlie. Non sono necessari trasferimenti di attributi e le entita figlievengono identificate esternamente dal padre.
La soluzione adottata, illustrata in figura 2.3, risulta essere unavariante del primo metodo sopra citato: abbiamo eliminato le entita figlie(Forno, Frigo, Lavello, etc.) aggiungendo un attributo tipo sul padre(Elettrodomestico), creando pero, al posto degli attributi presenti sullefiglie, due nuove entita (Gruppo Frigo e Base Lavello) relazionandole conl’entita padre. La soluzione adottata permette di non avere valori nullisull’entita Elettrodomestico a discapito della creazione di due nuove entita.Di seguito viene mostrato il diagramma ottenuto al termine della prima fasedi progettazione logica:
17
CAPITOLO 2. PROGETTAZIONE DELLA BASE DATI
ELETTRODOMESTICO
FAMIGLIA FORNITORE GRUPPO FRIGO
DATI FUTURI DATI ATTUALI BASE LAVELLO
L
IST
INO
AT
TU
AL
E
LAVELLO
STORICO
DESCRIZIONE CAPOFAMIGLIA
DIMENSIONI CLASSE ENERGETICA
(0,1)
(1,1
) (1
,1)
(1,1
)
(1,1
)(1
,1)
(1,1)(1,1)
(0,1
)
(0,1)
(0,1
) (1
,1)
(1,1
) (1
,N)
(1,N
) F
OR
NIT
UR
A
NOME
SCONTO AUM.
PERCENTUALE
MOLT. A
LISTINO
PATH. IMM.
HIGH RES.
MOLT.
FUTURO
MOLT. NON
A LISTINO
PATH. IMM.
LOW RES
FR
IGO
GRUPPO
LIS
TIN
O F
UT
UR
O
DIMENSIONI BASE CODICE INTERNO CODICE INTERNO FUTURO
LISTINO
FUTURO
PREZZO INTERNO
FUTURO LISTINO PREZZO INTERNO
NUMERICO
DATA
VIGORE
COD
ESTERNO
DATA
INSERIMENTO
COLORE
TIPO DATA
CESSAZIONE
MOBILE NON
PREVISTO
MAGAZZINO
DATA CAPOFAMIGLIA
SUCCESSORE PREDECESSORE
CA
PO
Figura 2.3. Diagramma ER Ristrutturato
18
CAPITOLO 2. PROGETTAZIONE DELLA BASE DATI
Analizzando le cardinalita delle varie relazioni di figura 2.3 possiamonotare come l’associazione uno a molti Capo, mostri come ogni modellodi elettrodomestico debba obbligatoriamente appartenere ad una famiglia;le cardinalita delle relazioni Frigo e Lavello, data l’opzionalita dellapartecipazione, evidenzia come i diversi tipi di elettrodomestico possano avereo meno come propri attributi Dimensione Base o Gruppo.
2.2.2 Traduzione Modello Relazionale
Nella seconda fase il modello concettuale ristrutturato e stato tradotto inun schema relazionale equivalente, sfruttando le informazioni ottenute dalprocesso di normalizzazione effettuato. Al termine di queste due fasi abbiamoottenuto le seguenti relazioni:
- Elettrodomestico (CodEsterno, NomeFornitore, DataVigore, Nume-rico, DataCessazione, DataInserimento, Colore, Magazzino, MobilePre-visto, TipoElettro, CodCapo, DataCapo)
– Fk:NomeFornitore references Fornitore.NomeFornitore
– Fk:TipoElettro references Tipologie.TipoElettro
– Fk:CodCapo references Famiglia.CodCapo
– Fk:DataCapo references Famiglia.DataCapo
- Dati Futuri (ListinoFuturo, PrezzoIntFut, CodIntFut)
– PFk:CodEsterno on Elettrodomestico
– PFk:DataVigore on Elettrodomestico
- Dati Attuali (Listino, PrezzoInterno, CodInterno)
– PFk:CodEsterno on Elettrodomestico
– PFk:DataVigore on Elettrodomestico
- Base Lavello (DimesioniBase)
– PFk:CodEsterno on Elettrodomestico
– PFk:DataVigore on Elettrodomestico
- Gruppo Frigo (Gruppo)
– PFk:CodEsterno on Elettrodomestico
– PFk:DataVigore on Elettrodomestico
19
CAPITOLO 2. PROGETTAZIONE DELLA BASE DATI
- Tipologie (TipoElettro)
- Storico (CodEsternoOld, DataVigoreOld)
– PFk:CodEsterno on Elettrodomestico
– PFk:DataVigore on Elettrodomestico
- Fornitore (NomeFornitore, Sconto, AumPercentuale, MoltAListino,MoltNonAListino, MoltFuturo, PathImmHiRes, PathImmLowRes)
- Famiglia (Descrizione, Dimensione, ClasseEnergetica)
– PFk:CodEsterno on Elettrodomestico
– PFk:DataVigore on Elettrodomestico
2.2.3 Creazione Base Dati e Ricerca Indici
Utilizzando le informazioni ricavate nei passi base effettuati abbiamo caricatolo schema ottenuto durante la progettazione logica su uno strumentoCASE (Computer Aided Software Engineering); questo tool ha permessola generazione automatica degli script SQL necessari alla creazione fisicadella base dati. Terminata la creazione della base dati abbiamo avviatouna successiva fase di individuazione degli indici tesa all’ ottimizzazionedell’accesso ai dati; per fare cio abbiamo fatto uso dei principali strumentiche SQLServer offre al progettista:
- SQL QueryAnalizer: tool che permette di eseguire queriesmostrando in modalita grafica il relativo piano di esecuzione.
- Index Tuning Wizard: tool che elabora le informazioni ricavatedall’esecuzione delle queries al fine di creare indici performanti.
- Sql Profiler: tool che monitora gli eventi che accadono su di uno opiu server permettendo la rilevazione di queries rallentate, di piani diesecuzione complessi, di deadlock e di molti altri eventi che degradanole prestazioni
20
CAPITOLO 2. PROGETTAZIONE DELLA BASE DATI
1
ListinoAttuale
1
ListinoFuturoFornitura
1
Storia
1
Tipologia
1
Frigo
1
Lavello
Appartenenza
Famiglia
Descrizione Text Dimensioni VarChar(30) ClasseEnergetica Text CodCapo VarChar(25) NN (PK)DataCapo DateTime NN (PK)
Tipologie
TipoElettro VarChar(25) NN (PK)
BaseLavello
DimensioniBase VarChar(30) NNCodEsterno VarChar(25) NN (PFK)DataVigore SmallDateTime NN (PFK
GruppoFrigo
Gruppo Integer CodEsterno VarChar(25) NN (PFK)DataVigore SmallDateTime NN (PFK)
DatiAttuali
Listino Bit NNPrezzoInterno Money NNCodInterno VarChar(25) NNCodEsterno VarChar(25) NN (PFK)DataVigore SmallDateTime NN (PFK)
Storico
CodEsternoOld VarChar(25) NNDataVigoreOld SmallDateTime NNCodEsterno VarChar(25) NN (PFK)DataVigore SmallDateTime NN (PFK)
DatiFuturi
ListinoFuturo Bit NNPrezzoIntFuturo Money NNCodIntFuturo VarChar(25) NNCodEsterno VarChar(25) NN (PFK)DataVigore SmallDateTime NN (PFK)
Fornitore
NomeFornitore VarChar(50) NN (PK)Sconto Float NNAumPercentuale Float NNMoltAListino Float NNMoltFuturo Float NNMoltNonAListino Float NNPathImmHiRes VarChar(200) NNPathImmLowRes VarChar(200) NN
Elettrodomestico
CodEsterno VarChar(25) NN (PK)NomeFornitore VarChar(50) NN (FKDataVigore SmallDateTime NN (PKNumerico VarChar(20) DataCessazione SmallDateTime DataInserimento SmallDateTime NNColore VarChar(50) NNMagazzino Bit MobilePrevisto Bit TipoElettro VarChar(25) NN (FK)CodCapo VarChar(25) NN (FK)DataCapo DateTime NN (FK)
Figura 2.4. Vista Fisica Diagramma ER
2.2.4 Funzioni di BackUp e Ripristino Informazioni
La strategia di backup dei dati adottata sfrutta la possibilita di SQLServer2000 di eseguire differenti tipologie di backup. Abbiamo quindi deciso dieffettuare:
- BackUp Completo: programmato per essere eseguito ogni finesettimana, esegue il salvataggio completo del Database includendoanche gli utenti.
21
CAPITOLO 2. PROGETTAZIONE DELLA BASE DATI
- BackUp Differenziale: eseguito giornalmente durante la pausapranzo, salva tutti i cambiamenti avvenuti dall’ultimo BackUpCompleto.
- Transaction Logs: viene eseguito ad ogni ora, fungendo da vero eproprio backup incrementale. In caso di fallimento del database, questotipo di backup puo essere usato sia con il backup differenziale sia conquello completo, permettendo il ripristino del database.
22
Capitolo 3
Progettazione eImplementazione Software
Nel seguente capitolo vengono illustrati gli strumenti e le metodologie,adottati per la progettazione e implementazione del software, in gradodi ingegnerizzare e razionalizzare l’intero processo di sviluppo; lescelte effettuate garantiscono una riduzione dei tempi di produzionee di aggiornamento dell’applicativo. Nella prima sezione del capitolovengono elencate le scelte tecnologiche adottate e l’ambiente di sviluppoprescelto. Nella seconda sezione viene illustrata l’architettura generaledell’applicazione, sulla base della quale, sono state illustrate le informazionipresenti nella terza e quarta sezione. Per una maggiore comprensione deiDesign Patterns presenti in questo capitolo il lettore puo fare riferimentoall’Appendice A.
3.1 Strumenti Utilizzati
Il framework di supporto adottato per la creazione dell’intero progetto e ilFramework .NET; in riferimento al linguaggio la scelta e ricaduta sul C#.Quest’ultimo infatti non soffre di problemi di retrocompatibilita essendo natocon il Framework, e definito da uno standard ECMA (European ComputerManufacturers Association), semplifica notevolmente il linguaggio C++ erisulta essere fortemente orientato agli oggetti. L’ambiente di supportoadottato durante tutto il processo di sviluppo del Software e stato MicrosoftVisual Studio. Per il testing del codice abbiamo usato il tool NUnit, dato ilcompleto redesign che gli sviluppatori hanno apportato per ottimizzarlo neiconfronti delle features di .NET. Per la definizione dei Mock Objects e statoutilizzato NMock, mentre per l’analisi della correttezza formale del codice
23
CAPITOLO 3. PROGETTAZIONE E IMPLEMENTAZIONE SOFTWARE
abbiamo utilizzato FxCop. Infine per la valutazione delle metriche objectoriented abbiamo utilizzato SourceMonitor. Dato l’utilizzo della versione2.0 del .NET framework, questo risulta essere l’unico prerequisito softwarenecessario per la corretta esecuzione dell’applicativo.
3.2 Definizione Architettura
Secondo la definizione ANSI-IEEE Std1471-2000 l’architettura e “l’organiz-zazione basilare di un sistema rappresentato dalle sue componenti, dalle re-lazioni che esistono tra di loro e con l’ambiente circostante, e dai principiche governano la sua progettazione ed evoluzione”. Si deve quindi riela-borare il frutto dell’analisi tenendo in considerazione le possibilita offertedall’orientamento all’oggetto.
Dalla rielaborazione dei requisiti raccolti e emersa la necessita diprogettare una ben determinata tipologia di software: un’ applicazione di tipoEnterprise. Non esiste una definizione rigorosa di applicazione enterprise,viste le molteplici sfumature che una problematica del mondo reale, risolvibiletramite progettazione software, puo assumere; si tratta comunque diapplicazioni che si occupano di persistere e recuperare informazioni dabasi di dati, gestendo l’interazione concorrente con esse da parte di unelevato numero di utenti e che solitamente si trovano ad interagire con altreapplicazioni enterprise. Progettando un sistema complesso, e buona normaricorrere alla Stratificazione (Layering): questa comporta una suddivisionedel sistema in sottosistemi di minore complessita, ognuno dei quali svolgecompiti specifici usufruendo dei servizi del layer inferiore. Tra i possibilischemi di Layering, a disposizione dell’architetto software, abbiamo optatoper un’architettura a tre livelli illustrata in figura 3.1:
24
CAPITOLO 3. PROGETTAZIONE E IMPLEMENTAZIONE SOFTWARE
Presenta�on Layer
Business Layer
Data Access Layer
Figura 3.1. Architettura three layer
Illustriamo brevemente le caratteristiche proprie di ogni livello:
Presentation/User Interface Layer (PL/UI) Rappresenta l’interfacciatra l’utente e il resto dell’applicazione. Se l’utente non fosse messoin condizione di interagire con l’applicazione al fine di eseguireefficacemente il proprio lavoro, il successo complessivo dell’applicazionerisulterebbe gravemente compromesso.
Business Logic Layer (BLL) Contiene la logica di business dell’ap-plicativo; effettua i calcoli basati sulla validazione dei dati diinput.
Data Access layer (DAL) Serve a far comunicare l’applicazione con altrisistemi; in un’applicazione di tipo Enterprise questo layer si occupadella persistenza sulla base dati.
Scelta l’architettura di base del sistema, siamo passati alla progettazionedella logica applicativa (business logic); quest’ultima rappresenta il legametra l’interfaccia utente e lo stato permanente del sistema informativo. Neicasi piu semplici e un insieme di funzionalita descritte da un linguaggio diprogrammazione generico che traducono le richieste dell’utente in una o piuoperazioni sulla base di dati. Nei casi piu complessi la logica applicativa none un semplice traduttore, ma opera sui dati, ricavando nuove informazioni apartire dal contenuto del database. In riferimento alla nostra applicazionel’elevata conplessita della logica applicativa emerge dall’insieme di BusinessRules, ricavate durante la fase di analisi dei requisiti. Sono principalmente
25
CAPITOLO 3. PROGETTAZIONE E IMPLEMENTAZIONE SOFTWARE
due i pattern che permettono la realizzazione di una logica applicativaaffidabile ed estendibile:
Transaction Script La logica applicativa viene organizzata in proceduredove ogni procedura gestisce una singola richiesta effettuata dal layerdi presentazione. Funziona bene in semplici casi, in cui la logicaapplicativa non comporta complesse interazioni tra utente e base didati. Tra i vantaggi che derivano dall’applicazione di tale patternpossiamo elencare:
- Facilita di progettazione usufruendo dei principi guida dellaprogrammazione procedurale (una procedura per ogni funzione).
- Semplicita di realizzazione; il programmatore traduce unarichiesta nell’equivalente istruzione SQL.
- Trasparenza nelle transazioni.
Da sottolineare come d’altra parte l’adozione del transaction scriptporti ad un basso riuso del codice ed una conseguente difficolta dimanutenzione dello stesso.
Domain Model Un modello del dominio ad oggetti che incorpora siacomportamento che dati; questo modello di rappresentazione delleinformazioni in casi non molto complessi somiglia al modello dirappresentazione dei dati tipico dei database ma offre la possibilitadi avvalersi di tutta una serie di peculiarita del mondo object oriented,ponendo l’architettura dei dati ad un livello di astrazione superiorerispetto alla struttura in cui sono memorizzati. Tra i vantaggi chederivano dall’applicazione di tale pattern possiamo elencare:
- Astrazione rispetto al sistema di archiviazione dei dati.
- Facilita di riutilizzo del codice dovuta alla minimalita con cui ognimetodo implementa una funzionalita.
- Facilita di evoluzione nei confronti di possibili cambiamenti futuri.
Le problematiche annesse all’uso di questo pattern, sono legate alladifficolta di progettazione di un modello che rappresenti in manieraesaustiva i concetti di interesse e alla quantita di codice richiesta peruna prima implementazione.
La scelta di adottare il pattern Domain Model, si e basata sullavolonta di disaccoppiare l’applicazione dalla struttura definita dal sistemadi archiviazione. Nella definizione delle classi di dominio abbiamo deciso
26
CAPITOLO 3. PROGETTAZIONE E IMPLEMENTAZIONE SOFTWARE
di creare un modello di dominio “anemico”: le classi componenti ilmodello infatti non presentano alcun metodo relativo alla persistenza deidati; personalmente infatti il concetto di persistenza viene visto come un“servizio”e non come un “comportamento”proprio delle classi di dominio.Rendendo anemico il modello, i servizi di persistenza sono stati centralizzatiintroducendo un livello di servizi (Service Layer) all’interno del livello diBusiness Logic. Di seguito viene illustrata l’evoluzione dell’architettura difigura 3.1:
Presenta�on Layery
Service Layer
Business Layer
Service Layer
Data Access Layer
Database
Do
ma
in M
od
el
Figura 3.2. Architettura three layer con Service Layer
Il Service Layer espone, tramite un’apposita interfaccia, tutte quellefunzionalita applicative richieste dall’utente tramite il livello di presentazione;l’implementazione di interfacce grafiche multiple viene facilitata dall’averinserito interamente la logica applicativa all’interno del Business Layer.In figura 3.2 possiamo inoltre notare come il Domain Model rappresentiuna sorta di “contratto”per l’intera applicazione essendo l’unica conoscenzacondivisa tra i vari strati.
3.3 Progettazione Domain Model
La prima fase di progettazione del Domain Model prevede la definizione dellaclassi che rappresentano il dominio. Nel nostro caso sono stati individuaticoncetti come: Elettrodomestico, Fornitore, Categorie di elettrodomesticoe Famiglia. Abbiamo comunque incontrato delle difficolta legate alladefinizione della gerarchia di classi facenti capo alla classe Elettrodomestico.In un primo momento, insieme al team di sviluppo, abbiamo deciso di definire
27
CAPITOLO 3. PROGETTAZIONE E IMPLEMENTAZIONE SOFTWARE
la classe Elettrodomestico astratta, derivando un numero di classi pari allecategorie di elettrodomestico. Questo approccio fortemente Object-Orientedha portato al seguente class diagram:
Accessorio
Elettrodomestico
Class
Properties
tipo : TipoElettro
Methods
Accessorio()
BloccoFunzione
Elettrodomestico
Class
Properties
tipo : TipoElettro
Methods
BloccoFunzione()
Coperchio
Elettrodomestico
Class
Properties
tipo : TipoElettro
Methods
Coperchio()
Dissipatore
Elettrodomestico
Class
Properties
tipo : TipoElettro
Methods
Dissipatore()
Lavatrice
Elettrodomestico
Class
Fields
_mobileNonPrevi…
Properties
MobileNonPrevist…
tipo : TipoElettro
Methods
Lavatrice()
Mix
Elettrodomestico
Class
Properties
tipo : TipoElettro
Methods
Mix()
NonReperibile
Elettrodomestico
Class
Properties
tipo : TipoElettro
Methods
NonReperibile()
Purificatore
Elettrodomestico
Class
Properties
tipo : TipoElettro
Methods
Purificatore()
Abstract Class
Fields
Properties
CodEsterno : string
CodEsternoStorico : string
CodInterno : string
CodInternoFuturo : string
Colore : string
DataCessazione : DateTime
DataInserimento : DateTime
DataVigore : DateTime
DataVigoreStorico : DateTime
Famiglia : Famiglia
Fornitore : Fornitore
ListinoAttuale : bool
ListinoFuturo : bool
Magazzino : bool
Numerico : string
PrezzoInterno : decimal
PrezzoInternoFuturo : decimal
Methods
Elettrodomestico()
FamigliaClass
Fields
Properties
CapoFamiglia : string
ClasseEnergetica : string
Descrizione : string
Dimensioni : string
Methods
Famiglia()
FornitoreClass
Fields
Properties
AumPercentuale : double
MoltAListino : double
MoltFuturo : double
MoltNonAListino : double
Nome : string
PathImmHiRes : string
PathImmLowRes : string
Sconto : double
Methods
Fornitore()
ElettroCollection
Collection<Elettrodomes…
Sealed Class
FamigliaCollection
Collection<Famiglia>
Sealed Class
FornitoreCollection
Collection<Fornitore>
Class
TipoElettroEnum
Figura 3.3. Primo Approccio Domain Model
28
CAPITOLO 3. PROGETTAZIONE E IMPLEMENTAZIONE SOFTWARE
Dal diagramma in figura 3.3, possiamo osservare come le classi derivate,rappresentanti le categorie di elettrodomestico, si differenzino dalla classebase astratta Elettrodomestico unicamente per la presenza aggiuntivadi alcuni membri. Questa iniziale scelta architetturale e stata quindiabbandonata poiche, a fronte di una maggiore flessibilita in termini disviluppi futuri, corrisponde il rischio di una vera e propria esplosione delleclassi (aggiunta di una classe per ogni nuova categoria di elettrodomestico).La successiva formulazione del domain model, consta nella definizione dellaclasse Elettrodomestico, come classe concreta, implementando la differenzafra le varie categorie di elettrodomestico tramite l’aggiunta di un campo tipo.
ElettroCollection
Collection<Elettrodomestico>
Class
FamigliaClass
Fields
_classeEnergetica : string
_codCapoFamiglia : string
_dataVigoreCapoFamiglia : DateTime
_descrizione : string
_dimensioni : string
Properties
CapoFamiglia : string
ClasseEnergetica : string
DataVigoreCapoFamiglia : DateTime
Descrizione : string
Dimensioni : string
Methods
Famiglia() (+ 1 overload)
FornitoreClass
Fields
_aumPercentuale : double
_moltAListino : double
_moltFuturo : double
_moltNonAListino : double
_nome : string
_pathImmHiRes : string
_pathImmLowRes : string
_sconto : double
Properties
AumPercentuale : double
MoltAListino : double
MoltFuturo : double
MoltNonAListino : double
Nome : string
PathImmHiRes : string
PathImmLowRes : string
Sconto : double
Methods
Fornitore()
FornitoriCollection
Collection<Fornitore>
Class
NonDefinito
Elettrodomestico
Class
TipoElettroEnum
NonReperibile
NonDefinito
Accessorio
BilanciaDaIncasso
BloccoFunzione
Cappa
Congelatore
Coperchio
Cucina
Dissipatore
DistributoriSapone
Forno
Frigo
Lavastoviglie
Lavatrice
Lavello
MacchinaDelCaffe
Mix
PianoCottura
Purificatore
Schienale
ElettrodomesticoClass
Fields
_baseLavello : string
_codEsterno : string
_codEsternoStorico : string
_codInterno : string
_codInternoFuturo : string
_colore : string
_dataCessazione : DateTime
_dataInserimento : DateTime
_dataVigore : DateTime
_dataVigoreStorico : DateTime
_famiglia : Famiglia
_fornitore : Fornitore
_gruppoFrigo : string
_listinoAttuale : bool
_listinoFuturo : bool
_magazzino : bool
_mobilePrev : bool
_numerico : string
_prezzoInterno : decimal
_prezzoInternoFuturo : decimal
_tipo : TipoElettro
Properties
BaseLavello : string
CodEsterno : string
CodEsternoStorico : string
CodInterno : string
CodInternoFuturo : string
Colore : string
DataCessazione : DateTime
DataInserimento : DateTime
DataVigore : DateTime
DataVigoreStorico : DateTime
Famiglia : Famiglia
Fornitore : Fornitore
GruppoFrigo : string
ListinoAttuale : bool
ListinoFuturo : bool
Magazzino : bool
MobilePrev : bool
Numerico : string
PrezzoInterno : decimal
PrezzoInternoFuturo : decimal
Tipo : TipoElettro
Methods
Elettrodomestico()
Figura 3.4. Ridefinizione Domain Model
29
CAPITOLO 3. PROGETTAZIONE E IMPLEMENTAZIONE SOFTWARE
Analizzando il domain model cosi come definito in 3.4 possiamo notarela presenza della classe NonDefinito (applicazione pratica del pattern SpecialCase): questa classe, ereditata da Elettrodomestico, viene utilizzata ogni qualvolta un metodo che operi su Elettrodomestico, restituisca una particolarecasistica quale ad esempio la restituzione di un valore null a seguito di unafunzione di ricerca di un particolare modello di elettrodomestico.
3.4 Business Logic Layer (BLL)
L’anemicita adottata nella progettazione del Domain Model, ha spinto allacreazione di uno strato di gestione della logica di business che comprendesseal proprio interno uno strato dedicato ai servizi (Service Layer). Di seguitoviene riportata la ripartizione, in termini di carico applicativo, prevista perla logica di business.
15%
Business Layer
0% 0%100%
Client DatabaseBusiness Layer
Figura 3.5. Ripartizione della logica di business
La soluzione adottata in figura 3.5 presenta numerosi vantaggi:
1. Concentrare la logica di business in un singolo punto rende agevole leattivita di verifica e modifica della logica stessa.
2. Vengono implementate le regole di business tramite un linguaggio diprogrammazione OO; tutt’oggi infatti troppo spesso ancora assistiamoa soluzioni che implementano la logica di business utilizzando linguaggicome SQL.
30
CAPITOLO 3. PROGETTAZIONE E IMPLEMENTAZIONE SOFTWARE
3. Il database esegue l’archiviazione e il recupero dei dati senza essere aconoscenza di quei vincoli di business che ne degradano le prestazioni.
Il livello di business cosı caratterizzato presenta un duplice obiettivo:
1. Fornire i servizi applicativi nei confronti del livello di presentazione.
2. Applicare la logica di business validando le classi di dominio secondoprecise regole di business.
La fornitura dei servizi effettuata dal livello di business e di fattoinvariante rispetto alla tipologia di strato di accesso ai dati utilizzata;questa flessibilita deriva dal fatto che, il livello di business non rileva alcundisallineamento tra la struttura propria degli oggetti di business e quelladefinita ad esempio dal modello relazionale (Impedance Mismatching). Lavalidazione degli oggetti di business e stata effettuata ricorrendo ad unavalidazione di tipo contestuale (Contextual Validation): ogni oggetto, peressere ritenuto valido, deve soddisfare un determinato insieme di regoleall’interno del contesto operativo in cui si trova; a seconda del contesto,l’insieme di regole puo cambiare sia nella definizione che nei parametri adesso associati. L’implementazione della logica di validazione ha previstola creazione di una classe astratta, rappresentante un generico contesto divalidazione, che possieda un membro privato composto da una lista di regole;presenta inoltre delle proprieta che permettono di tenere traccia delle regolenon rispettate in caso di validazione non corretta. A questo punto, per ognicontesto di validazione necessario, abbiamo derivato una classe concreta dallaclasse astratta appena definita, andando a dichiarare le regole di interesseall’interno dell’implementazione del metodo di inizializzazione.
Per implementare la business logic ed offrire allo strato di presentazionei servizi applicativi, siamo passati alla creazione di due classi manager comeillustrato in fugura 3.6.
31
CAPITOLO 3. PROGETTAZIONE E IMPLEMENTAZIONE SOFTWARE
ElettroManagerClass
Fields
dataProvider : IElettrodomesticoProvider
Methods
Create() : bool
Delete() : bool
ElettroManager()
FindById() : Elettrodomestico
GetAll() : ElettroCollection
GetAllFamily() : FamigliaCollection
GetAllOneCategory() : ElettroCollection
GetFamily() : ElettroCollection
Modify() : bool
FornitoreManagerClass
Fields
dataProvider : IFornitoreProvider
Methods
Create() : bool
Delete() : bool
FornitoreManager()
GetAll() : FornitoriCollection
Modify() : bool
Figura 3.6. Business Logic Layer
Dalla precedente figura notiamo come ogni manager abbia come membroprivato un dataProvider al quale, essendo definito nello strato di accessoai dati, spettera il compito di interfacciarsi fisicamente con la basedati; sono presenti inoltre una serie di metodi corrispondenti ai possibiliservizi applicativi richiedibili per quell’oggetto. Di seguito forniamo allettore il diagramma di sequenza relativo alla ricerca di tutti i modelli dielettrodomestici archiviati.
32
CAPITOLO 3. PROGETTAZIONE E IMPLEMENTAZIONE SOFTWARE
Utente Consultazione
1: Lettura Archivio Elettrodomestici
InterfacciaConsultazione
ElettroManager:Un Manger BLL pergli Elettrodomestici
DataProvider:Un provider dati perElettrodomestici
ElettroAccessProviderFactory: Factory Astratta per BO
2. GetAll()3: GetElettroProvider()
4 :
5 : GetAll()
6:
7:
8 :
Figura 3.7. Sequence Diagram relativo alla lettura degliElettrodomestici
Analizziamo brevemente l’interazione ed i riferimenti presenti tra i varilivelli, in riferimento a figura 3.7:
1. L’utente, tramite l’interfaccia grafica, richiede la lettura dell’archiviodei modelli di elettrodomestico.
2. Il livello di presentazione richiede il servizio alla parte Service del livellodi business, fornendo in input l’istanza della classe di dominio sul qualeil servizio opera.
3. Il livello di business riceve un riferimento allo strato di accesso ai datida utilizzare. Il riferimento viene attivato da una factory astratta(ElettroAccessProviderFactory).
4. Lo strato di accesso ai dati si interfaccia fisicamente con la base datieseguendo le operazioni indicate dal livello di business, restituendo aquest’ultimo l’insieme dei modelli di elettrodomestico.
5. Dopo aver eseguito le opportune validazioni, il livello di businessfornisce al livello di presentazione gli elettrodomestici da mostrareall’utente.
33
CAPITOLO 3. PROGETTAZIONE E IMPLEMENTAZIONE SOFTWARE
3.5 Data Access Layer (DAL)
Lo strato di accesso ai dati si occupa della persistenza delle informazionisulla base dati; esistono diverse soluzioni che permettono di interfacciarsiefficientemente con una base dati:
Utilizzo ORM Un ORM (Object-Relational Mapping) tool e unostrumento software in grado di mappare un modello objectoriented in un equivalente modello relazionale. Possono essere dei“semplici”generatori di codice oppure dei mapper xml puri (
DAL personale Soluzione che sviluppa l’accesso al dato in base al propriomodello, adattondosi allo scenario di riferimento
Utilizzo strumenti ambiente di sviluppo Soluzione che sfrutta gli stru-menti messi a disposizione dall’ambiente di sviluppo;
Analizzando le varie soluzioni sopra elencate abbiamo deciso diconcentrarci solamente sulle prime due; infatti, con riferimento all’ambientedi sviluppo adottato, possiamo notare come l’utilizzo di una logica drag&droptipica del Designer di Visual Studio, porti alla creazione di un’applicazionemonolitica che si contrappone ai concetti di stratificazione esposti. Lasoluzione adottata, basata sullo sviluppo di uno strato di accesso aidati personalizzato, tende a definire un’architettura massimizzata per leprestazioni, rispettando requisiti prefissati quali:
• Indipendenza dallo schema fisico.
• Indipendenza dal RDBMS scelto.
• Attivazione dello strato di accesso ai dati tramite tramite file diconfigurazione
Lo strato di accesso ai dati, avendo scelto come sistema di archiviazionedei dati un database relazionale, ha il compito di eseguire il mapping frala rappresentazione degli oggetti, cosı come definiti nel domain model, e larappresentazione tabellare tipica di una base dati. Esistono diversi patternche permettono di portare a termine questo compito tra cui:
Active Record Definisce un oggetto con il compito di rappresentareuna riga di una tabella della base dati, incapsulandone l’accesso eaggiungendo una logica di dominio a quel dato: da qui la definizionedi record attivo.
34
CAPITOLO 3. PROGETTAZIONE E IMPLEMENTAZIONE SOFTWARE
Row Data Gateway Similmente al pattern Active Record, definisce unoggetto con il compito di rappresentare una riga di una tabella dellabase dati, non implementando tuttavia la logica di business.
Table Data Gateway Rispetto al pattern Row Data Gateway definisce unoggetto con il compito di rappresentare una tabella della base dati.
Data Mapper Definisce uno strato di componenti dedicato al trasferimentodei dati dal modello a oggetti del dominio verso la base dati. Mascherale differenze fra i due schemi di rappresentazione del dato.
Avendo definito la logica di business mediante la costruzione di unmodello a oggetti che sfrutta l’ereditarieta, abbiamo deciso di applicare ilpattern Data Mapper.
Per soddisfare i requisiti prefissati e stato necessario utilizzare un insiemeinterconnesso di pattern. Il pattern principale con cui e stato modellatol’intero layer di accesso ai dati e Abstract Factory: questo pattern permettedi separare la creazione degli oggetti dal loro utilizzo, nascondendo l’identitadegli oggetti concreti al client; essendo rivolto agli oggetti consente di definirea runtime quali siano gli oggetti concreti che il client debba utilizzare. Ladefinizione del DAL e stata separata dall’effettiva implementazione medianteil pattern Separated Interface mentre il pattern Plug-In e stato utilizzato perpermettere l’ attivazione dello strato di accesso ai dati tramite configurazionepiuttosto che in fase di compilazione.
3.5.1 Implementazione
Seguendo l’evoluzione avuta dall’implementazione dello strato di accesso aidati, ripercorriamo il passo iniziale:l’applicazione del pattern Data Mapperha portato alla creazione di specifiche classi provider dei dati (classi didata mapping); il loro compito e quello di interfacciarsi con SQLSERVERrecuperando le informazioni che andranno ad essere mappate sugli oggetti dibusiness;
35
CAPITOLO 3. PROGETTAZIONE E IMPLEMENTAZIONE SOFTWARE
ElettrodomesticoSQLProviderClass
Methods
Create(Elettrodomestico elettro) …
Delete(Elettrodomestico elettro) …
Modify(Elettrodomestico elettro…
Read() : void
FamigliaSQLProviderClass
Methods
Create(Famiglia fam) : bool
Delete(Famiglia fam) : bool
Modify(Famiglia fam) : bool
Read() : void
FornitoreSQLProviderClass
Methods
Create(Fornitore forn) : bool
Delete(Fornitore forn) : bool
Modify(Fornitore forn) : bool
Read() : void
ElettrodomesticoClass
FamigliaClass
FornitoreClass
Figura 3.8. Primo Approccio Data Layer
Definiamo un ipotetico codice cliente che faccia uso dello strato definitoin figura 3.8:
class Program
{
static void Main(string[] args)
{
ElettrodomesticoSQLProvider prov = new ElettrodomesticoSQLProvider();
Elettrodomestico ele = new Elettrodomestico();
prov.Create(ele);
}
}
Analizzando il codice emerge come principale problema il forteaccoppiamento presente con la base dati utilizzata (in questo esempioSQLSERVER ); qualora dovessimo effettuare un porting dell’applicazionesu un diverso database (ad es.MySql) sarebbe necessario interveniredirettamente all’interno del codice, sostituendo le istanze dei providerdati presenti (ElettrodomesticoSQLProvider) con quelle di interesse (ElettrodomesticoMYSqlProvider). L’applicazione del pattern AbstractFactory risolve questi problemi di portabilita; andiamo a vedere comel’applicazione di tale pattern modifichi l’implementazione dello strato diaccesso ai dati definito precedentemente:
36
CAPITOLO 3. PROGETTAZIONE E IMPLEMENTAZIONE SOFTWARE
ElettrodomesticoSQLProviderClass
Methods
Create
Delete
Modify
Read
FamigliaSQLProviderClass
Methods
Create
Delete
Modify
Read
FornitoreSQLProviderClass
Methods
Create
Delete
Modify
Read
ElettrodomesticoClass
FamigliaClass
FornitoreClass
SQLProviderFactoryClass
Methods
GetElettrodomesticoProvider
GetFamigliaProvider
GetFornitoreProvider
MySqlProviderFactoryClass
Methods
GetElettrodomesticoProvider
GetFamigliaProvider
GetFornitoreProvider
FamigliaMYSqlProvi…Class
Methods
Create
Delete
Modify
Read
ElettrodomesticoMYSqlProviderClass
Methods
Create
Delete
Modify
Read
FornitoreMYSqlProviderClass
Methods
Create
Delete
Modify
Read
IElettrodomestic…Interface
Methods
IFamigliaProviderInterface
Methods
IFornitoreProviderInterface
Methods
IElettroProviderFact…Interface
Methods
IElettrodomesticoProviderIFamigliaProvider IFornitoreProvider
IElettroProviderFactory IElettroProviderFactory
IFamigliaProvider IElettrodomesticoProvider IFornitoreProvider
Figura 3.9. Data Layer Abstract Factory
Rispetto al passo iniziale illustrato in figura 3.8, possiamo notare lacreazione di numerose nuove classi:
IElettroProviderFactory Rappresenta l’Abstract Factory; e implemen-tata tramite l’ uso di un’interfaccia che definisce un factory methodastratto per ogni oggetto del dominio.
SQLProviderFactory, MYSQLProviderFactory Queste due classi rap-presentano due ipotetiche factory concrete che, implementando i fac-tory method definiti dall’abstract factory, hanno il compito di creare,secondo una propria logica, i corrispettivi provider dati concreti.
ElettrodomesticoSQLProvider,ElettrodomesticoMySqlProvider, etc.Rappresentano i provider dati concreti. Ad esempio, l’oggetto Elet-trodomesticoSQLProvider, verra creato dalla corrispondente factoryconcreta SQLProviderFactory.
IFamigliaProvider,IElettrodomesticoProvider,IFornitoreProvider Questeclassi, implementate tramite interfacce, rappresentano i provider datiastratti. Definiscono un contratto che i provider dati concreti, peressere tali, devono implementare.
37
CAPITOLO 3. PROGETTAZIONE E IMPLEMENTAZIONE SOFTWARE
Definiamo nuovamente un ipotetico codice client che sfrutti lo strato diaccesso ai dati appena illustrato in figura 3.9:
class Program
{
static void Main(string[] args)
{
IElettrodomesticoProvider prv;
Type providerType = Type.GetType(ConfigurationManager.
AppSettings["IElettroProviderFactory"]);
IElettroProviderFactory factory = Activator.CreateInstance(providerType)
as IElettroProviderFactory;
prv = factory.GetElettrodomesticoProvider();
Elettrodomestico ele = new Elettrodomestico();
prv.Create(ele);
}
}
Comparando i due codici client, quest’ultimo presenta alcune righeaggiuntive: nella prima linea di codice viene dichiarata l’interfaccia astrattaper il provider dati concreto, mentre nella seconda viene letta da unfile di configurazione la tipologia di provider dati concreta; nella lineasuccessiva viene creata la factory concreta (ad es. SQLProviderFactoryoppure MySqlProviderFactory); una volta creata la factory concretaquesta provvede alla creazione del provider dati concreto (ad es.ElettrodomesticoSQLProvider).
Notiamo come in quest’ultimo codice non ci sia alcun riferimento direttoal provider dati concreto, poiche la relativa istanza (prv) viene mantenutatramite l’interfaccia (IElettrodomesticoProvider) piuttosto che tramite laclasse concreta (ElettrodomesticoSQLProvider). La mancanza di alcunriferimento diretto ad uno specifico provider dati concreto permette didefinire a run-time quale provider utilizzare.
La soluzione presa in esame introduce un certo grado di ridondanzadovuta alla necessita di instanziare, previa lettura dal file di configurazione,la factory ogni qual volta vi si acceda. Per superare queste limitazioni
38
CAPITOLO 3. PROGETTAZIONE E IMPLEMENTAZIONE SOFTWARE
prestazionali, abbiamo raffinato ulteriormente la soluzione propostaapplicando il pattern Singleton: la formulazione finale (figura 3.10) haprevisto la creazione di uno strato di accesso ai dati generico all’internodel quale e stata creata una classe (ElettroAccessProviderFactory), con ilcompito di rappresentare l’unica istanza condivisa all’interno dell’applicativo(singleton istance).
Analizziamone brevemente il seguente codice:
public class ElettroAccessProviderFactory:IElettroProviderFactory
{
private static Assembly activeProvider = null;
private static IElettroProviderFactory activeProviderFactory =null;
private static IElettrodomesticoProvider elettroProvider = null;
private static IFornitoreProvider fornitoreProvider = null;
static ElettroAccessProviderFactory()
{
string providerName =
ConfigurationManager.AppSettings["DataProvider"];
string providerFactoryName =
ConfigurationManager.AppSettings["FactoryProvider"];
activeProvider =Assembly.Load(providerName);
activeProviderFactory =(IElettroProviderFactory)activeProvider.
CreateInstance(providerFactoryName);
}
#region IElettroProviderFactory Members
public IElettrodomesticoProvider GetElettroProvider()
{
if (elettroProvider == null)
elettroProvider = activeProviderFactory.GetElettroProvider();
return elettroProvider;
}
public IFornitoreProvider GetFornitoreProvider()
{
if (fornitoreProvider == null)
fornitoreProvider = activeProviderFactory.GetFornitoreProvider();
39
CAPITOLO 3. PROGETTAZIONE E IMPLEMENTAZIONE SOFTWARE
return fornitoreProvider;
}
La classe appena definita presenta un costruttore statico che, dopo averletto da un file di configurazione sia l’assembly contenente lo strato diaccesso ai dati concreto da attivare che il relativo nome della classe factory,attiva tramite reflection l’istanza della classe che in ogni strato di accessoai dati concreto implementa la propria factory; l’istanza attivata vienememorizzata all’interno del membro privato activeProviderFactory. I duefactory method GetElettroProvider() e GetFornitoreProvider(), invocano gliomonimi concreti della factory attiva, restituendo i provider dati per i dueoggetti di dominio. In definitiva abbiamo definito una factory astratta con ilcompito di restituire una factory concreta allo strato di business.
La soluzione adottata presenta una buona scalabilita: per la creazionedi un nuovo strato di accesso ai dati, una volta referenziato lo strato diaccesso ai dati astratto e il Domain Model di interesse, si passa direttamenteall’implementazione concreta, non curandosi affatto dei meccanismi diattivazione dello strato appena definito; la competenza di questo compitoviene riservata infatti alla classe ElettroAccessProviderFactory.
40
CAPITOLO 3. PROGETTAZIONE E IMPLEMENTAZIONE SOFTWARE
DataHelperClass
Properties
ConnectionString
Methods
ConfigureCmdParams
ConfigureCommand
DataHelper
ExecuteNonQuery (+ 2 ove…
ExecuteReader (+ 2 overlo…
ExecuteScalar (+ 2 overloa…
ElettrodomesticoDataProviderClass
Methods
Create
Delete
FindById
GetAll
GetAllOneCategory
GetFamily
Modify
ElettroProviderFactoryClass
Methods
GetElettroProvider
GetFornitoreProvider
FornitoreDataProviderClass
Methods
Create
Delete
GetAll
Modify
IFornitoreProviderInterface
Methods
ElettroAccessProviderFactoryClass
Methods
ElettroAccessProviderFactory
GetElettroProvider
GetFornitoreProvider
IElettrodomesticoProviderInterface
Methods
IElettroProviderFactoryInterface
Methods
IElettrodomesticoProvider
IElettroProviderFactory
IFornitoreProvider
IElettroProviderFactory
Figura 3.10. Strato accesso ai dati Generico e relativo stratoconcreto per SQLServer
41
Capitolo 4
Testing dell’Applicativo edEsempi d’Uso
Questo quarto capitolo si apre con la descrizione della fase di testing:componente fondamentale del processo di sviluppo software, misura il gradodi adesione del sistema realizzato, nei confronti dei requisiti stabiliti durantela fase di analisi, ovvero ne valuta la correttezza rispetto alle specifiche.Abbiamo suddiviso la fase di testing in due attivita principali:
1. Programmer Test/Technology Facing (Unit Testing o Testing d’unita)
2. Testing della qualita del codice (Code Analysis)
Da sottolineare come il ruolo del testing nello sviluppo del software sisia significativamente evoluto con le piu recenti metodologie di sviluppodel software, in particolare con la diffusione del modello dell’ExtremeProgramming (XP); XP prevede che siano scritti dei test per ogni metodointrodotto nelle classi e che siano mantenuti per tutta la durata dello svilupposoftware. Il testing rappresenta dunque un’attivita integrante dello sviluppodel software e non un accessorio, tenendo presente che i test rivelano lapresenza di bug e non la loro assenza. A conclusione del capitolo vengonoillustrati alcuni esempi di utilizzo dell’applicativo realizzato.
4.1 Unit Testing
Lo unit testing e una tipologia di test “automatico”, basata sulla possibilita disottoporre a test i singoli componenti di un sistema per verificarne la capacitadi soddisfare i requisiti; seguendo i principi propri di XP, abbiamo preferitoscrivere i test per ogni metodo prima di passare alla relativa implementazione,
42
CAPITOLO 4. TESTING DELL’APPLICATIVO ED ESEMPI D’USO
integrandoli continuamente durante l’intero ciclo di vita del software. L’applicazione del testing unitario porta ad avere un codice maggiormentedocumentato, essendo i test stessi esempi di casi d’uso.
La scelta del framework da utilizzare durante questa fase e ricaduta suNUnit, framework di riferimento per il testing unitario di software, realizzatoin C#; nato come semplice porting di JUnit, framework per testing di codiceJava, NUnit ha subito una rapida evoluzione sfruttando le caratteristicheavanzate di .NET, offrendo al programmatore una serie di classi con cuicostruire i propri test; fornisce anche un’applicazione host in grado di eseguireuna batteria di test, visualizzandone il risultato in modalita grafica.
I primi unit test sono stati creati per le classi appartenenti al domainmodel, testandone proprieta e relativi costruttori. Una volta testate le classidel domain model siamo passati al testing delle classi di data mapping delbusiness layer. Quest’ordine di testing e dovuto dal fatto che le classi chesi occupano del data mapping fanno uso delle classi del domain model;se in quest’ultime fossero stati presenti degli errori, questi sarebbero statipropagati alle classi di data mapping. Si ricordi infatti come un testunitario debba riuscire a testare una singola unita, requisito difficilmentemantenibile in architetture complesse dove spesso un componente interagiscecon altri componenti situati in layer differenti. Il fallimento di un componenteesterno puo provocare quindi il fallimento di un test. La soluzione a questoincoveniente consiste nell’isolare il componente sottoposto a test. Conriferimento alla nostra architettura ipotizziamo la creazione di un test che,facendo uso di una classe di business, richiami al suo interno una classedi data mapping. Se la classe di mapping va in errore, ad esempio peruna problematica relativa allo storage (sospensione temporanea), questoviene propagato alla classe business; lo sviluppatore non essendo in gradodi distinguere un fallimento avvenuto ad un livello piu basso, ritiene che ilfallimento si sia verificato all’interno della classe business.
Le varie soluzioni possibili consistono nel sostituire il componente esterno,che non puo essere sottoposto a test, con uno equivalente “testabile”.La soluzione adottata in un primo momento e basata sull’uso dei fakeobjects. Un fake object e un componente “finto”che implementa l’interfacciadell’oggetto che mi aspetto di utilizzare, restituendo per ogni metodo unvalore prestabilito. Abbiamo quindi definito un fake data provider che,ricevendo chiamate dalla parte business, restituisse valori validi. In questomodo tutti gli eventuali fallimenti riscontrati sarebbero senza dubbio dainputare allo strato business. Per l’implementazione del fake data provider ebastato implementare l’interfaccia IElettrodomesticoProvider comune a tuttii data access layer concreti. Abbiamo quindi settato come data providerall’interno del file di configurazione il fake provider appena creato ed eseguito
43
CAPITOLO 4. TESTING DELL’APPLICATIVO ED ESEMPI D’USO
i vari test per le classi di business. Per testare le funzionalita avanzate dellanostra classe di business siamo pero stati costretti a implementare il nostrofake provider in maniera tale che fosse necessario eseguire sullo stesso deitest. Per interrompere questo loop creatosi, abbiamo deciso di adottare unasoluzione alternativa basata sull’utilizzo dei Mock Objects : un Mock Object eun’evoluzione di un Fake Object poiche, oltre ad implementare l’interfacciadell’oggetto che mi aspetto di utilizzare, permette un controllo dei metodiche il test puo generare ed invocare sulle risorse esterne; utilizzando unMock Object e quindi possibile testare la correttezza delle interazioni trai comportamenti del sistema in esame (Interaction-Based Testing). Cometoolkit per la realizzazione dei mock ci siamo orientati su NMock.
4.2 Code Analysis
Durante la fase di code analysis e stata testata la qualita del codice prodotto.La prima verifica di qualita effettuata si basa sull’uso del tool FxCop:analizzando il codice compilato, rileva possibili problemi legati al design,alle prestazioni, alle naming conventions o alla sicurezza dell’applicazione.L’utilizzo di questo tool ha permesso una concreta adesione alle linee guidaMicrosoft per lo sviluppo di applicazioni. Per valutare invece le metricheOO abbiamo fatto uso del tool Freeware SourceMonitor che ci ha fornitomolteplici indici di valutazione software.
Tabella 4.1. Valutazione Metriche OOMetrica RisultatoNumero Files 46Linee Codice 7189Statements 4585Commenti 18%Classi 41Metodi per Classe 4.61Chiamate per Metodo 10.95Statement per Metodo 19.62Complessita Max 5Profondita Max 5Profondita Media 1.82Complessita Media 1.34
44
CAPITOLO 4. TESTING DELL’APPLICATIVO ED ESEMPI D’USO
Per la valutazione dei dati illustrati in tabella 4.1 abbiamo utilizzato ungrafico di Kiviat dove sono state riportate le metriche di maggiore interesse.
% Commenti [5-40]
Metodi per Classe [2-22]
Complessità Massima [2-8]
Profondità Massima [3-6]
Profondità Media [1.5-3.0]
Complessità Media [2.0-4.0]
Figura 4.1. Grafico di Kiviat
In riferimento alla figura 4.1, possiamo notare come le metriche checomprendano il numero di files, di classi, di linee di codice e di statementsrisultino piuttosto elevate, dato il tipo di architettura scelto combinato conl’uso dei pattern. Analizzando il rapporto ottenuto tra il numero complessivodi metodi e il numero di classi, emerge come mediamente ogni classe offrail giusto numero di funzionalita. Definiamo il concetto di complessita concui sono state eseguite le valutazioni: e una metrica che misura il numerodi possibili percorsi di esecuzione del codice, all’interno di un metodo o diuna funzione; ogni funzione presenta inizialmente una complessita unitaria,alla quale viene aggiunta una complessita di una unita per ogni costruttocondizionale (if, else, for, while), per ogni operatore logico (or, and) utilizzatoin espressioni condizionali e per ogni blocco di gestione delle eccezioni. Laprofondita massima e quella media sono parametri che ci danno informazionisul piano di esecuzione del nostro codice; dai dati emersi evince una bassanidificazione che permette sia delle buone prestazioni che un buon controlloda parte dello sviluppatore sul codice.
45
CAPITOLO 4. TESTING DELL’APPLICATIVO ED ESEMPI D’USO
4.3 Esempi d’Uso
L’interfaccia utente sviluppata e un’ Applicazione Windows che utilizzaWindows Form. Questa scelta e stata effettuata dopo un confronto tra ilteam di sviluppo e il terminalista addetto all’inserimento e consultazione deidati. L’interfaccia a documenti multipli (MDI) dell’applicazione consenteall’utente di visualizzare contemporaneamente piu finestre di lavoro; al lanciodell’applicazione, effettuata l’autentificazione utente, viene visualizzata lafinestra principale illustrata in figura 4.2.
Figura 4.2. Screenshot Finestra Principale Applicazione
Nella parte superiore della finestra e presente un menu principalecomposto dalle seguenti voci:
-Elettrodomestici : permette di accedere alle informazioni relative aglielettrodomestici. E’ composto da un sottomenu comprendentedue voci (figura 4.3): la voce Gestione, attiva solo per l’utenteterminalista, permette di accedere ad una finestra in cui e possibile,oltre alla visualizzazione, effettuare le operazioni di inserimento,
46
CAPITOLO 4. TESTING DELL’APPLICATIVO ED ESEMPI D’USO
modifica e cancellazione dei dati relativi agli elettrodomestici; la voceConsultazione permette invece di accedere ad una finestra in cuie possibile visualizzare le informazioni degli elettrodomestici in solalettura.
Figura 4.3. Particolare del sottomenu Elettrodomestici comevisualizzato dal terminalista
-Fornitori : permette di accedere alle informazioni relative ai fornitori. E’composto da un sottomenu comprendente due voci (figura 4.4): la voceGestione, attiva solo per l’utente terminalista, permette di accedere aduna finestra in cui e possibile, oltre alla visualizzazione, effettuare leoperazioni di inserimento, modifica e cancellazione dei dati relativi aifornitori; la voce Consultazione permette invece di accedere ad unafinestra in cui e possibile visualizzare le informazioni dei fornitori insola lettura.
Figura 4.4. Particolare del sottomenu Fornitori come visualizzatodal terminalista
-? : permette di accedere al manuale d’utilizzo utente dal quale ricavare utiliinformazioni sull’uso dell’applicativo.
Illustriamo di seguito alcuni esempi d’uso che possono essere eseguitidall’utente terminalista, dopo aver lanciato l’applicazione ed aver eseguitocorrettamente la procedura di autentificazione.
47
CAPITOLO 4. TESTING DELL’APPLICATIVO ED ESEMPI D’USO
4.3.1 Visualizzazione elettrodomestici della stessacategoria
Per visualizzare l’insieme degli elettrodomestici che appartengono ad unastessa categoria, l’utente terminalista, deve eseguire i seguenti passi:
1. Nella finestra principale, scegliere dal menu Elettrodomestici, la voceConsultazione (figura 4.3).
2. Viene visualizzata una finestra in cui automaticamente vengonomostrate, in sola lettura, le informazioni di ogni elettrodomesticopresente nel sistema; in figura 4.5 ad esempio vengono illustrate leinformazioni relative al secondo elettrodomestico presente nel sistema.
Figura 4.5. Screenshot Finestra Ricerca Elettrodomestici
48
CAPITOLO 4. TESTING DELL’APPLICATIVO ED ESEMPI D’USO
3. Nella finestra appena visualizzata, al di sotto del menu principale,e presente una barra degli strumenti; da questa barra selezionare ilpulsante Cerca Per Categoria. Viene mostrata all’utente la finestra didialogo illustrata in figura 4.6.
Figura 4.6. Screenshot Finestra Selezione Categoria diElettrodomestico
4. Selezionare dall’apposita casella combinata a discesa, la categoriadi elettrodomestico sulla quale effettuare la ricerca e confermareselezionando il tasto OK.
5. Viene visualizzata una finestra in cui vengono mostrati all’utentesolamente gli elettrodomestici che appartengono alla categoriaprecedentemente selezionata (figura 4.7); l’utente puo scorrere glielettrodomestici tramite i pulsanti di navigazione.
49
CAPITOLO 4. TESTING DELL’APPLICATIVO ED ESEMPI D’USO
Figura 4.7. Screenshot Finestra Ricerca Elettrodomestici, CategoriaAccessorio
4.3.2 Inserimento Fornitore
Per inserire un nuovo fornitore di elettrodomestici, l’utente terminalista, deveeseguire i seguenti passi:
1. Nella finestra principale, scegliere dal menu Fornitori, la voce Gestione(figura 4.4).
2. Viene visualizzata una finestra in cui automaticamente vengonomostrate, in sola lettura, le informazioni di tutti i fornitori presentinel sistema; in figura 4.8 ad esempio vengono illustrate le informazionirelative al primo fornitore presente nel sistema.
50
CAPITOLO 4. TESTING DELL’APPLICATIVO ED ESEMPI D’USO
Figura 4.8. Screenshot Finestra Gestione Fornitori
3. Nella finestra appena visualizzata, al di sotto del menu principale,e presente una barra degli strumenti; da questa barra selezionare ilpulsante indicato in figura 4.9.
Figura 4.9. Screenshot Pulsante Inserimento Fornitori
4. La selezione appena effettuata restituira la finestra di figura 4.8, inmodalita di inserimento dati (figura 4.10); a questo punto e possibileinserire le informazioni di interesse.
51
CAPITOLO 4. TESTING DELL’APPLICATIVO ED ESEMPI D’USO
Figura 4.10. Screenshot Finestra Inserimento Fornitori
5. Salvare le informazioni appena inserite selezionando il pulsante indicatoin figura 4.11.
Figura 4.11. Screenshot Pulsante Salvataggio Fornitori
52
Capitolo 5
Conclusioni e Possibili Sviluppi
Il lavoro. Quanto esposto e il risultato finale di un’attivita di tirocinio etesi durata dai primi giorni di Maggio 2006 fino all’inizio di Settembre delmedesimo anno. A causa dei tempi di ambientamento nel contesto aziendalee alla iniziale difficolta nel far parte di un team di sviluppo, la maggior partedei risultati operativi si sono concentrati nella fase finale dell’ intera attivita:gran parte delle ore nelle prime settimane sono state dedicate alla conoscenzaapprofondita del problema e al perfezionamento progressivo dell’architetturadi base.
Il risultato. L’attivita svolta ha permesso al sottoscritto di trovarsidi fronte allo sviluppo di un’ applicazione reale. Questo oltre ad unarricchimento delle conoscenze tecnologiche sulla base delle scelte effettuate,ha permesso durante le varie fasi di progettazione e sviluppo di analizzarele problematiche da diverse prospettive corrispondenti a diversi ruoliprofessionali. Il positivo riscontro, ottenuto sia dal responsabile di settoreche dagli utenti e terminalisti finali, evidenzia l’efficacia del processoingegneristico adottato nella realizzazione di un’applicazione reale.
Sviluppi Futuri. Un possibile sviluppo dell’applicazione realizzataconsiste nell’automatizzazione della procedura di inserimento deglielettrodomestici: il terminalista non dovra piu inserire direttamente i dati,dovra solamente indicare il file dove essi sono contenuti; sara compitodell’applicazione convertire le informazioni, in un formato standard quale adesempio XML, e passare successivamente alla relativa validazione attenendosiad uno schema XSD (XML Schema Definition).
Interazione ProgettoPartner. Il gruppo Del Tongo dispone di unportale intranet di nome ProgettoPartner al quale accedono sia il personale
53
CAPITOLO 5. CONCLUSIONI E POSSIBILI SVILUPPI
interno all’azienda che i clienti con le relative credenziali. ProgettoPartnerpermette di reperire informazioni riguardanti i vari rivenditori di cucineDel Tongo dislocati su territorio nazionale. L’applicazione sviluppatapotrebbe essere utilizzata come WebService dal portale per aggiungere aquest’ultimo funzionalita maggiori quali le informazioni relative ai varimodelli di elettrodomestici.
54
Capitolo 6
Appendice A : Design Pattern
In questo capitolo si descrivono i design patterns utilizzati durante la fasedi progettazione e sviluppo dell’applicazione. Un design pattern puo esseredefinito come “una soluzione progettuale generale a un problema ricorrente”.Esso non e una libreria o un componente software riusabile, quanto unadescrizione o un modello da applicare per risolvere un problema che puopresentarsi in diverse situazioni durante la progettazione e lo sviluppo delsoftware. I pattern utilizzati sono stati suddivisi in due categorie: PatternGof ed Enterprise Pattern.
55
CAPITOLO 6. APPENDICE A : DESIGN PATTERN
6.1 Pattern Gof
6.1.1 Abstract Factory
Il design pattern Abstract Factory definisce un’interfaccia (“AbstractFacto-ry”) tramite cui istanziare famiglie (famiglia 1, 2, etc.) di oggetti (Abstract-ProductA, AbstractProductB) tra loro correlati o comunque dipendenti, sen-za indicare da quali classi concrete (ProductA1 piuttosto che ProductA2).La scelta delle classi concrete e delegata ad una classe derivata (ConcreteFac-tory1 per la famiglia 1, ConcreteFactory2 per la famiglia 2). L’utilizzatore(Client) conosce solo l’interfaccia per creare le famiglie di prodotti (Abstract-Factory) ma non la sua implementazione concreta (ConcreteFactory1 per lafamiglia 1, ConcreteFactory2 per la famiglia 2); il meccanismo di scelta dellafamiglia di classi da istanziare (ConcreteFactory1 piuttosto che ConcreteFac-tory2) esula dallo scopo di questo design pattern. La classe ConcreteFactory1o ConcreteFactory2 che determina quale famiglia usare e stabilita a run-timequindi questo design pattern rispetto allo scopo e classificato come rivoltoagli oggetti. Rispetto al fine e classificato tra i Design Pattern Creazionali.La classe ConcreteFactory e solitamente a singola istanza e quindi viene im-plementata solitamente facendo uso del Pattern Singleton oppure ricorrendoalla definizione di una classe statica. Le classi di AbstractFactory spesso sonoimplementate con metodi che sfruttano il pattern FactoryMethod oppure ilpattern Prototype.
Figura 6.1. Pattern Abstract Factory
56
CAPITOLO 6. APPENDICE A : DESIGN PATTERN
6.1.2 Factory Method
Il design pattern Factory Method definisce un’interfaccia (Creator) perottenere una nuova istanza di un oggetto (Product) delegando ad unaclasse derivata (ConcreteCreator) la scelta di quale classe istanziare(ConcreteProduct). La classe ConcreteCreator che determina quale classeConcreteProduct istanziare e stabilita a design-time attraverso l’ereditarietaquindi questo design pattern rispetto allo scopo e classificato come rivoltoalle classi. Rispetto al fine questo questo design pattern e classificato tra iDesign Pattern Creazionali.
Figura 6.2. Pattern Factory Method
6.1.3 Singleton
Il design pattern Singleton permette di assicurare che una classe (Singleton)abbia una unica istanza e che questa sia globalmente accessibile in un puntoben noto. La classe Singleton determina a run-time l’istanza unica dautilizzare quindi questo design pattern rispetto allo scopo e classificato comerivolto agli oggetti. Rispetto al fine questo design pattern e classificato tra iDesign Pattern Creazionali.
57
CAPITOLO 6. APPENDICE A : DESIGN PATTERN
Figura 6.3. Pattern Singleton
6.2 Enterprise Pattern
6.2.1 Domain Model
A volte la logica di business su cui lavora la nostra applicazione puo esseremolto complicata. Un domain model rappresenta un insieme di oggettiinterconnessi utilizzati per rappresentare i dati su cui lavora la logica dibusiness. Questo modello di rappresentazione delle informazioni in casi nonmolto complessi somiglia al modello di rappresentazione dei dati tipico deidatabase ma offre la possibilita di avvalersi di tutta una serie di peculiaritadel mondo object oriented, ponendo l’architettura dei dati ad un livello diastrazione superiore rispetto alla struttura in cui sono memorizzati: e infattipossibile usare ereditarieta e polimorfismo, impostare relazioni molti-a-moltie, in generale, disegnare l’architettura implementandola tramite altri designpattern.
58
CAPITOLO 6. APPENDICE A : DESIGN PATTERN
Figura 6.4. Pattern Domain Model
6.2.2 Data Mapper
Il pattern Data Mapper introduce un layer applicativo con il compito dimappare le informazioni fra i business object e la struttura definita dal tipo distorage scelto tenendo conto della differenza fra i due schemi. Questo portaad una divisione netta e disaccoppiata fra la parte di business e quella dipersistenza dei dati permettendo allo sviluppatore di raggiungere un elevatolivello di astrazione.
59
CAPITOLO 6. APPENDICE A : DESIGN PATTERN
Figura 6.5. Pattern Data Mapper
60
CAPITOLO 6. APPENDICE A : DESIGN PATTERN
6.2.3 Service Layer
Questo pattern definisce i confini di un applicativo andando a inserire unastrato di servizi tra il livello di presentazione e quello di accesso ai dati.Compito di questo layer e quindi quello di coordinare i servizi applicativiincapsulando la logica di business dell’applicativo.
Figura 6.6. Pattern Service Layer
61
CAPITOLO 6. APPENDICE A : DESIGN PATTERN
6.2.4 Special Case
Questo pattern definisce una classe derivata che rappresenta un casoparticolare del tipo della classe base. La rappresentazione di un casoparticolare per un determinato tipo puo essere alle volte problematica: sipensi ad una funzione di ricerca in cui l’oggetto cercato non esista; larestituizione del valore null non e da considerarsi corretta dal punto di vistadell’architettura object-oriented, poiche non rispetta il polimorfismo.
Figura 6.7. Pattern Special Case
62
Bibliografia
[1] E.Gamma, R.Helm, R.Johnson, J.Vlissides.
Design Patterns. Addison-Wesley, 2001.
[2] Martin Fowler.
Patterns Of Enterprise Application Architecture. Addison-Wesley, 2004.
[3] Martin Fowler.
Refactoring. Addison-Wesley Professional, 1999.
[4] Christian Gross.
Foundations of Object-Oriented Programming Using NET 2.0 Patterns.Apress, 2005.
[5] David Trowbridge, Dave Mancini and Dave Quick, Gregor Hohpe, JamesNewkirk, David Lavigne.
Patterns Using Microsoft .NET. Microsoft Press, 2003.
[6] Atzeni, Ceri, Paraboschi, Torlone.
Basi Di Dati (Modelli e Linguaggi di Interrogazione). McGraw Hill, 2003.
[7] Atzeni, Ceri, Fraternali, Paraboschi, Torlone.
Basi Di Dati(Architetture e Linee Di Evoluzione). McGraw Hill, 2003.
[8] Ramez Elmasri, Shamkant B. Navathe.
Fundamentals of Database Systems, Fourth Edition. Addison Wesley,2003.
[9] Tamer Ozsu, P. Valduriez.
Principles of Distributed Database Systems. Prentice Hall, 1999.
63
BIBLIOGRAFIA
[10] Christian Nagel.
Professional C# 2005. Wrox Press, 2005.
[11] [Hunt]) Andrew Hunt, David Thomas.
Pragmatic Unit Testing in C# with NUnit. The PragmaticProgrammers, 2004.
[12] Kent Beck, Cynthia Andres.
Extreme Programming Explained: Embrace Change (2nd Edition).Addison-Wesley Professional, 2004.
64