Tesi di Laurea - unipr.it · 2017-01-05 · La presente tesi di Laurea Triennale e stata sviluppata...

UNIVERSITA DEGLI STUDI DI PARMA

Facolta di Scienze Matematiche, Fisiche eNaturali

Corso di laurea triennale in Informatica

Tesi di Laurea

Accesso a basi di dati con una piattaformaORM

Candidato:Simone Bianchi

Relatore:Chiar.mo Prof. Giulio Destri

Co-relatore:Ing. Alberto Picca

Anno accademico 2008—2009

Ringraziamenti

Desidero innanzitutto ringraziare il Prof. Giulio Destri e l’Ing. Alberto Pic-ca per la disponibilita in modo piu assoluto avuta e per avermi permesso losvolgimento del mio stage formativo presso la ditta Area Solutions Providerubicata a Casalmaggiore—Parma. Ho appresso le basi per lo sviluppo di soft-ware a livello professionale e impostando la stesura della mia tesi. RingrazioCarlo e Donatella in modo speciale per essermi stato molto vicini e per avermisupportato materialmente e moralmente. Un altro grosso ringraziamento vaad Adamo, Stina e Paolo per essermi stati vicini. Ringrazio i miei compagni diUniversita Maria Chiara, Davide, Fede, Marina, Cecilia, Paolo, Fabio, Sparty,Alessandro U., Alessandro T., Lucia, con cui ho passato questi anni di studioinsieme. Desidero ringraziare anche altri miei amici, in modo speciale Stefanoe Marcello, per tutta la disponibilita e l’amicizia avuta nei miei confronti.

Desidero concludere con un sentimento che offro a tutti quelli che come me,cercano di raggiungere obiettivi che sono importantissimi nella vita. Lo studioe uno strumento e la cultura ne fa padrona. I CARE, concludo con questasemplice frase che significa Me ne importa. Ho voluto scrivere questa fraseperche credo che per fare una cosa bisogna che te ne importi, se no diventauna cosa fatta male e non ti servira a niente nella crescita personale di ognunodi noi.

i

Indice

Ringraziamenti i

Indice iii

Introduzione vIl contesto del problema . . . . . . . . . . . . . . . . . . . . . . . . . v

1 Il problema della persistenzadei dati 11.1 Programmazione orientata agli oggetti . . . . . . . . . . . . . . 11.2 Persistenza dei dati . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Survey sulle soluzioni esistenti per la persistenza . . . . . . . . 61.4 L’importanza dei RDBMS . . . . . . . . . . . . . . . . . . . . . 81.5 Modello a oggetti vs modello relazionale . . . . . . . . . . . . . 121.6 Il disaccoppiamento di impedenza . . . . . . . . . . . . . . . . . 131.7 Le soluzioni possibili . . . . . . . . . . . . . . . . . . . . . . . . 14

2 Architetture software a oggetti 182.1 I Design Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . 182.2 Il pattern MVC nella progettazione software . . . . . . . . . . . 222.3 Le architetture stratificate ed i loro vantaggi . . . . . . . . . . . 232.4 Classi ed oggetti entita . . . . . . . . . . . . . . . . . . . . . . . 262.5 Algoritmi e strutture dati . . . . . . . . . . . . . . . . . . . . . 292.6 Classi ed oggetti contenitori . . . . . . . . . . . . . . . . . . . . 392.7 Le soluzioni informatiche dato-centriche . . . . . . . . . . . . . 442.8 Gli ORM ed il loro ruolo . . . . . . . . . . . . . . . . . . . . . . 492.9 Implementazione di un ORM : Il pattern Data Mapper . . . . . 50

3 Soluzioni nel mondo .NET: Nhibernate 513.1 Il mondo .NET . . . . . . . . . . . . . . . . . . . . . . . . . . . 513.2 Le DataTable e le loro caratteristiche . . . . . . . . . . . . . . . 543.3 Rappresentazioni in memoria: DataTable vs ArrayList di ogget-

ti entita . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.4 Introduzione a Nhibernate . . . . . . . . . . . . . . . . . . . . . 593.5 Scenari di applicazione . . . . . . . . . . . . . . . . . . . . . . . 70

iii

iv Indice

4 Realizzazione del mapper automatico per Nhibernate 824.1 UML e metodologie per la progettazione del software . . . . . . 824.2 Obiettivi del progetto . . . . . . . . . . . . . . . . . . . . . . . 874.3 Analisi, progettazione ed implementazione . . . . . . . . . . . . 884.4 Il progetto compiuto . . . . . . . . . . . . . . . . . . . . . . . . 92

5 Realizzazione del prototipo operativo 1095.1 Le entita e la base di dati utilizzata . . . . . . . . . . . . . . . 1095.2 Versione con Query automatiche . . . . . . . . . . . . . . . . . 1115.3 Versione con Nhibernate . . . . . . . . . . . . . . . . . . . . . . 123

6 Confronto di prestazioni 129

7 Conclusioni 1507.1 Bilancio del lavoro svolto . . . . . . . . . . . . . . . . . . . . . 1507.2 Esperienze e conoscenze acquisite . . . . . . . . . . . . . . . . . 1507.3 Espansioni future . . . . . . . . . . . . . . . . . . . . . . . . . . 150

Bibliografia 152

Introduzione

La presente tesi di Laurea Triennale e stata sviluppata dal candidato dopoun periodo di tirocinio svolto presso l’azienda informatica Area SolutionsProviders S.r.l., nella sede operativa Lombardia Est ed Emilia, sotto il co-ordinamento dell’Ing. Alberto Picca, e con la supervisione del Prof. GiulioDestri.

Il contesto del problema

Nello sviluppo di sistemi informatici si sono affermate numerose tecnologie,che vanno utilizzate in modo combinato e, possibilmente sinergico.

Da una parte, i sistemi di gestione di basi di dati relazionali consentonouna gestione efficiente ed efficace di dati persistenti, condivisi e transazion-ali [1]. Dall’altra, gli strumenti e i metodi orientati agli oggetti (linguaggi diprogrammazione, ma anche metodologie di analisi e progettazione) consentonouna sviluppo efficace della logica applicativa delle applicazioni [2].

E utile in questo contesto spiegare che cosa s’intende per sistema informa-tivo e sistema informatico.

• Sistema informativo: L’insieme di persone, risorse tecnologiche, pro-cedure aziendali il cui compito e quello di produrre e conservare le infor-mazioni che servono per operare nell’impresa e gestirla. (M. De Marcoin [3])

• Sistema informatico: L’insieme degli strumenti informatici utilizzatiper il trattamento automatico delle informazioni, al fine di agevolare lefunzioni del sistema informativo. Ovvero, il sistema informatico rac-coglie, elabora, archivia, scambia informazione mediante l’uso delle tec-nologie proprie dell’Informazione e della Comunicazione (ICT ): cal-colatori, periferiche, mezzi di comunicazione, programmi. Il sistemainformatico e quindi un componente del sistema informativo.

La costruzione dell’informazione ed il suo uso entro l’azienda puo avvenireseguendo questi passi, in base alla classificazione di G. Bellinger, N. Shedroffed altri, definita in [4] e [5]:

• Dati: I dati sono materiale informativo grezzo, non (ancora) elaboratoda chi lo riceve, e possono essere scoperti, ricercati, raccolti e prodotti.

v

vi INTRODUZIONE

Sono la materia prima che abbiamo a disposizione o produciamo percostruire i nostri processi comunicativi. L’insieme dei dati e il tesoro diun ’zazienda e ne rappresenta la storia evolutiva [6].

• Informazione: L’informazione viene costruita dai dati elaborati cog-nitivamente, cioe trasformati in un qualche schema concettuale succes-sivamente manipolabile e usabile per altri usi cognitivi. L’informazioneconferisce un significato ai dati, grazie al fatto che li pone in una relazionereciproca e li organizza secondo dei modelli. Trasformare dati in infor-mazioni significa organizzarli in una forma comprensibile, presentarli inmodo appropriato e comunicare il contesto attorno ad essi.

• Conoscenza: La conoscenza e informazione applicata, come un sensocomune, o non comune, che sa quando e come usarla. E attraverso l’es-perienza che gli esseri umani acquisiscono conoscenza. E grazie alle espe-rienze fatte, siano esse positive o negative, che gli esseri umani arrivanoa comprendere le cose. La conoscenza viene comunicata sviluppandointerazioni stimolanti, con gli altri o con le cose, che rivelano i percor-si nascosti e i significati dell’informazione in modo che possano essereappresi dagli altri. La conoscenza e fondamentalmente un livello di co-municazione partecipatorio. Dovrebbe rappresentare sempre l’obiettivoa cui tendere, poiche consente di veicolare i messaggi piu significativi.

Le informazioni ottenute dall’elaborazione dei dati devono essere salvateda qualche parte, in modo tale da durare nel tempo dopo l’elaborazione. Perrealizzare questo scopo viene in aiuto l’informatica.

Per informatica si intende il trattamento automatico dell’informazionemediante calcolatore (naturale o artificiale). Philippe Dreyfus

All’inizio di questo capitolo e stato accennato che nello sviluppo dei sistemiinformatici si sono affermate diverse tecnologie e che, in particolare, l’uso disistemi di gestione di basi di dati relazionali comporta una gestione efficaceed efficiente di dati persistenti.

Per persistenza di dati in informatica si intende la caratteristica dei datidi sopravvivere all’esecuzione del programma che li ha creati. Se non fossecosi, i dati verrebbero salvati solo in memoria RAM e sarebbero persi allospegnimento del computer.

Nella programmazione informatica, per persistenza si intende la possibilitadi far sopravvivere strutture dati all’esecuzione di un programma singolo. Oc-corre il salvataggio in un dispositivo di memorizzazione non volatile, come peresempio su un file system o su un database. Nel capitolo 1 si vedranno le prob-lematiche e le possibili soluzioni che si hanno per persistere i dati, mostrandol’importanza di database relazionali. Dal capitolo 2 in avanti si vedranno

IL CONTESTO DEL PROBLEMA vii

delle caratteristiche di una tecnica di programmazione per convertire dati fraRDBMS e linguaggi di programmazione orientati agli oggetti. Quindi per per-sistere i dati entro un database relazionale. Questa tecnica di programmazioneprende il nome di ORM, ovvero di Object-Relation mapping.

Capitolo 1

Il problema della persistenzadei dati

In questo capitolo viene introdotto il problema della persistenza dei dati. Sivedra anche come lo sviluppo di applicazioni orientate agli oggetti richiedequasi sempre di memorizzare lo stato degli oggetti in una base di dati. Saradimostrata l’importanza dei RDBMS per la gestione della persistenza dei datie si vedra qualche soluzione possibile.

1.1 Programmazione orientata agli oggetti

Il computer e una macchina capace di eseguire algoritmi generici descrittiattraverso un linguaggio noto come codice macchina. Purtroppo il linguag-gio macchina e poco espressivo in quanto descrive, attraverso codici binari,semplicemente istruzioni elementari aritmetiche e logiche o di input/outputdirettamente comprensibili dalla CPU.

E nata l’esigenza di esprimere gli algoritmi attraverso concetti e simboli piuvicini alla mente umana. I linguaggi di programmazione servono a questo. Unlinguaggio di programmazione e un testo piu facilmente leggibile da un essereumano che sara convertito cda un programma apposito (compilatore) in uncodice macchina dal medesimo significato. La programmazione proceduralee stato il primo paradigma di programmazione: infatti descrive gli algoritmicome una sequenza di operazioni da fare; a seconda del linguaggio le operazionierano le stesse del hardware (Assembly) oppure a piu alto livello (LinguaggioC).

Es. Apri il frigorifero, prendi l’uovo, rompi l’uovo nella padella, accendi ilfuoco, cuoci l’uovo e servi nel piatto.

La programmazione procedurale presenta dei limiti: i programmi nel tem-po sono diventati sempre piu complessi e programmando con questo stile nonsi riusciva piu a riutilizzare il codice e c’e stata la difficolta di adattarlo adesigenze che possono mutare in corso d’opera.

Per ridurre questi problemi, e nato il paradigma di programmazione ori-entata agli oggetti: invece di semplicemente descrivere i passi per risolvere iproblemi, si cerca di spezzare la realta in oggetti e programmare le operazionipossibili di ogni oggetto indipendentemente. Gli oggetti sono poi messi in

1

2CAPITOLO 1. IL PROBLEMA DELLA PERSISTENZA

DEI DATI

Figura 1.1: Un uovo nella realta un’istanza della classe uova

relazione per la risoluzione del problema, ma gli algoritmi relativi ai singolioggetti ed implementati entro i metodi interni di ogni oggetto sono facilmenteriutilizzabili.

Tornando all’esempio dell’uovo, usando il paradigma OOP si potrebbe pro-grammare le varie operazioni relative all’uovo in modo separato del resto delprogramma. In questo modo l’attenzioe si focalizza sull’uovo come entita delmondo reale e tutto il resto divemta solo l’insieme delle condizioni al contorno(vedi fig. 1.1).

Negli ultimi anni sempre piuOB lo sviluppo del software si basa sul paradig-ma di programmazione orientata agli oggetti OOP. Esso introduce un mododiverso e, se si vuole, piu efficiente per strutturare cil codice e la logica applica-tiva in esso contenuta. I primi linguaggi di programmazione che supportanoquesto paradigma sono stati progettati negli anni ’70 e ’80, come per esem-pio Simula1, Simula67 e SmallTalk. Ma e nella seconda meta degli anni’80che si diffondono anche nuove metodologie di programmazione piu adatte pergestiree problemi reali piu complessi. A fine anni’80 vede la luce un altrolinguaggio usatissimo, il C++, creato da Bjarne Stroustrup, in cui vengonointrodotti concetti Object-Oriented nel linguaggio di programmazione C.

Il grosso vantaggio dell’approccio Object-Oriented rispetto agli altri paradig-mi di programmazione consiste nel fatto che, per strutturare le applicazioni,lo sviluppatore si trova ad utilizzare una logica che e molto vicina a quella chee la percezione comune del mondo reale.

Pensare ad oggetti significa infatti saper riconoscere gli aspetti che carat-terizzano una particolare realta e saper fornire di conseguenza una rappresen-tazione astratta in un’ottica OOP.

Semplicemente, definiamo i concetti di oggetto e classe. Una classe e un’as-trazione di uno degli aspetti della realta che ci interessa. Questa astrazioneavviene tramite la definizione di attributi, che rappresentano i possibili statidell’aspetto in questione, e funzioni, che rappresentano le azioni possibili daparte di quell’aspetto e che, quindi, si possono fare con le istanze della classerappresentante tale aspetto. Un oggetto e una istanza di una classe, ovvero euna n-upla di valori memorizzati negli attributi, che occupa uno spazio entro

1.1. PROGRAMMAZIONE ORIENTATA AGLI OGGETTI 3

la memoria di lavoro del programma, tipicamente la memoria RAM. La suaclasse definisce come sono organizzati i dati di questa memoria, possiede tut-ti gli attributi definiti nella classe, ed essi hanno un valore, che puo mutaredurante l’esecuzione del programma, cosı come avviene per le variabili di unprogramma procedurale.

Gli oggetti e le classi di un sistema orientato agli oggetti si basano suiprincipi di [7]:

• Information Hiding: La descrizione interna dei dati di un oggetto edel suo funzionamento, non deve essere visibile all’esterno, ovvero all’u-tente, ma e resa accessibile soltanto definendone opportune interfacceben definite. Nei moderni linguaggi orientati agli oggetti vi sono diversilivelli di protezione delle informazioni (private, protette, pubbliche). In-oltre e bene notare che esiste una differenza concettuale tra InformationHiding e Incapsulamento. L’information hiding e il principio teorico sucui si basa la tecnica dell’incapsulamento. Con la tecnica dell’incap-sulamento si puo vedere l’oggetto in esame come una black-box, cioeuna scatola nera di cui, attraverso l’interfaccia si sa cosa fa e come in-teragisce con l’esterno ma non come lo fa, ossia l’implementazione deicomportamenti a livello di codice risulta totalmente nascosta all’esternodell’oggetto. L’incapsulamento contribuisce ai vantaggi della program-mazione ad oggetti: (indipendenza), (robustezza) e (riusabilita deglioggetti creati).

• Identita dell’oggetto: Ogni oggetto dispone di un’identita univocavalida in tutto il sistema. L’uguaglianza di due oggetti implica che tuttigli attributi hanno il medesimo valore, ma gli oggetti non hanno neces-sariamente la stessa identita. Due oggetti identici sono lo stesso ogget-to. L’identita e spesso espressa attraverso il concetto di identificatoreunivoco di un oggetto o Object IDentifier (OID).

• Ereditarieta: Gli oggetti con comportamenti simili e/o con strutturedati simili possono ereditare le loro proprieta e funzioni. Pensiamo peresempio ad una classe Cane che eredita da una classe Animale. Il Canee un animale. Questo tipo di relazione si chiama IS A e la piu usatanella programmazione orientata agli oggetti. Ne esistono delle altre, maun altra comunemente usata e la relazione per contenimento chiamataHAS A. Una classe che contiene un’istanza di un altra classe.

• Polimorfismo: I metodi con gli stessi nomi, possono avere una seman-tica diversa, secondo il contesto in cui vengono richiamati (concetto dioverriding).


DEI DATI

1.2 Persistenza dei dati

Nell’introduzione abbiamo parlato di cosa significa persistere i dati. Adessoprima di addentrarci sulle soluzioni esistenti per la persistenza, vediamo comesi rappresenta l’informazione in informatica.

Per far si che l’informazione esista nel mondo fisico, e necessario rappre-sentarla in modo fisico [6].

Puo essere rappresentata come variazioni di grandezze fisiche entro op-portuni supporti fisici. Per poterla immagazzinare e trasmetterla, sono nec-essari supporti fisici. L’immagazzinamento dell’informazione viene realizzatoattraverso archivi cartacei oppure attraverso archivi informatici. Anche latrasmissione dell’informazione puo aver luogo attraverso canali “tradizionali”come la posta cartacea o il fax o attraverso canali digitali come Internet ed ivari meccanismi di comunicazione in essa contenuti.

In informatica, l’informazione viene rappresentata e misurata come insie-mi di byte. L’unita elementare di informazione e la quantita di informazioneottenuta da un supporto che puo contenere al piu due configurazioni diverse.Essa viene chiamata bit. Esistono codifiche associate agli standard che asseg-nano significati particolari a tali valori, per esempio il codice ASCII associaai valori da 0 a 255 rappresentati dai byte le lettere (maiuscole e minuscole)dell’alfabeto latino internazionale, le lettere accentate, le cifre da 0 a 9, i segnidi interpunzione, parantesi, simboli matematici, caratteri di controllo tra qualicito l’a capo e il fine riga.

Poiche sempre piu spesso le applicazioni sono realizzate ad oggetti e neces-sario rendere persistenti alcune oggetti di alcune classi. Esistono diversi modiper persistere gli oggetti:

• Base di dati a Oggetti

• Base di dati relazionale

• Insieme di file

Confrontando le metodologie, la migliore oggi e quella basata sulle basi didati relazionali Vedremo nella prossima sezione l’importanza di esso e che sidimostrera un eccelente immagazzinatore dell’informazione e un modo utileper persistere gli oggetti nel mondo della programmazione OOP.

L’approccio convenzionale alla gestione dei dati e quindi alla loro persis-tenza sfrutta la presenza di archivi o file per memorizzare i dati in modo per-sistente sulla memoria di massa. Un file consente di memorizzare e ricercaredati, ma fornisce solo semplici meccanismi di accesso e di condivisione.

Le procedure scritte in un linguaggio di programmazione sono completa-mente autonome; ciascuna di essa definisce e utilizza uno o piu file privati.Dati di interesse per piu programmi sono replicati tante volte quanti sono i

1.2. PERSISTENZA DEI DATI 5

programmi che li utilizzano. Si noti che operando in questo modo inciampiamosu ridondanza e possibilita di incoerenza.

Per superare questi problemi, sono state concepite le basi di dati, che nonsono altro una collezione organizzata di dati, di interesse per una qualcheapplicazione.

Un sistema di gestione di basi di dati (DBMS) e un sistema software ingrado di gestire collezioni di dati che siano grandi, condivise, e persistenti,assicurando la loro affidabilita e privatezza. Inoltre devono essere efficace eefficienti.

Spieghiamo brevemente queste caratteristiche che deve avere un DBMS.

• Grandi: Le basi di dati possono avere dimensioni molto piu grandidella memoria centrale disponibile. Quindi i DBMS devono prevedereuna gestione dei dati in memoria secondaria.

• Condivise: Applicazioni e utenti diversi devono poter accedere ai daticomuni. Cosi facendo si riduce la ridondanza dei dati e si riduce anchepossibilita di inconsistenze. I DBMS dispongono di un controllo di con-correnza che serve nel garantire l’accesso condiviso ai dati da parte dimolti utenti che operano contemporaneamente.

• Persistenti: Le basi di dati sono persistenti, ovverro hanno un tempodi vita che non e limitato a quello delle singole esecuzioni dei program-mi che le utilizzano. Ricordo che, i dati gestiti da un programma inmemoria centrale hanno una vita che inizia e termina con l’esecuzionedel programma. Tali dati non sono persistenti.

• Affidabilita: Capacita del sistema di conservare sostanzialmente intat-to il contenuto della base di dati in caso di malfunzionamenti hardware osoftware. I DBMS devono offrire politiche di backup e disaster recovery.

• Privatezza: Attraverso meccanismi di autorizzazione, l’utente, riconosci-uto in base ad un nome utente, viene abilitato a svolgere determinateazioni sui dati.

• Efficienza: Capacita di svolgere le operazioni utilizzando un insieme dirisorse (spazio e tempo) che sia accettabile per gli utenti.

• Efficacia: Capacita della base di dati di rendere produttive, in ognisenso, le attivita dei suoi utenti.

Alcune delle caratteristiche dei DBMS sono gia garantite, per esempio,dai file. Possiamo quindi vedere un DBMS come concepito e realizzato perestendere le funzioni dei file systems.


DEI DATI

1.3 Survey sulle soluzioni esistenti per lapersistenza

In questa sezione vengono illustrate alcune soluzioni esistenti per gestire lapersistenza dei dati. Esistono diversi meccanismi o, per meglio dire, implemen-tazioni della persistenza. Il primo meccanismo e il concetto di serializzazionee deserializzazione.

La serializzazione e un meccanismo che permette la trasformazione auto-matica di oggetti (di qualunque complessita) in una sequenza di byte. In altritermini, e un meccanismo che permette di salvare un oggetto in un supportodi memorizzazione lineare, per esempio in un’area di memoria o in un file,o per trasmetterlo su una connessione di rete, per esempio in un socket. Inche forma puo essere la serializzazione? Una forma e quella binaria, abbiamodetton che essa trasforma automaticamente gli oggetti in sequenza di byteoppure in un altra forma piu leggibile ad un essere umano, per esempio informato XML.

Il processo inverso, detto di deserializzazione consiste nel riportare glioggetti negli stati in cui si trovavano prima di effettuare la serializzazione.

Prima di vedere un esempio, e meglio chiarire perche si utilizza questoapproccio per persistere gli oggetti.

Esistono sostanzialmente due motivi principali: quello di rendere persis-tente lo stato di un oggetto su un supporto di archiviazione in modo da poterricreare una copia esatta in una fase successiva e di inviare l’oggetto per valoreda un dominio dell’applicazione ad un altro.

Per chiarire meglio il concetto di serializzazione ecco un esempio in codiceJava:

public class Serializza public static void main(String[] args)throws IOException Film film = new Film("Fantozzi alla riscossa","Paolo Villaggio", "1994");

//Apriamo lo stream di output (supporto di persistenza) OutputStreamfos = new FileOutputStream("C:\\Film.ser");

//Apertura dello stream di serializzazione ObjectOutputStream oos =new ObjectOutputStream(fos);

//Scrittura su file della sequenza di byte rappresentativa dello//stato dell’oggetto. oos.writeObject(film); oos.close();fos.close();

Come si puo notare nel main(), vien creato un oggetto film ed aperto unostream in output in modo tale che l’oggetto, binarizzato, vien scritto nel fileC:

1.3. SURVEY SULLE SOLUZIONI ESISTENTI PER LA PERSISTENZA7

Film.ser. Lo stream di output funge come supporto alla serializzazione del-l’oggetto e una volta aperto viene scritto sul file la sequenza di byte rappre-sentativa dell’oggetto film.

Ed ecco l’esempio di deserilizzazione corrispondente:

public class Deserializza public static void main(String[] args) //Apertura dello stream di input InputStream fis = newFileInputStream("C:\\Film.ser");

//Apertura stream di deserializzazione ObjectInputStream ois = newObjectInputStream(fis);

//Lettura e assegnazione dell’oggetto Film film =(Film)ois.readObject();

ois.close(); fis.close(); System.out.println(film.toString());

In questo caso viene aperto lo stream di input dell’oggetto film, viene lettobyte per byte dal file Film.ser e viene ricostruita una copia esatta dell’oggettoFilm come era prima di effettuare la serializzazione.

Il meccanismo di serializzazione quindi, permette di salvare lo stato del-l’oggetto nel suo complesso. Cio significa due cose: se in tale oggetto e pre-sente un riferimento ad un altro oggetto viene salvato anche lo stato di taleoggetto, in questo caso si parla di Copia in profondita e non semplicemente ilriferimento ad esso nel qual caso si sarebbe parlato di Copia superficiale.

Questo e il motivo per cui il network di oggetti deve essere costituitada istanze derivanti da classi serializzabili. Nel file binario, questa rete vieneriprodotta esattamente con la stessa configurazione esistente in memoria primadella serializzazione. Gli indirizzi di memoria che sono privi di significato fuoridal contesto dell’esecuzione del programma, sono sostituiti da numeri seriali.Da qui prende il nome di serializzazione.

Chiaramente questo modo di procedere crea sia vantaggi sia svantaggi.Un grosso vantaggio della serializzazione e quello di essere semplice da im-plementare ed e intrinsicamente Object-Oriented. Uno svantaggio e che nondispone di supporto per transazioni e non consente il recupero selettivo deidati (se non dopo aver effettuato la deserializzazione). Un altro svantaggioe quello della gestione della sicurezza e delle versioni dei singoli oggetti, cherisulta molto onerosa. Quindi, questo metodo si puo impiegare per progettiche non presentano particolare criticita in termini di sicurezza e non gestiscanonotevoli quantita di dati.

Esistono diversi altri meccanismi per persistere i dati, per esempio:

• EJB (Enterprise Java Beans)


DEI DATI

• JDBC (Driver per la connessione alla sorgente di base di datiper Java)

• XMI

• JDO

• HIBERNATE (ORM nel mondo Java)

