Strumento per l'estrazione semi-automatica e il confronto di dati da pagine web

Università degli Studi di Padova

Dipartimento di Matematica

Corso di Laurea in Informatica

Strumento per l’estrazione semi-automatica eil confronto di dati da pagine web

Tesi di laurea triennale

Relatore

Prof. Fabio Aiolli

Laureando

Giovanni Cappellotto

Anno Accademico 2014-2015

Giovanni Cappellotto: Strumento per l’estrazione semi-automatica e il confronto didati da pagine web, Tesi di laurea triennale, c© Ottobre 2014.

Sommario

Il mercato del turismo on-line, in crescita da anni, anche in questo momento di crisiglobale, diventa sempre più competitivo. Per questo gli operatori del settore, conl’intento di accaparrarsi fette sempre più grandi di mercato, stanno investendo molto intecnologia. Gran parte delle strutture ricettive, hotel, agenzie di viaggi, tour operator,compagnie aeree, dispongono al giorno d’oggi di applicazioni web per prenotare on-linebiglietti e soggiorni, avvicinando grandi masse di consumatori.

In questo panorama fortemente competitivo, la guerra al prezzo più basso ha portatoalla nascita di applicazioni aziendali e servizi per il confronto dei prezzi. Questi serviziraccolgono, aggregano ed elaborano dati da diverse fonti per aiutare il consumatoree l’operatore, rispettivamente a scegliere e a creare, l’offerta migliore in termini dirapporto qualità/prezzo.

Questo documento descrive le attività svolte per realizzare un sistema di pricecomparison per il confronto dei prezzi di strutture alberghiere. Tali strutture vengonoraccolte dai maggiori siti di booking on-line per una consultazione interna alla societàNetStorming S.r.l., committente del software.

iii

“If you want to get laid, go to college. If you want an education, go to the library.”

— Frank Zappa

Ringraziamenti

Giorgia, Francesco, Matteo, Mara, Stefano, Anna, Michele.

Padova, Ottobre 2014 Giovanni Cappellotto

v

Indice

1 Introduzione 11.1 NetStorming S.r.l. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Obiettivi dell’attività di stage . . . . . . . . . . . . . . . . . . . . . . . 2

2 Sistemi per l’estrazione di dati web 32.1 Definizione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.2 Contesto storico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32.3 Fondamenti scientifici . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.3.1 Fondamenti formali e semantica della data extraction . . . . . 42.3.2 Metodi per la generazione di wrapper . . . . . . . . . . . . . . 52.3.3 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52.3.4 Sistemi commerciali per la generazione di wrapper . . . . . . . 8

2.4 Applicazioni chiave . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4.1 Web market monitoring . . . . . . . . . . . . . . . . . . . . . . 92.4.2 Web process integration . . . . . . . . . . . . . . . . . . . . . . 92.4.3 Mashup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

2.5 Direzioni future . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5.1 Generic web wrapping . . . . . . . . . . . . . . . . . . . . . . . 102.5.2 Auto-adapting wrappers . . . . . . . . . . . . . . . . . . . . . . 102.5.3 Wrapping da layout visuali . . . . . . . . . . . . . . . . . . . . 112.5.4 Estrazione di dati da file non HTML . . . . . . . . . . . . . . . 112.5.5 Imparare a gestire interazioni web . . . . . . . . . . . . . . . . 112.5.6 Comprensione e mapping dei form web . . . . . . . . . . . . . . 11

3 Descrizione del progetto 133.1 Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

3.1.1 Extractor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.1.2 Comparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.1.3 Web service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Analisi dei requisiti 174.1 Ricerca di disponibilità . . . . . . . . . . . . . . . . . . . . . . . . . . . 184.2 Normalizzazione dei dati . . . . . . . . . . . . . . . . . . . . . . . . . . 184.3 Memorizzazione dei dati estratti . . . . . . . . . . . . . . . . . . . . . 184.4 Selezione dei dati raccolti . . . . . . . . . . . . . . . . . . . . . . . . . 184.5 Ordinamento della selezione di dati . . . . . . . . . . . . . . . . . . . . 194.6 Facilità di adattamento a diversi siti web . . . . . . . . . . . . . . . . . 194.7 Facilità d’uso dell’estrattore . . . . . . . . . . . . . . . . . . . . . . . . 19

vii

viii INDICE

5 Progettazione 215.1 Strumenti e tecnologie . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

5.1.1 Linguaggi di programmazione . . . . . . . . . . . . . . . . . . . 215.1.2 Strumenti software . . . . . . . . . . . . . . . . . . . . . . . . . 215.1.3 Altri strumenti e librerie . . . . . . . . . . . . . . . . . . . . . . 22

5.2 Pianificazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.2.1 Ciclo di vita del software . . . . . . . . . . . . . . . . . . . . . 23

5.3 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.3.1 Struttura della base di dati . . . . . . . . . . . . . . . . . . . . 245.3.2 Modelli e interazione con il database . . . . . . . . . . . . . . . 255.3.3 Web service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 265.3.4 Comparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275.3.5 Selezione dei dati raccolti . . . . . . . . . . . . . . . . . . . . . 285.3.6 Ordinamento selezione di dati . . . . . . . . . . . . . . . . . . . 305.3.7 Extractor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 305.3.8 Ricerca di disponibilità . . . . . . . . . . . . . . . . . . . . . . 335.3.9 Normalizzazione dei dati . . . . . . . . . . . . . . . . . . . . . . 355.3.10 Memorizzazione dei dati estratti . . . . . . . . . . . . . . . . . 375.3.11 Facilità di adattamento a diversi siti web . . . . . . . . . . . . 38

6 Verifica e validazione 41

7 Conclusioni 437.1 Greasemonkey oggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 437.2 Raggiungimento degli obiettivi . . . . . . . . . . . . . . . . . . . . . . 43

A Metodologia Agile 45A.1 Principi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45A.2 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45A.3 Pratiche . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

Glossario 49

Acronimi 51

Bibliografia 53

Elenco delle figure

1.1 NetStorming S.r.l. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1

2.1 Architettura di un tipico sistema per l’estrazione di dati web . . . . . 6

3.1 Diagramma dei componenti . . . . . . . . . . . . . . . . . . . . . . . . 13

5.1 Diagramma E-R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245.2 Diagramma delle classi per l’interazione con il database . . . . . . . . 265.3 Diagramma delle classi che compongono la macro-componente Web service 275.4 Gerarchia delle classi Template utilizzate da Web service e Comparator 285.5 Diagramma delle classi che compongono la macro-componente Extractor 325.6 Avvio dello script Extractor, sito web non trovato . . . . . . . . . . . . 335.7 Avvio dello script Extractor, sito web trovato . . . . . . . . . . . . . . 335.8 Ricerca disponibilita, selezione della città . . . . . . . . . . . . . . . . 345.9 Ricerca personalizzata, selezione della città . . . . . . . . . . . . . . . 345.10 Ricerca personalizzata, selezione del periodo di soggiorno . . . . . . . 355.11 Ricerca personalizzata, selezione del tipo di camera . . . . . . . . . . . 355.12 Conversione, lista dei nuovi trattamenti trovati da convertire e selezione

dei valori di conversione . . . . . . . . . . . . . . . . . . . . . . . . . . 365.13 Conversione, risultato dell’operazione di memorizzazione delle conversioni 365.14 Normalizzazione, inserimento dati di conversione della valuta . . . . . 365.15 Risultato dell’inserimento nel database di un insieme di dati . . . . . . 38

Elenco delle tabelle

5.1 Struttura dei dati estratti . . . . . . . . . . . . . . . . . . . . . . . . . 375.2 Struttura degli oggetti contenuti nell’array hotels . . . . . . . . . . . 37

ix

x ELENCO DELLE TABELLE

5.3 Struttura degli oggetti contenuti nell’array prices . . . . . . . . . . . 37

Capitolo 1

Introduzione

Il mercato del turismo on-line, in crescita da anni, anche in questo momento di crisiglobale, diventa sempre più competitivo. Per questo gli operatori del settore, conl’intento di accaparrarsi fette sempre più grandi di mercato, stanno investendo molto intecnologia. Gran parte delle strutture ricettive, hotel, agenzie di viaggi, tour operator,compagnie aeree, dispongono al giorno d’oggi di applicazioni web per prenotare on-linebiglietti e soggiorni, avvicinando grandi masse di consumatori.

In questo panorama fortemente competitivo, la guerra al prezzo più basso ha portatoalla nascita di applicazioni aziendali e servizi per il confronto dei prezzi. Questi serviziraccolgono, aggregano ed elaborano dati da diverse fonti per aiutare il consumatoree l’operatore, rispettivamente a scegliere e a creare, l’offerta migliore in termini dirapporto qualità/prezzo.

Questo documento descrive le attività svolte per realizzare un sistema di pricecomparison per il confronto dei prezzi di strutture alberghiere. Tali strutture vengonoraccolte dai maggiori siti di booking on-line per una consultazione interna alla societàNetStorming S.r.l., committente del software.

1.1 NetStorming S.r.l.NetStorming S.r.l. nasce da diversi anni di collaborazione tra un gruppo di informaticifreelance ed un importante Tour Operator italiano: la Worldwide Hotel Link.

figura 1.1: NetStorming S.r.l.

La società opera da oltre un decennio nel settore del turismo on-line progettando erealizzando soluzioni software e hardware per alcuni tra i maggiori player nel mercatoitaliano.

La mission di NetStorming S.r.l. è da sempre quella di fornire software turistici atour operator ed agenzie di viaggi, scalabili ed aggiornabili nel tempo e soprattutto com-pletamente personalizzabili in base alla propria realtà. Per questo motivo NetStorming

1

2 CAPITOLO 1. INTRODUZIONE

S.r.l. ha scelto di sviluppare sistemi totalmente cloud based, quindi fruibili attraversol’utilizzo di un browser, permettendo ai suoi clienti di rimanere costantemente al passocon l’evoluzione del mercato del turismo, ma anche con la tecnologia.

1.2 Obiettivi dell’attività di stageL’obiettivo principale dell’attività di stage sarà la progettazione e lo sviluppo di un’ap-plicazione per il confronto dei prezzi di camere d’albergo.

Lo strumento verrà utilizzato da NetStorming S.r.l. per raccogliere informazioniche aiuteranno la società ad aggredire il mercato studiando le strategie di marketingdei maggiori competitors.

Un’obiettivo secondario consiste nell’acquisire la conoscenza necessaria per intro-durre nel ciclo di sviluppo delle altre applicazioni della società nuove tecnologie comeAjax e jQuery.

L’applicazione è composta da due componenti software distinte: un plugin utilizzabi-le tramite Firefox per la raccolta e la normalizzazione dei dati, e un’applicazione web perla consultazione e il confronto dei dati raccolti. Le due componenti dovranno lavorare intandem per supportare l’operatore nelle due fasi principali del processo: l’estrazione didati dalle applicazioni web dei concorrenti e il confronto delle informazioni strutturate.

Capitolo 2

Sistemi per l’estrazione di datiweb

2.1 DefinizioneUn sistema di web data extraction è un sistema software che estrae automaticamente eripetutamente dati da pagine web, e che registra o fornisce i dati estratti rispettiva-mente in una base di dati o ad un’altra applicazione.

L’attività di web data extraction eseguita da tale sistema è generalmente suddivisain cinque differenti funzioni:

1. web interaction, che comprende principalmente la navigazione verso pagine webpredeterminate contenenti le informazioni desiderate

2. generazione ed esecuzione di un wrapper, un programma che identifica i datidesiderati nelle pagine obiettivo, estrae i dati e li trasforma in un formatostrutturato

3. programmazione, che permette l’applicazione ripetuta del wrapper precedente-mente generato alle rispettive pagine obiettivo

4. trasformazione dei dati, che include il filtraggio, la trasformazione, la raffinazionee l’integrazione dei dati estatti da una o più sorgenti, e la strutturazione delrisultato a seconda del formato di output desiderato (di solito eXtensible MarkupLanguage (XML) o tabelle relazionali)

5. invio dei dati strutturati risultanti ad un’applicazione esterna come DBMS, datawarehouse, business software system, content management system, email server,SMS server. Alternativamente l’output può essere usato per generare nuovi webservice a partire da sorgenti esistenti

2.2 Contesto storicoI precursori dei web data extractor erano screen scraper, sistemi in grado di estrarreinformazioni dai dati formattati a schermo da applicazioni mainframe per terminalicome VT100 o IBM 3270. Un altro problema associato sono i metodi di ETL (Extract,

3

4 CAPITOLO 2. SISTEMI PER L’ESTRAZIONE DI DATI WEB

Transform, Load), che estraggono informazioni da vari processi aziendali per immagaz-zinarle in database o data warehouse. Esiste un enorme divario tra informazioni web ei dati qualificati e strutturati di cui hanno bisogno i sistemi informativi aziendali ocome li concepisce il web semantico. In molte aree applicative si è sentito il bisogno diestrarre automaticamente dati da sorgenti HyperText Markup Language (HTML) e ditradurre questi dati in un formato strutturato, e.g., XML, o in un formato adatto adun database relazionale.

