Tesi - Sviluppo di un'Applicazione Enterprise per la Gestione di elettrodomestici

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


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


UTENTE GENERICO

RICERCA

ELETTRODOMESTICO

Figura 1.2. Use Case Diagram Utente Generico

TERMINALISTA

INSERISCI, MODIFICA, ELIMINA

FAMIGLIA


CATEGORIA


FORNITORE


ELETTRODOMESTICO

<<include>>

Figura 1.3. Use Case Diagram Terminalista

4


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


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


• 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


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


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


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


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


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


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


- 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


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


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


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)



- Base Lavello (DimesioniBase)



- Gruppo Frigo (Gruppo)



19


- Tipologie (TipoElettro)

- Storico (CodEsternoOld, DataVigoreOld)



- Fornitore (NomeFornitore, Sconto, AumPercentuale, MoltAListino,MoltNonAListino, MoltFuturo, PathImmHiRes, PathImmLowRes)

- Famiglia (Descrizione, Dimensione, ClasseEnergetica)



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


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


- 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


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


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


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


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


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


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


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


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


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


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


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


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


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


ElettrodomesticoSQLProviderClass

Methods

Create

Delete

Modify

Read

FamigliaSQLProviderClass

Methods

Create

Delete

Modify

Read

FornitoreSQLProviderClass

Methods

Create

Delete

Modify

Read


FamigliaClass

FornitoreClass

SQLProviderFactoryClass

Methods

GetElettrodomesticoProvider

GetFamigliaProvider

GetFornitoreProvider

MySqlProviderFactoryClass

Methods

GetElettrodomesticoProvider

GetFamigliaProvider


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


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


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


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


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


FornitoreDataProviderClass

Methods

Create

Delete

GetAll

Modify

IFornitoreProviderInterface

Methods

ElettroAccessProviderFactoryClass

Methods

ElettroAccessProviderFactory

GetElettroProvider


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


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


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


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


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


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


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


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


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


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


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


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


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


Figura 6.5. Pattern Data Mapper

60


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


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

Tesi - Sviluppo di un'Applicazione Enterprise per la Gestione di elettrodomestici

Documents

Transcript of Tesi - Sviluppo di un'Applicazione Enterprise per la Gestione di elettrodomestici