• NHIBERNATE (ORM nel mondo C#)

Molti dei metodi citati usano al loro interno il metodo oggi piu diffuso perimmagazzinare (persistere) i dati, il RDBMS.

1.4 L’importanza dei RDBMS

Prima di dire il perche ancor’oggi i DBMS piu diffusi e piu utilizzati sonoquelli relazionali e bene spiegare i diversi modelli che esistono.Un DBMS e un potente strumento per creare e amministrare grosse moli didati in modo efficiente e permettendo di persistere per un lungo periodo ditempo questi dati. [8].

Le potenzialita che un DBMS offre agli utenti sono:

• Persistenza: Come un file system, un DBMS supporta la memoriz-zazione di grosse mole di dati che esistono indipendentemente dai moltiprocessi che li utilizzano.

• Programmazione di interfacce: Un DBMS permette agli utenti oad un programma applicativo di accedere o modificare dati offrendo unpotente linguaggio per creare delle Query.

• Gestione delle transazioni: Un DBMS supporta accessi ai dati inmodo concorrente. In altri termini, possiamo dire che accessi simultaneicorrispondono a molti processi distinti(transazioni).

Un modello di dati e un insieme di concetti utilizzati per organizzare i datidi interesse e descriverne la struttura in modo che essa risulti comprensibile aun elaboratore [1].

Questo modello si basa sullo standard ANSI/X3/SPARC (vedi Fig. 1.2).Lo standard definisce in pratica tre livelli [9] e [10]:

• Schema esterno: Rappresenta la visione che l’utente e le applicazioniutente devono avere del sistema; si opera per mezzo di SQL creandodelle viste.

1.4. L’IMPORTANZA DEI RDBMS 9

Figura 1.2: Architettura ANSI/SPARC delle moderne basi di dati

• Schema concettuale: Vengono definiti gli elementi costitutivi del database,talora chiamati anche oggetti del database, come le tabelle, le viste,gli indici; si opera anche qui per mezzo di SQL creando le tabelle edefinendone gli attributi.

• Schema interno: Rappresenta il layout fisico dei record e dei campi; siopera per mezzo di un linguaggio di programmazione come il C definendoa basso livello la struttura della tabella.

Questa struttura a livelli consente di avere indipendenza di dati tra unlivello e l’altro. All’interno dello schema concettuale viene definito il modellodei dati ed e qui che esistono diversi modelli.

• Modello gerarchico

• Modello reticolare

• Modello relazionale

• Modello ad oggetti

• Modelli ibridi relazionali e orientati agli oggetti

Il modello gerarchico e stato storicamente il primo modello ad affermarsi.Fu definito negli anni sessanta. In questo modello i dati sono organizzatisecondo strutture ad albero, che si suppone che riflettano in una gerarchiaesistente le entita che appartengono al database e le relazioni che le connettono.Un esempio di questo modello sono i file system che usiamo oggi. Essi sonoorganizzati secondo una struttura ad albero, in uso ormai da decenni.


DEI DATI

Il modello reticolare fu definito negli anni settanta. Esso e basato sull’usodei grafi.

I modelli ibridi sono invece quelli che all’interno del singolo record possoavere degli oggetti, ovvero elementi complessi come altri record o intere tabelle.

Il modello relazionale si basa su due concetti fondamentali, relazione etabella. Il termine relazione proviene dalla matematica, in particolare dal-la teoria degli insiemi. Infatti una relazione e un sottoinsieme del prodottocartesiano. Invece il termine tabella e un concetto semplice e molto intuitivo.

Esso risponde al requisito dell’indipendenza dei dati, che come abbiamovisto nell’introduzione, e uno dei requisiti per poter parlare di DBMS.

Il modello a oggetti e stato introdotto negli anni ottanta come evoluzionedel modello relazionale. Qui troviamo concetti Object-Oriented.I Database relazionali furono proposti da Edgar F. Codd nel 1970 per sem-plificare la scrittura di interrogazioni SQL e per favorire l’indipendenza deidati. Diciamo che un database e relazionale se asserisce alle 12 regole diCodd.

Richiamo qui di seguito le 12 regole:

• Regola 0 : Il sistema deve potersi definire come relazionale, base di dati,e sistema di gestione. Affinche un sistema possa definirsi sistema re-lazionale per la gestione di basi di dati (RDBMS), tale sistema deveusare le proprie funzionalita relazionali (e solo quelle) per la gestire labase di dati.

• Regola 1 : L’informazione deve essere rappresentata sotto forma di tabelle;L informazioni nel database devono essere rappresentate in maniera uni-voca, e precisamente attraverso valori in colonne che costituiscano, nelloro insieme righe di tabelle.

• Regola 2 : La regola dell’accesso garantito: tutti i dati devono essereaccessibili senza ambiguita (questa regola e in sostanza una riformu-lazione de requisito per le chiavi primarie). Ogni singolo valore scalarenel database deve essere logicamente indirizzabile specificando il nomedella tabella che lo contiene, il nome della colonna in cui si trova e ilvalore della chiave primaria della riga in cui si trova.

• Regola 3 : Trattamento sistematico del valore NULL; il DBMS deveconsentire all’utente di lasciare un campo vuoto, o con valore NULL. Inparticolare, deve gestire la rappresentazione di informazioni mancanti equello di informazioni inadatte in maniera predeterminata, distinta daogni valore consentito (per esempio, diverso da zero o qualunque altronumero per valori numerici), e indipendente dal tipo di dato. E chiaro in-oltre che queste rappresentazioni devono essere gestite dal DBMS semprenella stessa maniera.

1.4. L’IMPORTANZA DEI RDBMS 11

• Regola 4 : La descrizione del database deve avvenire ad alto livello logicotramite i metadati.

• Regola 5 : Deve esistere un linguaggio che permetta la gestione dei dati(come SQL).

• Regola 6 : Si possono creare delle viste per vedere una parte dei dati.Queste viste devono essere aggiornabili.

• Regola 7 : Le operazioni che avvengono sul database devono avvenireanche sulle tabelle.

• Regola 8 : I dati memorizzati nel database devono essere indipendentidalle strutture di memorizzazione fisiche.

• Regola 9 : I dati devono essere indipendenti dalla struttura logica deldatabase per garantire la crescita naturale e la manutenzione del database.

• Regola 10 : Le restrizioni sui dati devono essere memorizzate nel database.

• Regola 11 : L’accesso ai dati e indipendente dal tipo di supporto per lalettura o memorizzazione degli stessi.

• Regola 12 : L’accesso ai dati non deve annullare le restrizioni o i vincolidi integrita del linguaggio principale.

Vediamo adesso gli elementi principali che costituiscono un modello re-lazionale.

Come abbiamo detto in precedenza il tutto si basa sul concetto di relazione.Dati n > 0 insiemi A1, ..., An, non necessariamente distinti, il prodot-

to cartesiano di A1, ..., An, indicato con A1 × A2 × ... × An, e costituitodall’insieme delle n-uple (v1, ..., vn) tali che vi ∈ Ai, per1 ≤ i ≤ n.

Una relazione matematica sui domini A1, ..., An e un sottoinsieme delprodotto cartesiano A1 ×A2 × ...×An. Se vogliamo essere meno matematici,una relazione e un insieme di record omogenei, cioe definiti sugli stessi campi.Ad ogni campo e associato un nome, quindi associamo a ciascuna occorrenzadi dominio (A1, ..., An) nella relazione un nome, detto attributo, che descriveil ruolo giocato dal dominio stesso. Per essere piu formali, esiste una cor-rispondenza tra attributi e domini per mezzo di una funzione dom : X −→ A,che associa a ciascun attributo att ∈ X un dominio dom(att) ∈ A che nedefinisce valori discreti o intervalli di valori continui possibili. Prende il nomedi tupla un insieme non ordinato di valori degli attributi.

Le relazioni nei database relazionali vengono rappresentate graficamentetramite le tabelle. Ogni colonna di tale tabella costituisce un attributo. Letuple sono rappresentate dalle righe delle tabelle. Nella fig. 1.3 mostra unesempio di tabella nel mondo dei database relazionali.


DEI DATI

Figura 1.3: Una tabella

In altri termini, un database relazionale e un insieme di tabelle, collegatetramite determinati attributi, che hanno la caratteristica di avere diversi valoriassociati per ogni tupla della tabella e detti chiave primaria. Quando questivengono utilizzati per relazionare (ossia collegare, ponendole in relazione fraloro) due tabelle vengono dette chiavi esterne.

I sistemi informatici richiedono solitamente di gestire alcuni dati in modopersistente e abbiamo visto fino adesso dei modi per persistere (serializzazione,EJB, XML, ecc.). In un’applicazione a oggetti, e necessario rendere persistentialcuni oggetti di alcune classi (vedremo in seguito che queste classi sono spessoindicate col nome di classi entita). Queste classi prendono anche il nome diclassi persistenti. Sono classi che fanno parte della logica applicativa ispiratealle classi concettuali.

Pero, esistono alcuni problemi legati al voler gestire oggetti persistentimediante una base di dati relazionale. Questo problema e noto in letteraturacome Impedance Mismatch o disaccopiamento di impedenza.Vedremo in seguito di che cosa si tratta e di come poterlo risolvere. Perarrivare a spiegare l’importanza dei RDBMS e utile soffermarci un’attimo aconfrontare il modello a oggetti vs il modello relazionale. Da qui si evinceral’importanza dei database relazionali.

1.5 Modello a oggetti vs modello relazionale

I modelli a oggetti costituiscono una promettente evoluzione delle basi di dati.I sistemi a oggetti integrano la tecnologia della base di dati con il paradigmaad oggetti sviluppato nell’ambito dei linguaggi di programmazione.

1.6. IL DISACCOPPIAMENTO DI IMPEDENZA 13

Nelle basi di dati a oggetti, ogni entita del mondo reale e rappresentata daun oggetto. Per esempio: dati multimediali, cartine geografiche, ecc [11]. Danotare che e difficile pensare ad una struttura relazionale per queste entita. Iprogrammatori che utilizzano il paradigma OOP e hanno necessita di salvarei propri oggetti, possono scegliere di salvarli su un database relazionale; inquesto caso pero bisogna convertire gli oggetti in tabelle con righe e colonne,nel fare questo bisogna mantenere anche la descrizione e le relazioni delle varieclassi nonche lo schema relazionale e il mapping delle classi nel db relazionale.Se al contrario scegliamo una base di dati a oggetti, i programmatori pos-sono salvare gli oggetti cosi come sono e dovranno solamente preoccuparsi dimodellare una base di dati a oggetti che descriva correttamente la realta fisicache deve immagazzinare nel database. La differenza tra questi due modellista nella mancanza di interoperabilita. Cio significa che si puo accedere adun ODBMS solo per mezzo del DBMS che lo gestisce. Per esempio, ad un databaseGoods si puo accedere solo per mezzo di un programma scritto per Goods e nonqualcos’altro.

1.6 Il disaccoppiamento di impedenza

Le informazioni memorizzate in un database hanno una natura persistente: ognitabella sul disco conserva il suo stato (ossia il valore degli attributi nelle tuple) trasessioni di lavoro successive. Pertanto un programmatore che sfrutta un linguaggio diprogrammazione ad oggetti e che costruisce la classe tabella dovra fare in modo chetale classe sia persistente. Non ci deve essere nessuna differenza tra il trattamentofra oggetti transitori e oggetti persistenti. Cosi facendo, la persistenza e una propri-eta che non dipende dal particolare tipo di oggetto, ma e una proprieta attribuilead ogni classe di oggetti. Bisogna quindi che la classe che deve essere persistentedeve prevedere opportuni metodi per gestire la persistenza. L’oggetto persistentea differenza di un oggetto non persistente, deve essere in grado automaticamentedi rileggere da una memoria di massa le informazioni sul suo stato. dei probleminel persistere dei dati entro un database. Questo comporta la necessita di deciderein generale come implementare politiche di persistenza e in particolare quali scelteprogettuali fare nel programma specifico che si sta realizzando.

Un programmatore che utilizza un linguaggio di programmazione orientato aglioggetti (C++, Java, C#, J#, Vb.net, Eiffell, ecc.) gradisce nella maggior parte deicasi utilizzare lo stesso approccio anche quando salva i dati sul database. Cioe rendele classi persistenti. Il problema che e noto in letteratura sotto il nome di impedancemismatch [12], sta a significare il problema dell’integrazione tra SQL (linguaggiodichiarativo, in cui non si pensa all’algoritmo che implementa la ricerca, ma solo alrisultato della ricerca) e i normali linguaggi di programmazione OOP che non sonodichiarativi. Esiste anche il problema legato alla conversione dei dati come tornatidall’SQL in dati che possono essere interpretati dall’ambiente OOP, come Java oC++. Quindi questo dissaccoppiamento di impedenza porta a differenze sui tipi didato primitivi (anche se molte differenze sono risolte dai driver di comunicazione traprogramma e RDBMS) e, soprattutto, differenze tra i riferimenti interni al programmaad oggetti e gli insiemi di chiavi esterne che collegano i dati nel RDBMS.


DEI DATI

Figura 1.4: Un esempio di interazione sql immerso nelle classi

1.7 Le soluzioni possibili

Esistono diverse soluzioni per impedire il verificarsi del problema del disaccopiamentod’impedenza.

Una prima possibilita e quella di rendere persistente una classe scrivendo diret-tamente il codice SQL dentro la classe stessa (vedi fig. 1.4).

Questo approccio presenta alcuni ostacoli. Il primo problema deriva dal fattoche SQL e un linguaggio ricco, con una propria sintassi. Sono state proposte duesoluzioni:

1. SQL Embedded

2. CLI (Call Level Interface)

SQL Embedded prevede di introdurre direttamente nel programma sorgente scrit-to nel linguaggio ad alto livello le istruzioni SQL, distinguendole dalle normali istruzionitramite opportuni separatori e/o sintassi appropriate. Di norma in questo approccio lacompilazione e preceduta dall’esecuzione di un apposito preprocessore che riconoscerale istruzioni SQL e sostituira a esse un insieme opportuno di chiamate ai servizi deiRDBMS, tramite una libreria specifica per ogni RDBMS.

Le CLI sono un insiemi di funzioni messe a disposizione per il programmatoreche permettano di interagire con il DBMS. Rispetto al SQL Embedded con questalibreria di funzioni si dispone di uno strumento piu flessibile, meglio integrato conil linguaggio di programmazione, con l’incoveniente di dover gestire esplicitamenteaspetti che in SQL Embedded erano risolti dal preprocessore. Le CLI si usano inquesto modo:

1. Si utilizza un servizio della CLI per creare una connessione con il DBMS.

2. Si invia sulla connessione un comando SQL, in forma di stringa, che rappresentala richiesta.

1.7. LE SOLUZIONI POSSIBILI 15

Figura 1.5: Un esempio di utilizzo di data classes [ERRORE: 2 FIGUREUGUALI]

3. Si riceve come risposta del comando una struttura relazionale in un opportunoformato (col linguaggio C# usato nella parte sperimentale della corrente tesi euna DataTable); la CLI dispone di un certo insieme di primitive che permettonodi analizzare e descrivere la struttura del risultato del comando.

4. Al termine della sessione di lavoro, si chiude la connessione e si rilasciano lestrutture dati utilizzare per la gestione del dialogo.

Una seconda soluzione e quella di scrivere il codice SQL in appossite classi disupporto (detti data classes) alle classi persistenti (vedi fig. 1.5).

Una terza soluzione e quella di delegare la gestione della persistenza degli oggettiad un modulo apposito, detto PL - Persistence Layer (vedi fig. 1.6).

Un PL nasconde i dettagli della persistenza (nonche della condivisione e dellatransazionalita) al programmatore. Gli Object-Relational Mapper (ORM) sono unacategoria molto diffusa di PL e nel corso di questa tesi viene usato un ORM opensource chiamato NHibernate.

Qui di seguito ecco un esempio di codice che fa uso di un PL:

PersistenceManager pm = new PersistenceManager(...); Transaction tx= pm.currentTransaction(); PersonaID pID = new PersonaID("1");Persona p = (Persona) pm.getObjectByID(pID); p.setStipendio(1000);tx.commit();

Persona e una classe entita, che fornisce soltanto metodi get e set, cioe che consentonoaccesso pubblico in lettura e scrittura sui suoi attributi privati. Si puo dire che inquesto esempio esiste un isomorfismo tra tabella nel mondo dei database relazionalee la classe nel mondo OOP. Questo importante concetto verra dettagliato in seguito.


DEI DATI

Figura 1.6: Un esempio di utilizzo del PL

Un PL nasconde al programmatore i dettagli di come gli oggetti vengono resipersistenti. Esistono tre approcci principali per la realizzazione di un PL:

1. O/R Mapping

2. R/O Mapping

3. Incontro al centro

Nel primo approccio, il programmatore indica in un file di configurazione qualisono le classi che vanno rese persistenti e quindi a partire da questi file viene generatala base di dati e le data classes per le classi persistenti.

Nel secondo approccio, il programmatore indica in un file di configurazione labase di dati relazionale di interesse e quindi, a partire da questi file, vengono generatele data classes per accedere e modificare le tuple delle relazioni delle base di dati.

Nell’ultimo approccio, le classi persistenti e la base di dati vengono progettate erealizzate in modo indipendente. Il programmatore indica in un file di configurazionele corrispondenze tra classi persistenti e base di dati e quindi a partire da questi filevengono generate le data classes per le classi persistenti.Esistono altre soluzioni a questo problema:

1. Cursori

2. Uso di una struttura del tipo insieme di righe

Un cursore e uno strumento che permette a un programma di accedere alle righedi una tabella una alla volta; esso viene definito su una generica query. La sintassiSQL per la definizione di un cursore e la seguente:

declare NomeCursore [scroll] cursor for SelectSQL [for <readonly|update [of Attributo, Attributo]>]

1.7. LE SOLUZIONI POSSIBILI 17

E importante analizzare la semantica dell’istruzione:

1. declare cursor : Definisce un cursore, associato ad una particolare query sullabase di dati.

2. scroll : Opzionale, se si vuole permettere al programma di muoversi “libera-mente” sul risultato della query.

3. for update: Opzionale, specifica se il cursore deve essere utilizzato nell’ambito diun comando di modifica, permettendo di specificare eventualmente gli attributiche saranno oggetto del comando di update.

La seconda soluzione consiste nell’utilizzare un linguaggio di programmazione cheabbia a disposizione dei costruttori di dati piu potenti e in particolare riesce a gestirein modo naturale una struttura del tipo insieme di righe. Esempi che adottano questasoluzione sono: ADO, ADO.net, JDBC.

Per meglio chiarire gli aspetti pratici risultanti per i programmatori e bene il-lustrare brevemente le caratteristiche di alcune tra le soluzioni oggi maggiormentediffuse:

1. ODBC : Interfaccia standard che permette di accedere a basi di dati in qualunquecontesto, realizzando interoperabilita con diverse combinazioni DBMS - SistemiOperativi - Reti.

2. OLEDB: Soluzione proprietaria Microsoft, basata sul metodo COM, che perme-tte ad applicazioni Windows di accedere a sorgenti dati generiche, ovvero nonsolo DBMS. Vedremo che questa soluzione sara usata largamente nel progettodi generazione di strati software che sara descritta nel capitolo 5.

3. ADO: Soluzione proprietaria Microsoft che permette di sfruttare i servizi OLEDB,utilizzando un’interfaccia record-oriented.

4. ADO.NET: Soluzione proprietaria Microsoft che adatta ADO alla piattaforma.NET; offre un’interfaccia set-oriented e introduce i DataAdapter.

5. JDBC: Soluzione per l’accesso ai dati in Java sviluppata da Sun Microsystems;offre in quel contesto un servizio simile a ODBC.

In particolare vediamo ora ADO.NET. In ADO.NET i dati vengono gestiti tramiteDataSet i quali costituiscono dei contenitori di oggetti (in particolare entro i DataSetsi trovano le DataTable, che rappresentano in memoria le normali tabelle del RDBMScon tutte le loro caratteristiche). Parleremo piu in dettaglio di come sono rappresen-tate in memoria le DataTable e il loro utilizzo entro il contesto degli ORM e delprogetto creato. Un DataSet permette anche la gestione di relazioni e vincoli di in-tegrita tra gli oggetti al suo interno. Questa flessibilita e resa possibile dal fatto chei DataSet rappresentano strutture che risiedono pienamente nell’ambiente del pro-gramma. Per concludere questa breve descrizione, aggiungo che il coordinamento trai DataSet e le sorgenti dati avviene tramite dei componenti specifici, che prendono ilnome di DataAdapter.

Capitolo 2

Architetture software a oggetti

In questo capitolo vengono introdotte le architetture ad oggetti e, in particolare, iDesign Pattern e il loro utilizzo. Si vedranno come le architetture stratificate sonovantaggiose nella progettazione e realizzazione di progetti di medie-grandi dimensioni.Inoltre si vedranno i primi ingredienti nella realizzazione di un ORM: le classi e glioggetti entita. Sara presentato infine il ruolo degli ORM come strumento dato alprogrammatore per legare il mondo della programmazione a oggetti con il mondo deidatabase.

2.1 I Design Pattern

Progettare sistemi secondo il paradigma Object-Oriented non e facile e creare soft-ware Object-Oriented che sia anche riutilizzabile e ancora piu difficile: una soluzionedovrebbe essere specifica al problema ma abbastanza generale da poter essere riu-tilizzata. Di solito e molto difficile creare del software che risponda alle esigenzefunzionali alla prima scrittura e il programmatore in generale impiega molto tempoad imparare a creare del buon codice Object-Oriented. I programmatori esperti soli-tamente non risolvono i loro problemi partendo da zero ma riusano soluzioni o partedi esse, sulle quali hanno lavorato in passato: in questo modo riutilizzano pezzi didesign e di codice che sono consolidati e testati. Il riutilizzo di elementi della fase diprogettazione e l’obiettivo dei design pattern: il semplice riutilizzo del codice portaa degli indiscutibili vantaggi in termini di risparmio di tempo ma il poter usare deipezzi di design si pone ad un livello superiore. Come e noto, la fase di design e unadelle fasi piu impegnative nel ciclo di sviluppo di un’applicazione software mentre lascrittura del codice non e cosı critica: il riutilizzo di micro-architetture nella fase diprogettazione ha dei vantaggi notevoli sia nella fase stessa che nella fase di program-mazione, senza contare i riflessi sulla manutenzione del sistema. Alcune soluzioniper di risolvere dei problemi a livello di progettazione si sono rivelate una costantedi molti progetti, anche in contesti diversi. Da qui l’idea di collezionare e docu-mentare queste soluzioni sicure a dei problemi ricorrenti per migliorare lo sviluppodi un sistema software. Per facilitare il riutilizzo di alcuni elementi di progettazioneche sono gia stati sviluppati si ricorre ai design pattern, che hanno lo scopo di dareun nome, spiegare e valutare pezzi importanti e ricorrenti nella progettazione delsoftware Object-Oriented. I design pattern aiutano a costruire del software che siariusabile ed evitare scelte che compromettano il riutilizzo dello stesso, inoltre pos-sono migliorare la documentazione e la manutenzione di sistemi esistenti, in pocheparole aiutano a progettare in modo giusto in minor tempo. La prima e la piu famosacollezione di design pattern e contenuta nel libro di Gamma [13], piu noto come li-bro della “Gang of 4”. In questo libro sono contenuti e documentati 23 design pattern.

18

2.1. I DESIGN PATTERN 19

Un design pattern sistematicamente da un nome, motiva e spiega un concettogenerale che indirizza un problema di progettazione ricorrente nei sistemi ObjectOriented. Esso descrive il problema, la soluzione, quando applicare la soluzione ele sue conseguenze. Inoltre da suggerimenti sull’implementazione ed esempi. Lasoluzione e personalizzata e implementata per risolvere il problema in un particolarecontesto.

Il problema dell’impedance mismatch che abbiamo visto nel capitolo precedente,puo essere trattato anche per mezzo di pattern. I pattern quindi sono degli schemidi idee [14], ossia soluzioni preconfezionate, provate in diverse situazioni e stan-dardizzate [15]. Essi si concentrano maggiormente sui concetti e meno sull’aspettoimplementativo. I pattern nella programmazione Object-Oriented sono usatissimi.Vedremo che il progetto Generatore Strati Software si basa su un pattern chiamatoMVC. Ma prima di addentrarci in alcuni pattern fondamentali che ricorrono nellostudio degli ORM e nel mio progetto, vediamo alcune caratteristiche dei pattern evediamo come si classificano.

Nel libro dei Gang of four vengono identificati 23 tipi di design pattern, suddivisiin 3 categorie:

1. Pattern strutturali

2. Pattern creazionali

3. Pattern comportamentali

I pattern strutturali consentono di riutilizzare degli oggetti esistenti fornendoagli utilizzatori un’interfaccia piu adatta alle loro esigenze. Qui troviamo:

• Adapter: Converte l’interfaccia di una classe in un’altra permettendo a dueclassi di lavorare assieme anche se hanno interfacce diverse.

• Bridge: Disaccoppia un’astrazione dalla sua implementazione in modo chepossano variare in modo indipendente.

• Composite: Compone oggetti in strutture ad albero per implementare dellecomposizioni ricorsive.

• Decorator: Aggiunge nuove responsabilita ad un oggetto in modo dinamico,e un’alternativa alle sottoclassi per estendere le funzionalita.

• Facade: Provvede un’interfaccia unificata per le interfacce di un sottosistemain modo da rendere piu facile il loro utilizzo.

• Flyweigth: Usa la condivisione per supportare in modo efficiente un grannumero di oggetti con fine granularita.

• Proxy: Provvede un surrogato di un oggetto per controllarne gli accessi.

• Private class data

• Extensibility

I pattern creazionali nascondono i costruttori delle classi e mettono dei metodial loro posto creando un’interfaccia. In questo modo si possono utilizzare oggettisenza sapere come sono implementati.

20 CAPITOLO 2. ARCHITETTURE SOFTWARE A OGGETTI

• Abstract Factory: Provvede un’interfaccia per creare famiglie di oggetti inrelazione senza specificare le loro classi concrete.

• Builder: Separa la costruzione di un oggetto complesso dalla sua rappre-sentazione in modo da poter usare lo stesso processo di costruzione per altrerappresentazioni.

• Factory method: Definisce un’interfaccia per creare un oggetto ma lasciadecidere alle sottoclassi quale classe istanziare.

• Prototype: Specifica il tipo di oggetti da creare usando un’istanza prototipoe crea nuovi oggetti copiando questo prototipo.

• Singleton: Assicura che la classe abbia una sola istanza e provvede un mododi accesso.

• Lazy initialization: E la tattica di instanziare un oggetto solo nel momento incui deve essere usato per la prima volta. E utilizzato spesso insieme al patternfactory method.

I pattern comportamentali forniscono soluzione alle piu comuni tipologie diinterazione tra gli oggetti.

• Chain of responsibility: Evita l’accoppiamento di chi manda una richiestacon chi la riceve dando a piu oggetti la possibilita di maneggiare la richiesta.

• Command: Incapsula una richiesta in un oggetto in modo da poter eseguireoperazioni che non si potrebbero eseguire.

• Iterator: Provvede un modo di accesso agli elementi di un oggetto aggregatoin modo sequenziale senza esporre la sua rappresentazione sottostante.

• Mediator: Definisce un oggetto che incapsula il modo in cui un insieme dioggetti interagisce in modo da permettere la loro indipendenza.

• Memento: Cattura e porta all’esterno lo stato interno di un oggetto senzaviolare l’incapsulazione in modo da ripristinare il suo stato piu tardi.

• Observer: Definisce una dipendenza 1:N tra oggetti in modo che se uno cambiastato gli altri siano aggiornati automaticamente.

• State: Permette ad un oggetto di cambiare il proprio comportamento a secondadel suo stato interno, come se cambiasse classe di appartenenza.

• Strategy: Definisce una famiglia di algoritmi, li incapsula ognuno e li rendeintercambiabili in modo da cambiare in modo indipendente dagli utilizzatori.

• Interpreter: Dato un linguaggio, definisce una rappresentazione per la suagrammatica ed un interprete per le frasi del linguaggio.

• Template method: Permette di definire la struttura di un algoritmo lasciandoalle sottoclassi il compito di implementarne alcuni passi come preferiscono.

• Visitor: Permette di separare un algoritmo dalla struttura di oggetti compostia cui e applicato, in modo da poter aggiungere nuovi comportamenti senza dovermodificare la struttura stessa.

• Single-serving Visitor

2.1. I DESIGN PATTERN 21

• Hierarchical Visitor

• Event Listener

Esistono anche altri tipi di design pattern, ma questi non operano al livello diprogettazione del sistema. Essi sono suddivisi in:

1. Pattern architetturali

2. Pattern di metodologia

3. Pattern di concorrenza

I pattern architetturali operano ad un livello diverso (e piu ampio) rispetto aidesign pattern, ed esprimono schemi di base per impostare l’organizzazione strutturaledi un sistema software. In questi schemi si descrivono sottosistemi predefiniti insiemecon i ruoli che essi assumono e le relazioni reciproche.

Qui si trovano i pattern: Broker, MVC, Repository, Client-Server, Re-flection, Presentation Abstraction Control, Microkernel, Layers, Pipes andFilters e Blackboard.

Nei pattern di metodologia si trovano: Responsibility e Make it run, makeit right, make it fast, make it small.

Nel caso di processi che eseguono contemporaneamente delle attivita su dati con-divisi si parla di concorrenza. Alcuni design pattern sono stati sviluppati per man-tenere sincronizzato lo stato dei dati in tali situazioni. Si parla in tal caso di pat-tern di concorrenza. Essi sono suddivisi in: Active object, Balking, Doublechecked locking, Guarded suspension, Leaders/followers, Monitor object,Read-Write lock, Scheduler, Thread pool, Thread-specific storage, Tokenpassing synchronization e Reactor.

Al suo interno, un pattern e formato da questi quattro elementi:

1. Il nome, che e utile per descrivere la sua funzionalita.

2. Il problema nel quale il pattern e applicabile. Esso spiega il problema e ilcontesto, a volte descrive strutture di classi o a volte il design di sistema. Puoincludere anche una lista di condizioni.

3. La soluzione, che descrive in maniera astratta come il pattern risolve il prob-lema. Descrive anche la responsabilita e le collaborazioni che compongono ilprogetto.

4. Le conseguenze portate dall’applicazione del pattern. Servono per valutare icosti-benefici dell’utilizzo del pattern.

Il nome del pattern Il problema La soluzione Infine le conseguenzeVediamo adesso il pattern architetturale MVC che e stato usato nella proget-

tazione del prototipo Generatore Strati Software (GSS 1.0) realizzato durante lapresente tesi.


Figura 2.1: Schema funzionale MVC

2.2 Il pattern MVC nella progettazione software

Questo modello prevede una netta separazione tra i dati, la rappresentazioni dei datie la logica di funzionamento del sistema [16] e [17].

Questo approccio porta a diversi vantaggi:

1. Separazione dei ruoli e delle relative interfacce;

2. Indipendenza tra business data (model), logica di presentazione (view) e logicadi controllo (controller);

3. Viste diverse per il medesimo model;

4. Maggior semplicita per il supporto a nuove tipologie di client: basta scrivere lavista ed il controller appropriati riutilizzando il model esistente;

Nella figura (fig. 2.1) viene mostrata lo schema funzionale del pattern MVC(Model-View-Controller).

Nella figura si vedono i tre componenti funzionali del MVC: il model, view econtroller.

2.3. LE ARCHITETTURE STRATIFICATE ED I LORO VANTAGGI 23

• Model: Esso individua la rappresentazione dei dati dell’applicazione e le regoledi business con cui viene effettuato l’accesso e la modifica a tali dati. Il modellonon e a conoscenza dei suoi controller e tanto meno delle sue view; non contieneriferimenti ad essi, ma e il sistema che si prende la responsabilita di mantenerei link tra il modello e le sue view e di notificare quest’ultime le variazioni neidati del modello;

• View: E la presentazione visuale dei dati all’utente e interagisce con il mod-ello attraverso un riferimento ad esso. Uno stesso modello puo quindi esserepresentato secondo diverse viste (Form, WPF, Web, Console, ecc);

• Controller:E colui che interpreta le richieste della view in azioni che van-no ad interagire con il model (di cui possiede un riferimento), aggiornandoconseguentemente la view stessa.

La suddivisione in livelli permette di gestire la progettazione e la programmazionedei vari componenti in maniera indipendente tra loro, collegandoli solamente a run-time.

2.3 Le architetture stratificate ed i loro vantaggi

I sistemi software stanno diventando sempre piu complessi e piu grandi. Nell’ambitodella progettazione cresce sempre di piu la necessita della configurazione strutturaledel sistema. In tal modo nasce il concetto di Archittetura Software. Essa vienedefinita come [18]:

L’Archittetura software comprende la descrizione degli elementi partendo daiquali vengono creati i sistemi, le interazioni tra essi, i modelli che ne gestisconola composizione e i limiti rispetto a questi modelli. Un determinato sistema vienedescritto attraverso un insieme di componenti e le interazioni di questi.

Un altra definizione, estremamente pragmatica, di architettura software e laseguente:

L’Architettura software e l’insieme di decisioni progettuali le quali se non sonfattein modo coretto, causeranno il fallimento del progetto.

Prima d’arrivare a definire il concetto di archittetura stratificata e fornirne ivantaggi, e bene capire come si e arrivati alla necessita di ricorrere ad architetturenella strutturazione di un progetto software.

Il problema principale per chi si occupa di software e la manutenzione [6]. Essae definita come la fase che segue l’entrata in servizio di un software.

Il termine manutenzione viene usato tipicamente per descrivere due attivita dis-tinte:

1. Manutenzione evolutiva

2. Manutenzione ordinaria


Figura 2.2: Il Mainframe

La prima rappresenta i cambiamenti che il software deve subire per adattarsialle nuove specifiche dovute a mutamenti dei requisiti funzionali cui il software deverispondere. Il secondo e la rimozione di errori che in realta non avrebbero dovutoessere presenti, ma che sono sfuggiti alle fasi di test prima della messa in produzionedel software stesso. La maggior parte del costo del software sta nella manutenzione.Per ridurre questi costi, si sono sviluppate architetture software via via sempre piustabili.

Inizialmente ci fu il Mainframe. Esso prevedeva che tutto debba essere cen-tralizzato e il Mainframe ne costituiva l’unita centrale, spesso chiamato il cervellone.Ancor’oggi questa tipo di archittetura la troviamo nel settore bancario. A questoMainframe sono collegati un numero abbastanza elevato di terminali, per esempio idiffusissimi IBM 3270. Essi sono privi di sistema operativo, dotati di poca memoriae indipendenti da cio che accade all’interno dei Mainframe. Nella figura 2.2. vienerappresentato un Mainframe.

La manutenzione di questi sistemi con il passare del tempo e diventata semprepiu complessa, conducendo al concetto di legacy.

Con questo termine intendiamo un oggetto di cui non si puo fare a meno, ma chenessuno riesce piu a dominare [6] e [19]. Molto spesso, associata alla legacy c’e poiuna situazione di software ormai inadeguato, che, piu che subire degli aggiornamenti,e soggetto a continue correzioni, spesso non documentate, che rendono le ulteriorimanutenzioni piu difficili di giorno in giorno.

Il mainframe monolitico era destinato a scomparire sia a causa del legacy sia acausa dei problemi di costo di manutenzione e scalabilita. La soluzione di questiproblemi venne trovata ribaltando la situazione ovvero nel diminuire il carico com-putazionale del server e dotare invece il terminale di funzionalita diciamo piu intelli-genti.

Per essere piu formali, possiamo dire che questa architettura e la logica estensione

2.3. LE ARCHITETTURE STRATIFICATE ED I LORO VANTAGGI 25

Figura 2.3: Possibili configurazioni di un sistema Client-Server basato sulmodello 2-Tier

alla programmazione modulare il cui pressuposto base e la separazione di grossi stralcidi codice in tanti parti detti moduli che consentono uno sviluppo piu facile e unamigliore manutenzione; inoltre non e necessario che questi moduli debbano essereeseguiti all’interno dello stesso spazio di memoria.

Questa archittetura va sotto il nome di Client-Server.Il Client e il modulo che esegue le richieste dei servizi e il Server quello che mette

a disposizione i servizi.

In quasi tutte le applicazioni interattive, ossia destinate ad essere utilizzate da unoperatore umano, si possono riconoscere le tre differenti componenti:

1. L’interfaccia utente

2. Il Business-Logic

3. Dati

Nel momento in cui i 3 elementi logici vengono “spalmati” su 2 elementi fisici,l’archittetura prende il nome di 2-Tier. Se consideriamo un ambiente tipicamenteorientato alle basi di dati, possiamo schematizzare i tre livelli appena indicati comein figura 2.3.

Nelle applicazioni 2-Tier i primi due componenti (interfaccia e business-logic) sonounificati e il terzo e separato e rappresenta i servizi a cui accedere (es. base di dati).

Il problema di questa architettura e la scalabilita.Nella figura possiamo vedere tre casi (A, B e C) che rappresentano come una ap-

plicazione 2-Tier puo essere scritta. Purtroppo gran parti dell’applicazioni rientrano


Figura 2.4: I componenti logici di una architettura 3-Tier

nel caso C, dove non c’e una netta separazione fra server e client e ogni tier fa unaparte di quello che dovrebbe fare e una parte di quello che non dovrebbe fare.

Le architetture a 2-Tier col passare degli anni hanno cominciato a dimostrare iloro limiti e gli sviluppatori si sono accorti che non erano piu adatte a supportare ilpeso delle nuove funzionalita proposte dai manager.

Per questi motivi e nata l’architettura 3-Tier, in cui i 3 elementi logici vengonodistribuiti su 3 elementi fisici. Scrivere applicazioni in questa nuova architetturapresenta una complessita decisamente maggiore ma che viene ripagata nel tempo,migliorando molto la manutenzione.

Nella figura 2.4. vengono mostrati i componenti logici di un architettura 3-Tier.Il presentation service gestisce l’interfaccia utente verso il sistema. Il process

service agisce come sorta di buffer tra il livello superiore e quello inferiore. Il dataservice rappresenta di solito il database vero e proprio, quindi sia i dati propriamentedetti sia la logica che consente di aggiornarli, cancellarli e modificarli.

Nella figura 2.5. vengono mostrati invece i componenti fisici di un architettura3-Tier.

A questo punto e possibile descrivere l’architettura stratificata. Come dice ilnome, quest’architettura e suddivisa in livelli. Ogni livello fornisce fornisce un serviziopiu astratto ai livelli superiori, rispetto a quanto ad esso fornito da quelli inferiori.La stratificazione favorisce lo sviluppo incrementale ed evoluzione.

2.4 Classi ed oggetti entita

Uno degli ingredienti fondamentali quando si parla di ORM sono le classi entita.Prima avevamo parlato di achitetture software, piu precisamente di architettura a

3 livelli o 3-Tier. In questa architettura i tre livelli sono: presentazione, dominio e sor-gente dati. Tutta la logica business si trova nel livello dominio e qui che collocheremogli oggetti entita.

E chiarificante esaminare le caratteristiche di uno degli standard maggiormente

2.4. CLASSI ED OGGETTI ENTITA 27

Figura 2.5: I componenti logici di una architettura 3-Tier

usati per questi oggetti entita, usato nel linguaggio di programmazione Java, cheviene chiamato POJO(Plain Old Java Object). I POJO sono uno standard basatosui Bean entita, simile agli EJB.

Questi file POJO devono seguire la seguente semantica:

1. Il costruttore deve essere privo di argomenti;

2. Tutti gli attributi privati che si vuole considerare devono avere dei metodiaccessori ( chiamati getter e setter essendo basati sullo standard getAttributoper la lettura e setAttributo per la scrittura);

Gli attributi privati sono resi pubblici grazie ai metodi accessori. Risulta possibileanche definire degli attributi virtuali allorche i metodi accessori collegano il valoreritornato a quello di un attributo diverso da quello corrispondente al loro nome.

Questo standard e stato esteso anche al linguaggio di programmazione C#, dovegli oggetti entita corrispondenti vengono chiamati POCO.

Per meglio chiarire come e fatta una classe entita ecco un esempio, relativo almodello entita-relazione della figura 2.6.

La classe entita relativa alla tabella Dipartimento puo essere ottenuta con leseguenti caratteristiche:

public class Dipartimento

// ATTRIBUTI PRIVATI private Long id; private String nome;private String sede;

//COSTRUTTORE DI DEFAULT public Dipartimento()

public Dipartimento(String nome,String sede) this.nome=nome;this.sede=sede;


Figura 2.6: Un agenzia

//METODI ACCESSORI (getAttributo E setAttributo)

public Long getId() return id;

private void setId(Long id) this.id = id;

public String getNome() return nome;

public void setNome(String nome) this.nome = nome;

public String getSede() return sede;

public void setSede(String sede) this.sede = sede;

//METODI PER LA CONVERSIONE public String toString() ....

L’equivalente nel mondo C#, il POCO, e il seguente, in cui i metodi accessorisono sostituiti dalle proprieta che il C# eredita dal Visual Basic:

public class Dipartimento // ATTRIBUTI PRIVATI private long id;private string nome; private string sede;

//COSTRUTTORE DI DEFAULT public Dipartimento()

2.5. ALGORITMI E STRUTTURE DATI 29

public Dipartimento(string nome, string sede) this.nome =nome; this.sede = sede;

//METODI ACCESSORI (GET e SET)

public long Id get return id; set id = value;

public string Nome get return nome; set nome = value;

public string Sede get return sede; set sede = value;

Come si puo notare non c’e niente di complesso, e si crea un isomorfismo trala tabella Dipartimento del database e la classe entita Dipartimento. Per esseremaggiormente chiari, si parla di isomorfismo fra classi entita e tabelle, quando inomi dei campi sono gli stessi dei nomi degli attributi della classe e i tipi dati sonocorrispondenti (ad esempio, String e Varchar, double e numeric).

Dal punto di vista esterno, la classe entita viene trattata esattamente come sefosse una struttura (es. struct in C). Come si vedra meglio nei capitoli seguenti, glielementi interni della libreria ORM NHibernate provvedono al caricamento di questastruttura in presenza di un’operazione di lettura del database e alla lettura della stes-sa struttura per scrivere nel database nel caso opposto, il tutto in modo trasparenteper il programmatore. Nel caso di NHibernate, oltre alla classe entita serve anche ilfile mapper, che stabilisce una corrispondenza tra campi ed attributi, per mapparegli oggetti nel mondo Object-oriented e le tabelle nel mondo RDBMS.

Formalmente, indicando con:

• O: L’oggetto entita;

• T: Tabella o vista nel database;

• M: Il mapper in formato XML;

esiste la condizione:

∀O,∃ < T,M,O >

2.5 Algoritmi e strutture dati

Le strutture dati sono una delle caratteristiche fondamentali per una piattaforma disviluppo. La necessita di mantenere in memoria un insieme di informazioni primadella loro scrittura o dopo la loro lettura e infatti un’esigenza che si presenta in ogniprogramma, dal piu semplice al piu complesso.


In un programma a oggetti, l’importanza delle strutture dati e ridimensionatarispetto a un programma procedurale, in quanto sono gli oggetti stessi a mantenere leinformazioni. Nonostante questo, non potrebbe esserci cardinalita (es. piu oggetti figliper un oggetto padre) se non ci fossero strutture dati pronte a ospitare gli oggetti diapplicazione. Infatti, come si vedra anche nel prossimo capitolo, senza una strutturadati come la DataTable si sarebbe in grado di importare in memoria tutta una tabelladi un database, per esempio.

Diamo una definizione piu precisa di struttura dati, presa da [20].

Una struttura dati e un particolar tipo di dato, caratterizzata piu dall’orga-nizzazione imposta agli elementi che la compongono, che dal tipo degli elementistessi.

Per essere piu precisi, una struttura dati consiste di:

1. Un modo sistematico di organizzare i dati;

2. Un insieme di operatori che permettono di manipolare elementi della strutturao di aggregare elementi per costruire altri agglomerati;

Quello che segue e una classificazione delle strutture di dati in base alle caratter-istiche presentate dalla disposizione dei dati, dal loro numero e dal loro tipo.

• Lineari: Gli agglomerati sono formati da dati disposti in sequenza, tra i qualisi individua un primo elemento, un secondo, ecc.;

• Non lineari: In cui non si individua una sequenza;

• A dimensione fissa: Il numero di elementi dell’agglomerato rimane semprecostante nel tempo;

• A dimensione variabile: Il numero di elementi puo aumentare o diminuirenel tempo;

• Omogenee: I dati sono tutti dello stesso tipo;

• Non omogenee: I dati non sono tutti dello stesso tipo;

Vedremo in seguito, che l’utilizzo di strutture di dati sono fondamentali nella buonriuscita di un progetto software. Nel progetto GSS 1.0. o Generatore Strati Softwarevengono utilizzate tante strutture dati: HashTable, ArrayList, DataTable, SortedList,ecc. Ovviamente queste strutture sono definite nel framework .NET versione 3.5.

Prima di vedere un quadro generale delle strutture dati esistenti e la focalizzazionedelle stesse usate nel corso del progetto, e bene parlare di come descriverle e darequalche accenno sulla teoria della complessita di un algoritmo.

Nel descrivere una struttura dati, e opportuno distinguere, come per tutti i tipidi dato, tra la specifica astratta della proprieta della struttura e i possibili modi coni quali si puo memorizzare la struttura ed eseguire le operazioni.

La specifica e divisa in due aspetti fondamentali:

1. Specifica sintattica;

2. Specifica semantica;


Figura 2.7: Un vettore

La specifica sintattica, cioe la notazione con cui sono indicati sia i tipi di datoche le operazioni, fornisce l’elenco dei nomi dei tipi di dato utilizzati per definirne lastruttura, delle operazioni specifiche della struttura stessa, e delle costanti.

La specifica astratta, cioe il significato che diamo ai tipi di dato e le loro oper-azioni, associa un insieme matematico ad ogni nome di tipo introdotto nella specificasintattica, un valore ad ogni costante, e una funzione ad ogni nome di operatore.Questa funzione e definita in modo matematico, esplicitando una coppia di condizioni:< Precondizione, Postcondizione > sui domini di partenza e di arrivo.

La Precondizione stabilisce quando l’operatore e applicabile.

IF Precondizione is null THEN l’operatore e sempre applicabile;ELSE l’operatore non e applicabile;

La Postcondizione indica come il risultato sia vincolato agli argomenti dell’op-eratore.

Vediamo un esempio di Per meglio chiarire il concetto ecco un esempio di speci-fica sintattica e astratta con le relative precondizioni e postcondizioni attuato sullastruttura dati vettore.

Il vettore e una struttura lineare omogenea a dimensione fissa. (Vedi figura 2.8.)

Specifica sintattica:

Nomi dei tipi:

VETTORE, INTERO, TIPO ELEMENTO

Nomi degli operatori:

CREA VETTORE, LEGGI VETTORE, SCRIVI VETTORE

dove:CREA VETTORE: <>−→ VETTORE

LEGGI VETTORE: < V ETTORE, INTERO >−→ TIPO ELEMENTO

SCRIVI VETTORE: < V ETTORE, INTERO, TIPO ELEMENTO >−→VETTORE

Specifica semantica:


VETTORE: L’insieme di tutte le sequenze di n elementi di tipoTIPO ELEMENTO (grazie a questo TIPO ELEMENTO possiamo dichiararequalsiasi tipo, per esempio, reali, interi, ecc.);

v: Valore generico del tipo VETTORE;

i: Valore generico del tipo INTERO;

e: Valore generico del tipo TIPO ELEMENTO;

CREA VETTORE = v

Postcondizione : ∀i, 1 ≤ i ≤ n, l’i-esimo elemento v(i) del vettore e uguale ad unprefissato elemento di tipo TIPO ELEMENTO;

LEGGI VETTORE(v, i) = e

Precondizione : 1 ≤ i ≤ n;

Postcondizione : e = v(i);

SCRIVI VETTORE(v, i, e) = v’

Precondizione : 1 ≤ i ≤ n;

Postcondizione : v′(i) = e, v′(j) = v(j),∀j : 1 ≤ j ≤ n e j 6= i;

Il CREA VETTORE specifica come debba essere inizializzato il vettore. LEG-GI VETTORE restituisce il valore contenuto nell’i-esima posizione del vettore. SCRIVI VETTORErestituisce un nuovo vettore v’ con tutti i valori degli elementi uguali a quelli di v,tranne il valore dell’i-esima posizione che e posto al valore e.

La scelta nell’utilizzare una struttura dati piuttosto che un’altra non e semprefacile. Bisogna analizzare le varie operazioni (inserimento, cancellazione, ricerca,copia, ecc.) in termini di tempo di calcolo. Per risolvere un problema spesso sonodisponibili molti algoritmi diversi. Per scegliere un algoritmo invece che un altro uncriterio potrebbe essere quello di valutare la sua bonta in base alla quantita di risorsautilizzata per il calcolo. Quindi si considera:

1. Spazio: necessario per memorizzare e manipolare i dati;

2. Tempo: il tempo richiesto per eseguire le azioni elementari;

Queste azioni elementari sono: operazioni aritmetiche, logiche, di confronto edi assegnamento. Di solito il costo delle operazioni e valutato nel caso pessimo,cioe sul dato d’ingresso piu sfavorevole, tra tutti quelli di dimensione n. A volte evalutato anche nel caso medio, cioe mediando su tutti i possibili dati di dimensionen, tenendo conto della probabilita con cui ciascun dato puo occorrere.

Nella valutazione del tempo di calcolo di una procedura T(n) si ricorre alla comp-lessita computazionale asintotica in ordine di grandezza. Usiamo le seguenti notazioni:O, Ω e θ definite nel seguente modo:


O(f(n)), l’insieme di tutte le funzioni g(n) tali che esistono due costanti positivec ed m per cui g(n) ≤ c ∗ f(n),∀n ≥ m.

Ω(f(n)), l’insieme di tutte le funzioni g(n) tali che esistono due costanti positivec ed m per cui c ∗ f(n) ≤ g(n),∀n ≥ m.

θ(f(n)), l’insieme di tutte le funzioni g(n) tali che esistono tre costanti positivec,d ed m per cui c ∗ f(n) ≤ g(n) ≤ d ∗ f(n),∀n ≥ m.

Una classificazione degli ordini di grandezza e la seguente:

• θ(1) : ordine costante

• θ(log(n)): ordine logaritmico

• θ(n): ordine lineare

• θ(n ∗ log(n)): ordine pseudolineare

• θ(n2): ordine quadratico

• θ(n3): ordine cubico

• θ(2n): ordine esponenziale in base 2

• θ(n!): ordine fattoriale

• θ(nn)): ordine esponenziale in base n

Vediamo adesso le strutture dati esistenti.Quella che segue e una classificazione delle strutture dati che vengono utilizzate

quotidianamente durante la fase di implementazione di un progetto software.

1. Vettori

2. Liste

3. Pile

4. Code

5. Alberi

6. Insiemi

7. Dizionari

8. Code con priorita

9. Alberi bilanciati di ricerca

10. Grafi


Figura 2.8: Alcune realizzazioni di una lista con puntatori

Le liste

Una Lista e una sequenza di elementi di un certo tipo, in cui e possibile aggiungereo togliere elementi. Per far questo, occorre specificare la posizione relativa all’inter-no della sequenza nella quale il nuovo elemento va aggiunto o dalla quale il vecchioelemento va tolto. La lista e una struttura a dimensione variabile e si puo accederedirettamente solo ad un ristretto sottoinsieme di elementi (di solito al primo a all’ul-timo). Per accedere ad un generico elemento, occorre scandire sequenzialmente glielementi della lista: partendo da un elemento accessibile direttamente, ci si spostavia via da un elemento ad uno adiacente nella sequenza, fino a raggiungere l’elementodesiderato.

Le liste si possono realizzare in tanti modi: Puntatori o cursori.Nella figura 2.9. vengono mostrati alcuni realizzazioni possibili per una lista con

l’uso di puntatori.

Le pile

Una Pila o Stack e una sequenza di elementi di un certo tipo in cui e possibileaggiungere o togliere soltanto ad un estremo (la testa) della sequenza. Viene chiamatastruttura LIFO (Last In First Out), ovvero l’ultimo da arrivare e il primo ad essereservito (es. pila di piatti). Una pila puo essere anche vista come una particolare lista


Figura 2.9: Realizzazione di una pila con un vettore

Figura 2.10: Realizzazione di una coda con un vettore circolare

in cui l’ultimo elemento inserito e anche il primo ad essere rimosso e non e possibileaccedere ad alcun elemento che non sia quello in testa.

Una tipica realizzazione di tale struttura e con l’utilizzo di un vettore (comemostra la figura 2.10.).

Le code

La Coda o Queue e una sequenza di elementi di un certo tipo, in cui e possibileaggiungere elementi ad un estremo (il fondo) e togliere elementi dall’altro estremo(la testa). Viene chiamata struttura FIFO (First In First Out), ovvero il primo adarrivare e anche il primo ad essere servito (es. coda ad uno sportello in banca). Unacoda puo essere anche vista come una particolare lista in cui il primo elemento inseritoe anche il primo ad essere rimosso e non e possibile accedere ad alcun elemento chenon sia quello in testa o quello in fondo.

Una tipica realizzazione di tale struttura e con l’utilizzo di un vettore circolare(come mostra la figura 2.11.).


Figura 2.11: Un albero binario di decisione per l’ordinamento di tre numeri

Gli alberi

Un Albero ordinato e formato da un insieme finito di elementi, detti nodi. Setale insieme non e vuoto, allora un particolare nodo e designato come radice, ed irimanenti nodi, se esistono, sono a loro volta partizionati in insiemi ordinati disgiunti,ciascuno dei quali e un albero ordinato.

L’utilizzo degli alberi ricorre in tante situazioni (es. albero di derivazione di unagrammatica context free, organizzazione di un file system, albero geneaologico, ecc.).

Esistono particolari alberi chiamati alberi binari. Essi sono un particolare alberoordinato in cui ogni nodo ha al piu due figli e si fa distinzione tra il figlio sinistro e ilfiglio destro di un nodo (si veda la figura 2.12.).

Gli insiemi

Un insieme o SET e una collezione (o famiglia) di elementi distinti (detti membrio componenti) dello stesso tipo. L’insieme e la struttura matematica fondamen-tale, e puo essere descritto o elencadone tutti gli elementi (insiemi definiti per elen-cazione) o stabilendo una proprieta che ne caratterizzi gli elementi (insiemi definitiper proprieta).

Esistono diversi modi nella realizzazioni di insiemi: liste non ordinate, vettorebooleano, liste ordinate e mfset.

I Dizionari

Un Dizionario e un caso particolare di insieme, in cui e possibile verificare l’apparte-nenza di un elemento, cancellare un elemento e inserire un nuovo elemento.

Esistono anche qui diverse possibili realizzazioni di tale strutture: vettore ordi-nato, tabella hash, ecc.

Ci soffermiamo sulle HashTable o tabelle hash, poiche sono utilizzate nel proget-to di generazioni strati software nella creazione, come vedremo, di codice automaticonel realizzare un piccolo ORM.

Gli elementi di un dizionario vengono chiamati chiavi. La realizzazione di undizionario con queste tabelle hash si basa sul concetto di ricavare direttamente dalvalore della chiave la posizione che la chiave stessa dovrebbe occupare in un vettore.


Formalmente:

K: L’insieme di tutte le possibili chiavi distinte;

V: Vettore dove viene memorizzato il dizionario;

m: La dimensione del vettore V;

L’ideale sarebbe avere una funzione d’accesso H:K −→ 1, ...,m che permetta diricavare la posizione H(k) della chiave k nel vettore V in modo che ∀k1, k2 ∈ K, conk1 6= k2, risulti H(k1) 6= H(k2).

Per realizzare una tabella hash in maniera efficiente, occorre:

1. Una funzione H, detta funzione hash, che sia calcolabile velocemente (intempo O(1)) e che distribuisca le chiavi uniformemente nel vettore V, al fine diridurre il numero di collisioni tra le chiavi diverse che hanno lo stesso indirizzohash;

2. Un metodo di scansione, per reperire chiavi che hanno trovato la loro po-sizione occupata, che permetta di esplorare tutto il vettore V e non provochila formazione di agglomerati di chiavi;

3. La dimensione m del vettore V deve essere una sovrastima (di solito il doppio)del numero di chiavi attese, onde evitare di riempire V completamente;

Spendiamo ancora qualche parola sulla generazione di indirizzi hash (funzionihash) e sui diversi metodi di scansione.

Con la funzione hash, si vuole ricavare l’output (cioe un numero intero) che siascorrelato dalla struttura dell’input (la chiave stessa). L’algoritmo che calcola lafunzione hash non e casuale, in quanto se si ricalcola piu volte H(k) per la stessachiave k si ottiene sempre lo stesso valore, ma l’indirizzo hash si comporta da unpunto di vista statico come se fosse stato davvero prodotto con uno o piu lanci casualidi una moneta.

Per definire funzioni hash, e conveniente considerare la rappresentazione binariabin(k) della chiave k. Se la chiave k non e numerica, bin(k) e data dalla concatenazionedella rappresentazione binaria di ciascun carattere che la compone.

Denotiamo con int(b) il numero intero rappresentato da una stringa binaria b.Esistono quattro buoni metodi di generazione di indirizzi hash:

1. H(k) = int(b), dove b e un sottoinsieme di p bit di bin(k), solitamente estrattinella posizioni centrali;

2. H(k) = int(b), dove b e dato dalla somma modulo 2, effettuata bit a bit, didiversi sottoinsiemi di p bit di bin(k);

3. H(k) = int(b), dove b e un sottoinsieme di p bit estratti dalla posizioni centralidi bin(int(bin(k))2);

4. H(k) e uguale al resto della divisione di int(bin(k)) ∗m;

I metodi di scansione si suddividono in esterni e interni a seconda che le chiavisiano memorizzate all’esterno o all’interno del vettore V.

Metodi esterni:


Figura 2.12: Una rappresentazione di una tabella hash

• Liste di trabocco: Il vettore V contiene in ogni posizione, l’identificatore diuna lista (lista di trabocco) e tutte le chiavi che collidono sullo stesso indirizzohash vengono inserite nella stessa lista. Un vantaggio di queste liste e il nonformarsi di agglomerati e di non imporre alcun limite di capacita del dizionario.

Metodi interni:Sia fi la funzione che viene utilizzata nei diversi metodi di scansione interna.

• Scansione lineare: fi = (H(k) + h ∗ i)modm, dove h e un intero primo conm. Lo svantaggio e la non riduzione di agglomerati di chiavi;

• Scansione quadratica: fi = (H(k) + h ∗ i + i ∗ (i − 1)/2)modm, dove m eun numero primo. Si riduce l’effetto di agglomerazione dovuto alla scansionelineare. Uno svantaggio e la non riuscita di non includere tutte le posizioni diV;

• Scansione pseudocasuale: fi = (H(k)+ri)modm, dove ri e l’i-esimo numerogenerato da un generatore di numeri pseudo-casuali. Elimina gli svantaggi delledue scansioni precedenti;

• Hashing doppio: fi = (H(k) + i ∗ F (k))modm, dove F e un’altra funzionehash diversa da H. Evitiamo la formazione di agglomerati;

Una rappresentazione possibile di una tabella hash in figura 2.13.

Le code con priorita

Una coda con priorita e un particolare insieme, sugli elementi del quale e definitauna relazione ≤ di ordinamento totale, in cui e possibile inserire un nuovo elementoo estrarre l’elemento minimo.

Si possono realizzare queste code con alberi binari con gli elementi disposti in unoheap (vettore).

Gli alberi bilanciati di ricerca

Gli elementi di un insieme A possono essere contenuti nei nodi di un albero binarioB, detto albero binario di ricerca, che verifica le seguenti proprieta:

2.6. CLASSI ED OGGETTI CONTENITORI 39

Figura 2.13: Un albero binario di ricerca

Figura 2.14: Un grafo orientato

1. Per ogni nodo u, tutti gli elementi contenuti nel sottoalbero radicato nel figliosinistro di u sono minori dell’elemento contenuto in u;

2. Per ogni nodo u, tutti gli elementi contenuti nel sottoalbero radicato nel figliodestro di u sono maggiori dell’elemento contenuto in u;

Un esempio di tale albero in figura 2.14.

I grafi

Un grafo orientato e una coppia G =< N,A >, con N insieme finito di elementi, dettinodi (vertici), ed A insieme finito di coppie ordinate di nodi, detti archi (linee). Unesempio in figura 2.15.

Una possibile realizzazione di tale struttura puo essere: uso di matrici di adia-cenza, insiemi di adiacenza.

2.6 Classi ed oggetti contenitori

Nella programmazione Object-Oriented, un oggetto contenitore e una classe dioggetti che e preposta al contenimento di altri oggetti. Questi oggetti usualmentepossono essere di qualsiasi classe, e possono anche essere a loro volta dei contenitori.


Esempi di queste classi contenitori sono: insiemi, stack, pila, mappe, code, ecc...,ossia gli elementi visti nel paragrafo sulle strutture dati.

La progettazione orientata agli oggetti utilizza e puo modificare i risultati del-l’analisi per questioni implementative. Queste modifiche pero devono essere ridotteal minimo per mantenere coerenza con l’analisi e con le specifiche.

Molto spesso tra le classi intercorrono delle relazioni o associazioni. Possiamoavere:

• Associazioni 0-1 o 1-1: bisogna aggiungere alla classe del cliente un attributoche riferisce all’oggetto della classe fornitore, e il valore dell’oggetto della classefornitore (siamo nel caso di composizione);

• Associazioni 0-N o N-N: si utilizza una classe contenitore in cui le istanzesono collezioni a oggetti della classe fornitore, inoltre viene comunque aggiuntoal cliente un attributo che rappresenta per valore o per riferimento l’istanzadella classe contenitore;

Da cio, possiamo definire meglio che cosa si intende per classe contenitore.Un classe contenitore e una classe le cui istanze appartengono ad altre classi.

Se gli oggetti contenuti sono in numero fisso e senza ordine, allora si puo utilizzareun vettore; viceversa, se gli oggetti sono in numero variabile, o e chiesto che abbianoun ordine, allora occorre una classe contenitore. Queste classi contenitore hanno fun-zionalita minime (memorizzare, aggiungere, togliere, trovare un oggetto, enumeraregli oggetti) e possono essere classificate in base al modo in cui contengono gli oggetti,o all’omogeneita/eterogeneita degli oggetti contenuti.

Esistono quattro tipi di contenimento:

• Contenimento per valore: L’oggetto contenuto e memorizzato nella strut-tura dati del contenitore, ed esiste proprio perche e contenuto fisicamente inun altro oggetto. Quando un oggetto viene inserito nel contenitore, viene du-plicato, e la distruzione del contenitore implica la distruzione degli oggetticontenuti;

• Contenimento per riferimento: L’oggetto contenuto ha una propria esisten-za e puo essere contenuto in diversi contenitori, infatti quando viene inseritonel contenitore non viene copiato, ma ne viene memorizzato il riferimento. Perquesto motivo, alla distruzione del contenitore, l’oggetto contenuto non vieneeliminato;

• Contenimento di oggetti omogenei (valore o riferimento):E sufficientel’uso di template (classi generiche o parametriche). Il tipo degli oggetti con-tenuti viene lasciato generico e si pensa soprattutto agli algoritmi di gestionedella collezione. Quando serve una classe contenitore di oggetti di una classespecifica, basta istanziare una classe generica specificando il tipo dell’oggetto;

• Contenimento di oggetti eterogenei (riferimento): E necessario utiliz-zare l’ereditarieta e sfruttare la proprieta che un puntatore alla superclasse puopuntare alle istanze di qualunque sottoclasse. La classe contenitore puo esseregenerica, ma solo per la gestione dei riferimenti agli oggetti contenuti.

Ma perche uno sviluppatore puo avere bisogno di implementare una sua collezione(contenitore)?

Sostanzialmente ci sono due ragioni:


• Per implementare un oggetto di Business contenitore: Nella implemen-tazione di oggetti che appartengono al livello di astrazione applicativo spessoe necessario implementare un oggetto che e anche un contenitore; in concretosi puo pensare alle relazioni tra Ordini e Ordine, tra Ordine e RigaOrdine etra Cliente e Condizioni di Pagamento. Dall’oggetto contenitore si vuole poteraccedere ad un elemento, ciclare tutti gli elementi ed aggiungere o rimuovereelementi, cioe cio che fa una collezione, ma una collezione che deve operareesclusivamente con elementi di un determinato tipo (per esempio RigaOrdine)e allo stesso tempo fornire altri servizi (per esempio la persistenza, la ricercacon condizioni di filtro o specifiche regole di Business).

• Per implementare una collezione di Value-Type efficiente: Le collezionifornite dal .Net Framework possono essere utilizzate per contenere elementi diqualsiasi tipo (come si vedra nel prossimo capitolo). A questo scopo il tipo uti-lizzato per rappresentare un elemento nei metodi delle collezioni e Object, che ela radice di tutti i tipi dato. Tuttavia Object e anche un Reference-Type (queitipi dato che vengono passati come parametro o assegnati per riferimento),quindi se gli elementi inseriti nella collezione sono Value-Type (quei tipi datoche se passati come parametro o assegnati vengono copiati per valore) avverran-no continue operazioni di Boxing e Unboxing (cioe le conversioni necessarie perpoter trattare i Value-Type come oggetti) con sensibile peggioramento dei tem-pi di elaborazione. Quindi le collezioni fornite dal .Net Framework potrebberonon essere indicate.

Vediamo adesso, un esempio di utilizzo di un contenitore nel mondo .NET :l’HashTable. L’esempio e scritto nel linguaggio C#:

using System; using System.Collections;

namespace EsempioHashTable public class myClasse //MAIN staticvoid Main(string[] args) //Creazione di un oggetto HashTable(contenitore) HashTable myHashTable = new HashTable();

//Inserisco delle coppie di chiave e valoremyHashTable.Add("TAG + SelectQuery + TAG", "select * fromnomeTabella"); myHashTable.Add("chiavePrimaria","id");myHashTable.Add("tipoChiavePrimaria","int");

//Utilizziamo IDictionaryEnumerator che e un’interfaccia //perricavare l’elenco di tutte le chiavi //e dei rispettivi valoridell’hashtable Console.WriteLine("Coppie presentinell’HashTable"); IDictionaryEnumerator myEnumerator =myHashTable.GetEnumerator();

while (myEnumerator.MoveNext()) Console.WriteLine(" 0 : 1",myEnumerator.Key, myEnumerator.Value);

//Controlliamo se l’hashtable contiene una certa chiave //conil metodo ContainKey() Console.WriteLine("Contiene la chiave


’TAG + SelectQuery + TAG’ ?"); Console.WriteLine("myHashTable.ContainsKey("TAG + SelectQuery + TAG").ToString());

//Controlliamo se l’hashtable contiene una certa chiave //conil metodo ContainValue() Console.WriteLine("Contiene il valore’id’ ?");Console.WriteLine("myHashTable.ContainsValue("id").ToString());

//Stampo il numero totale di coppie presenti nell’hashtableConsole.WriteLine("Elementi totali: " +myHashTable.Count.ToString());

//Rimuovo una coppia di chiave ed elemento tramite //il nomedella chiave Console.WriteLine("Rimuovo la chiave’tipoChiavePrimaria’ ...");myHashTable.Remove("tipoChiavePrimaria");

//Ristampo il numero totale di coppie per verificare l’avvenuta//rimozione Console.WriteLine("Elementi totali : " +myHashTable.Count.ToString());

//end metodo main //end classe //end namespace

Schematizzando ogni contenitore offre alcuni servizi generici, comuni a tutti icontenitori (vedi figura 2.7.).

Un concetto importantissimo quando parliamo di contenitori sono gli iteratori.Gli iteratori derivano dai design pattern. Il pattern Iterator risolve diversi prob-

lemi connessi all’accesso e alla navigazione attraverso gli elementi, in particolare, diuna struttura dati contenitrice, senza esporre i dettagli dell’implementazione e dellastruttura interna del contenitore. L’oggetto principale su cui si basa questo designpattern e l’ iteratore.

Una classe contenitrice dovrebbe consentire l’accesso e la navigazione attraversol’insieme degli elementi che contiene. Nella programmazione a oggetti, un’alternativasemplice e preferibile all’uso di indici (come accade ad esempio per gli array) consistenell’aggiungere operazioni all’interfaccia del contenitore. Questa soluzione ha il grossovantaggio che, se l’interfaccia e ben definita, consente di annullare la dipendenza dadettagli interni del contenitore, ma cio presenta alcuni inconvenienti:

• Sovraccarico dell’interfaccia del contenitore: Le operazioni aggiunte sovrac-caricano l’interfaccia preesistente della classe contenitore;

• Mancanza di punti di accesso multipli: Le operazioni sono centralizzatenella classe contenitore. Questo non consente di effettuare contemporanea-mente piu visite indipendenti agli elementi dello stesso contenitore.

• Supporto carente per metodi di navigazione speciali: Quando i conteni-tori possiedono una struttura complessa, non di rado vi sono diversi e ugual-


Figura 2.15: Un contenitore in astratto

mente utili modi di attraversarne l’insieme degli elementi contenuti. Un’inter-faccia centralizzata si adatta male a questa situazione, perche richiede l’aggiun-ta di piu operazioni specializzate, esacerbando il problema del sovraccarico.

Abbiamo detto che l’elemento principale del pattern Iterator e l’iteratore. Essofornisce un metodo generale per accedere in successione a ciascun elemento di unoqualsiasi dei tipi di contenitore (sequenziali o associativi). Un esempio chiarificatore diclassificazione e la suddivisione degli iteratori nella STL (Standard Template Library)del linguaggio di programmazione C++.

Possiamo classificare gli iteratori in 5 categorie [21]:

• Input Iterator: Legge gli elementi di un contenitore ma non supporta lascrittura;

• Output Iterator: Scrive gli elementi di un contenitore ma non supporta lalettura;

• Forward Iterator: Usato per leggere da e scrivere in un contenitore in unasola direzione;

• Bidirectional Iterator: Usato per leggere da e scrivere in un contenitore inentrambe le direzioni;

• Random Access Iterator: Fornisce accesso a ogni posizione nel contenitorecon un costo costante in termini di tempo;


2.7 Le soluzioni informatiche dato-centriche

Abbiamo parlato nell’introduzione di sistemi informativi, precisamente dell’impor-tanza del dato come tesoro di ogni azienda. E meglio soffermarci per un momentosulla struttura di organizzazione di un azienda.

Possiamo vedere l’organizzazione di un azienda in due modi:

1. Strutturata per funzioni;

2. Strutturata per processi;

Storicamente l’aziende erano strutturate per funzioni. Le funzioni sono aggregazionidi uomini e mezzi necessari per lo svolgimento di attivita della stessa natura. Quindiin un azienda che e organizzata per funzioni le attivita simili, che assolvono cioe lastessa funzione, che richiedono le stesse competenze e che utilizzano lo stesso tipo dirisorse e di tecnologie, vengono raggrupate in un’unita organizzativa sotto un’unicaresponsabilita. [6].

Queste aziende che adottavano questo modo di struttura, erano meno interessatead utilizzare le tecnologie informatiche come supporto alle attivita produttive; questoperche ogni reparto procede all’inserimento semplice delle tecnologie IT entro funzionidi lavoro per proprio conto e le applicazioni specialistiche non sempre prevedono unafacile integrazione tra di loro, creando il cosiddetto problema delle isole informatiche,cioe sistemi informatici diversi in ogni reparto, che usano formati di rappresentazionedei dati diversi, costringendo i responsabili IT alla creazione di apposite interfacce dicomunicazione, che effettuino la traduzione dei dati tra i vari formati [22].

Gran parte delle aziende moderne sono strutturate per processi.

Un processo aziendale e un insieme organizzato di attivita e decisioni, final-izzato alla creazione di un output effettivamente domandato dal cliente, e al qualequesti attribuisce un valore ben definito. [23].

E bene tenere presente due concetti fondamentali quando trattiamo questi argo-menti. Il primo concetto e la Catena del valore di Porter in [24] e l’altro concettoe la Piramide di Anthony in [25].

Nella figura 2.16. viene mostrato il primo concetto nel caso di un azienda diproduzione.

In questa figura si puo notare che i processi sono suddivisi in:

• Buy side: processi il cui input proviene dai fornitori;

• Inside: processi aventi sia input sia output interni all’azienda, che possono es-sere suddivisi tra processi primari, che sono direttamente legati alla produzionedel valore del core business dell’azienda e processi secondari, che non generanodirettamente un valore, ma producono quei servizi senza i quali l’organizzazionenon potrebbe operare;

• Sell side: processi il cui output e rivolto direttamente ai clienti esterni al-l’azienda;

Invece nella figura 2.17. viene mostrata la piramide di Anthony.Nella figura i processi sono suddivisi:

2.7. LE SOLUZIONI INFORMATICHE DATO-CENTRICHE 45

Figura 2.16: La catena del valore di Porter nel caso di un azienda di produzione

Figura 2.17: La piramide di Anthony


• Processi direzionali: Sono anche chiamati strategici. Essi concorrono alladefinizione degli obiettivi strategici;

• Processi gestionali: Sono anche chiamati manageriali. Essi traducono gliobiettivi strategici in obiettivi economici e ne controllano il raggiungimento;

• Processi operativi: Concorrono alla attuazione degli obiettivi;

I sistemi informatici collegati ai processi devono essere flessibili e riprogrammabilirapidamente seguendo l’evoluzione dei processi business. In queste situazioni, e benedisporre di una base di dati unica, centralizzata e condivisa dalle varie aree funzionalicosicche i dati siano resi disponibili a tutti. Il dato viene messo al centro di tutto.Parliamo di struttura database-centrica.

Parlare di database come strumento informatico unico per la gestione delle infor-mazioni e molto riduttivo, in quanto esistono diversi sistemi applicativi adatti allagestione di ogni tipo di informazione. Tali sistemi si possono classificare come [6]:

• Sistemi a livello operativo: E il componente piu presente del sistema in-formatico. Supportano la registrazione delle attivita elementari e delle tran-sizioni che si svolgono nell’azienda (es. depositi, paghe,ecc.). Il loro scopoprincipale e quindi supportare le attivita routinarie e registrare il flusso delletransizioni entro l’azienda, al livello operativo. Il loro componente fondamen-tale sono i TPS(Transaction Processing Systems). Questi vengono chiamatianche OLTP(Online Transaction Processing), che svolgono e registrano le tran-sizioni di routine necessarie per le attivita quotidiane dell’azienda (es. Calcolostipendi, registrazione ordini, ecc.);

• Sistemi di gestione della conoscenza: Qui troviamo due componenti: i sis-temi per l’ufficio che aumentano la produttivita dei lavoratori (es. OpenOf-fice, MS Power Point, ecc.) e i KWS meglio conosciuti come Knowledge Work-ing Systems, che supportano i lavoratori della conoscenza nella creazione dinuova conoscenza;

• Sistemi di supporto dell’attivita manageriale: Questi sistemi favorisconole attivita di controllo e monitoraggio e le attivita decisionali e amministrative.Forniscono report periodici e sono composti dai MIS(Management InformationSystems), che servono principalmente le funzioni di pianificazione e controllo,con supporto alle decisioni manageriali. In mezzo al livello strategico e quellomenageriale troviamo i DSS(Decision Support Systems);

• Sistemi di supporto delle attivita strategiche: Questi sistemi aiutano isenior manager ad affrontare i problemi strategici e a valutare le tendenze alungo termine. Sono formati dagli ESS(Executive-Support Systems);

Nella figura 2.18. sono rappresentate le relazioni ed i flussi informativi cheintercorrono fra i sistemi che ho elencato sopra.

Per arrivare a capire come e fatta la struttura database-centrica nelle grosseaziende che sono strutturate secondo una visione a processi, e meglio comprendere iconcetti di OLAP e Datawarehouse.

A seconda del sistema dove ci troviamo, la struttura interna della base di daticambia. Le basi di dati per le attivita quotidiana di OLTP sono caratterizzate da:

2.7. LE SOLUZIONI INFORMATICHE DATO-CENTRICHE 47

Figura 2.18: Relazioni e flussi informativi che intercorrono fra i varicomponenti dello strato applicativo del sistema informatico (fonte in [26]).

1. Normalizzazione completa delle tabelle (per normalizzazione si intende in questocontesto il processo volto all’eliminazione della ridondanza e del rischio diinconsistenza del database);

2. Dati memorizzati al minimo livello di granularita;

3. Ottimizzazione per l’inserimento dei dati e lettura di un piccolo numero direcord alla volta;

4. Frequente uso di interrogazioni che richiedono join (operatore dell’algebra re-lazionale che unisce due tuple in relazione tra loro) di molte tabelle;

5. La struttura dei dati non varia di frequente;

6. Alto numero di tabelle e di associazioni;

La fase estrazione dei dati dalla base dati di produzione, di trasformazione deidati nella rappresentazione piu adatta all’analisi da effettuare e di caricamento deidati nel programma di analisi viene detta ETL( Extract Trasform an Load), ed eeffettuata ogni qual volta si debbano eseguire analisi strategiche.

Il processo di analisi completa dei dati prende il nome di OLAP. Esso vieneeseguito utilizzando un database che ha le seguenti caratteristiche:

1. Le entita sono denormalizzate;

2. I dati memorizzati possono essere aggregati o riassuntivi;

3. Le interrogazioni richiedono pochi join;

4. Lo schema del database e semplice (con meno tabelle e meno relazioni) per unacomprensione piu facile da parte dell’utente;

5. E ottimizzato per la consultazione di grandi moli di dati e solitamente e in solalettura


Figura 2.19: Struttura database-centrica

Esistono dei modelli di database generici pensati per queste esigenze come lo StarSchema e il Snowflake Schema vedi in [1].

Nel contesto aziendale, in cui vi e un unico database centrale dove vengono memo-rizzate le informazioni, i client, che condividono i dati, di solito inviano delle richiesteche sono per lo piu messaggi in formato SQL, al server. Il server elabora questi mes-saggi e produce come risultato un set di dati che spedisce come risposta ai client,oppure, nei casi di istruzioni di modifica dei dati (inserimento, aggiornamento, can-cellazione) il server effettua la modifica dei dati, notificando poi al client l’azionesvolta.

Il database centrale definisce le diverse entita in maniera univoca e omogenea pertutti i client al quale fanno riferimento. Tale database garantisce la mancanza diridondanza tra i dati e l’integrita del sistema.

Un data warehouse rappresenta il magazzino di dati a livello di impresa, ossia uninsieme di strumenti per convertire un vasto insieme di dati in informazioni utilizzabilidall’utente, con la possibilita di accedere a tutti i dati dell’impresa centralizzati in unsolo database che garantisce coerenza e consolidamento dei dati e velocita di accessoalle informazioni e supporto all’analisi dei dati. Il data warehouse a volte puo esseresegmentato per questioni di praticita o per dividere i dati in base ai dipartimentiaziendali; si parla allora di data mart (l’insieme di data mart di tutti i dipartimentiaziendali forma il data warehouse).

Nella figura 2.19. vediamo come e fatta una struttura database-centrica.Da questo contesto si evince l’importanza che copre una soluzione database-

centrica. Quindi l’idea e quella di mettere al centro del proprio lavoro il databasecome principe della persistenza dei dati. Infatti ancor’oggi troviamo database vec-chissimi ma ancora utilizzati, nonostante i cambiamenti del modo di programmareecc.

2.8. GLI ORM ED IL LORO RUOLO 49

2.8 Gli ORM ed il loro ruolo

Arriviamo finalmente a parlare di una tecnica di programmazione per convertire datifra RDBMS e linguaggi di programmazione orientati agli oggetti, gli ORM (Object-Relational Mapping).

Il ruolo che svolge un ORM e quello di associare a ogni operazione e elemento usatonella gestione del database degli oggetti con adeguate proprieta e metodi, astraendol’utilizzo del database dal DBMS specifico.

Prima di approfondire l’argomento ORM e bene sottolineare i principali vantaggiche porta usando questa tecnica di programmazione.

Il primo vantaggio e il superamento dell’impedance mismatch.

Il secondo vantaggio e l’elevata portabilita rispetto alla tecnologia DBMS uti-lizzata; i.e se noi cambiassimo DBMS (es. da Postgres vado a usare Oracle o meglioSqlServer), non ci dobbiamo preoccupare a riscrivere tutte le routine che implementi-no lo strato di persistenza. Come vedremo nei successivi capitoli, il cuore centraleche fa funzionare il tutto e il mapper. Grazie a lui sappiamo come sono relazionatile classi entita (i cosidetti POJO che abbiamo visto prima) e le tabelle o meglio loschema del mondo dei RDBMS.

Un altro grossisimo vantaggio e la facilita d’uso. Come vedremo nel seguitonon si e tenuti a scrivere query SQL. Le librerie ORM fra i quali cito Nhibernate,che vedremo, hanno il supporto al SQL, ma vengono utilizzate solo per interrogazionicomplesse e quindi che richiedono un elevata efficienza.

Nhibernate che come vedremo nel prossimo capitolo e una libreria ORM. Essooffre tante funzionalita:

1. Caricamento automatico dei grafi degli oggetti;

2. Gestione della concorrenza nell’accesso ai dati;

3. Meccanismo di caching dei dati (aumento delle prestazioni e riduzione del caricodi lavoro nei confronti del RDBMS;

La necessita di un ORM nasce dall’intrinseca differenza tra il modello relazionalee quello ad oggetti; quest’ultimo infatti ha concetti come ereditarieta, polimorfismo,relazioni bidirezionali ed altre che non hanno una controparte nel mondo relazionaledei database. Per questa ragione, se si ha la necessita di gestire la persistenza sudatabase relazionali, e consigliabile appoggiarsi ad una libreria che si occupi di gestirenella maniera piu trasparente possibile le trasformazioni necessarie tra questi duemondi.

Gli ORM in generale sono indispensabili quando l’architettura della propria ap-plicazione e fortemente basata sul Domain Model e quindi si modella la logica dibusiness con tutti i paradigmi dell’Object Orientation. Questo processo e il piu adat-to per un ORM, si parte infatti dal modello ad oggetti ed in base ad esso si crea unastruttura di Database dedicata per gestirne la persistenza. Il processo inverso, partireda uno schema di database preesistente e da questo arrivare al modello ad oggettie meno ideale, ma anche in questo caso un ORM mostra la sua potenza, dato chepermette di evitare la dicotomia un oggetto una tabella, che chiaramente finisce percreare un insieme di oggetti strutturati secondo il modello relazionale, andando cosia perdere la flessibilita di una struttura pienamente OO.


Figura 2.20: Un esempio di utilizzo del Data Mapper

Come abbiamo visto all’inizio del capitolo, i design pattern sono utilizzatissiminella progettazione del software in sistemi complessi.

Un ORM implementa il pattern Data Mapper.

2.9 Implementazione di un ORM : Il pattern DataMapper

Nel paragrafo precedente si e visto che cos’e un ORM e che ruolo investe nella proget-tazione e realizzazione di software di medie-grandi dimensioni. In questo paragrafoviene invece descritta l’implementazione di un ORM mediante un pattern chiamatoData Mapper. Esso si colloca nel terzo livello di un architettura a 3-Tier.

Il Data Mapper e un livello di software che sepera gli oggetti che risiedono inmemoria dal databse. Esso e responsabili nel trasferire i dati tra i due mondi e haanche la capicita di isolare i dati da ogni altro. Con questo pattern gli oggetti inmemoria non hanno bisogno di conoscere il database sottostante. Questi oggetti nonhanno bisogno di interfacciarsi con codice SQL e certamente non conoscono nulladello schema del database. Lo schema del database e sempre ignorato dagli oggettiche la utilizzano.

Nella figura 2.20. viene fatto un esempio di utilizzo del pattern Data Mapper.Come si puo notare nel mondo Object-Oriented c’e la classe Persona e si puo

supporre di avere la tabella Persona nel database relazionale. In mezzo si noti cheesiste una classe chiamata Persona Mapper che offre le seguenti tre funzionalita:Inserimento, Cancellazione e Modifica.

Come si puo notare il cuore dei dati e il mapper. Nella realizzazione del progettosviluppato durante la tesi, e stati scritto un generatore che origina in maniera auto-matica il file mapper per collegare il mondo relazionale con il mondo Object-Oriented.Nel capitolo 4 verranno presentati tutti i passi di tale realizzazione.

Capitolo 3

Soluzioni nel mondo .NET: Nhibernate

In questo capitolo vengono introdotte le soluzioni che offre il mondo .NET sul temadegli ORM. Dopo una breve spiegazione del mondo .NET si introduranno strutturedati proprie di questo mondo (DataTable e ArrayList) e si introdurra una libreria opensource per la gestione di un ORM: Nhibernate. Infine si fornira qualche scenario diapplicazione di questa libreria.

3.1 Il mondo .NET

Chiediamoci come mai uno sviluppatore dovrebbe scegliere il mondo .NET. Il mondo.NET offre le seguenti cose [27]:

1. Runtime comune per il software (una specia di macchina virtuale);

2. Stessi oggetti indipendentemente dal linguaggio e dall’ambiente di sviluppo(una specie di libreria di classi);

3. Indipendenza dal linguaggio (una specie di bytecode);

4. Linguaggio OOP flessibile e umano(una specie di Java);

Microsoft ha sviluppato .NET come contrapposizione proprietaria al linguaggioJava (che e open source) e attribuisce un ruolo strategico al lancio di .NET comepiattaforma di sviluppo per applicazioni desktop e server nel prossimo decennio perle architetture client/server, internet ed intranet. Rispetto a Java, .Net (e il suolinguaggio principe, cioe C#) sono standard ISO riconosciuti e quindi non e possibile,da parte della casa madre, modificarne la sintassi (a meno di discostarsi dal suo stessostandard).

Quindi possiamo definire .NET nel seguente modo:

.NET non e un linguaggio (e Runtime e una libreria) per eseguire e scrivereprogrammi scritti in ogni linguaggio compatibile (es. C#, J#, Vb.net). Quindi.NET e un nuovo framework per lo sviluppo di applicazioni web-based e windowsall’interno di un ambiente Microsoft.

Il framework offre un fondamentale spostamento verso la strategia Microsoft,quindi muove lo sviluppo di applicazioni client-centric ad una server-centric.

Nelle seguenti due figure (figura 3.1 e figura 3.2) mostrano rispettivamente .NETe il framework e linguaggi associati a .NET.

Bisogna pero confrontare il mondo .NET con un altra tecnologia di software acomponenti su cui Microsoft ci aveva puntato un sacco il COM(Component ObjectModel). Questa tecnologia poi si evolse in COM+, detto anche MTS. Per consentire

51

52 CAPITOLO 3. SOLUZIONI NEL MONDO .NET: NHIBERNATE

Figura 3.1: .NET

Figura 3.2: Framework e linguaggi

una migrazione graduale verso .NET dei progetti esistenti, .NET e stato progettatoper interagire con oggetti COM, facendo da wrapper (involucro), cioe da strato esternoche accede alle funzione dello strato interno.

La Common Language Runtime (CLR), il Common Intermediate Language (CIL)ed il .NET (C#) sono simili rispettivamente alla Java Virtual Machine, al bytecodee al linguaggio Java della Sun Microsystems, con cui sono in forte concorrenza. En-trambi utilizzano un proprio bytecode intermedio. Il bytecode di .NET e progettatoper essere compilato al momento dell’esecuzione (just in time compilation detta ancheJITtin come il bytecode di Java, che invece inizialmente era interpretato (ovvero noncompilato al momento). A momento .NET e compatibile soltanto con le piattaformeWindows, mentre Java e disponibile per tutte le piattaforme. La Java EE (Java Plat-form, Enterprise Edition) di Sun fornisce funzionalita leggermente superiori ad altretecnologie Microsoft, come COM+ e MSMQ, che lavorano peraltro in modo integratocon i sistemi operativi Windows. .NET fa un uso estensivo ed astratto di tutte questetecnologie ormai consolidate. Si deve altresı rilevare che .NET offre vantaggi di tipoprestazionale delle applicazioni quando sono in esecuzione nonche costi e tempi di

3.1. IL MONDO .NET 53

Figura 3.3: La compilazione

sviluppo applicativo inferiori rispetto alla piattaforma Java EE. Inoltre il progettoMono sta portando alla piena portabilita di .Net su sistemi operativi non windows.Gia attualmente un applicativo compilato con il .Net framework puo funzionare sottoaltri sistemi (per esempio Linux) con l’installazione del framework Mono.

La CLR funziona come una virtual machine eseguendo tutti i linguaggi compat-ibili. Tutti i linguaggi del mondo .NET devono obbedire alle regole e gli standardimposti dalla CLR. Per esempio, gestione degli errori, dichiarazione, creazione ed usodi oggetti ecc.

La Common Type Systems CTS e una ricca collezione di tipi dati all’interno diCLR. Esso implementa vari tipi (double, int, ecc.) e le operazioni su di esse.

La Common Language Specification CLS e un set di specifiche che il linguaggioe le librerie hanno bisogno. Questo assicura la interoperabilita tra i linguaggi.

Nella figura seguente viene mostra come avviene la compilazione in .NET (vedifigura 3.3).

I linguaggi .NET non sono compilati in codice macchina ma sono compilati in unlinguaggio intermedio chiamato IL(Intermediate Language).

Il CLR accetta il codice IL e lo ricompila in codice macchina. La ricompilazionee Just-in-time, JIT. Questo codice resta in memoria per le seguenti chiamate. Neicasi non c’e abbastanza memoria il codice JIT viene scartato e il codice Il vieneinterpretato.

Nella produzione del software, il framework e una struttura di supporto su cuiun software puo essere organizzato e progettato.

Un framework e definito da un insieme di classi astratte e dalle relazioni tradi esse. Istanziare un framework significa fornire un’implementazione delle classi


Figura 3.4: Framework .NET

astratte. L’insieme delle classi concrete, definite ereditando il framework, eredita lerelazioni tra classi; si ottiene in questo modo un insieme di classi concrete con uninsieme di relazioni tra classi.

La vera utilita di un framework e quello di rispiarmare allo sviluppatore lariscrittura di codice gia steso in precedenza per compiti simili.

Nella figura seguente viene mostrato il framework .NET (figura 3.4).

3.2 Le DataTable e le loro caratteristiche

La tecnologia per accedere ad una sorgente di basi di dati e ADO.net.Essa e definita come:

Un insieme di librerie di classi che consentono l’accesso non solo ai Database, maa diversi tipi di sorgenti di dati.

Distinguiamo tra ambiente connesso e ambiente disconesso. Il primo signifi-ca che i programmi applicativi sono costantemente in contatto con la base di dati. Losvantaggio e la non tanto scalabilita. Gli elementi infrastrutturali di questa modalitasono:

1. Connection;

2. Command;

3. DataAdapter;

4. DataReader;

3.2. LE DATATABLE E LE LORO CARATTERISTICHE 55

Figura 3.5: DataSet

Il secondo invece significa che in un sottoinsieme di dati puo essere estratto (copi-ato) da una base di dati, e riemesso nella base di dati stessa. Il vantaggio rispettoalla modalita connessa e la maggior scalabilita.

Gli elementi che manipolano i dati di questa modalita sono:

1. DataSet;

2. DataTable;

3. DataRow;

4. DataColumn;

5. Relation;

Parleremo in dettaglio della modalita disconessa.Il DataSet e stato progettato come un contenitore di dati. Esso consiste in un

insieme di DataTable, ognuna dei quali avranno un insieme di data columns e di datarows (vedi figura 3.5).

La DataTable e molto simile ad una tabella di un database, i.e. rappresentauna tabella di dati relazionali in memoria. Tali dati sono locali rispetto all’appli-cazione basata su .NET in cui risiedono, ma possono provenire da un’origine datiquale Microsoft SQL Server tramite DataAdapter. La DataTable consiste come abbi-amo detto, di un insieme di colonne con particolari proprieta e hanno zero o piu righedi dati. Una data table deve anche definire una chiave primaria, una o piu colonne edevono anche contenere dei vincoli sulle colonne (vedi figura 3.6).

Lo schema o struttura di una tabella e rappresentato da colonne e vincoli. Perdefinire lo schema di una DataTable, e possibile utilizzare gli oggetti DataColumn ogli oggetti ForeignKeyConstraint e UniqueConstraint. Le colonne di una tabellapossono essere associate a colonne di un’origine dati, contenere valori calcolati daespressioni, incrementare automaticamente i propri valori o contenere valori di chiaviprimarie.

Oltre a uno schema, e necessario che DataTable disponga anche di righe percontenere e ordinare i dati. La classe DataRow rappresenta i dati effettivi contenuti


Figura 3.6: DataTable

Figura 3.7: Costruttori della classe DataTable

in una tabella. La classe DataRow e i relativi metodi e proprieta consentono direcuperare, valutare e modificare i dati di una tabella. Quando si accede ai dati diuna riga e li si modifica, l’oggetto DataRow conserva sia lo stato corrente che lo statooriginale.

L’utilizzo di una o piu colonne correlate delle tabelle consente di creare relazionipadre-figlio tra tabelle. E possibile creare una relazione tra oggetti DataTable tramiteun tipo DataRelation. Gli oggetti DataRelation possono quindi essere utilizzati perrestituire le righe padre o figlio correlate di una particolare riga.

La figura 3.7 mostra i costruttori della classe DataTable nel framework .Net.La figura 3.8 mostra le proprieta della classe DataTable.La figura 3.9 mostra alcuni metodi che fornisce la classe DataTable.

3.3 Rappresentazioni in memoria: DataTable vsArrayList di oggetti entita

Prima di vedere i pro e contro delle DataTable rispetto agli ArrayList, e bene vederecosa sono gli ArrayList e come vengono rappresentati.

Gli ArrayList implementano una lista di dimensione dinamica che puo contenere

3.3. RAPPRESENTAZIONI IN MEMORIA: DATATABLE VSARRAYLIST DI OGGETTI ENTITA 57

Figura 3.8: Proprieta della classe DataTable

qualsiasi tipo di oggetto. 1 Il numero di elementi che possono essere contenuti nellalista e detto capacita. Il numero di elementi presenti effettivamente nella lista puoessere inferiore alla capacita e si ottiene utilizzando la proprieta Count.

Per aggiungere elementi alla lista si utilizza il metodo Add(). Qui di seguitoriporto un esempio nel frammento C#:

ArrayList myList = new ArrayList();myList.Add("Uno");myList.Add("Due");myList.Add("Tre");

myList.Count; //vale 3

E da notare che le strutture dati come ArrayList non sono tipizzate, quindi enecessario eseguire una conversione di tipo quando si estrae un elemento dalla stessa.Un altra cosa importante e che queste liste dinamiche possono anche contenere valori

1questi sono simili ai vector della STL nel linguaggio C++


Figura 3.9: Alcuni metodi della classe DataTable

3.4. INTRODUZIONE A NHIBERNATE 59

htbp

Metodo Descrizione

Add() Aggiunge un elemento alla listaAddRange() Aggiunge gli elementi di una collezione alla fine della listaClear() Rimuove tutti gli elementi della listaContains() Determina se un elemento e presente o meno nella listaGetEnumerator() Ritorna un enumeratore (iteratore) che puo essere utilizzato per scorrere la listaInsert() Inserisce un oggetto nella lista in una posizione particolareRemove() Rimuove uno specifico oggetto della lista

Tabella 3.1: Elenco di alcuni metodi della classe ArrayList

nulli.Nella tabella 3.1 che segue vengono riportati alcuni metodi della classe ArrayList.

3.4 Introduzione a Nhibernate

Nhibernate e una soluzione Object-relational Mapping (ORM) per il linguaggio diprogrammazione C#. E un software free, open source, e distribuito sotto licenzaLGPL. Nhibernate fornisce un framework semplice da usare, che mappa un modellodi dominio orientato agli oggetti in un classico database relazionale. E importantenotare che Nhibernate non si occupa solo di mappare dalle classi C# in tabelle deldatabase (e da tipi .NET ai tipi SQL), ma fornisce anche degli aiuti per le query didati, il recupero di informazioni e riduce significativamente il tempo che altrimentisarebbe speso lavorando manualmente in SQL e con OLEDB. Se noi ci ponessimoquesta semplice domanda: Ma dobbiamo usarlo sempre Nhibernate?. Ovviamenteno. Vanno valutate una serie di considerazioni quali:

1. Possibilita di cambiare DBMS;

2. L’uso API standard;

3. Aspetti specifici dei DBMS;

Per lavorare con Nhibernate abbiamo bisogno di:

• Entita o POCO: La classe che mappa le entita in oggetti;

• Mapping: Il file di mapping che esprime la corrispondenza tra oggetti e leentita;

• File di configurazione: File di configurazione specifico per Nhibernate;

Il primo di dei file richiesti non e altro che un POCO (lo abbiamo visto nel capitoloprecedente). E conveniente specificare:

• un campo id: rappresenta il valore del campo id corrispondente nel databasequando l’oggetto viene caricato;

• un costruttore di default: Nhibernate lo sfruttera tramite reflection (ve-dremo) per caricare le entita del database;

Il secondo file, come detto, rappresenta il mapping tra Entita ed Oggetti e verratrattato ed affrontato in seguito (scritto in XML).

Il terzo file serve a configurare Nhibernate. Esso permette di definire quale DBMSsi sta usando, quale dialetto (per sfruttare a fondo le capacita dei diversi DBMS),l’indirizzo IP del server e la porta, il nome utente e la password ed infine permette dispecificare quali file devono essere usati per il mapping (possono essere piu d’uno).

Viene riportato qui sotto un esempio di file di configurazione relativo al DBMSMySQL.

<?xml version=’1.0’ encoding=’utf-8’?><!DOCTYPE hibernate-configuration PUBLIC"-//Hibernate/Hibernate Configuration DTD 3.0//EN""http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd"><hibernate-configuration><session-factory>

<property name="connection.driver_class">

com.mysql.jdbc.Driver</property><property name="connection.url">

jdbc:mysql://IP:PORTA/DB</property><property name="connection.username">USER</property><property name="connection.password">PASSWORD</property><property name="connection.pool_size">2</property><property name="dialect">

org.hibernate.dialect.MySQLInnoDBDialect</property><property name="current_session_context_class">

thread</property><property name="cache.provider_class">

org.hibernate.cache.NoCacheProvider</property><property name="show_sql">false</property><mapping resource="it/demo/dominio/Dipartimento.hbm.xml"/>

</session-factory></hibernate-configuration>


Figura 3.10: Un documento XML rappresentante una canzone ed una suavisione grafica ad albero

Prima di vedere il funzionamento di Nhibernate, parliamo del linguaggio XML.

XML il futuro

Abbiamo visto nell’introduzione il problema della rappresentazione elettronica del-l’informazione. Questa e la parte piu complessa e critica per ogni organizzazioneaziendale. Per ovviare a questi problemi sono state proposte diverse soluzioni, manegli ultimi anni sta prendendo piede il metalinguaggio XML(eXtended MarkupLanguage).

Esso e un metalinguaggio, ovvero un linguaggio per definire altri linguaggi, basatosui tag, ossia particolari parola chiave racchiuse fra i caratteri ASCII ’¡’ e ’¿’, conrilevanza semantica. L’XML consente di definire una struttura avente contenutosemantico implicito entro i documenti.

XML e un file di testo (in formato ASCII o Unicode) dove, accanto alle infor-mazioni, sono presenti anche metainformazioni (tag) che ne definiscono un significato.

Normalmente distinguiamo due categorie di documenti:

1. Documenti di definizione, definiscono il formato di un documento XMLvero e proprio, formati dai DTD.

2. Documenti veri e propri con un contenuto di informazione che, non avendolodi solito incluso, hanno il riferimento, di solito in forma di indirizzo Web, delloschema o del DTD che li definisce.

Faccio notare che l’XML non rappresenta la rappresentazione visiva di un docu-mento, ma bensı solo il suo contenuto semantico.

Un esempio riguardante una canzone in figura 3.10.Vediamo come si utilizza Nhibernate in un progetto scritto nel linguaggio C#,

precisamente usando un IDE (Visual Studio 2008).Nhibernate deve referenziare quattro assembly:


1. Castle.DynamicProxy

2. Iesi.Collections

3. log4net

4. Nhibernate

E anche possibile decorare gli oggetti con attributi specifici di NHibernate, invecedi usare file XML esterni, ma questo secondo approccio e meno adottato per il princi-pio di persistence ignorance, ovvero gli oggetti non debbono contenere nulla correlatoalla persistenza.

Per prima cosa vediamo come e fatto un file di mapping scritto in XML.Esempio: Classe Impiegato (POCO).

<?xml version="1.0" encoding="utf-8" ?><nhibernate-mapping xlmns = "urn:nhibernate-mapping-2.2"

assembly = "..."namespace = "...">

<class name="Impiegato" table="impiegato" lazy="false"><id name="id" unsaved-value=0 access="field" type="System.Int32">

<generator class="native" /></id><property name="Nome" column="nome" type="System.String" /><property name="Cognome" column="cognome" type="System.String" />

</class>

</nhibernate-mapping>

Nel tag radice viene indicato l’assembly dove si trova la classe mappata e il names-pace di appartenenza. L’elemento class dichiara la classe mappata e grazie all’attrib-uto table, si puo specificare il nome della tabella del database su cui verra salvatol’oggetto. A questo punto e necessario specificare uno ad uno tutti i campi o proprietadella classe che si vuole salvare nel DB. NHibernate analizza la classe tramite reflec-tion ed e quindi in grado di accedere anche ai campi privati, questa caratteristica, chead un primo esame sembra violare il principio di incapsulamento, e invece veramenteutile, ad esempio per il campo id. Quest’ultimo infatti e molto particolare e lo sivede anche dal fatto che nel mapping viene identificato come id, ad indicare che e ilcampo dell’oggetto che ne defisce l’identita. Nel mapping viene poi indicato che ilmembro mappato e un campo e non una proprieta (access=Field mentre per defaultsi ha access=property), ne viene indicato il tipo e si avverte Nhibernate che per glioggetti mai salvati nel DB il valore del campo e zero (unsaved-value=0). Quest’ulti-mo attributo e fondamentale perche permette a NHibernate di distinguere tra inserted update. Nell’elemento id e necessario inserire un tag generator che specifical’algoritmo di generazione dei valori di identita, dato che per esempio in SQL serverviene utilizzata una colonna identity viene specificato come generatore il tipo native,ovvero e il DB che si occupera di generare un nuovo valore per ogni oggetto inserito.

Come abbiamo detto in precedenza, un altro ingrediente fondamentale per utiliz-zare Nhibernate e il file di configurazione.

Esistono tanti modi per configurare Nhibernate, il piu usato e quello di inserire nelfile di configurazione principale del progetto (App.config o Web.config) una sezioneapposita.

<configSections><section name="NHibernate" type="System.Configuration.NameValueSectionHand"

</configSections>

<NHibernate><add key="hibernate.connection.driver_class"

value="NHibernate.Driver.SqlClientDriver" /><add key="hibernate.dialect"

value="NHibernate.Dialect.MsSql2005Dialect" /><add key="hibernate.connection.provider"

value="NHibernate.Connection.DriverConnectionProvider" /><add key="hibernate.connection.connection_string"

value="Server=localhost\sql2005; Integrated Security=SSPI;<add key="hibernate.show_sql" value="true" />

</NHibernate>

Le informazioni minime che si debbono fornire sono: il driver fisico da utiliz-zare per accedere al DB (SqlClientDriver), il dialetto (che specifica il tipo esatto didatabase usato Es. MsSql2005Dialect), il provider (DriverConnectionProvider) edinfine la stringa di connessione.

E stato aggiunto come si puo vedere show.sql2 che permette di visualizzare nellaconsole tutto il codice SQL Server che viene inviato al database. Questa funzionalitae particolarmente utile perche permette di visualizzare esattamente le operazioni chevengono fatte sul DB.

Nella figura 3.11 che segue viene mostrata l’architettura ad alto livello delle APIdi Nhibernate [28].

Come si puo vedere dalla figura, l’interfaccia di Nhibernate viene classificata nelseguente modo:

• Interfaccie per operazioni CRUD: Usati per performance di query e oper-azioni CRUD (Create, Retrieve, Update e Delete). Queste interfaccie sono ilpunto principale di dipendenza delle applicazioni della logica business. Trovi-amo: ISession, ITransaction, IQuery e ICriteria.

• Interfaccie per l’infrastruttura: Per configurare Nhibernate. Troviamo:Classe Configuration.

2Attenzione!! Quando si eseguono dei test togliere questo valore aggiuntivo


Figura 3.11: Architettura ad alto livello delle API di Nhibernate

• Interfaccie per il Callback: Gestione degli eventi. Troviamo: IInterceptor,ILifeCycle e IValidatable.

• Interfaccie per estensioni mapping: IUserType, ICompositeUserTypee IIdentifierGenerator.

Dopo aver visto com’e composta l’architettura di Nhibernate, il punto da fo-calizzarci e l’oggetto ISession. Esso e l’oggetto principale con cui si interfaccia aNhibernate. Esso corrisponde al cuore del intero processo.

Data l’importanza, di solito si costruisce una classe SessionManager in gradodi gestire la centralizzazione delle sessioni. Il SessionManager si occupa di gestirela creazione delle sessioni , il cui costruttore statico non fa altro che inizializzareun’oggetto chiamato SessionFactory.

Configuration cfg = new Configuration();cfg.AddAssembly(Assembly.GetExecutingAssembly());factory = cfg.BuildSessionFactory();

Per caricare la configurazione basta creare un oggetto di tipo NHibernate.Cfg.Configuration,e poi si procede semplicemente aggiungendo gli assembly che contengono i file dimapping. Se si commettono errori nei mapping, la classe SessionManager genereraun’eccezione nella chiamata al metodo Configuration.AddAssembly, e in questo pun-


to infatti che NHibernate esamina le risorse dell’assembly, individua i mapping e lianalizza per creare dinamicamente le classi che gestiranno la persistenza.

Adesso vediamo un esempio di utilizzo delle sessioni.

private static void Inserimento()Impiegato imp = new Impiegato("Simone", "Bianchi");using (ISession session = NHSessionManager.GetSession() )

session.SaveOrUpdate(customer);session.Flush();

//end metodo Inserimento()

Il primo fatto importante da notare e che l’oggetto ISession di NHibernate e in-cluso in un blocco using, questo e fondamentale perche la sessione utilizza al suointerno oggetti come Connessioni e Transazioni, per cui e necessario che tali risorsevengano rilasciate correttamente quando si termina di utilizzare la sessione stessa,pena un possibile connection leak. Dimenticare di chiamare il Dispose() signifi-ca infatti delegare il rilascio delle risorse al garbage collector e quindi in un tempoindefinito nel futuro. Il secondo fatto importante e che e stato chiamato il metodoSaveOrUpdate() che internamente capisce se l’oggetto deve essere salvato o aggior-nato. Questa decisione viene infatti presa in base al valore della chiave primaria, chenel caso di oggetti nuovi e pari a zero (ricordiamo l’attributo unsaved-value), men-tre nel caso di oggetti gia salvati e pari al valore di identita restituito dal database.Infine, grazie all’impostazione show sql e possibile vedere nella console il codice SQLche NHibernate ha generato per inserire l’oggetto.

L’ultima nota riguarda la chiamata al metodo ISession.Flush() che e necessarioinvocare per informare la sessione che vogliamo propagare al database tutti gli eventu-ali cambiamenti degli oggetti. La sessione si comporta come uno stream, ovvero nonpropaga immediatamente al database i cambiamenti degli oggetti, ma solo quando loreputa necessario. Chiudere o chiamare il Dispose() su una sessione, senza chiamareil Flush(), non propaga al DB tutte i nostri cambiamenti, per cui si deve fare moltaattenzione.

Un altra cosa interessante, e che se noi volessimo cambiare database lo sforzo eminimo.

Per cui una delle particolarita piu interessanti degli ORM e che essi sono in gradodi accedere a database differenti in maniera praticamente trasparente. Dato che lequery SQL e gli oggetti di accesso al database sono creati dinamicamente dalla libreriae soprattutto visto che il dominio degli oggetti segue la persistence ignorance, e spessopossibile cambiare tipologia di database con sforzo veramente minimo. Per esempiose volessimo modificare l’esempio precedente per accedere ad un database Access,la prima operazione da fare e creare un database con lo stesso schema utilizzato inSQL, naturalmente con le differenze del caso. Quello che segue va aggiunto al file diconfigurazione principale.


<NHibernate><add key="hibernate.connection.driver_class"

value="NHibernate.JetDriver.JetDriver, NHibernate.JetDriver" /><add key="hibernate.dialect"

value="NHibernate.JetDriver.JetDialect, NHibernate.JetDriver" /><add key="hibernate.connection.provider"

value="NHibernate.Connection.DriverConnectionProvider" /><add key="hibernate.connection.connection_string"

value="Provider=Microsoft.Jet.OLEDB.4.0;Data Source=Databases\NHSamp<add key="hibernate.show_sql" value="true" />

</NHibernate>

Dopo aver parlato di come si utilizza Nhibernate, dell’importanza del file dimapping e del file di configurazioni, vediamo come Nhibernate gestisce le relazioni.

Partiremo sempre da un esempio, per capire il funzionamento. L’esempio chesegue riguarda: Impiegati e ordini. La relazione che intercorre tra i due e la molti auno.

<class name="Order" table="Orders" lazy="false"><id name="id" unsaved-value="0" access="field" type="System.Int32"><generator class="native" />

</id><property name="Date" column="Date" type="System.DateTime"/><many-to-one name="Impiegato"

class="Impiegato"column="ImpiegatoId"not-found="exception"not-null="true" />

</class>

La particolarita e che la proprieta Impiegato viene mappata come many-to-one,ma d’altra parte questa non e una sorpresa, perche la relazione tra Impiegato e Ordinie di tipo molti a uno in cui l’ordine e nella parte molti. Questa associazione, comeuna normale proprieta, possiede un set di attributi che permettono di specificarne ilfunzionamento. L’attributo class serve ad indicare a NHibernate il tipo di oggettousato nella relazione e tramite column si indica la colonna usata per memorizzare laforeign-key. NHibernate controlla se la classe usata per la relazione (ovvero Impiega-to) ha un id compatibile con il campo del db per vedere se la relazione e possibile. Inquesto caso Impiegato ha una chiave di tipo Int32, la colonna ImpiegatoId e interaper cui il mapping e compatibile con la struttura di database. Gli attributi not-founde not-null servono invece per specificare rispettivamente come comportarsi nel caso


Figura 3.12: Ciclo di vita della persistenza in Nhibernate

di una foreign-key orfana (id che non e presente in impiegati) e se possono esistereordini orfani con la foreign-key pari a null.

Nella figura 3.12 viene mostrato il ciclo di vita della persistenza in Nhibernate.Dopo aver spiegato il significato della figura vedremo com’e questo ciclo di vita vieneutilizzato quando si ha che fare con l’utilizzo delle API di Nhibernate.

Un entita che non e mai stata salvata con un oggetto Session prende il nome dioggetto transiente. Il suo stato non verra mai propagato al Database e Nhibernate loignora. Quando utilizziamo i metodi Save() o SaveOrUpdate(), l’entita diventa per-sistente. Tutte le modifiche che vengono fatte alle sue proprieta mappate verrannoautomaticamente propagate al database. Quando utilizziamo i metodi Dispose(),Close(), Evict(), Clear(), l’entita assume lo stato Detached. Esso indica che unoggetto che e stato precedentemente persistente, ma che ora e scollegato da qualsiasisessione attiva. L’oggetto puo essere riportato nello stato persistente semplicementetramite i metodi Lock(), Update(), SaveOrUpdate().

Adesso creiamo per esempio, un inserimento di un ordine:

using (ISession session = NHSessionManager.GetSession() )Impiegato simone = new Impiegato("Simone", "Bianchi")Ordine ord = new Ordine(DateTime.Now, simone);session.Save(ord);session.Flush();


Nel momento in cui l’oggetto ord deve essere reso persistente grazie al metodoSave(), Nhibernate prepara la INSERT per la tabella ordini (per il calcolo dell’ididentity autogenerato dal DBMS), e per conoscere il valore del campo ImpiegatoId,che rappresenta la foreign-key con la tabella Impiegato, esamina l’oggetto impiegatoassociato all’ordine. A questo punto si verifica il problema, perche l’oggetto impie-gato e ancora in stato transiente, dato che non e stato mai salvato con NHibernate.Questa situazione presenta due anomalie, in primo luogo NHibernate non conoscel’id dell ’oggetto impiegato e non puo quindi sapere cosa inserire nella colonna dellaforeign-key, in secondo luogo non e lecito salvare un entita quando esistono relazionicon altre entita che sono in stato transiente. Le soluzioni possono essere due, la primae chiamare Session.Save() anche sull’oggetto impiegato prima di salvare l’oggetto or-dine, effettuandone quindi il passaggio nello stato persistente, la seconda e modificareil mapping di ordini in questo modo:

...<many-to-one name="Customer" class="CustomerOne" column="CustomerId"

not-found="exception" not-null="true"cascade="save-update"/>

L’unico cambiamento e l’attributo cascade, che indica a NHibernate di percorrerela relazione propagando la persistenza agli oggetti correlati. Questa caratteristicanel mondo degli ORM e della programmazione con Domain Model si chiama: per-sistence by reachability, ovvero persistenza per raggiungimento. In pratica leoperazioni che cambiano lo stato di persistenza di un oggetto vengono propagate per-correndo il grafo degli oggetti. In questo modo e possibile salvare un oggetto ed esserecerti che anche tutti gli oggetti correlati vengano salvati in maniera automatica.

Parliamo adesso di strategie di fetching (ovvero strategie che permettono direndere ottimizate le operazioni di query).

La modalita LAZY

Se vado a mettere nel file mapping l’attributo lazy = true, indico a Nhibernate chel’entita puo essere usata in modalita lazy (pigra). L’implementazione del lazy avvienenel seguente modo:

Il termine Lazy indica un’operazione che viene effettuata solo quando stretta-mente necessaria. Nel caso di lazy load (caricamento pigro), si effettua la query perrecuperare i dati solamente quando si accede ad una proprieta e non prima. Chiara-mente NHibernate deve avere un modo per intercettare quando si utilizza per la primavolta la proprieta di un oggetto e per questa ragione, al momento del caricamentodell’oggetto Ordini, il sistema non assegna un vero oggetto Impiegati alla sua pro-prieta impiegato, ma un istanza di una classe creata dinamicamente, che eredita daImpiegati ed implementa il pattern proxy. Questo pattern significa che:

data una classe X, un suo proxy non e altro che un’istanza di una classe Y che


eredita da X e che al suo interno mantiene una istanza di X a cui delega tutte lechiamate fatte dall’esterno. Grazie a questo pattern e possibile associare in manieratrasparente funzionalita aggiuntive ad un oggetto esistente.

Nhibernate, all’atto del caricamento dell’oggetto Ordini, effettua una SELECTsulla sola tabella ordini, da questa tabella recupera l’id dell’oggetto impiegato corre-lato (dalla colonna con la foreign-key), istanza un proxy di Impiegato.

Questa tecnica, e anche conosciuta come Transparent Lazy Load, e una dellestrategie di fetch possibile e probabilmente la piu utile. Grazie ad essa si puo senzaproblemi navigare un grafo di oggetti in maniera completamente naturale, lasciandoa NHIbernate il compito di caricare i dati quando necessario.

La modalita EAGER

Proviamo ad osservare il seguente listato:

IList<Ordini> ordini =session.CreateQuery("from Ordini").List<Ordini>();

foreach(Ordini o in ordini)Console.WriteLine("Ordini Id 0 nome impiegato 1",

o.Id, o.Impiegato.Nome

In questo esempio abbiamo usato una query HQL, uno dei metodi che offreNHibernate per effettuare query sul Domain Model. La convenienza di usare HQL eche ha una sintassi molto simile a SQL, ma si usano i nomi di classi e proprieta, inquesto modo si e completamente scollegati dallo schema del database, che e inveceespresso solamente tramite i mapping.

In questa situazione il programmatore sa che le operazioni da effettuare prevedonol’accesso alla proprieta Impiegato per tutti gli ordini, per cui la strategia di LazyLoad e controproducente in termini di prestazioni, dato che viene eseguito un numeroelevato di interrogazioni al database. Anche i questo caso NHibernate ha la soluzione,basta cambiare la query in questo modo:

"from Ordini o inner join fetch o.Impiegato"

Grazie alla clausola inner join fetch si chiede a NHibernate di recuperare tutti idati con una join, proprio come se il lazy load fosse stato disattivato. Questa strategiadi fetch, in cui si recuperano tutti i dati con una singola interrogazione al db, vienechiamata Eager Load, ovvero caricamento anticipato, ed e utile in tutti quei casi incui si sa gia in anticipo come verra usato il grafo di oggetti.

E conveniente che gli oggetti siano tutti mappati come lazy, in questo modo sipuo poi scegliere al momento del la query se usare un caricamento lazy oppure eagerper i vari rami del grafo di oggetti che si vuole usare.

L’oggetto Nhibernate.ISession presenta due metodi distinti per recuperare entita


Figura 3.13: Un agenzia

dal loro id: Get() e Load(). Il metodo Get(), recupera l’oggetto dal databasee restituisce null se non esiste nessun record con l’id specificato, il metodo Load()ritorna invece un proxy senza eseguire nessuna query; in questo caso se non e presenteun record con l’id specificato viene generata eccezione al momento del primo accessoad una proprieta. Il metodo Load() permette quindi la creazione di un proxy ed eutile per creare associazioni; supponiamo di voler associare l’impiegato con id 12 adun ordine, in questo caso utilizzando la chiamata Session.Load¡Impiegati¿(12) si creaun proxy che puo essere assegnato al la proprieta Impiegto dell’ordine in questione. Ilvantaggio di questo approccio e che il proxy permette di impostare la relazione senzadover veramente caricare l’oggetto dal database.

Vedremo nella prossima sezione alcuni scenari di applicazione nell’uso di Nhiber-nate.

3.5 Scenari di applicazione

Dopo aver introdotto Nhibernate, forniamo qualche scenario di utilizzo di tale libreria.Ricordiamo lo schema entita-relazione del capitolo 2 relativo ad un’agenzia (vedifigura 3.10).

Ipotizziamo di realizzare un applicazione che abbia bisogno d’interagire con unabase di dati che rappresenta in modo banalissimo un’agenzia che ha un certo numerodi Dipartimenti in cui lavorano certe Persone che hanno determinati compiti.

Ci focalizzeremo solo e soltanto sulla persistenza degli oggetti entita.

Scenario num. 1

In questo primo scenario cercheremo di fare l’operazione piu semplice ovvero riceveredal database tutte le Entita memorizzate (ottenere una lista di oggetti corrispondentiad una ’select * from ..’); per fare questa operazione dobbiamo definire i due file di cui

3.5. SCENARI DI APPLICAZIONE 71

abbiamo parlato in precedenza. Partiamo dal POCO dell’entita (qui il Dipartimentoma il procedimento e lo stesso) che e sicuramente piu familiare:


//ATTRIBUTIprivate long _id;private string _nome;private string _sede;

//COSTRUTTORE DI DEFAULTpublic Dipartimento()

//COSTRUTTOREpublic Dipartimento(string pnome, string psede)

this._nome = pnome;this._sede = psede;

//PROPRIETA’

public Id()

get return _id; set _id = value;

public Nome()

get return _nome; set _nome = value;

public Sede()

get return _sede; set _sede = value;

//end classe Dipartimento

Adesso ci servira il relativo file di mapping Dipartimento.hbm.xml:


<?xml version="1.0"?><!DOCTYPE nhibernate-mapping PUBLIC"-//NHibernate/NHibernate Mapping DTD 3.0//EN""http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd"><nhibernate-mapping>

<class name="Dipartimento" table="dipartimento" lazy="false"><id name="Id" column="id_dipartimento">

<generator class="native"/></id><property name="Nome"/><property name="Sede"/>

</class></nhibernate-mapping>

Escluse le righe di intestazione il resto del file e fondamentale ai fini della persis-tenza. Come possiamo vedere definiamo un nodo nhibernate-mapping. All’interno diun mapping e possibile definire varie classi; per la classe Dipartimento specifichiamoche essa dovra corrispondere ad una tupla della tabella ’dipartimento’ e che vogliamoche gli oggetti siano caricati subito (lazy=false). All’interno del nodo di una classepossiamo specificare il mapping tra le colonne del database e gli attributi di istan-za della classe (qui in realta non dobbiamo definire niente se non le proprieta chevogliamo siano settate nell’oggetto caricato dal database perche i nomi degli attributidi istanza sono uguali ai nomi delle colonne del database).

L’ultima cosa interessante e il campo id, che deve derivare dal valore della colonnaid dipartimento (qui infatti i nomi dell’attributo e della colonna sono diversi e quindibisogna specificare questa corrispondenza) e che per generare id univoci nel databasesi sfrutta il generatore native (esistono diversi tipi di generatori, dai nativi a quellicorrispondenti a tecniche di High-Low).

Ora sfruttiamo la libreria Nhibernate:

public static List<Dipartimento> listaTuttiDipartimenti()

List<Dipartimento> result = null;Session session = NhibernateUtil.getSessionFactory().openSession();Transaction tx = null;try

tx = session.beginTransaction();Query q = session.createQuery("from Dipartimento");result = q.list();tx.commit();

catch (NhibernateException e)


if (tx!=null)tx.rollback();

throw e;

finally

session.close();return result;

//Crea un Dipartimento dati nome e sede e lo salva nel database

public static Dipartimento creaDipartimento(string pnome, string psede)

Dipartimento dip = new Dipartimento(pnome, psede);Session session = NhibernateUtil.getSessionFactory().openSession();Transaction tx = null;try

tx = session.beginTransaction();session.persist(d);tx.commit();


if (tx!=null)tx.rollback();throw e;

finally

session.close();

return dip;

In questi due metodi vengono aperte le sessioni (abbiamo visto cosa sono nell’in-troduzione a Nhibernate) tramite le quali si possono eseguire una serie di azioni: ilprimo metodo crea una Query che riportera una lista di tutti i Dipartimenti presentinel database; il secondo metodo invece salva un oggetto del database delegando aNhibernate la creazione di un id univoco, la esecuzione delle varie insert necessarie ela gestione degli errori.


Scenario num. 2

Nel primo esempio abbiamo visto alcune operazioni molto semplici e che tutto som-mato si ottengono semplicemente anche con OLEDB; come sappiamo il vero problematra database e linguaggio di programmazione ad oggetti e il cosiddetto problema delimpedance mismatch visto nel primo capitolo. Vediamo allora di aggiungere la navi-gabilita tramite riferimenti; vogliamo che una volta che sia caricato un Dipartimentodal database esso contenga una lista delle persone che vi lavorano. Questa operazionein OLEDB richiederebbe di eseguire una query e analizzare il risultato per caricareogni Persona in una lista. In Nhibernate questo si fa molto piu semplicemente; in-nanzitutto si deve aggiungere un attributo di istanza al Dipartimento, ovvero unalista di Persone che vi lavorano.

Relazione UNO — MOLTI


//ATTRIBUTIprivate long _id;private string _nome;private string _sede;private Set _persone;

//COSTRUTTORE DI DEFAULTpublic Dipartimento()

_persone = new HashSet();

//COSTRUTTOREpublic Dipartimento(string pnome, string psede)

this._nome = pnome;this._sede = psede;_persone = new HashSet();

...

...//end classe Dipartimento

Bisogna creare anche il file POCO per Persona e aggiungere il mapping tra latabella Persone e la classe. La classe Persona e uguale alla classe Dipartimento. Ilfile mapping invece bisogna modificarlo.


<?xml version="1.0"?><!DOCTYPE hibernate-mapping PUBLIC"-//Nhibernate/Nhibernate Mapping DTD 3.0//EN""http://nhibernate.sourceforge.net/nhibernate-mapping-3.0.dtd"><nhibernate-mapping>

<class name="Dipartimento" table="dipartimento" lazy="false"><id name="Id" column="id_dipartimento">

<generator class="native"/></id><property name="Nome"/><property name="Sede"/><set name="persone" lazy="false">

<key column="fk_dipartimento" not-null="true"/><one-to-many class="Persona"/>

</set></class>


Come e possibile vedere abbiamo aggiunto un set al mapping del Dipartimentospecificando che le Persone vengano caricate subito(lazy=false), quale e la chiaveesterna e che si tratta di una relazione uno a molti con la classe Persona unidirezionale.

Il mapping delle Persone:

<?xml version="1.0"?><!DOCTYPE nhibernate-mapping PUBLIC"-//nhibernate/nhibernate Mapping DTD 3.0//EN""http://nhibernate.sourceforge.net/nhibernate-mapping-3.0.dtd"><nhibernate-mapping>

<class name="Persona" table="persona"><id name="Id" column="id_persona">

<generator class="native"/></id><property name="Nome"/>

</class></hibernate-mapping>

Il mapping tra la classe Persona e la tabella persone e molto banale e richiama ilmapping originale che avevamo definito per il Dipartimento. Ora possiamo sfruttarequesti nuovi mapping per ottenere un livello di interazione maggiore; sfruttando infattilo stesso codice che abbiamo visto prima per caricare la lista dei Dipartimenti e lealtre opzioni, questa volta dal database verranno caricate automaticamente le Personedel Dipartimento, verranno salvate se si dovesse creare un nuovo Dipartimento conaltre Persone; il tutto modificando solo i file di configurazione del mapping.


Scenario num. 3

Nello scenario 2 per le Persone abbiamo definito un mapping semplice; abbiamo cioecaricato solo l’id e il nome. Possiamo pero aggiungere la possibilita di sfruttarela relazione di appartenenza ad un Dipartimento anche nel verso opposto, ovvero daPersona al Dipartimento dove lavora(supposto unico per semplicita). Andremo quindia definire un mapping bidirezionale tra Dipartimento e Persona. Per farlo innanzituttodobbiamo aggiungere un attributo di istanza per il Dipartimento all’interno dellaclasse Persona:

public class Persona

..private Dipartimento _dipartimento;...

//PROPRIETA’

public Dipartimento()

get return _dipartimento;set _dipartimento = value;

//end classe Persona

Dobbiamo inoltre aggiungere il mapping bidirezionale tra Persona e Dipartimen-to; per farlo modifichiamo il file Persona.hbm.xml:

Relazioni MOLTI—UNO


<class name="Persona" table="persona"><id name="Id" column = "id_persona">

<generator class="native"/></id><property name="Nome"/>

<many-to-one name="dipartimento" column="fk_dipartimento"not-null="true"/>

</class></nhibernate-mapping>


Come si puo vedere e bastato mettere un elemento che rappresenta l’opposto del-l’elemento che abbiamo nel mapping per il Dipartimento. Il programma di esempiodello scenario 3 serve a verificare la bidirezionalita della relazione; carica cioe il primoDipartimento, prende il primo elemento della lista delle Persone che lavorano pressoquel Dipartimento e verifica che quella Persona abbia il riferimento corretto al Di-partimento precedente. Nello scenario 3 e inoltre considerato un altro problema: lesessioni divise. Ipotizziamo di dover caricare un oggetto dal database e di dover usarequesto oggetto in strati piu alti della nostra applicazione. Usando OLEDB una voltacaricato l’oggetto dovremmo valutare attentamente come agire in una situazione delgenere, con nhibernate invece possiamo semplicemente caricare l’oggetto, chiuderela sessione in cui abbiamo eseguito queste azioni, lavorare per un certo tempo conl’oggetto e poi aggiornare lo stato nel database in maniera che rimanga consistente.Come si puo constatare in nhibernate tutto questo e spaventosamente semplice:

Dipartimento dip = creaDipartimento(".....",".....");//crea un nuovo Dipartimento//ed esegue il codice per salvarlo nel database//ipotizziamo che l’oggetto venga passato allo strato superiore//e che la sesssione sia chiusa

try

thread.sleep(2000);catch (System.Exception e)

dip.Nome = "Ingegneria del Software";Session session = NhibernateUtil.getSessionFactory().openSession();Transaction tx = null;try

tx = session.beginTransaction();session.saveOrUpdate(d);tx.commit();

catch (nhibernateException e)


throw e;


finally

session.close();

Scenario num. 4

Nello scenario 4 sfruttiamo nhibernate per creare un Dipartimento a patto che nonne esista gia uno con gli stessi parametri, che altrimenti sara semplicemente caricatodal database.

Dipartimento dip = null;Session session = NhibernateUtil.getSessionFactory().openSession();Transaction tx = null;try

tx = session.beginTransaction();List<Dipartimento> l =

session.createQuery("from Dipartimento wherenome=:nome and sede=:sede");

setString("nome", nome).setString("sede", sede).list();

if (l.size() == 0)

dip = new Dipartimento(nome, sede);session.save(d);

else

dip = l.iterator().next();tx.commit();



throw e;finally

session.close();return dip;


Scenario num. 5

In questo ultimo scenario cercheremo di vedere come la configurazione di Nhibernatepossa portare ad una differenza sostanziale nelle prestazioni e nell’uso di questo stru-mento. Ipotizziamo di voler ottenere una lista delle Persone con i rispettivi lavori;dopo quanto visto sembrerebbe una operazione facile, quasi banale; e invece, proprioqui stanno le insidie. Cominciamo innanzitutto definendo il mapping per i Job:

Relazioni MOLTI-MOLTI


<class name="Job" table="job"><id name="Id" column="id_job">

<generator class="native"/></id><property name="Lavoro" column="nome"/><set name="persone" table="assegnazione_compiti" inverse="true">

<key column="fk_job"/><many-to-many column="fk_persona" class="Persona"/>

</set></class>


Modifichiamo anche il mapping per Persona in modo da aver per ogni Persona lalista dei suoi lavori(ovviamente dobbiamo modificare anche la classe Persona, ma inmodo del tutto uguale a quanto fatto negli altri scenari:


<class name="Persona" table="persona"><id name="Id" column="id_persona">

<generator class="native"/>


</id><property name="Nome"/><set name="job" table="assegnazione_compiti" lazy="false">

<key column="fk_persona"/><many-to-many column="fk_job" class="Job"fetch="join"/>

</set><many-to-one name="dipartimento" column="fk_dipartimento"

not-null="true" fetch="join" lazy="false"/></class>


Per caricare una lista delle Persone con i rispettivi Job potremmo pensare di usareun codice del genere:

Query q = session.createQuery("from Persona");

Una sintassi del genere chiede a Nhibernate di caricare tutte le Persone memoriz-zate nel database e visto che il mapping richiede che i job siano caricati insieme chele liste siano popolate con i rispettivi Job. Di seguito possiamo vedere l’output conabilitata le visualizzazione delle query necessarie per ricavare le informazioni.

Stampo tutte le persone con i rispettivi jobNhibernate: select persona0_.id_persona ....Nhibernate: select job0_.fk_persona as fk1_1_ ....Nhibernate: select job0_.fk_persona as fk1_1_ ....Nhibernate: select job0_.fk_persona as fk1_1_ ....Nhibernate: select job0_.fk_persona as fk1_1_ ....Nhibernate: select job0_.fk_persona as fk1_1_ ....Nhibernate: select job0_.fk_persona as fk1_1_ ....leonardoJob: [scrivere documentazione, scrivere codice]aleJob: [rispondere alle mail, dialogare con i clienti]

Come possiamo facilmente vedere dai log, Nhibernate esegue una query per ot-tenere tutte le Persone e successivamente una per ogni Persona per ricercare i suoi


Job. E inutile dire che tale comportamento e inutile quanto dannoso, in quanto nonsfrutta le caratteristiche dei DBMS attuali ed esegue un numero di query che e linearecon il numero di Persone. E possibile, ragionando un secondo, trovare la soluzionee riuscire ad applicarla; si tratta semplicemente di eseguire una query unica in cuiottengo sia la lista delle Persone che dei Job relativi. Nhibernate si occupera per medi ritornare una lista di Persone correttemente inizializzate con i relativi Job senzadover analizzare autonomamente il risultato della query. La query da eseguire e laseguente:

Query q = session.createQuery("from Persona as pleft outer join fetch p.job");

Possiamo verificare come questa volta non ci sia bisogno di eseguire un numeromolto alto di query, ma come ne basti semplicemente una.

Stampo tutte le persone con i rispettivi jobNhibernate: select persona0_.id_persona as ....leonardoJob: [scrivere codice, scrivere documentazione]

Capitolo 4

Realizzazione del mapper automatico per Nhibernate

In questo capitolo si vedra la parte operativa della presente tesi. Dopo aver introdottouna tecnologia per la progettazione del software a livello molto professionale e di altaqualita, presenteremo il progetto Generatore di Strati Software (GSS 1.0) sviluppatoda me, in particolare si vedra com’e stato realizzato il file di mapping, cuore di ogniORM.

4.1 UML e metodologie per la progettazione delsoftware

All’inizio degli anni ’90 esistevano molte metodologie orientate agli oggetti; ognuna sibasava sulle esperienze di autori e su punti di vista diversi. Queste metodologie sonoconcorrenti sul mercato. Scegliere una metodologia piu adatta ad una certa aziendaspesso non e ad alcun titolo una decisione razionale, ma piuttosto e piu simile adun atto di fede. Nei vent’anni successivi alle prime esperienze con le metodologiedi sviluppo orientate agli oggetti furono investiti molti soldi nello sviluppo di varienotazioni per la descrizione di problemi tecnici e le relative soluzioni. Cosi sı affermoil linguaggio UML(Unified Modeling Language). Questo linguaggio fu sviluppato datre autori, cioe James Rumbaugh, Grady Booch e Ivar Jacobson i quali a sua voltaavevano sviluppato singolarmente tre metodologie orientate agli oggetti.

1. OMT

2. OOAD

3. OOSE

Ognuno di questi metodi aveva, naturalmente, i suoi punti di forza e i suoi puntideboli. Ad esempio, l’OMT si rivelava ottimo in analisi e debole nel design. Booch1991, al contrario, eccelleva nel disegno e peccava in analisi. OOSE aveva il suo puntodi forza nell’analisi dei requisiti e del comportamento di un sistema ma si rivelavadebole in altre aree.

UML e una notazione; i.e. non impone alcuna modalita di lavoro che possaportare a una metodologia ben precisa. Questo rende possibile adottare varie tecnichedi sviluppo software basandosi su un’unica notazione: UML.

Elenchiamo, qui di seguito, alcuni dei benefici derivanti dall’utilizzo del linguaggioUML:

• un sistema software, grazie al linguaggio UML, viene disegnato professional-mente e documentato ancor prima che ne venga scritto il relativo codice daparte degli sviluppatori. Si sara cosi in grado di conoscere in anticipo il risultatofinale del progetto su cui si sta lavorando;

82

4.1. UML E METODOLOGIE PER LA PROGETTAZIONE DELSOFTWARE 83

• poiche la fase di disegno del sistema precede la fase di scrittura del codice, neconsegue che questa e resa piu agevole ed efficiente, oltre al fatto che in talmodo e piu facile scrivere del codice riutilizzabile in futuro. I costi di sviluppo,dunque, si abbassano notevolmente con l’utilizzo del linguaggio UML;

• e piu facile prevedere e anticipare eventuali buchi nel sistema. Il software chesi scrive, si comportera esattamente come ci si aspetta senza spiacevoli sorpesefinali;

• l’utilizzo dei diagrammi UML permette di avere una chiara idea, a chiunque siacoinvolto nello sviluppo, di tutto l’insieme che costituisce il sistema. In questomodo, si potranno sfruttare al meglio anche le risorse hardware in termini dimemoria ed efficienza, senza sprechi inutili o, al contrario, rischi di sottostimadei requisiti di sistema;

• grazie alla documentazione del linguaggio UML diviene ancora piu facile effet-tuare eventuali modifiche future al codice. Questo, ancora, a tutto beneficiodei costi di mantenimento del sistema.

Mostriamo brevemente una sintesi delle operazioni da svolgersi per una correttaserializzazione del lavoro di progettazione di un software:

• Raccolta dei requisiti: E la prima fase di lavoro congiunto con il cliente, chepartendo dalle sue intenzioni iniziali e dai suoi desideri, ha lo scopo di produrreun documento informale, scritto in linguaggio naturale, che elenca i requisiti ele specifiche richiesti. Deve essere il piu possibile breve e chiaro;

• Stesura del glossario: In questa fase si deve definire la terminologia delprogetto, identificando con precisione e accurattezza le entita (eventi, persone,strutturazioni, ecc.) coinvolte nel sistema del mondo reale (ovvero del dominiodel business) che hanno importanza per il sistema informatico obiettivo delprogetto. E importante definire con precisione le entita allo scopo sia di definiremeglio i loro scenari d’uso (Use Case), sia di individuare le classi entita (ClassDiagram di analisi). Il risultato finale e il glossario;

• Stesura degli Use Case - Fase di Analisi: In questa fase devono essereindividuati con precisione gli scenari di interazione fra il sistema e gli attori,ovvero le entita esterne al sistema con cui esso interagisce e comunica. I passinecessari in questa fase possono essere cosı suddivisi:

1. Definizione esatta del boundary o confine del sistema (entro siste-mi particolarmente complessi questa fase puo anche essere applicata asottosistemi).

2. Identificazione e definizione degli attori, ossia delle entita esterne con cuiil sistema (o i sottosistemi) oggetto dell’analisi interagiscono e comuni-cano;

3. Individuazione dei vari scenari di uso/interazione fra sistema ed attori, checorrisponderanno ai singoli casi d’uso, identificati da elissi nel diagramma;

4. Definizione delle interazioni entro i singoli casi d’uso; tali interazioni,strutturate nella forma di richiesta dell’attore cui corrisponde una rispostadel sistema, andranno a costituire i campi descrizione dei singoli casi d’uso(operazione detta in gergo “srotolamento” dello use case);

84CAPITOLO 4. REALIZZAZIONE DEL MAPPER AUTOMATICO PER

NHIBERNATE

5. Esame dei diagrammi cosı ottenuti e delle loro descrizioni per procederealla raccolta a fattore comune di parti fra i singoli use case entro dia-grammi, facendo uso delle relazioni extends ed include definibili tra i varicasi d’uso. Il passo 5 puo essere iterato piu volte; occorre tenere contodella granularita del problema e del grado di definizione e precisione chesi vuole raggiungere. Inoltre si deve considerare che un singolo caso d’usospesso da origine ad una singola maschera (sia essa un menu testuale, unasingola finestra in ambiente grafico o una pagina Web).

Il prodotto di questo passo e l’insieme completo degli use case inseriti entro unoo piu diagrammi, ciascuno dei quali corredato da una adeguata descrizione,strutturata chiaramente in forma di request-response, e considerando sia ilpercorso principale di interazione (basic course) sia gli eventuali percorsi al-ternativi (alternative course). Il diagramma e le descrizioni devono essere benstrutturati, chiari ed esaurienti in quanto tutti i passi successivi si baserannosu di essi;

• Stesura del Class Diagram di analisi: In questa fase deve essere realizza-to il diagramma delle classi di analisi. Esso deve indicare chiaramente tuttele classi entita, ossia le classi definibili come proiezioni nel dominio dell’appli-cazione software dell’entita del problema in cui l’applicazione software andraad operare, piu eventuali altre classi individuate nel corso dell’analisi e chesiano di una certa rilevanza per i concetti funzionali che definiscono i requisitidel progetto. In pratica nel diagramma, che e l’equivalente dal punto di vistadel ruolo del diagramma Entita - Relazione (ER) usato nelle metodologie disviluppo piu tradizionali, devono essere indicate in modo chiaro:

1. tutte le classi entita che fanno parte del dominio del problema;

2. gli attribuiti caratteristici di tali classi, eventualmente procedendo al-la individuazione dei singoli attributi o dei gruppi che consentano unaindentificazione univoca delle istanze delle classi ovvero dei singoli oggetti;

3. le associazioni che intercorrono tra tali classi; queste associazioni (checorrispondono alle relazioni dei diagrammi ER) sono importanti perchein sede di implementazione del codice indicheranno anche la visibilitanecessaria tra le classi, cioe quali altre classi (eventualmente appartenentiad altri package o namespace) potranno essere viste da una certa classee definendo quindi la loro interdipendenza;

4. i versi di tali associazioni (ad esempio, se la classe magazzino deve conoscerela classe prodotto, non e sempre vero il contrario);

5. le molteplicita di tali associazioni (es. uno a molti, molti a molti) e l’even-tuale necessita di definire classi di associazione. Per esempio il concettodi proprieta di un’auto, una volta rappresentato nel dominio delle classi,puo costuire una classe di associazione fra l’auto e la persona che ricopreil ruolo di proprietario;

6. eventuali rapporti di inclusione legati a tali associazioni e suddivisi fraaggregazione e composizione. Si ricordi che l’eliminazione di una com-posizione, indicata con il diamante nero, elimina anche tutti i suoi el-ementi componenti, mentre l’eliminazione di una aggregazione, indica-ta nella rappresentazione UML dei class diagram con il diamante bian-

4.1. UML E METODOLOGIE PER LA PROGETTAZIONE DELSOFTWARE 85

co/nero, non elimina anche i componenti che comunque hanno un ambitodi sopravvivenza indipendente;

7. eventuali rapporti di ereditarieta fra le classi ottenuti applicando i principidi generalizzazione e specializzazione, ovvero raccogliendo a fattor comuneattributi e metodi o aggiungendone di nuovi.

Il processo che conduce al diagramma finale e ovviamente iterativo e puo dirsistabilizzato quando tutte le relazioni (in senso ampio) fra le classi sono chiara-mente individuate. Il Class Diagram di analisi e fondamentale per tutti i passisuccessivi;

• Scelta architetturale: La scelta architetturale e un passo fondamentale inquanto le fasi successive ne verranno pesantemente condizionate. Esistono co-munque regole generali che ne aiutano lo svolgimento quali il pattern Model-View-Controller (MVC) (che abbiamo visto) ed il conseguente approccio mul-ticanale alla realizzazione delle interfacce utenti. Seguendo tale metodo sisepara nettamente l’interfaccia utente vera e propria (View) che ha lo scopodi presentare i dati all’utente ed e ovviamente soggetta a vincoli, dal tipo dicanale di comunicazione utilizzato (interfaccia a finestre grafiche, shell a carat-teri, ecc.), dal reattore agli eventi trasmessi dall’utente (Controller) che usa imetodi forniti dagli strati interni dell’applicazione (Model e relativi Adapter)per garantire all’utente i servizi associati alle richieste effettuate. Grazie all’ap-proccio multicanale, eventualmente corredato dall’uso di altri strati di Adapter,diviene possibile riutilizzare (almeno in buona parte) il Controller (ed ovvia-mente gli strati sottostanti) cambiando solo la View quando si cambia canale,passando, ad esempio, da una applicazione GUI ad una Web. La scelta dell’ar-chitettura deve anche segnalare limiti e criticita nel sistema che sara realizza-to. L’output di questa fase sono documenti tecnici architetturali che sarannopoi corredati da eventuali Component Diagram e Deployment Diagram solo altermine della fase di progetto vera e propria;

• Definizione del class diagram di progetto - Fase di Progettazione: Inquesta fase occorre definire chiaramente tutte le classi che fanno parte dell’ap-plicazione software da implementare. Il Class Diagram di Progetto e l’elencocompleto delle classi e di tutte le relazioni e su di esso si basa anche il di-mensionamento della fase di sviluppo (ovvero la scrittura vera e propria delcodice). Il processo che permette di giungere al diagramma delle classi di pro-getto e necessariamente iterativo. Si parte dal diagramma delle classi di analisie progressivamente vengono inserite tutte le classi di servizio che permettonoal programma nel suo insieme di operare correttamente ed in modo efficiente.Le classi di servizio sono ovviamente fortemente dipendenti nella loro strut-tura dall’architettura scelta e da eventuali framework utilizzati nel progetto.Se un diagramma di analisi ben fatto puo essere spesso utilizzato con diversetecnologie ad oggetti, ovvero essere punto di partenza per progetti analoghi re-alizzati su piattaforme diverse, un diagramma di progetto e chiaramente moltopiu influenzato dalla tecnologia usata. Il processo usa anche altri diagrammiUML:

1. i diagrammi di interazione (sequence diagram, che evidenzia la sequen-za temporale delle interazioni, e collaboration diagram, che chiarisce ladipendenza fra le classi) sono di importanza fondamentale sia per la


NHIBERNATE

definizione dei metodi che le classi offrono (e dei loro argomenti e valori diritorno), sia per l’individuazione di eventuali colli di bottiglia che vengonorisolti con l’inserimento di nuove classi o la cancellazione di quelle ridon-danti. In teoria ad ogni use case corrisponde almeno un sequence o un col-laboration diagram: infatti ogni corso di eventi individuato nell’analisi congli use case dovrebbe produrre una precisa sequenza temporale di invo-cazione di metodi all’interno dell’insieme delle classi costituenti il sistemasoftware. Non sempre e pero indispensabile un’implementazione comple-ta, specie se gli eventi presentano evidenti analogie e similitudini, nel qualcaso basta apportare le opportune descrizioni di accompagnamento;

2. i diagrammi di attivita (activity diagram) derivano dagli Use Case e dan-no loro una sequenza temporale e logica. Inoltra possono aiutare moltonella definizione della mappa di navigazione tra le finestre, consenten-do di definire completamente l’interfaccia utente di un applicativo edeventualmente di realizzare i prototipi d’analisi;

3. i diagrammi di stato (statechart diagram) sono anch’essi molto importantiper valutare l’evoluzione temporale delle singole classi (o meglio deglioggetti da esse istanziati) o di sottosistemi che esse vanno a costituire,aiutando ad individuare eventuali condizioni critiche o colli di bottigliadell’applicazione.

L’obiettivo finale e comunque la realizzazione del Class Diagram di Progetto,completo di tutte le classi. Spesso per motivi di chiarezza (specialmente inprogetti grandi dove le classi sono molto numerose) il diagramma viene divisoin package o namespace, associazioni di classi corrispondenti ad unita funzion-ali, che indicano esternamente solo le reciproche relazioni. Ciascun packageviene poi rappresentato completamente entro un diagramma di secondo livello.Quasi sempre questa suddivisione funzionale viene anche portata a livello im-plementativo servendosi delle aggregazioni tipiche dei linguaggi, come i packagedi Java o i namespace di C#. L’obiettivo deve essere sempre quello di avereun diagramma leggibile, che serve come mappa per lo sviluppo. Da questodiagramma possono anche essere generati gli scheletri delle classi attraversoopportuni strumenti, oppure essere estrapolati i Fogli di specifica, ossia i doc-umenti che descrivono ciascuna classe con attributi, metodi, vincoli e controllida implementare;

• Definizione delle strutture di contorno : Usando i diagrammi realizzati inprecedenza si arriva a definire le parti implementative di contorno del progetto,che devono essere opportunamente documentate come segue:

1. definizione della base di dati, attraverso un EER, eventualmente corredatodagli script di creazione delle tabelle e vincoli che genera la base di datinello specifico DBMS scelto;

2. definizione dell’insieme dei singoli componenti software (namespaces, li-brerie statiche o dinamiche, dll, ecc.) che devono essere prodotti, conl’indicazione delle loro interdipendenze, attraverso un opportuno Compo-nent Diagram;

3. definizione della distribuzione dei componenti sulla o sulle piattaformedi produzione prescelte attraverso uno o piu opportuni Deployment Dia-gram;

4.2. OBIETTIVI DEL PROGETTO 87

4. stesura di opportuni documenti Readme ed altro che corredino il progettoe l’installazione; in particolare devono essere chiaramente indicati even-tuali limiti e/o malfunzionamenti delle piattaforme software e hardwareutilizzate;

5. stesura dell’opportuno manuale utente dell’applicazione secondo i criteristabiliti;

6. definizione delle scadenze e pianificazione dell’esecuzione temporale delprogetto in base ai dimensionamenti svolti e alle risorse a disposizione;

7. definizione dei testi e dei singoli casi di test;

8. pianificazione del collaudo e dell’entrata in produzione;

9. definizione della successiva fase di manutenzione.

Il linguaggio C#

Il linguaggio C# e il nuovo linguaggio semplice, moderno e orientato agli oggettiprogettato da Microsoft per combinare la potenza del C e C++ e la produttivitadi Visual Basic. E molto simile a Java, il linguaggio introdotto dalla SUN Mi-crosystems nel 1995, soprattutto in merito alla sintassi, alla grande integrazionecon il Web e alla gestione automatica della memoria. Le caratteristiche di talelinguaggio sono:

1. C# e case sensitive, differenzia cioe tra maiuscole e minuscole;

2. Le parole chiave del linguaggio fanno uso principalmente del minuscolo;

3. I blocchi di codice sono delimitati da parentesi graffe;

4. Ogni istruzione, a eccezione dei cicli e dei blocchi di codice, va terminatacon il punto e virgola;

4.2 Obiettivi del progetto

Il progetto Generatore Strati Software ha come obiettivo quello che data una tabellanel mondo dei database relazionali, costruisca in modo automatico le seguenti cose:

1. Il file POCO dove conterra la classe entita;

2. L’adapter con le query automatiche dove saranno costruiti in manieraautomatica le principali operazioni CRUD (creazione, selezione, cancellazionee aggiornamento);

3. Il wrapper dove conterra metodi che richiamano l’adapter. Valido solo per lequery automatiche;

4. L’adapter che usa Nhibernate dove saranno costruiti in maniera automat-ica le principali operazioni CRUD usando la libreria Nhibernate che abbiamovisto nel capitolo precedente;

5. Il file XML che serve a Nhibernate per il fare il mapping Object-Relational;


NHIBERNATE

Figura 4.1: Use Case Diagram del GSS

Questo progetto ideato dalla ditta Area SP, sara collocato nel framework 3.5 di.NET. Per questo abbiamo deciso come scelta di linguaggio di programmazione ilprincipe del mondo .NET: C#.

Alla fine si dovra provare a caricare dati in strutture OO da RDBMS e si dovran-no confrontare in termini di prestazioni Nhibernate con il mio generatore di stratisoftware.

4.3 Analisi, progettazione ed implementazione

Nella figura 4.1 viene mostrato il diagramma dei casi d’uso che l’utente puo sceglierenell’utilizzo del software Generatore Strati Software.

L’utente all’inizio deve scegliere il nome del progetto dove vorra salvare gli -ingredienti per l’ORM. Dopo di che, dovra connettersi ad una sorgente di basi di datifornendo una stringa di connessione e una volta che la connessione e avvenuta consuccesso, dovra selezionare una o piu tabelle del database che e stato connesso. Aquesto punto l’utente avra la possibilita di generare i seguenti cinque file: file POCO,file Adapter, file Adapter che usa Nhibernate, file Mapping. Per la generazione degliAdapter, Wrapper vengono utilizzati dei template, che sono file di testo contenentidei tag. Esempio:

using System;using System.Collections.Generic;

4.3. ANALISI, PROGETTAZIONE ED IMPLEMENTAZIONE 89

using System.Collections;using System.Text;using System.Data;using System.Data.Common;using System.Data.OleDb;using System.Linq;using Poco;using AreaFramework.Wrapper;

namespace $NomeNamespace$.Adapter

public class $NomeTabella$_Adapter : ProtoAdapter

// ATTRIBUTI// stringhe query di selezione (analoghe alle precedenti)private static string sql_Select = "SELECT * FROM $NomeTabella$";

$GeneraQuerySelectDataBy$private static string sql_SelectBy$Campi$ = sql_Select + "WHERE ($Campi$ = ?) ";

private static string sql_SelectBy$ChiavePrimaria$ =sql_Select + " WHERE ($ChiavePrimaria$ = ?) ";

private static string sql_SelectMax$ChiavePrimaria$ ="SELECT MAX($ChiavePrimaria$) FROM $NomeTabella$";

private static string sql_DeleteBy$ChiavePrimaria$ ="DELETE FROM $NomeTabella$ WHERE ($ChiavePrimaria$ = ?)";

private static string sql_DeleteByAllField ="DELETE FROM $NomeTabella$ WHERE($ChiavePrimaria$ = ? AND $CampiSeparatiAnd$)";

private static string sql_Insert ="INSERT INTO $NomeTabella$ ($CampiSeparatiVirgola$)VALUES ($Interrogativi$)";

private static string sql_UpdateBy$ChiavePrimaria$ ="UPDATE $NomeTabella$SET $CampiSeparatiVirgolaConAssegnamento$ WHERE

$ChiavePrimaria$ = ? ";.........


NHIBERNATE

Vediamo brevemente la descrizione dei casi d’uso relativi alla figura 6.1.

Configurazione del progetto: L’utente inserisce il nome del progetto e altriparametri per salvare i file che mano a mano vengono generati;

Connessione ad una base di dati: L’utente puo scegliere come inserire la stringadi connessione per accedere ad una sorgente di basi dati;

Selezione di una o piu tabella da DBMS: L’utente dopo essersi connesso aduna base di dati avra la possibilita di selezionare una o piu tabelle di queldeterminato database;

Scelta della sintassi del linguaggio da generare: L’utente avra la possibilitadi scegliere il come generare l’Adapter e il Wrapper, ovvero quale sintassi dilinguaggi di programmazione orientati agli oggetti da utilizzare;

Genera file POCO: L’utente ha la possibilita di generare un classe entita che eisomorfo ad una tabella che sono state selezionate in precedenza;

Genera Adapter: L’utente ha la possibilita di generare un Adapter partendo dallalettura di un template specifico;

Genera Wrapper: L’utente ha la possibilita di generare un Wrapper partendodalla lettura di un template specifico;

Genera Adapter che usa Nhibernate: L’utente ha la possibilita di generareun Adapter che usa al suo interno la libreria open source Nhibernate partendodalla lettura di un template specifico;

Genera Mapper: L’utente ha la possibilita di generare un Mapper scritto in xml;

Lettura template: L’utente per generare l’adapter e il wrapper ha bisogno dileggere un template, cioe un file di testo contenente del codice;

Per quanto riguarda la progettazione, ho utilizzato il paradigma MVC, strutturatain tre livelli principali: LibCodeDB (model), Generatore Strati Software (View) eLibVisualDb (Controller).

In figura 4.2 e possibile vedere l’organizzazione modulare dell’applicazione, dovevengono evidenziati i seguenti namespace: LibCodeDb, Generatore Strati Software eLibVisualDb.

In figura 4.3 e possibile vedere come e fatto il namespace LibCodeDB.In figura 4.4 viene mostrato il namespace LibCodeDb.LinguaggiProgrammazione.

Mentre nella figura 4.5 viene mostrato il namespace LibCodeDb.Tags.Per implementare il mio progetto ho utilizzato il concetto dell’ OCP (Open-Close

Principle). Ideato da Bertrand Meyer nel 1988.

Le entita software (Classi, Moduli, Funzioni ecc.) devono essere aperte alleestensioni, ma devono essere chiuse alle modifiche.

Cio vuole dire che occorre strutturare un’applicazione in modo che sia possibileaggiungere nuove funzionalita con una modifica minima al codice esistente. Occorreevitare che una semplice modifica si diffonda con effetto domino nelle varie classi

4.3. ANALISI, PROGETTAZIONE ED IMPLEMENTAZIONE 91

Figura 4.2: Struttura a Namespace del Software GSS

Figura 4.3: Il Namespace LibCodeDB

Figura 4.4: La struttura del namespaceLibCodeDb.LinguaggiProgrammazione


NHIBERNATE

Figura 4.5: La struttura del namespace LibCodeDb.Tags

dell’applicazione. Cio rende il sistema fragile, incline a problemi di regressione edispendioso da estendere. Per isolare le modifiche, e possibile scrivere classi e metodiin modo tale che che non sia mai necessario modificarli una volta scritti. Un esempiodi utilizzo dell’OCP e la classe astratta Linguaggi. Essa fornisce dei metodi virtualiche una volta che una classe concreta (per esempio Java) eredita da lui, puo ridefinirsii metodi della classe astratta (polimorfismo dinamico e tecnica override).

Se un giorno qualcuno ci chiedesse di generare gli ingredienti per l’ORM nellinguaggio Python, per esempio, basta scrivere una classe concreta Python che ereditada Linguaggi.

4.4 Il progetto compiuto

Vediamo adesso come ho progettato il mapper automatico.Il file che permette a una libreria ORM di mappare tabelle del mondo RDBMS e

classi entita nel mondo OOP e chiamato file di mapping. Esso come abbiamo vistoquando si e parlato di Nhibernate consiste nello specificare usando sintassi XML inche modo si mappa la classe con la tabella e le relazioni tra le tabelle.

Le classi che ho usato per creare il mapping, come si vede nella figura 4.3 sono:

1. GeneratoreMapping;

2. DescrittoreSchemaDb;

Il DescrittoreSchemaDb e una classe che permette di estrapolare le relazioniche intercorrono tra le tabelle di un RDBMS mediante una proprieta dell’oggettoOleDbConnection.

Nel codice che segue viene mostrato il metodo che ho creato per estrapolare lerelazioni.

/// <summary>/// Carica dentro i vettori latoUno[] e latoMolti[]

4.4. IL PROGETTO COMPIUTO 93

/// i nomi delle tabelle facente parte rispettivamente/// il lato uno e il lato molti delle relazioni che intercorrono/// tra le tabelle di un database./// </summary>

private void caricaVettoriRelazioni()

tabella = connessione.GetOleDbSchemaTable(OleDbSchemaGuid.Foreign_Keys,new object[]null, null, null, null );

latoUno = new string[tabella.Rows.Count];latoMolti = new string[tabella.Rows.Count];fk = new string[tabella.Rows.Count];

int i = 0;foreach (DataRow row in tabella.Rows)

//Nome della tabella dove sta il lato 1 della relazionestring strTable = row["PK_TABLE_NAME"].ToString();

//Nome della colonna del genitore, ovvero della tabella dove//c’e il lato 1

string strParentColName = row["PK_COLUMN_NAME"].ToString();//Nome della chiave esterna della tabella figlia//relazionate con il padrestring strChildColName = row["FK_COLUMN_NAME"].ToString();

//Nome della tabella figlia relazionata con strTablestring strChild = row["FK_TABLE_NAME"].ToString();

latoMolti[i] = strChild;latoUno[i] = strTable;fk[i] = strChildColName;++i;

//end ciclo//end metodo caricaVettoriRelazioni()

Per quanto rigurda la classe GeneratoreMapping ho utilizzato i metodi dellalibreria System.Xml. Esso supporta classi che servono per elaborare e creare fileXML.

Qui di seguito viene riportato il codice relativo alla generazione automatica delmapper in XML.


NHIBERNATE

public void costruisciXML(string p_nomeClasse,string p_nomeTabella,string p_percorso)

XmlDocument documentoMapper = new XmlDocument();

//Creazione sezione dichiarazione e dtdXmlDeclaration xDec = documentoMapper.CreateXmlDeclaration("1.0",

"utf-8","no");

XmlDocumentType xType = documentoMapper.CreateDocumentType("hibernate-mapping",@"-//Hibernate/Hibernate Mapping DTD 2.0//EN",@"http://hibernate.sourceforge.net/

hibernate-mapping-2.0.dtd", null);

//Inseriamo, prima della radice del documento, la dichiarazionedocumentoMapper.InsertBefore(xDec, documentoMapper.DocumentElement);

//Creiamo il primo nodo, radiceXmlNode root = documentoMapper.CreateNode(XmlNodeType.Element,

"hibernate-mapping",null);

XmlAttribute attributi = documentoMapper.CreateAttribute("xmlns");attributi.Value = "urn:nhibernate-mapping-2.2";attributi = documentoMapper.CreateAttribute("assembly");attributi.Value = "";root.Attributes.Append(attributi);attributi = documentoMapper.CreateAttribute("namespace");attributi.Value = "";root.Attributes.Append(attributi);documentoMapper.InsertAfter(root, xDec);

//Nodo Class : <class ...>...</class>XmlNode nodoClasse = documentoMapper.CreateNode(

XmlNodeType.Element,"class", null);

attributi = documentoMapper.CreateAttribute("name");attributi.Value = p_nomeClasse;nodoClasse.Attributes.Append(attributi);attributi = documentoMapper.CreateAttribute("table");attributi.Value = p_nomeTabella;nodoClasse.Attributes.Append(attributi);

//Nodo Id :<id ...>....</id>XmlNode nodoId = documentoMapper.CreateNode(XmlNodeType.Element,


"id",null);

attributi = documentoMapper.CreateAttribute("name");attributi.Value =

ManipolazioneStringhe.trasformaMaiuscoloLetteraIniziale(tInf["chiavePrimaria"]);

nodoId.Attributes.Append(attributi);attributi = documentoMapper.CreateAttribute("unsaved-value");attributi.Value = "0";nodoId.Attributes.Append(attributi);

attributi = documentoMapper.CreateAttribute("access");attributi.Value = "property";nodoId.Attributes.Append(attributi);

attributi = documentoMapper.CreateAttribute("type");attributi.Value = tipiNibh.getChiave(tInf["tipoChiavePrimaria"]);nodoId.Attributes.Append(attributi);

//Nodo Id figlio : <id ...> <column ...> ... </column></id>XmlNode nodoIdFiglio = documentoMapper.CreateNode(XmlNodeType.Element,

"column", null);

attributi = documentoMapper.CreateAttribute("name");attributi.Value = tInf["chiavePrimaria"];nodoIdFiglio.Attributes.Append(attributi);

XmlNode nodoIdGenerator = documentoMapper.CreateNode(XmlNodeType.Element,"generator", null);

attributi = documentoMapper.CreateAttribute("class");attributi.Value = "increment";nodoIdGenerator.Attributes.Append(attributi);

//Creiamo le relazioni "familiari" tra i nodiroot.AppendChild(nodoClasse);nodoClasse.AppendChild(nodoId);nodoId.AppendChild(nodoIdFiglio);nodoId.AppendChild(nodoIdGenerator);

//Sezione propriety//Nodo Proprieta : <proprety ...> costruzione dinamicaIEnumerator count = nomeAttributi.GetEnumerator();int i = 0;while (count.MoveNext())

bool presente = false;


NHIBERNATE

if (presente == false)

XmlNode nodoProperty = documentoMapper.CreateNode(XmlNodeType.Element,"property", null);


ManipolazioneStringhe.trasformaMaiuscoloLetteraIniziale(nomeAttributi[i].ToString());

nodoProperty.Attributes.Append(attributi);attributi = documentoMapper.CreateAttribute("type");attributi.Value = tipiNibh.getChiave(

tipiNomeAttributi[i].ToString());nodoProperty.Attributes.Append(attributi);

XmlNode nodoPropertyFiglio = documentoMapper.CreateNode(XmlNodeType.Element,"column", null);

attributi = documentoMapper.CreateAttribute("name");attributi.Value = nomeAttributi[i].ToString();nodoPropertyFiglio.Attributes.Append(attributi);nodoProperty.AppendChild(nodoPropertyFiglio);nodoClasse.AppendChild(nodoProperty);

++i;

//end ciclo

//Sezione attributi relazionati: Gestione relazione 1 a moltiIEnumerator c = latoUno.GetEnumerator();int conta = 0;while (c.MoveNext())

if (latoUno[conta].Contains(p_nomeTabella))

XmlNode nodoSet = documentoMapper.CreateNode(XmlNodeType.Element,"set", null);


ManipolazioneStringhe.trasformaMaiuscoloLetteraIniziale(latoMolti[conta].ToString());

nodoSet.Attributes.Append(attributi);attributi = documentoMapper.CreateAttribute("lazy");attributi.Value = "false";nodoSet.Attributes.Append(attributi);

XmlNode nodoSetFiglio = documentoMapper.CreateNode(XmlNodeType.Element,


"key", null);attributi = documentoMapper.CreateAttribute("column");attributi.Value = fk[conta];nodoSetFiglio.Attributes.Append(attributi);attributi = documentoMapper.CreateAttribute("not-null");attributi.Value = "true";nodoSetFiglio.Attributes.Append(attributi);

XmlNode nodoSetFiglioDue = documentoMapper.CreateNode(XmlNodeType.Element,"one-to-many", null);

attributi = documentoMapper.CreateAttribute("class");attributi.Value = latoMolti[conta];nodoSetFiglioDue.Attributes.Append(attributi);

nodoSet.AppendChild(nodoSetFiglio);nodoSet.AppendChild(nodoSetFiglioDue);nodoClasse.AppendChild(nodoSet);

++conta;

//end ciclo

//Sezione attributi relazionati: Gestione relazione molti a 1IEnumerator c2 = latoMolti.GetEnumerator();int contaMolti = 0;while (c2.MoveNext())

if (latoMolti[contaMolti].Contains(p_nomeTabella))

XmlNode nodoManyToOne = documentoMapper.CreateNode(XmlNodeType.Element,"many-to-one", null);

attributi = documentoMapper.CreateAttribute("name");attributi.Value = latoUno[contaMolti];nodoManyToOne.Attributes.Append(attributi);attributi = documentoMapper.CreateAttribute("column");attributi.Value = fk[contaMolti];nodoManyToOne.Attributes.Append(attributi);attributi = documentoMapper.CreateAttribute("not-null");attributi.Value = "true";nodoManyToOne.Attributes.Append(attributi);nodoClasse.AppendChild(nodoManyToOne);

++contaMolti;

//end ciclo//Salviamo il documento XML in PERCORSOpercorso = p_percorso;


NHIBERNATE

if (File.Exists(percorso))File.Delete(percorso);

documentoMapper.Save(percorso);

//end metodo costruisciXML(..)

Il namespace System.Xml e formato dalle seguenti classi:

• XmlNode: Una classe astratta che rappresenta un singolo nodo in un docu-mento XML;

• XmlDocument: Estende XmlNode. Questo e l’implementazione di W3CDOM. Esso provedere a rappresentare in memoria un albero di un documentoXML, abilitato a navigarlo e a modificarlo;

• XmlDataDocument: Estende XmlDocument. Questo e un documento chepuo essere caricato da dati XML o da dati relazionali in ADO.NET;

• XmlResolver: Una classe astratta che risolve esternamente risorse basate suXML come DTD e riferimenti a schema;

• XmlNodeList: Una lista di XmlNodes che possono essere iterati tra di loro;

• XmlUrlResolver: Estende XmlResolver. Risolve esternamente i nomi dellerisorse tramite un URI.

Come si puo vedere dal codice sopra, per prima cosa ho costruito la parte iniziale,che e uguale per tutti i file con estensione .hbm.xml.

Quindi mi costruisce la seguente cosa: Esempio tratto dall’entita ANAGRAFICAche vedremo nel prossimo capitolo quando parleremo delle entita e delle basi di datiche ho utilizzato.

<?xml version="1.0" encoding="utf-8" standalone="no"?><hibernate-mapping assembly="" namespace=""><class name="ANAGRAFICA" table="ANAGRAFICA">......</class></hibernate-mapping>

Poi ho costruito il tag id ... ....id e il risultato e stato:

<id name="Id" unsaved-value="0" access="property" type="System.Int32"><column name="ID" /><generator class="increment" />

</id>


Poi ho costruito il tag property..column...column..property e il risultato e stato:

<property name="Cognome" type="System.String"><column name="COGNOME" />

</property>

<property name="Nome" type="System.String"><column name="NOME" />

</property>

<property name="Codice" type="System.String"><column name="CODICE" />

</property>

<property name="Data_nascita" type="System.DateTime"><column name="DATA_NASCITA" />

</property>

<property name="Binario" type="System.Boolean"><column name="BINARIO" />

</property>

<property name="Colore" type="System.String"><column name="COLORE" />

</property>

Adesso veniamo a vedere come ho generato il file POCO o POJO o POVO aseconda della scelta di un linguaggio di programmazione orientati agli oggetti.

In sede di Analisi si e scelta la generazione automatica nei seguenti tre linguaggidi programmazione:

1. CSharp: File POCO;

2. Java: File POJO;

3. Vb.net: File POVO;

Nella figura 4.6 viene mostrata la classe astratta Linguaggi con i suoi metodiastratti. In questo capitolo ci focalizzeremo sul metodo astratto GeneraTestoPoco.

Per comodita faccio vedere come ho implementato il file POCO. Per i file POJOe POVO l’implementazione e analoga cambia ovviamente soltanto la sintassi e il tipodi dato (vedremo nel prossimo capitolo quando parleremo di che basi di dati ho sceltoi tipi di dato da RDBMS al mondo .NET).

Riporto le costanti che ho usato per generare il POCO. Si noti che sono usati soloed esclusivamente per la sintassi C#.


NHIBERNATE

Figura 4.6: La classe astratta Linguaggi con le classi concrete che ridefinisconodei metodi di Linguaggi

//ATTRIBUTI COSTANTI#region SEZIONE COSTANTI C#

const string INSERISCI_UNDERLINE = "_";const string CREAZIONE_PUB_STAT_CONST_STRING =

"public static string fieldName";const string CREAZIONE_CLASSE_PUB = "public class ";const string CREAZIONE_PUB_VIRT = "public virtual ";

const string DIRETTIVA_USO = "using System;";const string DIRETTIVA_USO_IESI = "using Iesi;\n

using Iesi.Collections.Generic;\nusing Iesi.Collections;";

const string SPAZIO_NOMI = "namespace ";

const string APRI_GRAFFA = "";const string CHIUDI_GRAFFA = "";const string TONDE = "()";const string SPAZIO = " ";const string PUNTO_VIRGOLA = "; ";

const string COMMENTO_COSTANTI = "//ATTRIBUTI COSTANTI";const string COMMENTO_ATTRIBUTI = "//ATTRIBUTI";const string COMMENTO_COSTRUTTORE = "//COSTRUTTORI";const string COMMENTO_PROPRIETA = "//PROPRIETA’";const string COMMENTO_FINE_CLASSE = "//end class ";const string COMMENTO_FINE = "//end ";

const string VISIBILITA_PRIVATE = "private ";


const string VISIBILITA_PUBLIC = "public ";const string INSERIRE_GET = "get ";const string INSERIRE_SET = "set ";

const string VALORE_DI_RITORNO = "return ";const string VALORE = "value;";

const string INSIEME = "ISet ";const string INIZIALLIZZA_INSIEME = " = new HashedSet();";

#endregion

Il metodo astratto che viene ridefinito nella classe concreta CSharp e il seguente:

public override string generaTestoPoco(string p_nomeNamespace,string p_nomeTabella,ArrayList p_nomeAttributi,ArrayList p_tipoDato,DescrittoreSchemaDB p_descrittoreDb)

latoUno = p_descrittoreDb.ritornaLatoUno();latoMolti = p_descrittoreDb.ritornaLatoMolti();fk = p_descrittoreDb.ritornaForeignKey();

nomeColonnaConvertita = new string[p_nomeAttributi.Count];string testoPoco = null;

testoPoco = sezioneTesta(p_nomeNamespace,p_nomeTabella,p_nomeAttributi,p_tipoDato,p_descrittoreDb);

testoPoco += sezioneProprieta(p_nomeAttributi,p_tipoDato,p_nomeTabella);

testoPoco += sezioneCoda(p_nomeTabella,p_nomeNamespace);

return Indentazione.indenta(testoPoco, 4);//end metodo generaTestoPoco();


NHIBERNATE

Come si puo notare ho suddiviso la mia generazione automatica del file POCOin tre sezioni: sezioneTesta, sezioneProprieta e sezioneCoda. Quando si e parlato diclassi entita e abbiamo fatto vedere di come e fatto, e intuibile la scelta che ho fattonel generarlo.

La sezioneTesta e cosi fatta:

/// <summary>/// Costruisce la parte iniziale del mio file POCO/// </summary>/// <param name="p_nomeNamespace">Il nome del namespace</param>/// <param name="p_nomeTabella">Il nome della tabella</param>/// <param name="p_nomeAttributi">I nomi degli attributi

di una tabella di un database</param>/// <param name="p_tipoDato">I tipi di dato degli attributi

di una tabella di un database</param>/// <returns>Una stringa contenente/// tutta la parte iniziale del file POCO</returns>

private string sezioneTesta(string p_nomeNamespace,string p_nomeTabella,ArrayList p_nomeAttributi,ArrayList p_tipoDato,DescrittoreSchemaDB p_descrittoreDb)

string temp = DIRETTIVA_USO +Environment.NewLine +Environment.NewLine +Environment.NewLine +SPAZIO_NOMI + p_nomeNamespace +Environment.NewLine +APRI_GRAFFA +Environment.NewLine +Environment.NewLine +CREAZIONE_CLASSE_PUB + p_nomeTabella +Environment.NewLine +APRI_GRAFFA +Environment.NewLine +COMMENTO_COSTANTI +Environment.NewLine +Environment.NewLine +costruzioneAttributiCostanti(p_nomeAttributi) +Environment.NewLine +COMMENTO_ATTRIBUTI +Environment.NewLine +Environment.NewLine;

IEnumerator count = p_nomeAttributi.GetEnumerator();


int i = 0;

while (count.MoveNext())

if (nomeColonnaConvertita[i] != null)temp += VISIBILITA_PRIVATE +

p_tipoDato[i] +SPAZIO +nomeColonnaConvertita[i] +PUNTO_VIRGOLA +Environment.NewLine;

++i;

nomeTabellaRifLatoMolti = new string[latoUno.Length];nomeTabellaRifLatoUno = new string[latoMolti.Length];

//Controlliamo se quella determinata tabella e soggetta//a una relazione relativo al lato unoint t = 0;while (t < latoUno.Length)

if (latoUno[t].Contains(p_nomeTabella))

nomeTabellaRifLatoMolti[t] = INSERISCI_UNDERLINE +latoMolti[t].ToLower();

temp += VISIBILITA_PRIVATE +INSIEME +nomeTabellaRifLatoMolti[t] +PUNTO_VIRGOLA +Environment.NewLine;

++t;

//Controlliamo se quella determinata tabella e soggetta//a una relazione relativo al lato moltiint y = 0;while (y < latoMolti.Length)

if (latoMolti[y].Contains(p_nomeTabella))

nomeTabellaRifLatoUno[y] = INSERISCI_UNDERLINE +latoUno[y].ToLower();

temp += VISIBILITA_PRIVATE +latoUno[y] +SPAZIO +


NHIBERNATE

nomeTabellaRifLatoUno[y] +PUNTO_VIRGOLA +Environment.NewLine;

++y;

temp += Environment.NewLine +COMMENTO_COSTRUTTORE +Environment.NewLine +Environment.NewLine;

//Costruzione del mio costruttore di defaulttemp += VISIBILITA_PUBLIC +

p_nomeTabella +TONDE +Environment.NewLine +APRI_GRAFFA +Environment.NewLine;

t = 0;while (t < nomeTabellaRifLatoMolti.Length)

if (nomeTabellaRifLatoMolti[t] != null)temp += nomeTabellaRifLatoMolti[t] +

INIZIALLIZZA_INSIEME +Environment.NewLine;

++t;temp += CHIUDI_GRAFFA +

Environment.NewLine;return temp;

//end metodo sezioneTesta()

La sezioneProprieta e cosi fatta:

/// <summary>/// Costruisce le property del mio file POCO/// </summary>/// <param name="p_listaAttributi">I nomi degli attributi

di una tabella di un database</param>/// <param name="p_tipoDato">I tipi di dato degli attributi

di una tabella di un database</param>/// <returns>La stringa contenente la parte delle proprieta</returns>private string sezioneProprieta(ArrayList p_listaAttributi,


ArrayList p_tipoDato,string p_nomeTabella)

string temp = Environment.NewLine +

COMMENTO_PROPRIETA +Environment.NewLine +Environment.NewLine;

IEnumerator count = p_listaAttributi.GetEnumerator();int i = 0;while (count.MoveNext())

bool presente = ManipolazioneStringhe.verificaPresenzaFk(p_listaAttributi[i].ToString(), fk);

bool presente = false;if (presente == false)

temp += CREAZIONE_PUB_VIRT +p_tipoDato[i] +SPAZIO +ManipolazioneStringhe.trasformaMaiuscoloLetteraIniziale(

p_listaAttributi[i].ToString()) +Environment.NewLine +APRI_GRAFFA +Environment.NewLine +INSERIRE_GET +APRI_GRAFFA +SPAZIO +VALORE_DI_RITORNO +nomeColonnaConvertita[i] +PUNTO_VIRGOLA +CHIUDI_GRAFFA +Environment.NewLine +INSERIRE_SET +APRI_GRAFFA +SPAZIO +nomeColonnaConvertita[i] +" = " +VALORE +SPAZIO +CHIUDI_GRAFFA +Environment.NewLine +CHIUDI_GRAFFA +Environment.NewLine +Environment.NewLine;

++i;


NHIBERNATE

//Controlliamo se quella determinata tabella e soggetta//a una relazione relativo al lato unoint t = 0;while (t < latoUno.Length)

if (latoUno[t].Contains(p_nomeTabella))

temp += CREAZIONE_PUB_VIRT +INSIEME +ManipolazioneStringhe.trasformaMaiuscoloLetteraIniziale(

latoMolti[t]) +Environment.NewLine +APRI_GRAFFA +Environment.NewLine +INSERIRE_GET +APRI_GRAFFA +SPAZIO +VALORE_DI_RITORNO +nomeTabellaRifLatoMolti[t] +PUNTO_VIRGOLA +CHIUDI_GRAFFA +Environment.NewLine +INSERIRE_SET +APRI_GRAFFA +SPAZIO +nomeTabellaRifLatoMolti[t] +" = " +VALORE +SPAZIO +CHIUDI_GRAFFA +Environment.NewLine +CHIUDI_GRAFFA +Environment.NewLine +Environment.NewLine;

++t;//Controlliamo se quella determinata tabella e soggetta a una relazione//relativo al lato moltiint y = 0;while (y < latoMolti.Length)

if (latoMolti[y].Contains(p_nomeTabella))

temp += CREAZIONE_PUB_VIRT +latoUno[y] +SPAZIO +


ManipolazioneStringhe.trasformaMaiuscoloLetteraIniziale(latoUno[y]) +

Environment.NewLine +APRI_GRAFFA + Environment.NewLine +INSERIRE_GET +APRI_GRAFFA +SPAZIO +VALORE_DI_RITORNO +nomeTabellaRifLatoUno[y] +PUNTO_VIRGOLA +CHIUDI_GRAFFA +Environment.NewLine +INSERIRE_SET +APRI_GRAFFA +SPAZIO +nomeTabellaRifLatoUno[y] +" = " +VALORE +SPAZIO +CHIUDI_GRAFFA +Environment.NewLine +CHIUDI_GRAFFA +Environment.NewLine +Environment.NewLine;

++y;return temp;

//end metodo sezioneProprieta()

La sezioneCoda e cosi fatta:

/// <summary>/// Costruisce la parte finale del mio file POCO/// </summary>/// <param name="p_nomeTabella">Il nome della tabella</param>/// <param name="p_nomeNamespace">il nome del namespace</param>/// <returns>La stringa contenente la parte finale del file POCO</returns>private string sezioneCoda(string p_nomeTabella, string p_nomeNamespace)

string temp = Environment.NewLine +CHIUDI_GRAFFA +COMMENTO_FINE_CLASSE +p_nomeTabella +


NHIBERNATE

Environment.NewLine +CHIUDI_GRAFFA +COMMENTO_FINE +SPAZIO_NOMI +SPAZIO +p_nomeNamespace;

return temp;//end metodo sezioneCoda()

Capitolo 5

Realizzazione del prototipo operativo

In questo capitolo viene spiegato in dettaglio le entita e le basi di dati che ho utilizzato.Inoltre verra visto come ho generato l’Adapter e il Wrapper nella versione con queryautomatiche e versione con Nhibernate.

5.1 Le entita e la base di dati utilizzata

Per realizzare il prototipo operativo, abbiamo gia visto le classi che ho utilizzato eabbiamo parlato di come ho realizzato sia il mapper che l’oggetto entita.

Abbiamo detto piu volte che esiste una stretta relazione tra le classi entita e letabelle di un RDBMS.

I DBMS che ho utilizzato sono:

1. SQL SERVER 2005;

2. MICROSOFT ACCESS 2003;

3. MYSQL 5.0;

4. ORACLE 10g;

Diamo un occhiata alla conversione tra tipo di dato nel mondo RDBMS specificoper i 4 RDBMS sopra elencati e il tipo di dato corrispondente nel mondo .NET.Inoltre ci sara anche il tipo di conversione che ho effettuato tramite il mio GeneratoreStrati Software.

La conversione dei tipi di dato: RDBMS — .NET

Nella tabella 4.1 vengono riportati le conversioni di tipo di dato relative al DBMS:SQLSERVER 2005.

Nella tabella 4.2 vengono riportati le conversioni di tipo di dato relative al DBMS:MICROSOFT ACCESS 2003.

Nella tabella 4.3 vengono riportati le conversioni di tipo di dato relative al DBMS:MYSQL 5.0.

Prima di passare a vedere i tipi di dato di ORACLE, mi soffermo sulla tabelladei tipi di MYSQL.

Ho riscontrato che per i tipi bool e boolean sono trattati come tinyint(1), ovverocome short (Int16). 1

Nella tabella 4.4 vengono riportati le conversioni di tipo di dato relative al DBMS:ORACLE 10g.

1Per maggiori dettagli vedere: http://database.html.it/guide/lezione/2444/tipi-di-dati/

109

110 CAPITOLO 5. REALIZZAZIONE DEL PROTOTIPO OPERATIVO

Tipo mondo RDBMS Tipo .NET Conversione usando GSSint System.Int32 int

bigint System.Int64 longbinary(50) System.Byte[] byte[]

bit System.Boolean boolchar(10) System.String stringdatetime System.DateTime DateTime

decimal(18,0) System.Decimal intfloat System.Double double

image System.Byte[] byte[]money System.Decimal decimal

nchar(10) System.String stringntext System.String string

numeric(18,0) System.Decimal intnvarchar(50) System.String string

nvarchar(MAX) System.String stringreal System.Single float

smalldatetime System.DateTime DateTimesmallint System.Int16 short

smallmoney System.Decimal decimalsql variant System.Object object

text System.String stringtimestamp System.Byte[] byte[]

uniqueidentifier System.Guid Guidvarbinary(50) System.Byte[] byte[]

varbinary(MAX) System.Byte[] byte[]varchar(50) System.String string

varchar(MAX) System.String stringxml System.String string

tinyint System.Byte byte

Tabella 5.1: Conversioni di tipo di dato tra DBMS a .NET e conversione datoda GSS per SQLSERVER 2005

5.2. VERSIONE CON QUERY AUTOMATICHE 111

Tipo mondo RDBMS Tipo .NET Conversione usando GSStesto System.String stringmemo System.String string

Numerico: byte System.Byte byteNumerico: intero System.Int16 short

Numerico: intero lungo System.Int32 intNumerico: precisione singola System.Single floatNumerico: precisione doppia System.Double double

Numerico: IDReplica System.Guid GuidNumerico: decimale System.Decimal int

data/ora System.DateTime DateTimeValuta: numero generico System.Decimal decimal

Valuta: valuta System.Decimal decimalValuta: euro System.Decimal decimalValuta: fisso System.Decimal decimal

Valuta: standard System.Decimal decimalValuta: percentuale System.Decimal decimal

Valuta: notazione scientifica System.Decimal decimalcontatore System.Int32 int

Si/No: si/no System.Boolean boolSi/No: vero/falso System.Boolean bool

Si/No: on/off System.Boolean boologgetto OLE System.Byte[] byte[]

collegamento ipertestuale System.String string

Tabella 5.2: Conversioni di tipo di dato tra DBMS a .NET e conversione datoda GSS per Access 2003

Un osservazione da fare e che i tipi NUMERIC, REAL, SMALLINT, DEC vengonotrasformati rispettivamente nei tipi NUMBER, FLOAT, NUMBER, NUMBER.

Come base di dati utilizzata per provare il Generatore Strati Software e undatabase di nome ProtoNews che mi ha fornito l’azienda.

5.2 Versione con Query automatiche

Per generare l’adapter che usa la versione con query automatiche, ho utilizzato laseguente tecnica come illustra la figura 5.1.

Ho utilizzato la classe astratta Tag che come si vede nel codice seguente offre leseguenti funzionalita:

public abstract class Tag


Tipo mondo RDBMS Tipo .NET Conversione usando GSSbigint System.Int64 longbinary System.String string

bit System.String stringblob System.Byte[] byte[]bool System.Int16 short

boolean System.Int16 shortchar System.String stringdate System.DateTime DateTime

datetime System.DateTime DateTimedecimal System.String stringdouble System.Double doubleenum System.String stringfloat System.Single floatint System.Int32 int

longblob System.Byte[] byte[]longtext System.String string

mediumblob System.Byte[] byte[]mediumint System.Int32 intmediumtext System.String string

numeric System.String stringreal System.Double doubleset System.String string

smallint System.Int16 shorttext System.String stringtime System.String string

timestamp System.DateTime DateTimetinyblob System.Byte[] byte[]tinyint System.Int16 short

tinytext System.String stringvarbinary System.String stringvarchar System.String string

year System.Int16 short

Tabella 5.3: Conversioni di tipo di dato tra DBMS a .NET e conversione datoda GSS per MYSQL 5.0


Tipo mondo RDBMS Tipo .NET Conversione usando GSSvarchar2 System.String stringnumber System.Decimal int

clob System.String stringblob System.Byte[] byte[]bfile System.Byte[] byte[]char System.String string

char varying System.String stringcharacter System.String string

character varying System.String stringdate System.DateTime DateTimedec System.Decimal int

decimal System.Decimal intdouble precision System.Double double

float System.Double doubleint System.Decimal int

integer System.Decimal intinterval day System.String stringinterval year System.String string

long System.String stringlong raw System.Byte[] byte[]

long varchar System.String stringnational char System.String string

national char varying System.String stringnational character System.String string

national character varying System.String stringnchar System.String string

nchar varying System.String stringnclob System.String string

numeric System.Decimal intraw System.Byte[] byte[]real System.Double double

rowid System.String stringsmallint System.Decimal int

timestamp System.DateTime DateTimeurowid System.String stringvarchar System.String string

binary double System.Double doublebinary float System.Single float

Tabella 5.4: Conversioni di tipo di dato tra DBMS a .NET e conversione datoda GSS per ORACLE 10g


Figura 5.1: Tecnica utilizzata per generare l’adapter nella versione con queryautomatiche

//COSTRUTTORE/// <summary>/// Costruttore di default della classe/// </summary>public Tag()

public abstract string rimpiazzati(Linguaggi p_linguaggio,PopolatoreDatiDb p_pd,string p_riga);

public static Tag tagFactory(string p_tipoTag)

switch (p_tipoTag)

case "NomeNamespace":return new NomeNamespace(); //Il nome del namespace

case "NomeTabella":return new NomeTabella(); //Il nome della tabella

case "ChiavePrimaria":return new ChiavePrimaria();


case "GeneraQuerySelectDataBy":return new GeneraQuerySelectDataBy();

case "GeneraMetodoSelectDataBy":return new GeneraMetodoSelectDataBy();

case "CampiSeparatiAnd":return new CampiSeparatiAnd();

case "CampiSeparatiVirgola":return new CampiSeparatiVirgola();

case "CampiSeparatiVirgolaConAssegnamento":return new CampiSeparatiVirgolaConAssegnamento();

case "Interrogativi":return new Interrogativi();

case "TipoNomeChiavePrimaria":return new TipoNomeChiavePrimaria();

case "NomeEntita":return new NomeEntita();

case "ListaParametri":return new ListaParametri();

case "TipoCampo":return new TipoCampo();

case "ListaParametriNoEntita":return new ListaParametriNoEntita();

case "GeneraParametri":return new GeneraParametri();

case "TipoChiavePrimaria":return new TipoChiavePrimaria();

case "ControlloID":return new ControlloID();

case "ControlloOverride":return new ControlloOverride();

default:throw new System.NotSupportedException("The tag type " +

p_tipoTag.ToString() +" is not recognized.");

//end classe astratta Tag

Il template nella versione query automatiche e il seguente:

using System;using System.Collections.Generic;using System.Collections;using System.Text;using System.Data;


using System.Data.Common;using System.Data.OleDb;using System.Linq;using Poco;using AreaFramework.Wrapper;

namespace $NomeNamespace$.Adapter

public class $NomeTabella$_Adapter : ProtoAdapter

// ATTRIBUTI// stringhe query di selezione (analoghe alle precedenti)

private static string sql_Select = "SELECT * FROM $NomeTabella$";

$GeneraQuerySelectDataBy$private static string sql_SelectBy$Campi$ = sql_Select +

" WHERE ($Campi$ = ?) ";private static string sql_SelectBy$ChiavePrimaria$ = sql_Select +

" WHERE ($ChiavePrimaria$ = ?) ";private static string sql_SelectMax$ChiavePrimaria$ =

"SELECT MAX($ChiavePrimaria$) FROM $NomeTabella$";


private static string sql_DeleteByAllField ="DELETE FROM $NomeTabella$ WHERE ($ChiavePrimaria$ = ? AND$CampiSeparatiAnd$)";

private static string sql_Insert ="INSERT INTO $NomeTabella$ ($CampiSeparatiVirgola$) VALUES($Interrogativi$)";

private static string sql_UpdateBy$ChiavePrimaria$ ="UPDATE $NomeTabella$ SET $CampiSeparatiVirgolaConAssegnamento$WHERE $ChiavePrimaria$ = ? ";

//------------------------

/////////////////////////////////////////////// COSTRUTTOREpublic $NomeTabella$_Adapter(DbConnection p_conn) : base(p_conn)// end costruttore

/////////////////////////////////////////////

/// <summary>/// Metodo per ottenere l’elenco completo dei dati


/// </summary>/// <returns></returns>public DataTable GetData()

return this.ExecuteQuery(sql_Select); // end method GetData

public DataTable GetDataBy$ChiavePrimaria$($TipoNomeChiavePrimaria$)ArrayList ht = new ArrayList();ht.Add(new DictionaryEntry("$ChiavePrimaria$", p$ChiavePrimaria$));

return this.ExecuteQuery(sql_SelectBy$ChiavePrimaria$, ht);

// end method GetDataBy$ChiavePrimaria$

$GeneraMetodoSelectDataBy$public DataTable GetDataBy$Campi$($TipoCampi$ p$CampiParametro$)

ArrayList ht = new ArrayList();ht.Add(new DictionaryEntry("$Campi$", $CampiParametroConControllo$));

return this.ExecuteQuery(sql_SelectBy$Campi$, ht);

// end method GetDataBy$Campi$$END$

// METODI CHE RITORNANO VALORI SCALARIpublic int GetMax$ChiavePrimaria$()return ExecuteInt32Scalar(sql_SelectMax$ChiavePrimaria$, null);

// end method GetMax$ChiavePrimaria$

/////////CANCELLAZIONE///////////////

// METODI DMLpublic int DeleteQuery($TipoNomeChiavePrimaria$)ArrayList ht = new ArrayList();ht.Add(new DictionaryEntry("$ChiavePrimaria$", p$ChiavePrimaria$));

return this.ExecuteNonQuery(sql_DeleteBy$ChiavePrimaria$, ht);

// end method DeleteOneRecordBy$ChiavePrimaria$

public int DeleteByEntity($NomeEntita$ p$NomeEntita$)


ArrayList ht = new ArrayList();

$ListaParametri$ht.Add(new DictionaryEntry("$Campi$", $NomeEntita$.$Proprieta$));

return ExecuteNonQuery(sql_DeleteByAllField, ht); // end method DeleteByEntity

/////////INSERIMENTO///////////////

public int InsertQuery($TipoCampo$)

ArrayList ht = new ArrayList();

$ListaParametriNoEntita$ht.Add(new DictionaryEntry("$Campi$", $CampiConControllo$));

return ExecuteNonQuery(sql_Insert, ht);

// end method InsertQuery

public int InsertByEntity($NomeEntita$ p$NomeEntita$)ArrayList ht = new ArrayList();

$ListaParametri$ht.Add(new DictionaryEntry("$Campi$", $NomeEntita$.$Proprieta$));

return ExecuteNonQuery(sql_Insert, ht);

// end method InsertByEntity

/////////AGGIORNAMENTO///////////////

public int UpdateQuery($TipoCampo$, $TipoNomeChiavePrimaria$)ArrayList ht = new ArrayList();

$ListaParametriNoEntita$ht.Add(new DictionaryEntry("$Campi$", $CampiConControllo$));

ht.Add(new DictionaryEntry("$ChiavePrimaria$", p$ChiavePrimaria$));

return ExecuteNonQuery(sql_UpdateBy$ChiavePrimaria$, ht);


// end method UpdateQuery

// end class $NomeTabella$_Adapter // end namespace

Qui mostro il cuore della conversione automatica: la classe ElaboraTemplate.

/// <summary>/// Leggi un template(file di testo)/// </summary>/// <param name="p_nomeFile">percorso del template</param>/// <returns>stringa contenente il testo del template convertito</returns>

public string leggiConvertaTemplate(string p_nomeFile,Linguaggi p_linguaggio)

fileTemplateDb = new FileStream(p_nomeFile,

FileMode.OpenOrCreate,FileAccess.Read);

StreamReader sr = new StreamReader(fileTemplateDb);

string testoConvertito = leggiRigaESostituisci(sr, 4, p_linguaggio);

//Rilascio le risorsesr.Close();fileTemplateDb.Close();

return testoConvertito;//end leggiConvertaTemplate()

Il metodo leggiRigaESostituisci e il seguente:

/// <summary>/// Legge una riga dal template e sostituisce tutti i tag con del codice/// </summary>/// <param name="p_sr">Lo stream Reader</param>/// <param name="p_quantoIndentare">Quanto identare</param>/// <returns></returns>private string leggiRigaESostituisci(StreamReader p_sr,

int p_quantoIndentare,Linguaggi p_linguaggio)


string testo = null;int dollaroIniziale = -1;int dollaroFinale = -1;string tmp;string riga = null;

do

codice = p_sr.ReadLine();if (codice != null)

codice = codice.Trim();riga = codice;

#region SEZIONE USATA PER GENERARE L’ADAPTER

#region Relativo al tag $GeneraQuerySelectDataBy$

if (riga.Contains(TAG + TAG_GENERA_QUERY_SELECT + TAG))codice = codice.Remove(TAG_GENERA_QUERY_SELECT.Length + 2);

#endregion

#region Relativo al tag $ListaParametri$per quei metodi che usano come parametro l’oggetto entita

if (riga.Contains(TAG + TAG_LISTA_PARAMETRI + TAG))codice = codice.Remove(TAG_LISTA_PARAMETRI.Length + 2);

#endregion

#region Relativo al tag $ListaParametriNoEntita$per quei metodo che usano come parametro il nomee il tipo degli attributi di una tabella

if (riga.Contains(TAG + TAG_LISTA_PARAMETRI_NO_ENTITA + TAG))codice = codice.Remove(TAG_LISTA_PARAMETRI_NO_ENTITA.Length + 2);

#endregion

#region Relativo al Tag $GeneraMetodoSelectDataBy$

if (riga.Contains(TAG + TAG_GENERA_METODO_SELECT + TAG))

string metodo = null;

while (codice.Contains(TAG + "END" + TAG) == false)


metodo += codice;codice = Environment.NewLine +

p_sr.ReadLine();codice = ManipolazioneStringhe.rimuoviTag(codice,

TAG +"END"+TAG);

codice = TAG + TAG_GENERA_METODO_SELECT + TAG;riga = metodo;

//end costruzione blocco relativo//alla generazione dei metodi per le query di selezione.

#endregion

#endregion

#region SEZIONE USATA PER GENERARE IL WRAPPER

#region Relativo al tag $GeneraParametri$

if (riga.Contains(TAG + TAG_GENERA_PARAMETRI + TAG))codice = codice.Remove(TAG_GENERA_PARAMETRI.Length + 2);

#endregion

#endregion

#region SEZIONE USATA IN COMUNE PER GENERARE L’ADAPTER E IL WRAPPER

while(codice.Contains(TAG))

dollaroIniziale = riga.IndexOf(TAG) + 1;tmp = riga.Substring(dollaroIniziale);dollaroFinale = tmp.IndexOf(TAG);tmp = tmp.Substring(0, dollaroFinale);codice = codice.Replace(TAG + tmp + TAG,Tag.tagFactory(tmp).rimpiazzati(p_linguaggio, pd, riga));riga = codice;

#endregiontesto += codice + Environment.NewLine;

while (codice != null);

testo = Indentazione.indenta(testo, p_quantoIndentare);return testo;


//end metodo leggirigaesostituisci()

Il tutto sta nel seguente frammento di codice:

while(codice.Contains(TAG))

dollaroIniziale = riga.IndexOf(TAG) + 1;tmp = riga.Substring(dollaroIniziale);dollaroFinale = tmp.IndexOf(TAG);tmp = tmp.Substring(0, dollaroFinale);codice = codice.Replace(TAG + tmp + TAG,Tag.tagFactory(tmp).rimpiazzati(p_linguaggio, pd, riga));riga = codice;

Quello che viene generato in automatico e il seguente frammento di codice trattodal template Adapter:

Stringhe di select

private static string sql_Select = "SELECT * FROM $NomeTabella$";$GeneraQuerySelectDataBy$private static string sql_SelectBy$Campi$ =

sql_Select +"WHERE ($Campi$ = ?) ";

private static string sql_SelectBy$ChiavePrimaria$ =sql_Select +"WHERE ($ChiavePrimaria$ = ?) ";

private static string sql_SelectMax$ChiavePrimaria$ ="SELECT MAX($ChiavePrimaria$)FROM $NomeTabella$";

Il tag GeneraQuerySelectDataBy permette di generare la stringa private staticstring sql SelectByCampi =... tante volte quanti sono i campi/attributi della tabelladel RDBMS selezionato. Esempio di stringa generata:

private static string sql_Select = "SELECT * FROM Anagrafica";private static string sql_SelectByNome =

sql_Select +"WHERE (Nome = ?)";

ecc.

5.3. VERSIONE CON NHIBERNATE 123

Stringhe di cancellazione In questo frammento usiamo il tag CampiSeparatiAnd.Esso genera in maniera dinamica la seguente stringa: Id = ? AND Nome = ? ANDecc...


private static string sql_DeleteByAllField ="DELETE FROM $NomeTabella$ WHERE ($ChiavePrimaria$ = ? AND$CampiSeparatiAnd$)";

Stringhe di inserimentoIn questo frammento usiamo i tag: CampiSeparatiV irgola e CampiSeparatiV irgolaConAssegnamento.

Essi generano rispettivamente le seguenti stringhe: Id, Nome, Cognome, ecc. e Id =?, Nome = ? e Cognome = ?. In piu abbiamo il tag Interrogativi che mi costruisceuna stringa dinamica di simboli ’?’ tanti quanti sono gli attributi di una tabella.

private static string sql_Insert ="INSERT INTO $NomeTabella$ ($CampiSeparatiVirgola$) VALUES($Interrogativi$)";

Stringhe di aggiornamento

private static string sql_UpdateBy$ChiavePrimaria$ ="UPDATE $NomeTabella$ SET $CampiSeparatiVirgolaConAssegnamento$WHERE $ChiavePrimaria$ = ? ";

5.3 Versione con Nhibernate

Per generare l’adapter che usa la versione con Nhibernate, ho utilizzato la seguentetecnica come illustra la figura 5.2.

Di seguito riporto il template Adapter versione Nhibernate.

using System;using System.Collections.Generic;using System.Linq;


Figura 5.2: Tecnica utilizzata per generare l’adapter nella versione Nhibernate

using System.Text;using NHibernate;using NHibernate.Cfg;using System.Reflection;using Iesi.Collections;using System.Collections;using NHibernate.Criterion;

namespace Adapter.Adapter

public class NhibernateAdapter

public NhibernateAdapter()

//Apertura della sessionepublic static ISession OpenSession()

Configuration c = new Configuration();c.AddAssembly(Assembly.GetCallingAssembly());ISessionFactory f = c.BuildSessionFactory();


return f.OpenSession();//end metodo OpenSession()

//metodi

//SELECT ALL

/// <summary>/// Metodo che utilizza Nhibernate/// per prelevare tutti i campi di una tabella/// Precisamente esegue sotto la seguente query:/// select * from nome_tabella/// ---------------------------/// nome_tabella equivalente a oggetto_entita/// </summary>/// <param name="p_tipoEntita">Il tipo dell’Oggetto Entita/param>/// <returns>Lista ordinata del risultato di una query di tipo

select</returns>public IList selectAll(Type p_tipoEntita, ISession pValue)

PropertyInfo[] propr = p_tipoEntita.GetProperties();if (pValue == null)

using (ISession sessione = OpenSession())

returnsessione.CreateCriteria(p_tipoEntita).

AddOrder(Order.Asc(propr[0].Name)).List();

else

return pValue.CreateCriteria(p_tipoEntita).

AddOrder(Order.Asc(propr[0].Name)).List();

/// <summary>////// </summary>/// <param name="p_tipoEntita"></param>/// <returns></returns>public string selectMaxChiavePrimaria(Type p_tipoEntita)

PropertyInfo[] propr = p_tipoEntita.GetProperties();using (ISession sessione = OpenSession())

String qIdMax = String.Format("select max(t.0) from 1 t ",


propr[0].Name, p_tipoEntita.Name);Console.WriteLine(qIdMax);IQuery query = sessione.CreateQuery(qIdMax);Object val = query.UniqueResult();

return val.ToString();

//INSERIMENTO

/// <summary>////// </summary>/// <param name="p_entita"></param>/// <returns>Messaggio </returns>public void insert(object p_entita, ISession pValue)

if (pValue == null)

//apro una sessioneusing (ISession sessione = OpenSession())

//inizio una transazioneusing (ITransaction transazione =

sessione.BeginTransaction())