Una prima ed ovvia soluzione fu l’evoluzione da screen scraper a web scraper, ingrado di navigare attraverso pagine web e di estrarre contenuti testuali. Tuttaviai web scraper, solitamente, mancano della logica necessaria per definire un outputdi informazioni altamente strutturate in opposizione a blocchi di testo o frammentitestuali. Inoltre sono spesso incapaci di collezionare ed integrare dati da differentisorgenti collegate tra loro, di definire modelli di estrazione che rimangono stabiliin caso di piccole differenze di layout, di trasformare i dati estratti nei formati inoutput desiderati e di fornire i dati rifiniti a differenti tipi di applicazioni. Per questaragione erano necessarie ricerche specifiche sulla web data extraction e diversi progettiaccademici, ed alcuni progetti di ricerca commerciale, sono partiti attorno agli anni2000. Mentre progetti accademici come XWRAP [19], Lixto [4], Wargo [22], e isistemi commerciali RoboMaker di Kapow technologies1 e WebQL di QL2 Software2si concentravano su metodi di generazione di wrapper “semi-automatici” fortementesupervisionati, fornendo ai progettisti di wrapper uno strumento con supporto visivo edinterattivo per la dichiarazione di modelli di estrazione e formattazione, altri progettisi basavano su tecniche di machine learning. Per esempio, WIEN [16], Stalker [21] eDEByE [17] si concentravano sull’induzione di wrapper automatici a partire da esempicommentati. Altri progetti si concentravano su problemi specifici come la generazioneautomatica di insiemi di dati strutturati a partire da pagine web [6] e particolari aspettidi navigazione ed interazione con le pagine web [3]. Infine, alcuni sistemi richiedono alprogettista di programmare il wrapper in un linguaggio ad alto livello (e.g. linguaggiSQL-like per selezionare i dati da una pagina web) e danno solo un supporto visivo alprogrammatore; un esempio è il sistema W4F [25]. Alcuni dei primi prototipi sviluppatiin ambito accademico hanno poi dato vita a sistemi completi che sono oggi disponibilicommercialmente. Per esempio, Stalker ha dato vita a Fetch Agent Platform di FetchTechnologies (ora parte di Connotate3), Lixto ha dato vita a Lixto Suite di LixtoSoftware Company4, e Wargo è evoluto in Denodo Platform [22].

2.3 Fondamenti scientifici

2.3.1 Fondamenti formali e semantica della data extraction

Ci sono quattro principali approcci formali per definire la semantica dei web wrapper:

1. Nell’approccio funzionale, un web wrapper è visto come una funzione f chemappa un Document Object Model (DOM) tree T di una pagina web versoun insieme f(T ) di sotto-alberi di T , dove ogni sotto-albero corrisponde ad un

1Kapow Technologies. url: http://www.kapowtech.com/.2QL2 Software. url: http://www.ql2.com/.3Connotate. url: http://www.connotate.com/.4Lixto Software Company. url: http://www.lixto.com/.

http://www.kapowtech.com/

http://www.ql2.com/

http://www.connotate.com/

http://www.lixto.com/

2.3. FONDAMENTI SCIENTIFICI 5

oggetto estratto. Un altro passo specifica la rinominazione dei dati estratti peradattarsi ad uno schema di output predefinito.

2. L’approccio logico consiste nella specifica di un numero finito di predicati mo-nadici, i.e., predicati che definiscono un insieme di nodi di alberi sintattici eche restituiscono vero o falso su ogni nodo di un documento che possiede unastruttura ad albero. I predicati possono essere definiti sia da formule logicheche da programmi logici come monadic datalog, che sono stati dimostrati essereequivalenti per potenza espressiva alla logica monadica di secondo ordine (MSO)[11]. Da notare come linguaggi quali XPath o espressioni regolari siano compresiin MSO.

3. L’approccio che sfrutta la teoria degli automi si basa sul tree automata, unageneralizzazione dell’automa a stati finiti che elabora alberi al posto di stringhe.L’equivalenza dei due approcci logici, MSO e monadic datalog, e l’approcciounranked query automata, mostrano che la classe di wrapper definibile in questiformalismi è abbastanza naturale e robusta. Fortunatamente questa classe èanche abbastanza espressiva, visto che accoglie molte delle attività rilevanti perl’estrazione di dati e contiene opportunamente i wrapper definibili in alcunilinguaggi di programmazione specifici [10].

4. Infine l’approccio testuale interpreta le pagine web come stringhe di testo e usa ilpattern matching per l’estrazione dei dati [21].

2.3.2 Metodi per la generazione di wrapper

Per quanto riguarda il coinvolgimento dell’utente, possono essere distinti tre principaliapprocci per la generazione di wrapper:

1. Programmazione manuale di wrapper, in cui il sistema supporta semplicementel’utente nella scrittura di un wrapper specifico, ma non fa nessuna generalizzazionea partire dagli esempi forniti dall’utente.

2. Induzione di wrapper, dove l’utente fornisce esempi e controesempi di istanze didata extraction e il sistema induce un wrapper adatto usando tecniche di machinelearning.

3. Generazione interattiva semi-automatica di wrapper, dove il progettista di wrappernon solo fornisce dati di esempio per il sistema, ma piuttosto accompagna lagenerazione del wrapper attraverso un processo interattivo e sistematico checoinvolge generalizzazione, correzione, test e tecniche di visual programming.

2.3.3 Architettura

L’immagine raffigura una visione ad alto livello di un tipico sistema semi-automaticointerattivo di web data extraction. Questo sistema comprende diverse componentistrettamente connesse ed interfaccia tre entità esterne:

1. il Web, che contiene le pagine con le informazioni di interesse;

2. un’applicazione obiettivo verso la quale verranno consegnati i dati estratti erifiniti;


figura 2.1: Architettura di un tipico sistema per l’estrazione di dati web

3. l’utente che progetta in maniera interattiva il wrapper.

Il generatore di wrapper accompagna l’utente durante tutta la fase di progettazionedel wrapper. Comunemente ha un’interfaccia visuale che permette all’utente di definirequali dati dovrebbero essere estratti dalle pagine web e come questi dati dovrebberoessere mappati in un formato strutturato quale XML. La stessa interfaccia visuale puòincludere diverse finestre come:

1. una finestra browser che rappresenta le pagine web di esempio;

2. una finestra che mostra l’albero sintattico associato al codice HTML della paginaweb rappresentata dalla finestra browser;

3. una finestra di controllo che permette all’utente di visualizzare e di controllareil processo generale di progettazione del wrapper e di inserire dati testuali (e.g.nomi di attributi e tag XML);

4. una finestra che mostra il programma wrapper costruito fin’ora e permetteall’utente di applicare ulteriori correzioni e rifiniture al programma.

La sottounità che effettivamente genera il wrapper è contenuta in quello che quiviene riferito come il program generator. Questa sottounità interpreta le azioni utentenelle pagine esempio e successivamente genera il wrapper. I generatori semi-automaticidi wrapper permettono all’utente, sia di specificare l’URL delle pagine web di esempio,strutturalmente simili alle pagine web obiettivo, che di navigare verso quelle stessepagine di esempio. Nel secondo caso la navigazione viene registrata e può essere automa-ticamente riprodotta. Le pagine di esempio vengono rappresentate nella finesta browser.La maggior parte dei generatori di wrapper visualizzano inoltre l’albero sintattico dellapagina corrente. Nella maggioranza dei sistemi, il progettista di wrapper può cliccaresu un nodo HTML e il sistema evidenzia immediatamente la parte corrispondentenella pagina di esempio all’interno del browser e vice versa. Il progettista può quindi

2.3. FONDAMENTI SCIENTIFICI 7

restringere iterativamente un esempio associato ad un pezzo rilevante di informazione.Molti sistemi di web data extraction utilizzano delle espressioni di percorso simili aXPath che identificano precisamente il pezzo rilevante di informazione. Il progettista diwrapper può generalizzare questa espressione di percorso rimpiazzando alcuni elementicon wildcards, caratteri speciali che rappresentano insiemi di caratteri. Il risultato èun modello generalizzato che si abbina a porzioni simili di informazione o a paginestrutturate in maniera simile. Alcuni sistemi (e.g. Denodo e Lixto) permettono alprogettista di selezionare direttamente queste porzioni dalla pagina web rappresentata.Il generatore di wrapper inoltre fornisce spesso supporto per associare un nome, oun’etichetta, ad ogni modello di estrazione e per l’organizzazione gerarchica dei mo-delli. I sistemi basati sull’induzione dei wrapper permettono all’utente di fornire ungran numero di esempi di pagine web con esempi positivi e/o negativi di porzioni diinformazioni desiderate, dai quali il programma generatore cerca di “imparare” unmodello generalizzato. I sistemi per la programmazione manuale dei wrapper fornisconosemplicemente un ambiente visuale per lo sviluppo di un wrapper nel linguaggio diprogrammazione utilizzato, per il test del wrapper con pagine di esempio e per ildebugging. Inoltre, l’interfaccia visuale permette generalmente ad un progettista dispecificare quando il wrapper dovrebbe essere eseguito.

Il wrapper executor è il motore che facilita il deployment del wrapper generatoprecedentemente. Tipicamente un programma wrapper comprende funzioni come lanavigazione web profonda (e.g. mezzi per compilare i form), indentificazione di elementirilevanti per mezzo di regole dichiarative o di script procedurali, e la generazione diun output in formato strutturato (e.g. XML o tabelle relazionali). Tipicamente, ilwrapper executor può anche ricevere parametri addizionali in ingresso, come un URLdi partenza, una struttura di output predefinita (e.g. uno schema XML particolare) evalori speciali per i form. In alcuni approcci, l’output include dei metadati (e.g. av-visi in caso di violazioni dei vincoli di integrità) oltre alle attuali informazioni d’interesse.

Il wrapper repository memorizza i wrapper generati insieme ai metadati. In alcuniapprocci, modelli di wrapper e concetti appartenenti al dominio possono essere riutiliz-zati ed estesi. Sistemi come Dapper offrono un wrapper community-based repositoryestensibile. In linea di principio, i sistemi possono offrire manutenzione automatica eadattamento dei wrapper come parte del repository.

L’unità di trasformazione ed integrazione dei dati fornisce un mezzo per snellire irisultati di diversi wrapper in un risultato omogeneo ed armonizzato. Questo passoinclude integrazione, trasformazione e pulizia dei dati, fondamentalmente funzioniche si trovano comunemente nella fase di trasformazione dei processi ETL dei datawarehouse e dei sistemi di mediazione. Tecnologie e strumenti comprendono linguaggidi interrogazione, data mapping visuale, tecniche di shema matching e de-duplicazioneautomatiche. Inoltre, i dati possono essere composti ed esportati nel formato desideratocome HTML, Excel o PDF.

L’unità di distribuzione dei dati (che ricalca la fase di Load nella filosofia ETL) de-cide il canale di output appropriato come email, Open Database Connectivity (ODBC)connection o FTP. Sistemi avanzati per la generazione dei wrapper offrono diversi con-nettori verso database e software enterprise come Customer Relationship Management(CRM) o Enterprise Resource Planning (ERP), o stringono relazioni con fornitori disoftware nel campo di Enterprise Application Integration (EAI) o Business Intelligence


(BI) che offrono tali soluzioni.

L’unità di controllo centrale e di organizzazione è il cuore del motore di elaborazione.In generale può essere distinto un processo di estrazione sincrono o asincrono. Untipico esempio di attivazione asincrona è la richiesta utente real-time in un’applicazionedi meta-ricerca di voli. La richiesta viene accodata, i relativi wrapper vengono attivati,viene fatto un mapping dei parametri e il risultato viene integrato e presentato all’utentein real-time. Approcci sofisticati offrono un paradigma di esecuzione basato su workflow,includendo parallelismo, il ritorno di risultati parziali e l’intercettazione di punti intransazioni di prenotazione complesse. Al lato opposto, market monitoring o webprocess integration sono tipici scenari sincroni. Uno scheduler è responsabile delladistribuzione di richieste all’esecutore di wrapper, iterando sul numero di possibili forminput e gestendo le eccezioni.

2.3.4 Sistemi commerciali per la generazione di wrapper

I sistemi commerciali per la generazione di wrapper includono:

Dapper

La Dapp Factory di Dapper offre una generazione di wrapper completamente basatasul server e supporta un repository di wrapper riutilizzabili gestito dalla community.Dapper si basa fortemente su tecniche di machine learning per la generazione di wrappere si concentra esclusivamente sulle pagine web che possono essere raggiunte senzanavigazione web profonda. Gli utenti che progettano un wrapper etichettano esempipositivi e negativi e mettono a punto il risultato su diverse pagine web strutturatein maniera simile. I wrapper sono ospitati sul server ed i risultati possono essereinterrogati attraverso un’Application Programming Interface (API) REST. Vengonoofferte anche API commerciali per usare Dapper in scenari aziendali.

Denodo

Denodo ITPilot, precedentemente noto come Wargo, è una piattarforma per la creazio-ne e l’esecuzione di script per la navigazione e l’estrazione in maniera indipendente.Il software offre un wizard grafico per la configurazione di wrapper e permette l’e-laborazione di eventi DOM durante la navigazione di pagine web. Si può eseguireuna navigazione web profonda all’interno di Internet Explorer e le pagine risultantivengono passate allo script di estrazione. Inoltre, ITPilot offer alcune funzionalità perla manutenzione dei wrapper. Denodo offre addizionalmente uno strumento chiamatoAracne per il crawling e l’indicizzazione di documenti.