//Salvo e eseguo il commitsessione.Save(p_entita);transazione.Commit();

else

pValue.Save(p_entita);

//end insert(...)

//INSERIMENTO INTELLIGENTE / UPDATE/// <summary>////// </summary>/// <param name="p_entita"></param>/// <returns></returns>public void insertIntelligence(object p_entita)



//inizio una transazioneusing (ITransaction transazione =

sessione.BeginTransaction())

//Salvo e eseguo il commitsessione.SaveOrUpdate(p_entita);transazione.Commit();

//end insertIntelligence(...)

//AGGIORNAMENTO

/// <summary>////// </summary>/// <param name="p_entita"></param>/// <returns></returns>public void update(object p_entita, ISession pValue)

if (pValue == null)


sessione.Update(p_entita);

else

pValue.Update(p_entita);

//end update(...)

//CANCELLAZIONE

/// <summary>////// </summary>/// <param name="p_entita"></param>/// <returns></returns>public void delete(object p_entita, ISession pValue)

if (pValue == null)



sessione.Delete(p_entita);

else

pValue.Delete(p_entita);

//end delete(...)

Capitolo 6

Confronto di prestazioni

In questo capitolo illustreremo un confronto in termini di tempo e scalabilita tra laversione di query automatiche e la versione che usa Nhibernate.

I test di performance sono state effettuate nella seguente macchina:

• Nome Sistema Operativo: Microsoft Windows Vista Ultimate;

• Versione: 6.0.6001 Service Pack 1 Build 6001;

• Processore: Pentium(R) Dual-Core CPU E5200 @ 2.50GHz, 2520 Mhz, 2core, 2 processori logici;

• Versione/data BIOS: American Megatrends Inc. V3.2C, 01/08/2008;

• Versione SMBIOS: 2.5;

• Memoria fisica installata - RAM: 4.00 GB;

I test che ho fatto hanno utilizzato i seguenti prodotti DBMS:

1. MYSQL 5.0

2. ORACLE 10g

3. SQLSERVER 2005

4. FIREBIRD 5.0

5. POSTGRES 8.5

Ma i test effettivi ovvero quelli veramente fatti sono state per MYSQL, ORACLEe SQLSERVER 2005. Per FIREBIRD e POSTGRES ho riscontrato problematichelegate alla connessione, forse legate alle nuove versioni dei due prodotti.

Per ogni DBMS ho eseguito i test di velocita nella versione query automatiche eversione Nhibernate testando le seguenti operazioni:

• Metodo INSERT(HASH TABLE);

• Metodo INSERT(OGGETTO ENTITA);

• Metodo DELETE(HASH TABLE);