Lixto

Lixto Suite comprende il Lixto Visual Developer (VD), un framework completamentevisuale ed interattivo per la generazione di wrapper, e il Lixto Transformation Server,basato su Java, che fornisce un ambiente scalabile per la trasformazione di datiincludendo diversi connettori verso applicazioni aziendali. VD è l’ideale per applicazionidinamiche Web 2.0 perchè supporta la registrazione visuale di macro per la navigazioneprofonda che rende possibile simulare click da parte dell’utente su elementi DOM.Strettamente connesso con le fasi di navigazione e nascosto al progettista di wrapper, il

2.4. APPLICAZIONI CHIAVE 9

linguaggio espressivo Elog viene utilizzato per l’estrazione dei dati e per il collegamentocon ulteriori fasi di navigazione. VD è basato su Eclipse ed incorpora il browser Mozilla.

Kapowtech

Kapow RoboSuite (rinominata Kapow Mashup Server) è un ambiente visuale basatosu Java per lo sviluppo di wrapper web. Incorpora un browser Java proprietario,implementa una Graphical User Interface (GUI) al di sopra di un linguaggio discripting procedurale e mappa i dati verso tabelle relazionali. Il RoboServer offre APIin diversi linguaggi di programmazione per la comunicazione sincrona e asincrona.Inoltre vengono offerte anche varianti del Mashup Server per impostazioni specifichecome la migrazione di contenuti.

WebQL

QL2 usa un linguaggio di interrogazione simile a SQL chiamato WebQL per scriverei wrapper. WebQL usa, in maniera predefinita, il suo albero HTML DOM al postodi basarsi su un browser standard, anche se viene offerta una vaga integrazione conInternet Explorer. Il QL2 Integration Server supporta concetti come server clusteringe HTML diffing. Inoltre viene offerto un ambiente per l’anonimizzazione dell’indirizzoIP.

2.4 Applicazioni chiave

2.4.1 Web market monitoring

Al giorno d’oggi possono essere raccolte un gran numero di informazioni di base suiconcorrenti a partire da sorgenti di informazioni pubbliche sul Web come report annuali,press release o database pubblici. D’altro canto strumenti potenti ed efficienti perl’estrazione, la trasformazione e il caricamento (ETL) di dati da sorgenti interne edapplicazioni verso data warehouse per Business Intelligenge (BI) sono già disponibilie largamente impiegati. D’altronde c’è un crescente bisogno di integrare in manieraefficiente dati esterni, come informazioni di mercato e sui concorrenti, all’interno diquesti stessi sistemi. Vedendo il World Wide Web come la più grande singola basedi dati sulla terra, tecniche avanzate per l’estrazione di dati e l’integrazione delleinformazioni come quelle descritte sono necessarie per l’elaborzione automatica deidati. Allo stesso tempo le informazioni estratte devono essere ripulite e trasformate informati semanticamente utili, e distribuiti da un processo di web-ETL verso sistemidi BI. Aspetti chiave in quest’area di applicazione includono ambienti scalabili perl’estrazione e l’elaborazione programmata in maniera efficiente di insiemi molto grandidi dati, capacità di raccogliere campioni di dati rappresentativi, pulizia dei dati estrattiper un successivo confronto e la connessione verso data warehouse.

2.4.2 Web process integration

In alcuni mercati, come l’industria automobilistica, i processi di business vengono ingran parte effettuati per mezzo di portali web. Dati di business critici da diversi reparticome quality management, marketing e vendite, engineering, gestione della catena diapprovvigionamento, devono essere raccolti manualmente dai portali web. Attraversol’automazione, i fornitori possono ridurre drasticamente il costo mentre allo stesso tempo


riescono ad aumentare la velocità e l’affidabilità di questi processi. Inoltre l’automazionetrasforma applicazioni web in web service e quindi i sistemi di generazione di wrapperpossono essere considerati come una tecnologia che consente di passare a ServiceOriented Architecture (SOA) come previsto e realizzato da Enterprise ApplicationIntegration (EAI) e proocessi B2B. Tra i fattori chiave in quest’area applicativa troviamola capacità di gestire workflow durante l’intero processo di estrazione, trasformazione econsegna dei dati, la capacità di trattare tutti i casi speciali che si incontrano nelleinterazioni web ed un eccellente supporto per gli standard di ultima generazione usatidurante le transazioni web sicure.

2.4.3 MashupSempre più spesso, i principali fornitori software mettono a disposizione piattaformemashup come Yahoo! Pipes o IBM QEDWiki. Un mashup è un’applicazione web checombina un diverso numero di siti web in una vista integrata. Spesso il contenuto vieneraccolto tramite API incorporando feed RSS o Atom, o in maniera simile utilizzandoREST (Representational State Transfer). In questo contesto, la tecnologia del wrappertrasforma un’applicazione web legacy in un insieme di API leggere che possono essereintegrate nello stesso modo nei mashup. Il risultato è che le soluzioni di web mashupnon hanno più bisogno di fare affidamento sulle API offerte dai fornitori di siti web, mapossono espandere il loro campo di applicazione al Web nella sua interezza. I fattorichiave per questo scenario applicativo comprendono capacità di estrazione efficientein real-time per un gran numero di interrogazioni concorrenti e una comprensionedettagliata di come mappare queste interrogazioni verso particolari form web.

2.5 Direzioni future

2.5.1 Generic web wrappingSenza commenti semantici espliciti nel Web corrente, i sistemi generici di data extrac-tion, che permettono un wrapping generale del web, dovranno andare verso il wrappingcompletamente automatico per il World Wide Web esistente.

Sfide di ricerca importanti comprendono:

1. come avvicinare in maniera ottimale conoscenza semantica al processo di estra-zione

2. come rendere il processo di estrazione robusto (in particolare come gestire i falsipositivi)

3. come gestire i problemi di scalabilità

I sistemi odierni per la raccolta e l’estrazione automatica di informazioni mostranoun progresso ragguardevole (vedi e.g. [7, 18]), ma mancano ancora della precisionenecessaria per permettere query veramente robuste.

2.5.2 Auto-adapting wrappersUn argomento associato è quello sui wrapper auto-adattanti. Molti wrapper oggidipendono dalla struttura ad albero di una data pagina web e falliscono quando il

2.5. DIREZIONI FUTURE 11

layout e il codice delle pagine web cambia. I wrapper auto-adattanti, che non soffronodi questi cambiamenti, possono usare la conoscenza esistente delle relazioni associatea precedenti versioni della pagina web per “guarire” automaticamente ed adattare leregole di estrazione al nuovo formato. La domanda a questo punto è come acquisireformalmente queste azioni di modifica ed eseguire le appropriate azioni di riparazione.

2.5.3 Wrapping da layout visualiMentre i wrapper web di oggi si concentrano in maniera dominante sul codice HTML osulla rappresentazione ad albero del DOM delle pagine web, approcci recenti puntanoall’estrazione di dati a partire dal Cascading Style Sheets (CSS) box model e, quindi,dalla rappresentazione visiva delle pagine web [9]. Questo metodo può essere parti-colarmente utile per strutture dati orientate al layout, come tabelle web, e permettedi creare wrapper automatici ed indipendenti dal dominio che resistono a modifichenell’implementazione del codice HTML.

2.5.4 Estrazione di dati da file non HTMLC’è un interesse sostanziale dell’industria nel wrapping di documenti in formati comePDF e PostScript. Il wrapping di questi documenti dev’essere guidato principalmenteda un ragionamento sugli spazi bianchi e sulla psicologia della Gestalt, che è sostan-zialmente differente dal web wrapping e quindi richiede nuove tecniche ed algoritmiche includono concetti presi in prestito dalla document understanding community.

2.5.5 Imparare a gestire interazioni webLe pagine web stanno diventando sempre più dinamiche ed interattive, linguaggi diwrapping efficienti devono rendere possibile registrare, eseguire e generalizzare macroper le interazioni web e quindi modellare l’intero processo di integrazione del workflow.Un esempio di tali interazioni web è una transazione di prenotazione complessa.

2.5.6 Comprensione e mapping dei form webPer interrogare form web in maniera automatica o interattiva, i wrapper devono impa-rare il processo di compilazione di form complessi e l’uso di interfacce di interrogazione.Questi sistemi devono imparare la rappresentazione astratta di ogni form e devonomapparli verso un meta form unificato e vice versa, tenendo conto di diversi tipi dielementi, contenuti ed etichette.

Capitolo 3

Descrizione del progetto

3.1 IntroduzioneIl software è stato diviso in tre macro-componenti: Extractor, Comparator eWeb service.

figura 3.1: Diagramma dei componenti