• Metodo DELETE(OGGETTO ENTITA);

• Metodo UPDATE(HASH TABLE);

• Metodo UPDATE(OGGETTO ENTITA);

129

130 CAPITOLO 6. CONFRONTO DI PRESTAZIONI

Figura 6.1: La tabella BUFFER usata per il test di performance

• Metodo SELECT(HASH TABLE);

• Metodo SELECT(OGGETTO ENTITA);

Per ogni metodo ho effettuato i test con numeri di record pari a: 10, 100, 1000,5000, 10000, 50000, 100000, 500000, 1000000, 5000000 e 10000000. Il test consistenel prelievo della velocita del metodo per otto volte e si prende alla fine una mediaaritmetica. Questo per ogni record. Per esempio: inserimento di 10 record, prelievodella velocita nelle due versioni effettuando il test di velocita otto volte, calcolo lamedia. Inserimento di 100 record e cosi via.

Tutti i test sono stati effettuati usando una tabella di nome BUFFER (vedi figura6.1).

Test di performance su SQLSERVER 2005

Nelle varie operazioni (insert, update, delete, select) i grafici vengono costruiti inter-polando i punti (numero di record, media aritmetica delle 8 prove). Cosi facendo hoottenuto delle spline del primo ordine. Nell’asse delle ascisse abbiamo il numero direcord mentre nell’ordinata abbiamo la media aritmetica espressa in secondi. Gliandamenti delle due spline sono colorate di blu per la versione con query automatichee di rosso per la versione che usa Nhibernate.

Operazione INSERT

Nella figura 6.2 viene mostrato l’andamento delle due spline relative all’inserimen-to di record. Dal grafico si puo notare che i due metodi scalano bene inizialmente e sipuo dire che fino a un milione di record riescono ad andare quasi alla stessa velocita.Si puo notare che impiegano mediamente 770,00 secondi ad inserire un milione direcord. Ma ho notato un crash da parte di Nhibernate dopo aver inserito 3.471.900record impiegandoci un tempo pari a 3338,841 secondi. Mentre scala benissimo laversione con query automatiche, infatti nell’inserire 10 milioni di record ha impiegatomediamente 7090,57 secondi.

Una considerazione in questo caso va fatta sulla gestione delle risorse, precisa-mente sulla gestione della memoria. Ho notato che usando la versione con query

131

Figura 6.2: Confronto di prestazioni relativo all’inserimento di record entro latabella Buffer

automatiche partendo da un utilizzo della memoria pari a 12 Mb resto attorno ai14 Mb. Mentre nell’altra versione partendo da un utilizzo della memoria pari a 20Mb continua a salire fino ad andare in crash, precisamente a 1.3 Gb. Deduco cheusare Nhibernate c’e un notevole spreco di risorse nel caso di inserimento dentro unatabella.

Nelle quattro figure seguenti (figura 6.3) sono mostrati gli andamenti delle dueversioni in modo piu dettagliato, ovvero si e scelto uno zoom sulle scale: [10, 1000],[1000, 10000], [10000, 100000] e [100000,1000000].