3.1.1 ExtractorL’Extractor consiste in uno script Greasemonkey in grado di estrarre le informazioni suiprezzi delle camere d’albergo da siti di booking-online (e.g. http://www.expedia.it,il primo sito preso in esame).

Le informazioni raccolte dallo script, prima di essere inserite nella base di datidell’applicazione, vengono normalizzate attraverso una richiesta di conversione dei dati

13

http://www.expedia.it

14 CAPITOLO 3. DESCRIZIONE DEL PROGETTO

raccolti verso dati codificati nel database (e.g. il tipo di camera Camera matrimonialeverrà convertito dall’utente nel tipo double già esistente nel database).

Per l’estrazione delle informazioni l’Extractor si appoggia a wrapper specifici peril sito in esame (e.g. per http://www.expedia.it si farà riferimento allo scriptwww.expedia.it.js). Gli script estrattori si interfacciano con l’Extractor attraversoun set di funzioni comune che permette il disaccoppiamento della parte di estrazionedati dalla parte di gestione e inserimento dati.

3.1.2 ComparatorIl Comparator consiste in un’applicazione web che, attraverso chiamate a procedureremote, fatte con l’utilizzo di tecniche Ajax per velocizzare i tempi di risposta dell’in-terfaccia, permette la consultazione delle informazioni estratte dall’Extractor e tieneaggiornata la base di dati con funzioni per la cancellazione dei dati obsoleti o relativi asiti che non sono più di interesse per il confronto.

Per facilitare il confronto sono presenti parametri su cui poter filtrare i risultatidella query di ricerca tra cui:

• nazione dell’albergo

• città dell’albergo

• nome dell’albergo (campo autocompletante)

• sito di provenienza dei dati

• data di check in

• data di check out

La tabella dei prezzi risultante potrà essere ordinata per rendere l’utilizzo dell’ap-plicazione ancora più semplice e produttivo. Le colonne ordinabili comprendono:

• trattamento

• contratto

• tipo di camera

• prezzo camera per notte

3.1.3 Web serviceEntrambe le componenti si interfacceranno ad un web service per ottenere le funzio-nalità richieste. Le chiamate a procedure remote fatte dalle componenti avvengonoattraverso XML-RPC, un protocollo per chiamate a procedure remote che utilizza lostandard XML per codificare le richieste e HyperText Transfer Protocol (HTTP) comemeccanismo di trasporto.

Questa gerarchia permette il disaccoppiamento tra la parte dell’applicazione per lagestione dei dati ed i servizi fruibili dall’utente per l’inserimento dei dati raccolti e la


3.1. INTRODUZIONE 15

loro consultazione.

Per la memorizzazione dei dati estratti l’applicazione si appoggia al RDBMSMySQL.

Capitolo 4

Analisi dei requisiti

La prima fase del periodo di stage è servita a definire i requisiti descritti in questo capi-tolo. Il software in questione deve permettere l’estrazione in maniera semi-automaticadi informazioni strategiche dai siti dei concorrenti ed il confronto dei dati raccolti.

Lo strumento sviluppato verrà utilizzato internamente alla società per raccoglieredati che, grazie a processi di Business Intelligence, forniranno un vantaggio competitivorispetto ai concorrenti.

Il processo può essere diviso in due fasi fondamentali: la raccolta ed il confronto deidati.

La fase di raccolta dei dati può essere ulteriormente scomposta in tre fasi: laselezione, l’estrazione e la normalizzazione. Questo processo include l’interazionedell’operatore con i siti concorrenti attaverso il wrapper. In fase di selezione l’opera-tore decide quali dati raccogliere inviando al sito concorrente criteri per la selezionedelle informazioni da estrarre. I criteri per la selezione dei dati corrispondono ai datinecessari per fare una ricerca di disponibilità di strutture alberghiere e comprendono:nazione, città, data di arrivo, durata del soggiorno. Una volta effettuata la selezionepuò partire la fase di estrazione. Durante questa fase i dati raccolti vengono strutturatie normalizzati utilizzando dati provenienti da tabelle di conversione (i.e. conversionedel tipo di camera Camera doppia nella stringa costante double).

La fase di confronto viene gestita attraverso l’utilizzo di un’interfaccia web chepermette all’operatore di filtrare e consultare i dati raccolti durante la fase precedente.I dati selezionati verranno visualizzati in una tabella, alcune colonne di questa tabellapotranno essere utilizzate per ordinare le righe e facilitare quindi la comprensione delleinformazioni estratte.

Alla fine del processo di analisi della fase di raccolta sono state individuate leseguenti funzionalità:

• ricerca di disponibilità

• normalizzazione dei dati

• registrazione dei dati raccolti su tabelle relazionali

17

18 CAPITOLO 4. ANALISI DEI REQUISITI

Per la fase di confronto sono state individuate le seguenti funzionalità:

• selezione dei dati raccolti

• ordinamento selezione di dati

I requisiti non funzionali comprendono:

• facilità di adattamento a diversi siti web

• facilità di utilizzo dell’estrattore

4.1 Ricerca di disponibilitàL’operatore che utilizza l’Extractor dovrà ricavare i dati da confrontare effettuandoricerche di disponibilità sui siti concorrenti. In una ricerca di disponibilità standardè necessario l’inserimento di alcune informazioni in un form web che determina laselezione di un certo numero di sistemazioni con relativi prezzi, tipi, servizi.

La soluzione ideale di questa richiesta prevede la composizione di un form comu-ne integrato nell’estrattore per rendere l’ambiente di estrazione standard e quindicoadiuvare l’operatore nell’attività di estrazione.

4.2 Normalizzazione dei datiOgni sito concorrente utilizza denominazioni, attributi ed etichette leggermente diverseassociate alle sistemazioni. Per rendere più efficace il confronto quindi, i dati estrattidevono essere necessariamente normalizzati. La fase di normalizzazione dev’esseresemi-automatica, richiedendo l’iniziativa dell’operatore solo nel caso in cui una conver-sione non sia triviale o non si riescano ad utilizzare conversioni esistenti.

La normalizzazione, attuata in fase di estrazione dei dati, consiste in un processoincrementale che raccoglie nuove conversioni ad ogni nuova estrazione, questo perrendere le estrazioni successive meno dipendenti da azioni dell’operatore. Ogni nuovaconversione viene inviata al web service che associa la conversione al sito preso inesame e la aggiunge alla collezione per una succesiva consultazione.

4.3 Memorizzazione dei dati estrattiI dati, raccolti e normalizzati durante la fase di estrazione, devono essere memorizzatisu tabelle relazionali per una successiva cosultazione per mezzo di una web application.La memorizzazione delle informazioni strutturate, in output dal wrapper, avvieneinviando al web service, tramite una chiamata Ajax, un messaggio XML che vienememorizzato nel database con l’aggiunta di alcuni metadati come la data di estrazionee il sito obiettivo.

4.4 Selezione dei dati raccoltiL’operatore che analizza e confronta i dati deve poter selezionare una porzione di datiin base ad alcuni parametri di ricerca fondamentali. Le ricerche di mercato necessarie

4.5. ORDINAMENTO DELLA SELEZIONE DI DATI 19

a NetStorming S.r.l. ad esempio, potrebbero prendere in esame solo alcuni concorrenti(i.e. filtro per sito web), oppure solo un determinato periodo nel quale si vuole aggredireil mercato con una strategia di marketing che potrà essere basata sulle informazioniricavate.

4.5 Ordinamento della selezione di datiUna volta selezionati i dati da analizzare, l’operatore deve poter individuare a colpod’occhio il prezzo più basso tra quelli estratti. Per fare ciò si vuole poter ordinarela tabella dei dati selezionati in base a diverse colonne come ad esempio: tipo dicamera, trattamento, prezzo camera per notte. L’ordinamento avviene cliccando suuna qualunque tra le colonne ordinabili della tabella, click successivi sulla stessa colonnadeterminano un cambiamento di verso nell’ordinamento.

4.6 Facilità di adattamento a diversi siti webIl sistema deve potersi adattare facilmente a diversi layout per poter raccogliereinformazioni da diversi competitor in maniera efficiente. L’ambiente di esecuzionedel wrapper condivide un flusso comune di estrazione dei dati dai siti obiettivo, maprevede l’esecuzione di wrapper specifici per ogni diverso obiettivo. Ciascun sitoweb prevederà un processo di personalizzazione di un wrapper template. Il wrapper,specializzando un’interfaccia comune, specifica, in base alla struttura della pagina webdel sito obiettivo, regole diverse per la selezione dei dati e la navigazione.

4.7 Facilità d’uso dell’estrattoreLa raccolta delle informazioni dev’essere quanto più possibile automatizzata, in manierada velocizzare le operazioni. Inoltre l’ambiente di estrazione deve risultare di facileutilizzo per permetterne l’accesso a personale non altamente specializzato. Per fare ciòsarà necessario minimizzare il numero di operazioni richieste per procedere alla fase diraccolta dei dati.

Capitolo 5

Progettazione

5.1 Strumenti e tecnologiePer sviluppare il progetto è stato necessario configurare adeguatamente la stazione dilavoro: una macchina dove è stato installato il sistema operativo GNU/Linux.

Nella costruzione dell’applicazione sono stati utilizzati diversi strumenti software,tecnologie e linguaggi di programmazione elencati nei seguenti capitoli.

5.1.1 Linguaggi di programmazioneI linguaggi di programmazione usati nello sviluppo del progetto sono stati:

• PHP (PHP Hypertext Preprocessor)

• JavaScript

PHP

PHP è un linguaggio di scripting lato server progettato per lo sviluppo di applicazioniweb, la cui prima versione risale al 1994 ad opera di Rasmus Lerdorf. Web service eparte dell’applicazione web Comparator sono stati scritti in PHP.

JavaScript

JavaScript è un linguaggio di scripting orientato agli oggetti e agli eventi originariamentesviluppato da Brendan Eich per Netscape Communications Corporation. Il linguaggioè stato utilizzato per realizzare front-end dell’applicazione di confronto e lo scriptGreasemonkey per l’estrazione semi-automatica dei dati.

5.1.2 Strumenti softwarePer servire le pagine web, per la gestione delle database relazionale, per la personaliz-zazione del wrapper template e per l’esecuzione del wrapper, sono stati utilizzati:

• Apache HTTP Server

• MySQL

21

22 CAPITOLO 5. PROGETTAZIONE

• Firefox

• Firebug

• GreaseMonkey

Apache HTTP Server

Apache HTTP Server, o più comunemente Apache, è un server web con architetturamodulare originariamente basato su NCSA HTTPd. Apache, sviluppato e mantenutoda una comunità di sviluppatori patrocinata dalla Apache Software Foundation, dallaseconda metà degli anni novanta è uno dei server web di maggior successo.

MySQL

MySQL è attualmente il secondo RDBMS (Relational DataBase Management System)open-source più largamente utilizzato al mondo. In congiunzione con Apache, PHP eLinux forma il famigerato stack software per applicazioni web LAMP (Linux, Apache,PHP, MySQL).

Firefox

Mozilla Firefox, conosciuto più semplicemente come Firefox, è un browser web open-source sviluppato dalla Mozilla Foundation. Questo strumento è stato scelto per lasua duttilità ed aderenza agli standard. Firefox permette l’aggiunta di funzionalità permezzo di estensioni, requisito fondamentale per la riuscita del progetto.

Firebug

Questa estensione per Firefox permette di accedere a funzionalità che facilitano ildebugging, la modifica e il monitoraggio di CSS, HTML, DOM, XHR e JavaScriptdi ogni sito web. Lo strumento, rilasciato sotto licenza BSD e inzialmente scritto nelgennaio 2006 da Joe Hewitt, uno dei creatori originali di Firefox, è stato utilizzatoprincipalmente nella fase di personalizzazione del wrapper grazie alle sue funzioni dianalisi del DOM e di debugging.

Greasemonkey

Greasemonkey è un’estensione per Firefox che permette all’utente di installare scriptche fanno modifiche on-the-fly ai contenuti delle pagine web prima o dopo il caricamento(augmented browsing). Questo strumento permette di eseguire il wrapper rendendodisponibile un ambiente per l’esecuzione di script JavaScript all’interno dello stessocontesto della pagina web contenente i dati che devono essere estratti.

5.1.3 Altri strumenti e librerie

XML

XML è un linguaggio di markup che viene utilizzato per codificare i messaggi scambiatitra Extractor, Comparator e Web service.

5.2. PIANIFICAZIONE 23

XPath

XPath è un linguaggio di interrogazione per selezionare nodi all’interno di un documentoXML. Le query XPath vengono generate selezionando, col supporto di Firebug, i nodiprescelti per poi andare a far parte della personalizzazione del wrapper templateassociata al sito web obiettivo.

jQuery

Rilasciata inizialmente nel 2006 da John Resig, jQuery è una libreria JavaScript cross-platform progettata per semplificare lo sviluppo di script client-side. È la libreriaJavaScript attualmente più usata nel web e nel contesto del progetto viene utilizzatasia nel wrapper, per la selezione e la manipolazione del DOM, che nel front-enddell’applicazione di confronto, per facilitare la comunicazione Ajax con il web service eper gestire l’ordinamento dei dati.

5.2 Pianificazione

La pianificazione del progetto è stata programmata con l’aiuto del tutor aziendale,Matteo Giacomazzi. Prima di iniziare con la vera progettazione e realizzazione dellefunzionalità indicate nel capitolo precedente, è stato dedicato del tempo allo studio delladocumentazione delle librerie e degli strumenti, in modo da avere un’idea più chiara dicome agire. Questo studio è stato fatto sia con l’utilizzo della documentazione fornita,sia con la realizzazione di un piccolo prototipo di script Greasemonkey. Lo scopodello script consisteva semplicemente dell’injection di una risorsa esterna nella paginaweb visitata e nella manipolazione del DOM per aggiungere un elemento in overlay.Questo piccolo programma d’esempio è stato molto utile per capire le potenzialitàdello strumento e per individuare eventuali problemi (e.g. conflitti nelle regole CSS trai fogli di stile dello script e quelli della pagina web ospitante).

5.2.1 Ciclo di vita del software

Per quanto riguarda il ciclo di vita adottato per il progetto, la scelta è stata pressochéobbligata. Trattandosi di uno studio dove non era disponibile precedente esperien-za per valutare il lavoro da svolgere, è stato necessario focalizzare l’attenzione piùsulla riuscita del progetto che non sulla progettazione. Superfluo dire che non erapossibile progettare nei minimi dettagli il lavoro da svolgere dal momento che nonsi conoscevano le potenzialità degli strumenti e delle librerie con cui si andava a lavorare.

Per questo motivo si è adottato il metodo Agile programming [2]. Si tratta di unciclo di vita in cui il committente viene coinvolto il più possibile, in modo da correggerevelocemente il progetto in base alle esigenze. Questo metodo ben si adatta allo stagesvolto, dove ogni singola funzionalità richiesta poteva essere considerata come unpiccolo progetto a sé stante, e dove si lavorava a stretto contatto con il committente,in questo caso personificato dallo stesso tutor aziendale.

La scelta di quali funzionalità implementare prima delle altre è stata fatta conl’accortezza di iniziare da quelle più semplici per poi arrivare a quelle più complesse,stando attenti però che non fossero implementate prima delle funzionalità che richiede-vano l’esistenza di altre. Anche questo approccio è stato dettato dalla natura dello


stage, infatti, per acquisire familiarità con gli strumenti e le tecnologie, è stato utilepartire dalla funzionalità più semplice, per arrivare a quella più complessa una voltaapprese le conoscenze per realizzarla.

Per quanto riguarda la pianificazione di tempi e risorse, è stato possibile solo inparte fare una quantificazione a priori. Va infatti sempre tenuto ben presente che primadi questo progetto, all’interno dell’azienda, nessuno aveva mai utilizzato strumenticome Greasemonkey o librerie come jQuery. Da ciò ne deriva che c’era quindi soloun’esperienza parziale da cui prendere spunto, trattandosi di un progetto pilota, dacui futuri progetti potranno ispirarsi.

5.3 Progettazione

La progettazione è partita con la definizione del web service e della comunicazionetra classi PHP e database MySQL. A partire dal diagramma ER concordato con ilcommittente, è stato costruito il database per la raccolta delle informazioni strutturatee per la gestione delle conversioni dei dati estratti dallo script in fase di normalizzazione.

Le informazioni ricavate dal wrapper vengono inviate per mezzo di richieste Ajaxal web service, una macro-componente fondamentale che determina l’interfaccia perla comunicazione tra script estrattore, front-end e database. Tali informazioni sa-ranno quindi disponibili per una successiva consultazione e, grazie al processo dinormalizzazione, per un confronto efficiente.

5.3.1 Struttura della base di dati

Dopo aver individuato assieme al commitente i requisiti fondamentali dell’applica-zione si è passati alla progettazione della base di dati per mezzo di un diagrammaentità-relazione. Il diagramma avrebbe fornito una mappa visuale della struttura deidati, questa struttura avrebbe influenzato a sua volta la gerarchia di classi che gesti-scono la business logic e la parte di conversione dei dati nel processo di normalizazzione.

figura 5.1: Diagramma E-R

5.3. PROGETTAZIONE 25

Nel diagramma si possono distinguere alcune entità principali tra cui elenchiamosite e price. Queste registrano rispettivamente, i dati relativi ai siti web obiettivo del-l’estrazione, e i prezzi. Ogni riga della tabella price accentra, attraverso quattro diverserelazioni con le entità hotel, site, contract e arrangement, i dati strutturati estratti.

Le tre entità che consentono di effettuare una conversione delle informazioni grezze,in output dall’elaborazione della pagina web presa in esame, sono: arrangement_conv,contract_conv e room_type_conv. In queste tabelle ogni riga, associata rispettiva-mente all’entità site e all’entità relativa all’informazione da convertire, modella laconversione tra un’informazione grezza ed un record esistente nel database. In questomodo per ogni sito si possono collezionare un insieme di conversioni che faciliterannoi successivi processi di estrazione. Da notare l’assenza della relazione verso l’entitàrelativa all’informazione da convertire per la tabella room_type_conv, questa sceltaè stata fatta per semplicità visto che i tipi di camera vengono modellati come unsemplice campo di tipo enum nell’entità price. Per maggiori informazioni sul processodi conversione dei dati grezzi vengono si rimanda alla sezione di approfondimento sullanormalizzazione.

Nel linguaggio tecnico delle prenotazioni alberghiere contract, può essere tradotto incontratto, viene definito come la tipologia di sistemazione che viene concessa e ne esisto-no migliaia, e.g. standard room, sea view, superior room, suite. Arrangement invece,tradotto trattamento, riguarda quello che l’ospite ottiene oltre al pernottamento, e.g.room only (solo pernottamento), room and breakfast (pernottamento con colazione),half board (mezza pensione), full board (pensione completa).

Infine le due entità city e country sono informazioni accessorie associate all’entitàhotel per permettere una successiva ricerca.

5.3.2 Modelli e interazione con il database

L’interazione con il database è delegata all’uso di classi che modellano tabelle relazionali,sfruttando il pattern architetturale active record, un design pattern comunemente usatoper fare object-relational mapping. Singole istanze delle classi modello rappresentanorighe nelle tabelle relazionali, nascondendo i dettagli implementativi delle query chevengono eseguite per ottenere i dati richiesti.

Tutte le classi modello estendono la classe Model, dove sono implementate alcunefunzionalità di base comuni a tutti i modelli come: get_id, set_id, insert, delete.Model include inoltre l’unica proprietà condivisa da tutte le classi modello e cioè id, ditipo intero, che serve per memorizzare la chiave primaria di ogni entità. Model dipendeda DbConnection, un singleton che viene utilizzato per condividere una connessione alserver MySQL e per operare a basso livello sul database.

Tutte le classi che effettuano una conversione tra stringhe in output dall’estra-zione e oggetti di tipo Contract, RoomType o Arrangement, ereditano dalla classeConversion che definisce i metodi is_present e get_conversion specificati dallediverse implementazioni di Conversion.


figura 5.2: Diagramma delle classi per l’interazione con il database

5.3.3 Web service

La definizione generica di web service lo descrive come un sistema software progettatoper supportare l’interoperabilità tra diversi elaboratori su di una medesima rete; talecaratteristica si ottiene associando all’applicazione un’interfaccia software che esponeall’esterno il servizio/i associato/i e utilizzando la quale altri sistemi possono interagi-re con l’applicazione stessa attivando le operazioni descritte nell’interfaccia tramiteappositi messaggi di richiesta, che nel protocollo XML-RPC sono formattati secondolo standard XML e trasportati tramite HTTP.

Sia Extractor che Comparator, le due macro-componenti dell’app usate rispettiva-mente per estrarre i dati e per confrontare i dati normalizzati, comunicano con un webservice per memorizzare informazioni nella base di dati, per ricavare i dati memorizzatied in generale per accedere, in maniera strutturata, a funzioni messe a disposizionedalle classi modello.

Il protocollo del web service implementato durante lo stage non aderisce in manierafedele alla specifica XML-RPC, ma mima l’implementazione interna messa a puntodella società committente per motivi di compatibilità con i sistemi esistenti. In questomodo all’occorrenza si sarebbe potuto semplicemente aggiornare il web service esistenteaggiungendo le funzioni che riguardano questo progetto per un’integrazione pressochèimmediata.

L’interfaccia più esterna del web service consiste in uno script PHP (xml_rpc/call.php)che espone un’API descritta all’interno dello stesso file. Ogni funzione esposta è elen-cata in un array di stringhe associate a nomi di metodi implementati nelle librerie delweb service. Lo script seleziona la corretta libreria e la corretta versione dell’API inbase all’header della richiesta HTTP. Una volta incluso il file associato alla libreria, loscript richiama il metodo associato alla procedura richiesta a cui vengono passati ininput i parametri contenuti nel body della richiesta. I parametri in ingresso del metododerivano dalla decodifica del corpo della richiesta da XML ad oggetti PHP. Il risultatoin output dall’esecuzione del metodo selezionato viene quindi ricodificato in formato


XML per essere rispedito nella risposta HTTP. In caso di errori durante l’esecuzionedel metodo, o in caso di un errore nella selezione della procedura, della libreria o dellaversione dell’API, lo script risponde includendo i messaggi di errore in una rispostasempre codificata in XML.

figura 5.3: Diagramma delle classi che compongono la macro-componente Web service

5.3.4 Comparator

Il Comparator è un’applicazione web utilizzata per confrontare i dati raccolti. Oltrea mostrare una selezione dei dati, l’applicazione offre funzioni per la manutenzionedella base di dati, come la cancellazione dei record relativi ad un dato sito web oppurei record più vecchi di una certa data (i dati relativi a date di check in più vecchierispetto alla data odierna sono dati ormai inutilizzabili). Include inoltre funzioni perl’export di un sottoinsieme di record selezionati in formato Comma-Separated Values(CSV) per una successiva elaborazione con altri programmi (e.g. foglio di calcolo).

Il modulo è composto da uno script PHP (index.php) che istanzia un templateSmarty (index.tpl), assegna le variabili che compongono le sezioni dinamiche dellapagina, lo compila e stampa la stringa risultante che viene inviata come risposta dalserver HTTP.

Smarty è un template engine PHP che facilita la scrittura di applicazioni web


separando logica e contenuto dalla sua presentazione1. Nel progetto viene utilizza-to per uniformare la gestione del codice HTML, con l’utilizzo di un layout comunepage.tpl che include a sua volta i template di alcune sezioni globali, come header.tple footer.tpl. Tali template compongono testata e piè di pagina identici per tutte lepagine dell’applicazione. Il layout generale prevede una sezione di contenuto (identi-ficato dalla variabile $content), una sorta di placeholder, che viene di volta in voltapopolata con il risultato della compilazione del template specifico associato alla paginache si sta visitando. Ogni istanza di template, oltre alle variabili del caso, può riceverein input anche percorsi a fogli di stile CSS e a script JavaScript specifici, che si vannoad aggiungere a quelli predefiniti, per modificare presentazione e comportamento dellapagina in esame. Grazie al template engine e alla struttura di templates, si separanoin maniera concreta presentazione e logica, evitando così la ripetizione di codice emettendo in pratica uno dei più diffusi principi nello sviluppo del software: Don’tRepeat Yourself (DRY).

figura 5.4: Gerarchia delle classi Template utilizzate da Web service e Comparator

La pagina indice dell’applicazione web è composta principalmente da due sezioni:

• un form per la selezione dei dati

• una tabella per visualizzare i dati selezionati grazie al form

5.3.5 Selezione dei dati raccoltiIl form viene utilizzato per selezionare un sottoinsieme di risultati ed è composto dacampi che comprendono:

• selezione della nazione

• selezione della città

• selezione dell’albergo

• selezione del sito di provenienza dei dati

• data di check in1Smarty Documentation - What is Smarty? url: http://www.smarty.net/docs/en/what.is.

smarty.tpl.

http://www.smarty.net/docs/en/what.is.smarty.tpl




I campi di selezione nazione e sito di provenienza vengono popolati dinamicamentedallo script PHP utilizzando rispettivamente le funzioni Comparator::get_country_selecte Comparator::get_url_select, che ritornano in output un’array multidimensionaleche contiene valori ed etichette da assegnare ad ogni elemento <option> del campo diselezione corrispondente.

I campi città e albergo sono campi dinamici, ma vengono popolati con chiamate Ajaxe sono rispettivamente una lista di città, che dipende dalla nazione selezionata, e un cam-po di testo autocompletante, che contiene una lista di alberghi filtrata per città e sito se-lezionati. Le funzioni per popolare questi due campi, messe a disposizion dal web service,rispettivamente Comparator::get_city_select e Comparator::get_hotel_select,sono utilizzate dalla libreria Comparator del web service che mette a disposizione dueprocedure remote con lo stesso nome. L’operatore, interagendo con la pagina web, fascaturire eventi JavaScript (i.e. l’aggiornamento della nazione selezionata, un nuovocarattere nel campo autocompletante per la selezione dell’albergo) che mandano inesecuzione callback che fanno partire chiamate Ajax verso il web service. Le chiamateAjax scaturiscono altri eventi (i.e. risposta HTTP) che mandano in esecuzione callbackche hanno il compito di aggiornare l’interfaccia modificando rispettivamente la listadelle città o degli hotel visualizzabili grazie all’autocompletamento.

Utilizzando Ajax per aggiornare l’interfaccia si evita l’aggiornamento di tutta lapagina HTML ad ogni evento JavaScript rendendo l’applicazione più usabile e veloce.Ajax2 (dininutivo di asynchronous JavaScript + XML) è un gruppo di tecniche chepermettono di comunicare in maniera asincrona con un server HTTP senza interferirecon la visualizzazione ed il comportamento della pagina web. I dati vengono richiesti permezzo di un oggetto di tipo XMLHttpRequest. JavaScript e l’oggetto XMLHttpRequestforniscono un metodo di scambio di dati in maniera asincrona tra un browser e unserver per evitare il ricaricamento completo della pagina web.

L’operatore procede quindi alla selezione dei dati:

1. seleziona una nazione dall’elenco, l’evento aggiornamento nazione selezionatadetermina il caricamento delle città associate alla nazione selezionata

2. seleziona una città, l’evento aggiornamento città selezionata determina il carica-mento degli alberghi associati alla nazione selezionata

3. seleziona un albergo, ad ogni carattere digitato all’interno della casella di testodi selezione albergo la lista di opzioni disponibili viene filtrata utilizzando comequery di ricerca la sottostringa inserita

4. seleziona un sito da cui sono stati estratti i dati

5. selezione una data di check in

6. seleziona una data di check out

2Jesse James Garrett. Ajax: A New Approach to Web Applications. 2005. url: http://www.adaptivepath.com/ideas/ajax-new-approach-web-applications/.

http://www.adaptivepath.com/ideas/ajax-new-approach-web-applications/



Ogni parametro di selezione è opzionale e se inserito restringe l’insieme di risultati.

Infine l’operatore clicca sul pulsante Compare per inviare la richiesta asincrona alserver che esegue l’interrogazione e restituisce una porzione di codice HTML che andràa costituire la tabella dei dati da confrontare.

5.3.6 Ordinamento selezione di dati

La tabella contenente i risultati della selezione, per facilitare la consultazione da partedell’operatore, dev’essere ordinabile. Questa funzione viene implementata lato clientgrazie all’utilizzo della libreria jQuery jquery.tablesorter.js. Questa libreria è ingrado di elaborare i dati della tabella e mettere a disposizione funzioni per l’ordina-mento.

Uno dei punti di forza di jQuery è la sua estensilità. La libreria implementa diretta-mente un piccolo set di funzionalità core, ma mette a disposizione un’API per estenderein maniera semplice questo insieme. Un plugin jQuery è uno script JavaScript cheestende le funzionalità della libreria aggiungendo metodi all’API degli oggetti jQuery(i.e. gli oggetti ritornati da una selezione per mezzo della funzione $()) o direttamentealla funzione $3. Nel caso di Tablesorter, il plugin estende l’API degli oggetti jQueryaggiungendo un metodo tableSorter che prende in input un oggetto contenente delleopzioni e aumenta la tabella aggiungendo funzioni per l’ordinamento dei dati.

Le opzioni utilizzate nell’applicazione sono:

sortColumn: ’price_per_night’la colonna su cui fare il primo ordinamento della tabella, nel caso specifico ilprimo ordinamento viene fatto sulla colonna prezzo per notte

sortClassAsc: ’header-asc’la classe CSS utilizzata per segnalare un ordinamento crescente

sortClassDesc: ’header-desc’la classe CSS utilizzata per segnalare un ordinamento decrescente

stripeRowsOnStartUp: trueun valore booleano che determina l’applicazione uno stile alla tabella che colorain maniera alternata ogni riga della tabella per facilitarne la consultazione

L’esecuzione del metodo tableSorter applicato all’elemento <table> inoltre ag-giunge callback all’evento click ad ogni elemento <th>. Queste callback, eseguite all’at-tivazione dell’evento, ordinano tutte le righe della tabella secondo i valori contenutinella colonna selezionata alternativamente in maniera crescente o decrescente.

5.3.7 Extractor

L’operatore che procede all’estrazione dei prezzi delle strutture alberghiere dai siticoncorrenti deve poter lavorare in un ambiente il più possibile familiare. Per questo, eper altre ragioni che verranno illustrate in seguito, si è deciso di implementare questa

3jQuery Learning Center: How to Create a Basic Plugin. url: http://learn.jquery.com/plugins/basic-plugin-creation/.

http://learn.jquery.com/plugins/basic-plugin-creation/



macro-componente con uno userscript Greasemonkey.

Il principale scopo dell’estensione Greasemonkey è quello di gestire gli userscript.Uno userscript permette all’utente di controllare il modo in cui usa il web, perso-nalizzandolo con uno script4. Gli userscript possono essere localizzati ovunque inInternet o anche offline. Nel caso dell’Extractor lo script è memorizzato nei serverdella società committente e può essere scaricato via web da un indirizzo raggiungibiledalla rete interna. Ogni file che finisce per .user.js è uno userscript Greasemonkeyvalido. L’operatore, utilizzando un borwser Firefox e dopo aver installato l’estensioneGreasemonkey, naviga verso l’URL dello script extractor.user.js. Quando un URLfinisce per .user.js Greasemonkey intercetta il file in caricamento presentando unafinestra di dialogo per l’installazione5.

Una volta installato lo script, l’operatore è pronto per eseguire operazioni di estra-zione. Lo script, infatti, include un blocco di metadati contenente informazioni chedescrivono lo script, tra le quali, regole di inclusione ed esclusione. Queste regoledeterminano l’esecuzione automatica dello script se l’indirizzo visitato corrispondeall’espressione indicata nelle regole. I metadati dello script indicano a Greasemonkey,ad esempio, di eseguire automaticamente lo script non appena viene visitato uno dei siticoncorrenti per cui è stato scritto un wrapper in grado di estrapolare le informazionisui prezzi delle strutture alberghiere.

Lo userscript extractor.user.js implementa solo un sottoinsieme delle funzio-nalità richieste dalla componente di estrazione, questo script è un punto di partenzaper il caricamento di librerie contenenti l’implementazione della GUI di estrazione,metodi per la comunicazione con il web service e librerie che specializzano l’interfacciadel wrapper per il riconoscimento e l’estrazione delle informazioni della pagina webobiettivo.

L’ambiente di esecuzione del wrapper fornisce una piccola interfaccia grafica asupporto dell’operatore durante tutto il processo di estrazione. Questa interfacciaviene iniettata in overlay nella pagina web obiettivo, in modo da lasciare all’operatorel’opportunità di confrontare visivamente le informazioni sorgente e quelle estratte, perevitare errori ed omissioni. L’estrattore fornisce un sistema di navigazione automa-tica del sito obiettivo, che permette di effettuare una ricerca sul sito preso in esamedirettamente dall’interfaccia dell’ambiente di esecuzione. Durante il processo di estra-zione i dati saranno vagliati e, in caso di bisogno, convertiti manualmente dall’operatore.

Infine i dati strutturati, in output dal processo di elaborazione, sono pronti peressere inviati al web service per poi essere memorizzati nella base di dati remota. Perinviare i dati lo script deve effettuare una chiamata remota asincrona cross site, cioèuna chiamata verso un dominio differente (i.e. il dominio dove risiede il server delweb service, e.g. www.hotelsclick.com) dal dominio di origine (i.e. il dominio delsito concorrente preso in esame, e.g. www.expedia.it). Per motivi di sicurezza peròi browser non permettono questo tipo di chiamate, la same-origin policy, infatti, èun concetto di sicurezza che permette agli script in esecuzione in pagine provenientidallo stesso sito (una combinazione di scheme, hostname e porta), di accedere ai

4GreaseSpot Wiki: User script. url: http://wiki.greasespot.net/User_script.5Greasemonkey manual: Installing scripts. url: http://wiki.greasespot.net/Greasemonkey_

Manual:Installing_Scripts.

http://wiki.greasespot.net/User_script

http://wiki.greasespot.net/Greasemonkey_Manual:Installing_Scripts



figura 5.5: Diagramma delle classi che compongono la macro-componente Extractor

reciproci metodi e proprietà senza specifiche restrizioni, impedendo invece l’accessoalla maggior parte dei metodi e delle proprietà tra pagine provenienti da siti diversi.Nel caso specifico, anche se l’origine della chiamata Ajax è il sito obiettivo, la chiamataproviene da uno userscript. Greasemonkey, per casi come questi, mette a disposizioneun metodo per generare richieste asincrone che non soffrono di questa limitazione. Ilmetodo GM_xmlhttpRequest funziona in maniera simile all’oggetto XMLHttpRequest,ma non soffre delle limitazioni di sicurezza descritte sopra e permette quindi di generarechiamate dai siti obiettivo verso il web service per memorizzare i dati raccolti dalwrapper.

Le librerie utilizzate dall’Extractor sono composte da script JavaScript che peressere eseguiti devono essere caricati nella pagina del browser che si sta visitando. Ognifile di libreria viene quindi iniettato nella pagina ospitante attraverso la generazione diun tag di tipo <script>. In maniera simile il foglio di stile che modella l’interfacciadell’ambiente di esecuzione del wrapper viene caricato iniettando un tag di tipo <link>.Il nome del file delle librerie che implementano il wrapper specifico per ogni sitoobiettivo, corrisponde al dominio del sito (e.g. la libreria per l’estrazione dei dati dahttp://www.expedia.it si chiama www.expedia.it.js), in questo modo lo scriptviene iniettato utilizzando la variabile document.location.hostname come prefissoper l’elaborazione del nome file corretto.

La versione prototipale dello script, per interagire con la pagina web, usa un oggettodenominato unsafeWindow, una scorciatoia a window.wrappedJSObject, che contienel’oggetto window grezzo all’interno del XPCNativeWrapper messo a disposizione dallasandbox di Greasemonkey. Per motivi di sicurezza, il suo uso è sconsigliato perchè questo



oggetto elude il sistema di sicurezza di Greasemonkey basato su XPCNativeWrapper.Questo sistema di sicurezza esiste per evitare che pagine web maligne alterino gli oggettiin maniera che gli userscript (la cui esecuzione prevede maggiori privilegi di quelli diuno script JavaScript ordinario) facciano cose che gli autori non intendevano fare. Inquesto progetto è stato comunque fatto uso di tale oggetto, sia perchè lo userscriptveniva eseguito solo in determinate pagine, riducendo al massimo la possibilità diattacchi, sia per rendere più veloce la prototipazione dell’ambiente di estrazione.

5.3.8 Ricerca di disponibilità

Il primo compito dell’operatore che vuole compiere un’attività di estrazione di dati èquello di fare una ricerca di disponibilità. Basta visitare il sito concorrente utilizzandoun browser Firefox, che includa l’estensione Greasemonkey attivata e lo userscriptExtractor installato, per attivare automaticamente l’esecuzione dello stesso al carica-mento della pagina web.

Dopo il completo caricamento dello script viene subito fatta una richiesta al serverper controllare che il sito visitato esista nella base di dati. La procedura remotaExtractor::is_site_present ritorna un valore booleano che determina la presenzadel sito in esame nella tabella site del database.

figura 5.6: Avvio dello script Extractor, sito web non trovato

In entrambi i casi l’operatore può solo continuare nel processo, determinando, nelcaso in cui il sito non sia presente nel database, una chiamata a procedura remota perl’inserimento del nuovo sito a cui verranno poi associate le estrazioni successive.

figura 5.7: Avvio dello script Extractor, sito web trovato

La procedura remota Extractor::insert_site prende in input nome e l’URL delsito, ed inserisce nel database una nuova riga corrispondente al sito web obiettivo.

A questo punto l’operatore può procedere con la ricerca di disponibilità. L’inter-faccia mette a disposizione un form di ricerca di disponibilità semplificato che vieneutilizzato per popolare il form di ricerca dell’obiettivo, automatizzando la navigazioneverso la pagina dei risultati, fonte delle informazioni che si vogliono estrarre per il


confronto.

figura 5.8: Ricerca disponibilita, selezione della città

Vengono selezionati successivamente:

• nazione

• città

• data di check in


L’Extractor inizialmente non possiede alcuni dati necessari per effettuare la ricerca,come una lista di tutte le città per ogni nazione, per questo è possibile bypassare laricerca automatica per eseguire l’estrazione su una lista di hotel selezionata in base aduna ricerca personalizzata.

L’operatore quindi procede ad una normale ricerca nel sito web, selezionando dap-prima nazione e città.

figura 5.9: Ricerca personalizzata, selezione della città

Il passo successivo consiste nel selezionare la durata del soggiorno impostando datadi check in e data di check out nelle caselle corrispondenti.

Alcune applicazioni web poi permettono di rifinire ulteriormente la ricerca aggiun-gendo filtri sul tipo di camera desiderato, sul trattamento o sul contratto.

Le figure mostrano l’esecuzione di alcuni dei passi descritti, in una vecchia versionedel portale http://www.hotelsrus.com.

Alla fine del processo, lo script, riconoscendo la pagina dei risultati di una ricercada cui è possibile eseguire un’estrazione, si riattiva per proseguire nel processo diestrazione dei dati.

http://www.hotelsrus.com


figura 5.10: Ricerca personalizzata, selezione del periodo di soggiorno

figura 5.11: Ricerca personalizzata, selezione del tipo di camera

5.3.9 Normalizzazione dei dati

Il processo di estrazione, come già descritto nel capitolo 2, comprende una fase dielaborazione dei dati, che include il filtraggio, la trasformazione, la raffinazione e l’in-tegrazione dei dati estatti da una o più sorgenti, e la strutturazione del risultato aseconda del formato di output desiderato (di solito XML o tabelle relazionali). Diquesta fase fa parte anche un processo per la normalizzazione dei dati e la conversionedelle entità sconosciute in valori esistenti nella base di dati del sistema. Questo processoviene eseguito in maniera semi-automatica dal wrapper, che facendo una richiesta allaprocedura remota Extractor::conv_<type>, dove <type> è un valore compreso traarrangement, contract e room_type, a cui viene passato un array di valori da con-vertire, riceve in output una lista di id associati alle conversioni da applicare ai valori.Questo metodo utilizza le tabelle <type>_conv che contengono per ogni conversioneuna riga che associa un valore da convertire (convert) ad una riga nella tabella <type>corrispondente attraverso la chiave esterna <type>_id. Basta quindi una sola inter-rogazione del database per raccogliere tutti gli id dei record da associare ai dati estratti.

Se nel database non viene trovata una conversione per tutti i valori estratti, ilprocesso di associazione viene svolto manualmente dall’operatore che deve riconoscereed associare in maniera corretta i dati estratti con i dati già presenti nel database odeve aggiungerne di nuovi nel caso in cui una conversione non sia possibile. L’interfac-cia dell’Extractor coadiuva l’utente in questa operazione individuando le conversionimancanti e proponendo una lista di oggetti a cui associare i nuovi valori.

Le informazioni da convertire sono i valori relativi ai trattamenti, ai contratti e aitipi di camera. Per ogni informazione da convertire, solo nel caso in cui non venganotrovate delle conversioni esistenti per i valori estratti, viene presentata all’operatoreuna lista dei valori che necessitano di una conversione. Ad ogni valore nella lista vieneassociata una casella di selezione che contiene le possibili conversioni da applicare.I valori delle caselle di selezione sono ricavati facendo una richiesta alla proceduraremota Extractor::<type>_values, che ritorna una lista di array che contengono ide description degli oggetti presenti nel database di tipo <type>. L’operatore deve


quindi selezionare i valori di conversione corretti e cliccare il pulsante Continua.

Per velocizzare questo processo è stata aggiunta una funzione, accessibile cliccandosul pulsante Copia, che copia la prima conversione nella lista, in tutte le caselle chenon sono state ancora valorizzate.

figura 5.12: Conversione, lista dei nuovi trattamenti trovati da convertire e selezione deivalori di conversione

Una volta selezionate le conversioni e cliccato il pulsante Continua, le informazionivengono registrate nel database per mezzo della procedura remota Extractor::insert_conv_<type>.

figura 5.13: Conversione, risultato dell’operazione di memorizzazione delle conversioni

Il processo di normalizzazione procede presentando all’operatore un form di con-versione della valuta in cui sono espressi i prezzi delle camere d’albergo. Questa faseviene omessa se la valuta dei prezzi è uguale dalla valuta scelta per tutte le conversioni(i.e. Euro).

figura 5.14: Normalizzazione, inserimento dati di conversione della valuta

La parziale automazione del processo permette di creare una lista di conversioni cheviene incrementata ad ogni nuova serie di dati estratti e quindi di richiedere sempremeno spesso un intervento esplicito da parte dell’operatore.


Una volta terminato il processo, i dati, in attesa di essere inviati al web serviceper la memorizzazione, sono facilmente confrontabili essendo regolari e conformi allostandard interno della società.

5.3.10 Memorizzazione dei dati estrattiI dati estratti, convertiti e normalizzati, possono essere finalmente inviati al webservice per la memorizzazione ed essere reperibili in caso di selezione. Le informazionistrutturate vengono memorizzate prima in un oggetto JavaScript in attesa di essereinviate tramite richiesta HTTP al server.

Il web service mette a disposizione la procedura remota Extractor::insert_datache accetta in input:

Chiave Descrizionesite_id l’id associato al sito web in esamecity_id l’id associato alla città inserita nel form di ricercacheck_in una data di check incheck_out una data di check outhotels un array che contiene tutte le strutture alberghiere in output

dalla ricerca di disponibilitàtabella 5.1: Struttura dei dati estratti

Ogni elemento dell’array hotels è composto da:

Chiave Descrizionehotel_name il nome dell’albergoprices un array che contiene tutti i prezzi associati alla struttura

alberghieratabella 5.2: Struttura degli oggetti contenuti nell’array hotels

Ogni elemento dell’array prices è composto a sua volta da:

Chiave Descrizionearrangement_id l’id associato al trattamentocontract_id l’id associato al contrattoroom_type_id l’id associato al tipo di cameraprice_per_night prezzo per notte della struttura alberghiera espresso in Euro

tabella 5.3: Struttura degli oggetti contenuti nell’array prices

La risposta del web service contiene la lista di righe con le descrizioni degli oggettitrattamento, contratto e tipo camera associati, che vengono visualizzati per dare unmessaggio di feedback all’operatore dell’avvenuta archiviazione dei dati inviati.

Le richieste di memorizzazione vengono effettuate in maniera automatica alla finedel processo di conversione e normalizzazione. Nel caso in cui la lista dei risultatidella ricerca sia composta da più di una pagina, lo strumento si comporta in maniera


figura 5.15: Risultato dell’inserimento nel database di un insieme di dati

leggermente diversa in base all’implementazione della paginazione nel sito web. Per isiti web che prevedono richieste successive per ogni pagina, viene inviata una richiestadi memorizzazione per ogni pagina di risultati. Per i siti web che prevedono unapaginazione asincrona, azionata cioè dal ricaricamento solo di una porzione del DOM,lo strumento continua a raccogliere dati fino alla selezione dell’ultima pagina, incorrispondenza della quale viene inviata la richiesta di memorizzazione.

5.3.11 Facilità di adattamento a diversi siti webQuesto requisito, pur non essendo un requisito funzionale, era di vitale importanzaper la buona riuscita del progetto. Infatti il gran numero di competitors nel mercato ela varietà di strutture del codice HTML, stili e presentazioni, rendeva fondamentaletrovare un sistema efficiente per gestire l’estrazione nei diversi ambienti.

La soluzione al problema è stata trovare un set generico di funzioni che potesseroaccomunare, in fase di estrazione, i diversi siti web e le relative diverse strutture efunzioni. Sono state identificati tre tipi di differenze fondamentali:

• strutturali

• funzionali

• di contenuto

Le differenze strutturali possono essere riassumibili in diversi percorsi XPath daattraversare per raggiungere le informazioni da estrarre. Ogni sito web, ad esempio,adotta una diversa struttura HTML per rappresentare gli elementi della pagina deirisultati della ricerca. Anche uno stesso sito cambia, di tanto in tanto, stile e quindi avolte anche struttura del DOM. La soluzione adottata per questo problema è l’utilizzodi funzioni per l’estrazione delle informazioni che utilizzano query XPath diverse perogni sito web. Per rendere efficaci le query XPath è necessario quindi bilanciarespecificità, per non raccogliere dati non richiesti, e generalità, per poter funzionare nelmaggior numero di casi possibili.

Per differenze funzionali si intende il diverso modo di gestire funzioni come l’invio diuna richiesta di ricerca e la paginazione. Alcuni siti web come http://www.expedia.ithanno un funzionamento abbastanza semplice e sia ricerca che paginazione vengonogestite con successive richieste HTTP verso percorsi diversi o con parametri diversi.



Al contrario siti web più dinamici, come ad esempio http://www.venere.com, noneffettuano quasi mai un ricaricamento completo della pagina, ma optano per soluzionipiù innovative, come l’utilizzo di richieste Ajax, che però rendono più complesso illavoro di navigazione del wrapper. La soluzione adottata è stata quella di definire dellefunzioni di navigazione che potessero essere completamente personalizzate dai wrapperspecifici.

Le differenze di contenuto comprendono le differenti nomenclature definite daidiversi siti web, o addirittura dai diversi alberghi, associate ad informazioni seman-ticamente identiche, come le differenti nomenclature assegnate ad un trattamento ditipo pensione completa (e.g. pc, fullboard, fb). La risoluzione di queste differenze èun problema complesso che è stato risolto in prima battuta in fase di ricerca delleconversioni e, in caso di insuccesso, con il successivo intervento manuale dell’operatore,grazie all’inserimento di nuove conversioni.

Ogni wrapper specifico estende quindi una classe Wrapper che include un’implemen-tazione generica delle funzioni per l’estrazione e la navigazione, che vengono ridefinitein caso di bisogno dalle classi che specializzano la super classe.

Questa semplice gerarchia permette di modellare in maniera sufficientemente potentei wrapper che di volta in volta vengono sviluppati da operatori specializzati in gradodi utilizzare strumenti come Firebug, che permettono di elaborare le query XPathper accedere agli elementi contenenti le informazioni da estrarre, o JavaScript, perla ridefinizione parziale di alcune parti del wrapper in casi estremi. Tutte le classicosì generate, condividendo una stessa interfaccia definita in Wrapper, possono essereutilizzate in maniera interscambiabile nell’ambiente di esecuzione.

http://www.venere.com

Capitolo 6

Verifica e validazione

Parte del software, in maniera specifica le classi che implementano la business logic, èstata testata utilizzando PHPUnit, un framework PHP per fare unit testing1. Questasuite di test accerta la correttezza delle funzioni che determinano le fondamenta delsistema. Per ogni classe model.php ne esiste una controparte model_test.php che, perogni metodo della classe method include uno o più test method_test. I test vengonoeseguiti in maniera semi-automatica dalla shell eseguendo il comando phpunit e irisultati possono essere visualizzati a schermo o raccolti in report da allegare comedocumentazione.

Ogni prototipo viene vagliato manualmente dal progettista e dal tutor aziendale percertificarne la correttezza e l’aderenza alle specifiche del committente. Per prototipo siintende una versione non completa, ma utilizzabile, dell’insieme di script estrattore,web application per la comparazione e web service. Per la verifica dei prototipi si usaun server di test, a cui viene associato un database vuoto, e vengono seguite delle fasipredefinite per cercare di coprire un numero sufficiente di casi.

1PHPUnit. url: http://phpunit.de/.

41

http://phpunit.de/

Capitolo 7

Conclusioni

Lo stage svolto presso NetStorming S.r.l., che ha richiesto un totale di 320 ore circa,può essere considerato soddisfacente. Nel tempo a disposizione si è riusciti, partendo daconoscenze di base, a realizzare il progetto nella sua interezza e a fornire una parzialedocumentazione accessoria per l’operatore.

7.1 Greasemonkey oggiAnche se ai giorni nostri alcuni browser web, ad esempio Chrome, includono in manierapredefinita funzionalità per la manipolazione delle pagine web1 simili a quelle offerteda Greasemonkey, l’analisi e la messa in opera dell’estensione ha aperto la strada allosviluppo di una nuova classe di applicazioni e strumenti. Solo Greasemonkey inoltremette a disposizione caratteristiche come la gestione dei menù dell’applicazione e lechiamate remote che bypassano la same-origin policy. C’è da notare che Greasemonkey,pur avendo democratizzato lo sviluppo di estensioni per Firefox, offrendo una sempliceAPI in supporto all’ambiente web, sta perdendo terreno a causa dell’avvento di browserpiù moderni come Chrome e di nuove tecniche per lo sviluppo delle estensioni cherichiedono l’utilizzo di tecnologie già conosciute dagli sviluppatori web: JavaScript,HTML e CSS.

7.2 Raggiungimento degli obiettiviUn aspetto considerato positivo riguarda l’effettiva realizzazione delle funzionalitàrichieste. Non sono state incontrate grosse difficoltà durante l’implementazione eil tempo impiegato a produrle è stato quello preventivato. In questo modo è statopossibile concentrare l’attenzione sull’implementazione di nuovi wrapper per altri sitiweb, il cui sviluppo ha portato alla luce aspetti che non si erano tenuti in considerazionecome, ad esempio, la navigazione asincrona di alcune applicazioni web.

Un altro aspetto interessante del progetto è stato l’utilizzo, per la prima volta inazienda, di strumenti e librerie come Firebug, Greasemonkey e jQuery. Questi software,che attualmente fanno parte dello stack usuale dello sviluppatore web, durante ilperiodo di stage muovevano i primi passi ed il loro impiego in un progetto collaterale

1The Chromium Projects - User Scripts. url: http://www.chromium.org/developers/design-documents/user-scripts.

43

http://www.chromium.org/developers/design-documents/user-scripts


44 CAPITOLO 7. CONCLUSIONI

ne ha permesso l’introduzione graduale nello stack dell’azienda.

Pur avendo introdotto nuovi concetti e nuove pratiche all’interno dell’azienda, lostage non ha raggiunto lo scopo di dotare NetStorming S.r.l. di uno strumento in gradodi essere utilizzato per analizzare i prezzi dei concorrenti. Lo strumento infatti, dopoessere stato utilizzato internamente per un certo periodo, è stato dismesso perchè nonportava il vantaggio competitivo sperato e il suo impiego risultava troppo oneroso.

In conclusione, si può affermare che lo stage è stato svolto con discreto successo edha soddisfatto gli scopi prefissati.

Appendice A

Metodologia Agile

A.1 PrincipiI principi su cui si basa una metodologia leggera che segua i punti indicati dall’1, sonoquattro:

• le persone e le interazioni sono più importanti dei processi e degli strumenti,perché considerati molto più importanti del progetto;

• è più importante avere software funzionante che molta documentazione;

• bisogna collaborare con i clienti al di là del contratto (la collaborazione direttaoffre risultati migliori dei rapporti contrattuali);

• bisogna essere pronti a rispondere ai cambiamenti (quindi il team di sviluppodovrebbe essere autorizzato a suggerire modifiche al progetto in ogni momento).

A.2 MetodologiaIl termine Metodologie Agili fu coniato nel 2001 quando il Manifesto Agile è statoformulato. Nell’ingegneria del software, per metodologia agile (o leggera) si intende unparticolare metodo per lo sviluppo del software che coinvolge quanto più possibile ilcommittente, ottenendo in tal modo una elevata reattività alle sue richieste. Esistonoun certo numero di tali metodologie, tra le quali vanno citate quelle della2, un’organiz-zazione no-profit creata allo scopo di diffonderle.

In senso lato questo termine indica tutte quelle metodologie di sviluppo che rivo-luzionano i vecchi sistemi di ingegneria del software (modello a cascata, modello aspirale, ecc.), basati su una raccolta delle specifiche e su una strutturazione sequenzialedello sviluppo software. L’obiettivo è la piena soddisfazione del cliente e non solol’adempimento di un contratto. L’uso di queste metodologie, inoltre, serve ad abbatterei costi di sviluppo del software.

La gran parte dei metodi agili tentano di ridurre il rischio di fallimento sviluppandoil software in finestre di tempo limitate chiamate iterazioni, che in genere, durano

1Agile Manifesto. url: http://agilemanifesto.org/iso/it/.2Agile Alliance. url: http://www.agilealliance.org/.

45

http://agilemanifesto.org/iso/it/

http://www.agilealliance.org/

46 APPENDICE A. METODOLOGIA AGILE

qualche settimana. Ogni iterazione è un piccolo progetto a sé stante e deve conteneretutto ciò che è necessario per rilasciare un piccolo incremento nelle funzionalità delsoftware: pianificazione (planning), analisi dei requisiti, progetto, implementazione,test e documentazione. Anche se il risultato di ogni singola iterazione non ha sufficientifunzionalità da essere considerato completo deve essere rilasciato e, nel susseguirsi delleiterazioni, deve avvicinarsi sempre di più alle richieste del cliente. Alla fine di ogniiterazione il team deve rivalutare le priorità di progetto.

I metodi agili preferiscono la comunicazione in tempo reale, preferibilmente faccia afaccia, a quella scritta (documentazione). Il team agile è composto da tutte le personenecessarie per terminare il progetto software. Come minimo il team deve includerei programmatori ed i loro clienti (con clienti si intendono le persone che definisconocome il prodotto dovrà essere fatto: possono essere dei product manager, dei businessanalysts, o veramente dei clienti).

A.3 PraticheLe singole pratiche applicabili all’interno di una metodologia leggera sono decine edipendono dalle necessità dell’azienda e dall’approccio del project manager. Nella sceltabisogna tenere conto delle caratteristiche di ogni pratica per i benefici e le conseguenzeche comporta. Le pratiche più diffuse tra cui scegliere sono simili fra di loro e possonoessere raggruppate in categorie:

AutomazioneSe l’obiettivo delle metodologie agili è concentrarsi sulla programmazione senza de-dicarsi alle attività collaterali, allora possono essere eliminate o automatizzate; laseconda soluzione è migliore perché si può ottenere eliminando la documentazionee aumentando il testing, ma non si possono eliminare entrambe.

Comunicazione strettaQuesto è l’unico vero aspetto nodale che renda leggera una metodologia. Percomunicazione diretta si intende la comunicazione interpersonale, fra tutti gliattori del progetto, cliente compreso. Ciò serve ad avere una buona analisi deirequisiti ed una proficua collaborazione fra programmatori.

Coinvolgimento del clienteIl coinvolgimento del cliente è qui indicato singolarmente perché ci sono differentigradi di coinvolgimento possibili; il coinvolgimento può essere totale dove il clientepartecipa persino alle riunioni settimanali dei programmatori; in altri casi, ilcliente è coinvolto in una prima fase di progettazione e poi non più; in altriancora il cliente partecipa indirettamente e viene usato come test della versionerilasciata.

Progettazione e documentazionePensare che le metodologie leggere eliminino la progettazione e la documenta-zione è un errore; quanta progettazione fare e quanta documentazione produrre,escludendo i casi estremi, è una scelta lasciata a chi gestisce il progetto e spessoi teorici dell’Agile Alliance avvisano che è un errore trascurare o addiritturaomettere queste due fasi.

Consegne frequentiEffettuare rilasci frequenti di versioni intermedie del software permette di ottenere

A.3. PRATICHE 47

più risultati: si ricomincia l’iterazione avendo già a disposizione un blocco dicodice funzionante in tutti i suoi aspetti, si offre al cliente “qualcosa con cuilavorare”, si usa il cliente come se fosse un test visto che utilizzerà il software eriscontrerà eventuali anomalie, si ottengono dal cliente informazioni più precisesui requisiti che probabilmente non sarebbe riuscito ad esprimere.

GerarchiaLa scelta di creare una struttura gerarchica all’interno del team di sviluppodipende molto dall’approccio del project manager; se si decide per una strutturagerarchica ad albero e frammentata si ottiene la possibilità di gestire un numeromolto alto di programmatori e di lavorare a diversi aspetti del progetto paral-lelamente; se si decide per una totale assenza di gerarchia si avrà un team disviluppo molto compatto e motivato, ma necessariamente piccolo in termini dinumero di programmatori.

Pair programmingLo sviluppo viene fatto da coppie di programmatori che si alternano alla tastiera.

RefactoringLa ristrutturazione di parti di codice mantenendone invariato l’aspetto e ilcomportamento esterno.

Miglioramento della conoscenzaNata con l’avvento della programmazione Object-Oriented, non è altro che lapresa di coscienza della produzione di conoscenza che si fa in un’azienda manmano che si produce codice; questa conoscenza prodotta non deve andare perdutaed è per far ciò che si sfruttano spesso le altre pratiche, come la comunicazionestretta o la condivisione della proprietà del codice.

RetroingegneriaOssia ottenere, la documentazione a partire dal codice già prodotto; è una dellepratiche più diffuse e più controverse, diffusa perché permette un guadagnoenorme in termini di tempo, ma controversa perché spesso la documentazioneprodotta è inutilizzabile.

SemplicitàUno dei punti chiave delle metodologie leggere, è la semplicità; semplicità nelcodice, nella documentazione, nella progettazione, nella modellazione. I risultaticosì ottenuti sono una migliore leggibilità dell’intero progetto.

Formazione di una squadra e Proprietà del codiceLa formazione del team di sviluppo è condizionata dalla scelta sulla gerarchiainterna, ma segue regole. La scelta dei membri del team è condizionata anchealla scelta della proprietà del codice, che può essere individuale o collettiva; nelprimo caso la responsabilità sullo sviluppo è individuale, nel secondo dipende datutto il team e quindi dal project manager.

TestPratica diffusissima anche prima della nascita delle metodologie leggere, haprodotto una letteratura vastissima ed una serie di approcci differenti come ilRapid Testing o il Pair Testing; nell’ambito delle metodologie leggere vengonospesso utilizzati insieme tre tipi di test differenti: i test funzionali, i test d’unità,e i test indiretti effettuati inconsciamente dal cliente ogni volta che gli si consegnauna versione.

48 APPENDICE A. METODOLOGIA AGILE

Controllo della versioneUna delle conseguenze dirette dell’iterazione nella produzione è la necessità diintrodurre un modello, per il controllo delle versioni del software prodotto erilasciato.

Glossario

API in informatica con il termine Application Programming Interface (API) (ing.interfaccia di programmazione di un’applicazione) si indica ogni insieme diprocedure disponibili al programmatore, di solito raggruppate a formare un setdi strumenti specifici per l’espletamento di un determinato compito all’interno diun certo programma. La finalità è ottenere un’astrazione, di solito tra l’hardwaree il programmatore o tra software a basso e quello ad alto livello semplificandocosì il lavoro di programmazione. 51

CSS è un linguaggio usato per definire la formattazione e lo stile di documenti HTML,XHTML e XML ad esempio nelle pagine web. L’introduzione del CSS, all’iniziodegli anni novanta, si è resa necessaria per separare il contenuto dallo stile equindi promuovere buone pratiche che avrebbero portato al riuso di codice eduna sua più facile manutenibilità. 51

CSV comma-separated values (CSV) è un formato di file di testo utilizzato perl’importazione ed esportazione (ad esempio da fogli elettronici o database) diuna tabella di dati. 51

design pattern nell’ingegneria del software, un design pattern (schema di proget-tazione) può essere definito una soluzione progettuale generale a un problemaricorrente. Esso non è una libreria o un componente di software riusabile, quantopiuttosto una descrizione o un modello da applicare per risolvere un problemache può presentarsi in diverse situazioni durante la progettazione e lo sviluppodel software. 25

DOM il Document Object Model (DOM) è lo standard ufficiale del W3C per la rappre-sentazione di documenti strutturati in maniera indipendente dalla piattaforma edal linguaggio. 51

DRY un principio di progettazione e sviluppo secondo cui andrebbe evitata ogni formadi ripetizione e ridondanza logica nell’implementazione di un sistema software. Ilprincipio venne inizialmente enunciato da Andy Hunt e Dave Thomas nel lorolibro The Pragmatic Programmer: «Ogni elemento di conoscenza deve avere unasola, non ambigua, autorevole rappresentazione all’interno di un sistema». 51

framework nella produzione del software, il framework è una struttura di supportosu cui un software può essere organizzato e progettato. Alla base c’è sempre unaserie di librerie di codice utilizzabili con uno o più linguaggi di programmazione,spesso corredate da una serie di strumenti di supporto allo sviluppo del software,come ad esempio un debugger, o altri strumenti ideati per aumentare la velocitàdi sviluppo del prodotto finito. 8

49

50 Glossario

GUI in informatica è un tipo di interfaccia che permette agli utenti di interagire condispositivi elettronici per mezzo di elementi grafici ed icone in opposizione adinterfacce basate sul testo. 51

HTML è un linguaggio di markup che i browser usano per interpretare e comporre te-sto, immagini e altri tipi di contenuto in pagine web. L’HTML è stato sviluppatoverso la fine degli anni ottanta da Tim Berners-Lee al CERN di Ginevra assiemeal protocollo HTTP che supporta il trasferimento di documenti in tale formato.Attualmente i documenti HTML sono in grado di incorporare molte tecnolo-gie, che offrono la possibilità di aggiungere al documento ipertestuale controllipiù sofisticati sulla resa grafica, interazioni dinamiche con l’utente, animazioniinterattive e contenuti multimediali. 51

HTTP è un protocollo applicativo usato come principale sistema per la trasmissioned’informazioni sul Web. L’ipertesto è un testo strutturato che usa dei collegamentilogici (collegamenti ipertestuali o hyperlinks) tra nodi contenenti testo. HTTP èil protocollo per scambiare o trasferire ipertesto in Internet. 51

prototipo sottoinsieme dell’applicazione utilizzato per verificare la correttezza di unalgoritmo o la comprensione da parte dell’utente (usabilità). Esistono diversiprototipi, ci sono quelli usa e getta, utilizzati solo per effettuare un particolaretipo di test e poi rilasciati, quelli evolutivi costituiti dall’applicazione stessa nonancora completata. 23

UML in ingegneria del software Unified Modeling Language (UML) (ing. linguaggiodi modellazione unificato) è un linguaggio di modellazione e specifica basatosul paradigma object-oriented. L’UML svolge un’importantissima funzione di“lingua franca” nella comunità della progettazione e programmazione a oggetti.Gran parte della letteratura di settore usa tale linguaggio per descrivere soluzionianalitiche e progettuali in modo sintetico e comprensibile a un vasto pubblico. 51

XML eXtensible Markup Language (XML) è un linguaggio di markup, ovvero unlinguaggio marcatore basato su un meccanismo sintattico che consente di definiree controllare il significato degli elementi contenuti in un documento o in un testo.51

Acronimi e abbreviazioni

API Application Programming Interface. 8–10, 26, 27, 30, 43, 49

CSS Cascading Style Sheets. 11, 22, 23, 28, 30, 43, 49

CSV Comma-Separated Values. 27, 49

DOM Document Object Model. 4, 8, 9, 11, 22, 23, 38, 49

DRY Don’t Repeat Yourself. 28, 49

GUI Graphical User Interface. 9, 31, 50

HTML HyperText Markup Language. 4, 6, 7, 9, 11, 22, 28–30, 38, 43, 50

HTTP HyperText Transfer Protocol. 14, 26, 27, 29, 37, 38, 50

UML Unified Modeling Language. 50

XML eXtensible Markup Language. 3, 4, 6, 7, 14, 18, 22, 23, 26, 27, 29, 35, 50

51

Bibliografia

Riferimenti bibliografici[3] V. Anupam et al. «Automating web navigation with the WebVCR». In: Computer

Networks 33 (1-6 2000), pp. 503–517 (cit. a p. 4).

[4] R. Baumgartner, S. Flesca e G. Gottlob. «Visual web information extractionwith Lixto». In: VLDB (2001) (cit. a p. 4).

[6] V. Crescenzi, G. Mecca e P. Merialdo. «RoadRunner: Towards automatic dataextraction from large Web sites». In: VLDB (2001) (cit. a p. 4).

[7] O. Etzioni et al. «Web-scale information extraction in KnowItAll: (preliminaryresults)». In: WWW (2004) (cit. a p. 10).

[9] W. Gatterbauer et al. «Towards domain-independent information extractionfrom web tables». In: WWW (2007) (cit. a p. 11).

[10] G. Gottlob e C. Koch. «A formal comparison of visual web wrapper generators».In: SOFSEM (2006) (cit. a p. 5).

[11] G. Gottlob e C. Koch. «Monadic datalog and the expressive power of languagesfor web information extraction». In: JACM 51 (1 2002), pp. 74–113 (cit. a p. 5).

[16] N. Kushmerick, D. S. Weld e R.B. Doorenbos. «Wrapper induction for informationextraction». In: IJCAI (1997) (cit. a p. 4).

[17] A.H.F. Laender, B.A. Ribeiro-Neto e A.S. da Silva. «DEByE - Data extractionby example». In: Data and Knowledge Engineering 40 (2 2000), pp. 121–154(cit. a p. 4).

[18] B. Liu, R.L. Grossman e Y. Zhai. «Mining web pages for data records». In: IEEEIntelligent Systems 19 (6 2004), pp. 49–55 (cit. a p. 10).

[19] L. Liu, C. Pu e W. Han. «XWRAP: An XML-enabled wrapper constructionsystem for web information sources». In: ICDE (2000) (cit. a p. 4).

[21] I. Muslea, S. Minton e C. Knoblock. «A hierarchical approach to wrapperinduction». In: Autonomous Agents and Multi-Agent Systems 4 (1/2 2001),pp. 93–114 (cit. alle pp. 4, 5).

[22] A. Pan et al. «The Denodo data integration platform». In: VLDB (2002) (cit. ap. 4).

53

54 BIBLIOGRAFIA

[25] A. Sahuguet e F. Azavant. «Building intelligent web applications using lightweightwrappers». In: Data and Knowledge Engineering 36 (3 2001), pp. 283–316 (cit. ap. 4).

Siti Web consultati[1] Agile Alliance. url: http://www.agilealliance.org/ (cit. a p. 45).

[2] Agile Manifesto. url: http://agilemanifesto.org/iso/it/ (cit. alle pp. 23,45).

[5] Connotate. url: http://www.connotate.com/ (cit. a p. 4).

[8] Jesse James Garrett. Ajax: A New Approach to Web Applications. 2005. url:http://www.adaptivepath.com/ideas/ajax-new-approach-web-applications/(cit. a p. 29).

[12] Greasemonkey manual: Installing scripts. url: http://wiki.greasespot.net/Greasemonkey_Manual:Installing_Scripts (cit. a p. 31).

[13] GreaseSpot Wiki: User script. url: http://wiki.greasespot.net/User_script (cit. a p. 31).

[14] jQuery Learning Center: How to Create a Basic Plugin. url: http://learn.jquery.com/plugins/basic-plugin-creation/ (cit. a p. 30).

[15] Kapow Technologies. url: http://www.kapowtech.com/ (cit. a p. 4).

[20] Lixto Software Company. url: http://www.lixto.com/ (cit. a p. 4).

[23] PHPUnit. url: http://phpunit.de/ (cit. a p. 41).

[24] QL2 Software. url: http://www.ql2.com/ (cit. a p. 4).

[26] Smarty Documentation - What is Smarty? url: http://www.smarty.net/docs/en/what.is.smarty.tpl (cit. a p. 28).

[27] The Chromium Projects - User Scripts. url: http://www.chromium.org/developers/design-documents/user-scripts (cit. a p. 43).

http://www.agilealliance.org/

http://agilemanifesto.org/iso/it/

http://www.connotate.com/








http://www.kapowtech.com/

http://www.lixto.com/

http://phpunit.de/

http://www.ql2.com/





Documents

Strumento per l'estrazione semi-automatica e il confronto di dati da pagine web