Nella tabella che segue sono espresse le valutazioni sui grafici che sono stati ot-tenuti zoomando ogni fetta dell’andamento della figura 6.2. Precisamente ottengo leseguenti valutazioni:

Operazione DELETE

Nella figura 6.4 viene mostrato l’andamento delle due spline relative alla cancel-lazione di record. Dal grafico si puo notare che i due metodi scalano bene inizialmentefino ad arrivare a circa 10000 record. Dopo di che la versione che usa Nhibernate epiu veloce rispetto alla versione che usa le query automatiche. Questo fino ad arrivarea circa un milione di record. Alla fine ho notato un crash di Nhibernate a circa unmilione e rotti di record mentre l’altro continua a scalare bene.

Nelle quattro figure seguenti (figura 6.5) sono mostrati gli andamenti delle due


Figura 6.3: Diversi tipi di Zoom relativi al grafico dell’inserimento

Zoom GSS con queryautomatiche

GSS con usoNhibernate

Intervallo [10, 1000] 0,30 sec. 0,35 sec.Intervallo [1000, 10000] 4,03 sec. 3,7 sec.


Intervallo [1000000, 10000000] 3732,28 sec. crash

Tabella 6.1: Valutazioni delle prestazioni relative all’inserimento

133

Figura 6.4: Confronto di prestazioni relativo alla cancellazione di record entrola tabella Buffer

versioni in modo piu dettagliato, ovvero si e scelto uno zoom sulle scale: [10, 1000],[1000, 10000], [10000, 100000] e [100000,1000000].


Operazione UPDATE

Nella figura 6.6 viene mostrato l’andamento delle due spline relative all’aggiorna-mento di record. Dal grafico si puo notare che i due metodi scalano bene inizialmentefino ad arrivare a circa 100000 record. Dopo di che la versione che usa Nhibernate epiu veloce rispetto alla versione che usa le query automatiche. Questo fino ad arrivarea circa un milione di record. Alla fine ho notato un crash di Nhibernate a circa unmilione e rotti di record mentre l’altro continua a scalare bene.



Operazione SELECT

Nella figura 6.8 viene mostrato l’andamento delle due spline relative alla select direcord. Dal grafico si puo notare che i due metodi scalano bene inizialmente fino adarrivare a circa 100000 record. Dopo di che la versione che usa le query automatichee piu veloce rispetto alla versione che usa Nhibernate. Questo fino ad arrivare a circa


Figura 6.5: Diversi tipi di Zoom relativi al grafico della cancellazione






Tabella 6.2: Valutazioni delle prestazioni relative alla cancellazione

135

Figura 6.6: Confronto di prestazioni relativo all’aggiornamento di record entrola tabella Buffer

un milione di record. Alla fine ho notato un crash sempre di Nhibernate a circa unmilione e rotti di record mentre l’altro continua a scalare bene.



Test di performance su MYSQL 5.0

Operazione INSERT

Nella figura 6.10 viene mostrato l’andamento delle due spline relative all’inseri-mento di record. Dal grafico si puo notare che i due metodi scalano bene e hannoinizialmente lo stesso andamento. Ma si puo notare che ancora una volta la versionecon query automatiche e migliore in termini di velocita di inserimento Ho osservatoun crash da parte di tutte e due le versioni al record 100000. Questo e dovuto allaseguente eccezione lanciata dall’applicativo: MYSQL for Away. Conclusione e colpadel provider MYSQLOLEDB.

Nelle tre figure seguenti (figura 6.11) sono mostrati gli andamenti delle due ver-sioni in modo piu dettagliato, ovvero si e scelto uno zoom sulle scale: [10, 1000],[1000, 10000] e [10000, 100000].


Figura 6.7: Diversi tipi di Zoom relativi al grafico dell’aggiornamento






Tabella 6.3: Valutazioni delle prestazioni relative all’aggiornamento

137

Figura 6.8: Confronto di prestazioni relativo alla selezione di record entro latabella Buffer

Nella tabella che segue sono espresse le valutazioni sui grafici che sono stati ot-tenuti zoomando ogni fetta dell’andamento della figura 6.10. Precisamente ottengole seguenti valutazioni:

Operazione DELETE

Nella figura 6.12 viene mostrato l’andamento delle due spline relative alla cancel-lazione di record. Dal grafico si puo notare che i due metodi scalano bene inizialmentefino ad arrivare a circa 10000 record. Dopo di che la versione che usa query auto-matiche e piu veloce rispetto alla versione che usa Nhibernate. Alla fine ho notato uncrash sia di Nhibernate e sia di query automatiche. La causa di cio e stato spiegatoprima.



Operazione UPDATE

Nella figura 6.14 viene mostrato l’andamento delle due spline relative all’aggiorna-mento di record. Dal grafico si puo notare che i due metodi scalano bene inizialmentefino ad arrivare a circa 30000 record. Dopo di che la versione che usa le query auto-matiche e piu veloce rispetto alla versione che usa Nhibernate. Alla fine ho notato uncrash sia di Nhibernate e sia di query automatiche. La causa di cio e stato spiegatoprima.

Nelle tre figure seguenti (figura 6.15) sono mostrati gli andamenti delle due ver-


Figura 6.9: Diversi tipi di Zoom relativi al grafico della select






Tabella 6.4: Valutazioni delle prestazioni relative alla select

139

Figura 6.10: Confronto di prestazioni relativo all’inserimento di record entrola tabella Buffer






Intervallo [10000, 100000] 1934,50 sec. 2045,31 sec.Intervallo [100000, 1000000] crash crash

Intervallo [1000000, 10000000] crash crash



sioni in modo piu dettagliato, ovvero si e scelto uno zoom sulle scale: [10, 1000],[1000, 10000] e [10000, 100000].


Operazione SELECT

Nella figura 6.16 viene mostrato l’andamento delle due spline relative alla selectdi record. Dal grafico si puo notare sostanzialmente che i due andamenti scalano allastessa velocita circa fino a record 50000. Dopo di che la versione che usa Nhibernate epiu veloce rispetto alla versione che usa le query automatiche. Alla fine ho notato uncrash sia di Nhibernate e sia di query automatiche. La causa di cio e stato spiegatoprima.


Nella tabella che segue sono espresse le valutazioni sui grafici che sono stati ot-

141








tenuti zoomando ogni fetta dell’andamento della figura 6.16. Precisamente ottengole seguenti valutazioni:

Test di performance su ORACLE 10g

Operazione INSERT

Nella figura 6.18 viene mostrato l’andamento delle due spline relative all’inseri-mento di record. Dal grafico si puo notare che i due metodi scalano bene e hannoinizialmente lo stesso andamento. Ma si puo notare che ancora una volta la versionecon query automatiche e migliore in termini di velocita di inserimento. Ho osservatoun crash da parte di tutte e due le versioni al record 100000. Questo e dovuto ad uneccezione di Oracle.



Figura 6.14: Confronto di prestazioni relativo all’aggiornamento di recordentro la tabella Buffer


143

Zoom GSS con queryautomaticheb















Figura 6.18: Confronto di prestazioni relativo all’inserimento di record entrola tabella Buffer


145









Operazione DELETE

Nella figura 6.20 viene mostrato l’andamento delle due spline relative alla cancel-lazione di record. Dal grafico si puo notare che i due metodi scalano bene e hannocirca lo stesso andamento. Ma si puo notare che la versione con Nhibernate e untantino migliore in termini di velocita di cancellazione.



Operazione UPDATE

Nella figura 6.22 viene mostrato l’andamento delle due spline relative all’aggior-namento di record. Dal grafico si puo notare che i due metodi scalano bene e hanno









circa lo stesso andamento. Ma si puo notare che la versione con Nhibernate e untantino migliore in termini di velocita di aggiornamento.



Operazione SELECT

Nella figura 6.24 viene mostrato l’andamento delle due spline relative alla selectdi record. Dal grafico si puo notare che i due metodi hanno circa lo stesso andamentofino a 5000 record e rotti. Poi gli andamenti si diversificano in maniera abbastanzagrossa e la migliore in termini di velocita di selezione e la versione con le queryautomatiche.

Nelle tre figure seguenti (figura 6.25) sono mostrati gli andamenti delle due ver-

147

Figura 6.22: Confronto di prestazioni relativo all’aggiornamento di recordentro la tabella Buffer











sioni in modo piu dettagliato, ovvero si e scelto uno zoom sulle scale: [10, 1000],[1000, 10000] e [10000, 100000].


Conclusioni finali sulle prestazioni

Nella tabella che segue sono espresse le velocita in secondi delle operazioni (INSERT,DELETE UPDATE e SELECT) relative alla versione con query automatiche. E stato

149







DBMS INSERT DELETE UPDATE SELECTSQLSERVER 40,64 sec. 31,21 sec. 38,41 sec. 1,13 sec.

MYSQL 1934,50 sec. 1883,86 sec. 1840,62 sec. 3,29 sec.ORACLE 290,27 sec. 201,53 sec. 213,53 sec. 3,15 sec.

Tabella 6.13: Confronto velocita in sec. tra DBMS e utilizzo GSS con queryautomatiche nel caso di 100000 record

DBMS INSERT DELETE UPDATE SELECTSQLSERVER 37,82 sec. 21,74 sec. 21,50 sec. 1,72 sec.

MYSQL 2045,31 sec. 2023,45 sec. 1958,32 sec. 2,69 sec.ORACLE 389,47 sec. 189,77 sec. 200,45 sec. 5,67 sec.

Tabella 6.14: Confronto velocita in sec. tra DBMS e utilizzo GSS con uso diNhibernate nel caso di 100000 record

scelto un confronto su 100000 record.Come si puo notare il DBMS che e piu scalabile e che impiega il minor tempo e

SQLSERVER. Poi segue ORACLE e infine MYSQL.Nella tabella che segue sono espresse le velocita in secondi delle operazioni (IN-

SERT, DELETE UPDATE e SELECT) relative alla versione con uso di Nhibernate.Anche qui e stato scelto un confronto su 100000 record.

Come si puo notare anche usando la versione Nhibernate, SQLSERVER rimaneil DBMS piu scalabile e che impiega il minor tempo.

Capitolo 7

Conclusioni

In questo capilo finale si tirerrano le somme sul lavoro svolto e le possibile espansionifuture.

7.1 Bilancio del lavoro svolto

L’utilizzo di un framework .NET ha permesso di lavorare con l’accesso alle base didati in maniera molto semplice e a mio avviso ben pulita. Nel complesso il progettoGeneratore Strati Software e risultato un ottimo generatore automatico di ingredientiper crearsi un piccolo ORM fatto in casa. Sono risultati molto comodi durante la fasedi implementazione del progetto l’utilizzo di design pattern: quali MVC, ecc. A mioavviso se uno dovesse chiedersi: ma e meglio usare il Generatore Strati Software nellaversione con le query automatiche o con la versione Nhibernate, io gli risponderei inquesto modo:

Dal punto di vista dello sviluppatore e preferibile usare l’accoppiata: Poco eNhibernate, poiche per interagire con una base di dati utilizzi solo ed esclusivamentel’oggetto entita e non scrivi nessuna riga di SQL. Ma come abbiamo visto nel capi-tolo precedente nei test di performance, la versione con le query automatiche e digran lunga la piu veloce e per certi versi la piu scalabile. Quindi dal punto di vistadell’utente e preferibile usare il Generatore con la versione query automatiche.

7.2 Esperienze e conoscenze acquisite

Durante i mesi di stage presso l’azienda, mi sono occupato dell’Analisi, progettazionee implementazione del mio Generatore Strati Software. Ho imparato un nuovo lin-guaggio: il C# e ho acquisito una certa esperienza professionale e di qualita nellosviluppare il software. Un dovereso grazie al Prof. Ing. Giulio Destri e un ringrazi-amento anche all’Ing. Alberto Picca per avermi fatto capire come si lavora a unlivello professionale e il come bisogna essere bravi nel documentare tutto e al meglio.Molto spesso si ignora l’importanza che riveste la documentazione del software. Horiscontrato che se tu lavori con metodo, ovvero documenti tutto e in maniera precisae cerchi di organizzare al meglio tutto il lavoro, impieghi minor tempo e cosi facendopuoi ottenere un software di qualita.

7.3 Espansioni future

Le possibili espansioni future sono:

1. Creare una versione Web del progetto;

150

7.3. ESPANSIONI FUTURE 151

2. Gestione di relazioni tra le entita di un database complesse (es. relazioniricorsive ecc.);

3. Gestione delle chiavi primarie multiple;

4. Maggiore tolleranza agli errori del caricamento del template (es. uso delleespressioni regolari);

5. Test di performance piu mirati (per esempio test sull’inserimento a cascata,tenere conto delle relazioni tra le tabelle, ecc.).

Bibliografia

[1] Stefano Paraboschi Riccardo Torlone Paolo Atzeni, Stefano Ceri. Basi di dati.Modelli e linguaggi di interrogazione. McGraw-Hill, Via Ripamonti, 89 - 20139Milano, 2 edition, 2002.

[2] Craig Larman. Applying UML and Patterns. An introduction to Object-OrientedAnalysis and Design and the Unified Process. Prentice Hall, 2 edition, 2002.

[3] M. De Marco. Sistemi Informativi Aziendali. Franco Angeli Edizioni, 2000.

[4] A. Mills G. Bellinger, D. Castro. Data, Information, Knowledge, and Wisdom.1994.

[5] N. Shedroff. Information Interaction Design: A Unified Field Theory of Design.1994.

[6] Giulio Destri. Introduzione ai sistemi informativi aziendali. Monte Universitadi Parma, Borgo Bruno Longhi, 10 - 43100 Parma, 1 edition, 2007.

[7] Thomas Grechenig Monika Kohle Wolfgang Zuser, Stefan Biffl. Ingegneria delsoftware con UML e Unified Process. McGraw-Hill, Via Ripamonti, 89 - 20139Milano, 1 edition, 2004.

[8] J. Widom H.G. Molina, J.D. Ullman. Database Systems. The complete book.Prentice Hall, Upper Saddle River, New Jersey 07458, 1 edition, 2002.

[9] ANSI/X3/SPARC. Study Group on Database Management System. InterimReport- ACM FDT Bullettin. 1975.

[10] A. Klug D.C. Tsichritzis. The ANSI/X3/SPARC DBMS Framework Report ofthe study Group on Database Management Systems. 1978.

[11] L.D. Martino E. Bertino. Sistemi di basi di dati orientate agli oggetti. Addison-Wesley Masson, 1992.

[12] B. Meyer. Object-Oriented software construction. Prentice Hall, Upper SaddleRiver, New Jersey 07458, 2 edition, 1997.

[13] R.Johnson J. Vlissides E. Gamma, R. Helm. Design Patterns: Elements ofReusable Object Oriented Software. Addison-Wesley Masson, 1995.

[14] B.G. Whitenack K. Brown. A Pattern Language for Object-RDBMS Integration.The static Pattern. Technical Journal Knowledge Systems Corporation.

[15] D. Moore M. Stonebraker. Object-Relation DBMSs, The next great wave. MorganKauffman, San Francisco CA, 1996.

[16] Design Pattern MVC. http://ootips.org/mvc-pattern.html.

152

153

[17] Sun Microsystems, Inc. Design pattern MVC.http://java.sun.com/blueprints/patterns/MVC.html.

[18] Garlan David Shaw, Mary. Software Architecture: Perspectives on a emergingdiscipline. Prentice Hall, Upper Saddle River, New Jersey 07458, 1996.

[19] Keith Bennet. Legacy Systems. IEEE Software, 1995.

[20] Alan Bertossi. Algoritmi e strutture di dati. UTET Libreria, Via Ormea, 75 -10125 Torino, 2004.

[21] J. Lajoie Stanley B. Lippman. C++ : Corso di programmazione. Addison-WesleyMasson, 3 edition, 2000.

[22] D.A. Chappell. Enterprise Service Bus. O’Reilly, 2004.

[23] R. Verganti E. Bartezzaghi, G. Spina. Organizzare le PMI per la crescita. Comesviluppare i piu avanzati modelli organizzativi: gestione per processi, lavoro perprogetti, sviluppo delle competenze. Ed. Il Sole 24 Ore, 1999.

[24] V.E. Miller M.E. Porter. How information gves you competitive advantage.Harward Business Review, 1985.

[25] R. Anthony. Planning and control systems: A framework for analysis. HarwardBusiness Review, 1965.

[26] J. Laudon K. Laudon. Management dei sistemi informativi. Pearson EducationItalia, Milano, 2004.

[27] Giulio Destri. Dispense per il corso di Ingegneria del Software: DOTNET. GiulioDestri, 2004.

[28] C. Bauer G. King Pierre Henri Kuate, T. Harris. Nhibernate in action. MEAP,2008.

Tesi di Laurea - unipr.it · 2017-01-05 · La presente tesi di Laurea Triennale e stata sviluppata...

Documents

Transcript of Tesi di Laurea - unipr.it · 2017-01-05 · La presente tesi di Laurea Triennale e stata sviluppata...