ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB

Transcript

1 UNIVERSITÀ DEGLI STUDI DI UDINE Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea Specialistica in Informatica Tesi di Laurea ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Relatore: Prof. SERAFINI PAOLO Laureando: MARASPIN STEFANO ANNO ACCADEMICO

2 ii

3 iii Ai miei genitori, ai miei nonni, a Desy, Elvira e Valentina.

4 iv

5 Introduzione Il presente elaborato raccoglie e documenta i risultati del lavoro svolto dallo scrivente dall'ottobre 2007 al marzo 2008 e verte sulla pianificazione di itinerari, tematica verso la quale lo stesso stava già da tempo rivolgendo la propria attenzione. Durante la ricerca di mezzi di trasporto e strutture ricettive per viaggi che lo hanno riguardato, egli ha infatti avuto modo di constatare la totale assenza di sistemi in grado di contemplare qualcosa che potesse essere più di un semplice spostamento o pernottamento, tenendo in considerazione l'eventuale flessibilità di cui il viaggiatore potesse godere e di effettuare le proprie ricerche di conseguenza. Tutti i siti di agenzie di viaggio online e fornitori di servizi legati al turismo consultati, presuppongono infatti ancora oggi che l'utente abbia già in mente date precise per spostamenti e pernottamenti ed offrono quindi strumenti di ricerca assolutamente rigidi, specifici e soprattutto indipendenti tra loro. Conseguenza diretta di tali caratteristiche, il fatto che la ricerca delle tariffe effettivamente più vantaggiose per l'utente, quando questi ha pianificato un certo itinerario da seguire, ma ha anche a disposizione una certa flessibilità nelle date di partenza e permanenza in ciascuna delle mete visitate, richiede un cospicuo numero di consultazioni di diversi sistemi, oltre che confronti tra possibili soluzioni in uno spazio di ricerca che cresce in maniera esponenziale sul numero delle mete considerate e sulla flessibilità disponibile. Anche dal punto di vista accademico, per quanto riguarda il settore dei viaggi, è possibile riscontrare in letteratura un cospicuo numero di articoli riguardanti problemi di VRT, Yield Management ed altri problemi di ottimizzazione, cui scopo è in genere la massimizzazione dei profitti (o minimizzazione dei costi) per chi fornisce i servizi; assolutamente scarno si presenta invece il panorama delle pubblicazioni per ciò che concerne l'ottimizzazione dal punto di vista dell'utente finale, ovvero del viaggiatore. Ecco dunque che lo scopo del presente lavoro è quello di proporre metodologie, algoritmi e relative implementazioni (in forma prototipizzata), che possano essere destinati a generici utenti, per la pianificazione dei propri viaggi. Il lavoro si articola in cinque capitoli: nel primo vengono introdotti gli attuali sistemi per la ricerca di tariffe di servizi legati al turismo ed ai viaggi; nel secondo viene introdotto un primo modello di pianificatore di itinerari, basato su programmazione dinamica; nel terzo viene presentata un'implementazione di tale modello; nel quarto questo viene esteso, dando all'utente la possibilità di considerare itinerari ottenuti tramite permutazione dell'ordine di visita delle proprie mete; nel quinto capitolo vengono infine riportate alcune considerazioni sulla complessità della determinazione delle tariffe aeree e sulle ripercussioni che tale complessità comporta alla pianificazione di itinerari. v

6 vi

7 Indice INTRODUZIONE...V INDICE...VII ELENCO DELLE FIGURE...IX ELENCO DELLE TABELLE...X 1 ATTUALI SISTEMI AUTOMATIZZATI PER LA PIANIFICAZIONE E PRENOTAZIONE DI VIAGGI Travel Technology Computer Reservations System Global Distribution Systems (GDS) Evoluzione del mercato dei viaggi Risorse su World Wide Web La situazione attuale UN PRIMO MODELLO Altri Lavori Le misure del problema L'idea di base Richiami di Programmazione Dinamica L'algoritmo Ottimalità con Molti Obiettivi Correttezza e complessità del modello proposto IMPLEMENTAZIONE ,1 Architettura del prototipo...39 vii

8 3.2 Interazione con l'utente Strutture dati Inizializzazione delle variabili relative a mete e preferenze Implementazione Algoritmica Fetching dei dati Combinazione Convessa Inserimento dei Nodi Presentazione dei Risultati Estensioni del modello Prestazioni del sistema Qualità delle Soluzioni Fornite IL SECONDO MODELLO L'idea Algoritmo Gestire un maggior numero di mete Impegni nel viaggio Considerazioni su correttezza e complessità Prestazioni del sistema Qualità delle Soluzioni Fornite DETERMINAZIONE DEI COSTI DELLE TRATTE AEREE Yield Management Voli, Fares, Fare Components, Regole e Priceable Units Complessità nella Determinazione delle Fare Altre problematiche Conseguenze sui modelli proposti CONCLUSIONI A SCENARIO SU CUI SONO STATI EFFETTUATI I TEST B ESTRATTI SIGNIFICATIVI CODICE SORGENTE BLIOGRAFIA SITI WEB CONSULTATI viii

9 Elenco delle Figure Figura Pag. Fig. 1-1 Distribuzione globale dei più importanti sistemi GDS. 6 Fig. 1-2 Sequenza dei passaggi per la prenotazione di un viaggio nel modello classico 12 Fig. 2-1 Esempio di grafo impiegato nella modellazione 24 Fig. 2-2 Punti di partenza per la costruzione del grafo 28 Fig. 2-3 Punto di arrivo nella costruzione del grafo 29 Fig. 2-4 Eventi Ridondanti 30 Fig. 2-5 Inconveniente derivato da cattiva sincronizzazione di eventi 31 Fig. 2-6 Problema grave derivato da cattiva sincronizzazione di eventi 32 Fig. 2-7 Combinazione convessa 36 Fig. 3-1 Architettura del sistema 39 Fig. 3-2 Use Case 40 Fig. 3-3 Diagramma di sequenza interazione utente 41 Fig. 3-4 Interfaccia inserimento mete 42 Fig. 3-5 Interfaccia inserimento opzioni di viaggio 43 Fig. 3-6 Interfaccia selezione strutture alberghiere 45 Fig. 3-7 Schermata di notifica possibili attese nella presentazione dei risultati 47 Fig. 3-8 Schermata di presentazione dell'output 48 Fig. 3-9 Rappresentazione array associativi 49 Fig Rappresentazione clustered index 63 Fig Rappresentazione non-clustered index 64 Fig Applicazione Programmazione Dinamica 69 Fig Sincronizzazione degli eventi 70 Fig. 4-1 Cambiamento di costi al variare dell'itinerario seguito 80 Fig. 5-1 Selezione fare compatibili 99 Fig. 5-2 Combinazione Price Units 100 Fig. A1-1 Contesto Geografico di Riferimento 106 Fig. A1-2 Struttura del Database 110 ix

10 Elenco delle Tabelle Tabella Pag. Tab. 1-1 Quote di mercato dei più importanti sistemi GDS 5 Tab. 1-2 Sistemi web attraverso i quali i più importanti GDS offrono i propri servizi 7 Tab. 1-3 Portali attraverso i quali i più importanti GDS offrono i propri servizi 14 Tab. 1-4 Maggiori portali dedicati ai viaggi e sistemi di prenotazione consultati 15 Tab. 2-1 Attributi dei Nodi 27 Tab. 3-1 Tempi di carico e scarico da mezzi di trasporto 60 Tab. 3-2 Attributi di Ciascun Nodo/Evento 68 Tab. 3-3 Prestazioni del sistema 74 Tab. 3-4 Prestazioni del sistema senza indici 74 Tab. 4-1 Prestazioni del secondo modello 86 Tab. 5-1 Alcune grandezze che intervengono nell'ambito del RM nel settore dei viaggi 90 x

11 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Capitolo 1 ATTUALI SISTEMI AUTOMATIZZATI PER LA PIANIFICAZIONE E PRENOTAZIONE DI VIAGGI Nel presente capitolo saranno trattati gli argomenti in qualche modo propedeutici alla comprensione dei risultati prodotti dallo scrivente nel complesso di questo elaborato. Verranno introdotte le le tecnologie attualmente impiegate per la selezione e la prenotazione di tratte aeree, navali, ferroviarie o stradali su mezzi pubblici, oltre che di alloggio, noleggio veicoli e altri servizi direttamente o indirettamente collegati con l'industria dei viaggi e del turismo. Tali nozioni saranno precedute o accompagnate, dove opportuno, da brevi note sulle vicende storiche che hanno guidato il processo di sviluppo dell'automatizzazione e informatizzazione del settore. Il capitolo si concluderà quindi con un'analisi di quelle che possono essere considerate le lacune degli attuali sistemi di prenotazione. 1.1 Travel Technology L'espressione travel technology viene generalmente impiegata per indicare quelle applicazioni dell'information Technology (IT) o dell'information and Communications Technology (ICT), in qualche modo pertinenti al turismo, alla pianificazione di itinerari o alla gestione delle prenotazioni delle strutture ricettive. Il termine comparve in principio associato ai sistemi di prenotazione delle compagnie aeree (CRS o computer reservations system), a dire il vero, in maniera così congiunta che non vi era una netta distinzione tra le due espressioni nel loro utilizzo. Tali tecnologie trovavano impiego per la gestione delle interazioni tra i sistemi di prenotazione delle diverse compagnie aeree e le agenzie di viaggio ad esse collegate, attraverso reti private a commutazione di pacchetto (X25), ancora prima della diffusione di Internet. La diffusione del World Wide Web degli ultimi decenni, ma soprattutto nel periodo del cosiddetto dot-com boom ( ) ed il conseguente cambiamento dei modelli di business associati ai contesti di pianificazione turistica hanno fatto si che il termine assumesse un significato più ampio, associandolo di fatto anche a tutte quelle soluzioni automatizzate a supporto della pianificazione di itinerari ed in particolare, all'industria delle prenotazioni alberghiere e dei servizi, associati in vario modo al mondo del turismo (traghetti, navi, assicurazioni, auto a noleggio, etc). 1

12 ATTUALI SISTEMI AUTOMATIZZATI PER LA PIANIFICAZIONE E PRENOTAZIONE DI VIAGGI Il termine ha inoltre visto accrescere ulteriormente il proprio spettro semantico anche di recente, essendo impiegato sempre più anche per intendere un crescente numero di applicazioni, sempre correlate in modo più o meno prossimo al settore turistico, ma non sempre in regime di stretta pertinenza con il significato originale del termine. Vengono infatti attualmente contemplate dal termine sia le applicazioni per il dynamic packaging, sia i dispositivi elettronici in grado di aiutare un utente durante un viaggio (dispositivi basati su GPS, guide multimediali portatili di vario genere), sia nel senso più lato del termine, anche i passaporti biometrici o semplicemente i dispositivi che sono in grado di essere portati con se dal turista nel proprio viaggio (portatili ultraleggeri e adatti a diversi voltaggi, connessioni Internet satellitari). Sinonimi di travel technology sono spesso anche tourism technology (cui è comunemente associato il significato più lato del termine) e hospitality automation (cui sono comunemente associati quegli aspetti della travel technology riferiti alla gestione delle prenotazioni di strutture ricettive). Nel contesto del presente documento il termine travel technology sarà sempre impiegato nel proprio senso stretto, ovvero riconducibile unicamente ai sistemi di pianificazione degli itinerari e gestione delle prenotazioni. [Wiki ] 1.2 Computer Reservation System I Computer Reservations System (CRS) sono sistemi automatizzati per la memorizzazione di informazioni (prenotazioni, in genere) e l'effettuazione di transazioni di vario tipo relative a viaggi. Originariamente progettati, implementati e gestiti unicamente da compagnie aeree, il loro utilizzo fu in seguito esteso anche alle agenzie di viaggio, che costituivano così un canale di vendita indiretto aggiuntivo per le tratte aeree. Agli albori dell'aviazione commerciale (prima metà del secolo scorso) il numero di passeggeri, così come quello delle tratte aeree era piuttosto esiguo; queste ultime erano regolate nel Nord America solamente dal Civil Aeronautics Board che pubblicava la cosiddetta Official Airline Guide, dalla quale agenti di viaggio e singoli viaggiatori potevano ricavare le informazioni di loro interesse (orari, costi) e costruire il proprio itinerario di conseguenza. Per prenotare i voli l'utente telefonava o inviava via telex la propria richiesta alla compagnia aerea, che a questo punto registrava la cosa. E' ovvio come l'accrescere delle tratte disponibili e del flusso di passeggeri abbia immediatamente reso tale processo lento e costoso per le compagnie aeree. E' così che American Airlines inizia gli studi e le sperimentazioni su dispositivi elettronici in grado di automatizzare la gestione delle prenotazioni e nel 1946 installa il primo sistema di prenotazione elettronica sperimentale, denominato Electromechanical Reservisor e subito dopo Magnetronic Reservisor, in seguito all'introduzione di meccanismi di memorizzazione temporanea basata su supporti magnetici. Il sistema si rivelò piuttosto efficace e la sperimentazione venne estesa ad altre compagnie aeree, oltre che agli Sheraton Hotels e persino alla Goodyear per la gestione del proprio inventario. Tali sistemi tuttavia risolvevano i problemi solo in parte, dato che comunque un intervento umano costante era richiesto per mediare tra le richieste provenienti per via telefonica e l'interazione pratica con questi sistemi; gli agenti di viaggio e a maggior ragione gli utenti finali non erano assolutamente in grado di interagire con tali sistemi direttamente, mentre 2

13 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB chi si occupava di prenotazioni per l'american Airlines doveva comunque disporre di personale tecnico specializzato in grado di interagire con il mezzo per lui. E' nel 1953 che Trans-Canada Airlines (TCA) per prima inizia la sperimentazione di sistemi computerizzati autonomi per la prenotazione, basata su terminali remoti, appoggiandosi al Manchester Mark I presso l'university of Toronto per effettuare tutti i test del caso. Il sistema poteva sicuramente considerarsi un successo concettuale e potenzialmente anche pratico, non fosse stato per i problemi di I/O e soprattutto per l'instabilità delle valvole del Mark I. Ferranti Canada intervenne nell'ambizioso progetto, suggerendo la sostituzione del Mark-I con un computer a transistor e I/O basato su cards; il sistema che ne risultò, chiamato ReserVec, iniziò le operazioni nel 1962 e sostituì gli altri mezzi di prenotazione della TCA nel gennaio I terminali furono dislocati in tutti gli uffici abilitati all'emissione di biglietti da parte di TCA e le prenotazioni potevano avvenire nel giro di pochi secondi, senza la necessità di intervento umano sull'elaboratore centrale. Sempre nel 1953, il CEO di American Airlines, C. R. Smith incontrò R. Blair Smith, un funzionario commerciale senior dell'ibm e la propria idea originale di un sistema di prenotazione automatica si concretizzo nel 1959 in un progetto noto con il nome di Semi- Automatic Business Research Environment, o semplicemente SABRE, progetto che venne di fatto messo in produzione nell'anno seguente, diventando il più grande sistema di calcolo non governativo del mondo; era basato su due mainframe IBM 7090 in un datacentre dislocato a Briarcliff Manor, nello stato di New York. Il costo dello stesso era stato di quaranta milioni di dollari di allora. Dal punto di vista pratico, l'innovazione principale del sistema Sabre era l'abilità di gestire correttamente in tempo reale e remotamente il carico degli aereovelivoli. Nel frattempo, anche le altre compagnie aeree non erano rimaste passive di fronte a queste innovazioni e avevano avviato simili progetti per conto loro: nel 1968 ad esempio Delta Air Lines diede vita al proprio sistema DATAS; nel 1971 fu la volta di United Airlines e TWA con i sistemi rispettivamente Apollo e PARS. Questi sistemi erano oramai generalmente noti con il nome di Airline Reservation System (ARS) e gli agenti di viaggio, venuti a conoscenza di tali tecnologie, iniziavano a reclamare sistemi che potessero automatizzare e velocizzare anche i loro processi, richiedendo in sostanza accessi diretti su tali sistemi. Nel 1974, il presidente di American Airlines, Robert Crandall spaventato dall'eccesso di potere che poteva essere conferito alle agenzie di viaggio qualora queste richieste fossero state accolte, propose alle compagnie aeree di creare un loro sistema unificato, basato su una rete indipendente con accesso consentito a tutte le agenzie di viaggio, ma senza offrire a queste il controllo completo sullo strumento. Preoccupate di perdere il controllo delle proprie prenotazioni e senza alcuna garanzia antitrust (fosse andato in porto il progetto di Crandall, American Airlines avrebbe ottenuto una posizione di assoluto predominio), le compagnie aeree puntarono invece sullo sviluppo indipendente dei propri ARS, iniziando ad accogliere peraltro anche le richieste di interazione diretta da parte delle agenzie di viaggio. Nel 1976, la United Airlines iniziò l'installazione nelle agenzie del proprio software Apollo, immediatamente seguita da American Airlines. [Das 2002] Nel periodo in cui il mercato dell'aria negli Stati Uniti veniva liberalizzato (1978), l'importanza di avere un buon CRS si rivelava quantomai importante, tanto che il CEO di 3

14 ATTUALI SISTEMI AUTOMATIZZATI PER LA PIANIFICAZIONE E PRENOTAZIONE DI VIAGGI Texas Air Frank Lorenzo acquistò la malandata Eastern Air Lines specificatamente per ottenere il controllo sul loro CRS SystemOne. [WebWatch 2002] Così come l'invenzione dei sistemi ARS aveva inizialmente automatizzato la gestione del controllo dei posti a sedere per una specifica compagnia aerea, i sistemi CRS avevano ora iniziato ad estendere tale controllo ai velivoli di tutte le compagnie, permettendo l'interazione diretta tra gli agenti di viaggio e i sistemi di prenotazione di ciascuna compagnia, eliminando la necessità di effettuare molteplici telefonate per verificare la disponibilità di posti ed effettuare prenotazioni. Ciò permise agli agenti di viaggio di dedicare più tempo all'assistenza del cliente e, al tempo stesso alle compagnie aeree, di risparmiare ingenti quantità di denaro (milioni di dollari dell'epoca) grazie all'outsourcing pressoché totale dell'attività di prenotazione. 1.3 Global Distribution System (GDS) Il successo dei sistemi ARS e CRS diventò sempre più evidente e, nella seconda metà degli anni '80, il ROI annuale di Apollo raggiungeva il 70%, mentre per Sabre superava addirittura il 100%. [WebWatch 2002] Fu più o meno in questo periodo che anche le compagnie di bandiera europea, oltre che gli altri colossi del Nord America iniziarono i loro investimenti in questo campo; nel 1987, un consorzio guidato da Air France e Lufthansa sviluppò Amadeus, un sistema basato su SystemOne. Nel 1990 fu la volta di Delta, Northwest Airlines, and Trans World Airlines, le quali diedero alla luce Worldspan; nel 1993, infine, un altro consorzio che includeva British Airways, KLM e United Airlines formava Galileo International, basando il proprio sistema sull'architettura del precedente Apollo. In Asia, intanto, a causa di significative diversità linguistiche, culturali e soprattutto alfabetiche, i sistemi CRS rimanevano di dimensioni ridotte e segmentati all'interno di ciascuna nazione, con l'eccezione di Fantasia, ma soprattutto di Abacus, consorzi che comprendevano diverse compagnie del sud-est. Numerosi sistemi minori inoltre venivano alla luce, specializzandosi in nicchie geografiche o linguistiche, escluse dagli altri sistemi precedentemente introdotti; è doveroso citare ad esempio: SITA (Sahara), Infini (Giappone), Axess (Giappone), Gets (Africa) e Topas (Korea). [Farhoomand & Lee 1998] Mentre tali sistemi rimanevano confinati nelle loro zone d'origine, i quattro grandi sistemi iniziavano ad espandere il loro ambito, sia a livello territoriale, sia a livello di servizi offerti. Il successo globale di tali sistemi comportò infatti ulteriori investimenti con il fine ultimo di far risultare ciascun sistema in grado di gestire autonomamente le prenotazioni a livello globale non solo per una moltitudine di compagnie aeree (quindi non necessariamente solo quelle in controllo dello strumento), ma anche una serie di fornitori di servizi accessori comunque legati all'industria del turismo (alberghi, compagnie di crociera, compagnie di noleggio auto, etc). Entro la fine degli anni '90 la maggior parte dei sistemi CRS era quindi diventata GDS (Global Distribution System), impiegati dagli agenti di viaggio per la visualizzazione e la prenotazione in tempo reale ti tratte aeree, crociere, alloggi, noleggi auto, etc nonché per l'emissione dei biglietti. Delle evoluzioni dei primi sistemi GDS, i quattro principali di allora, rimangono ad oggi i 4

15 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB più diffusi ed utilizzati, come è possibile evincere dalla seguente tabella riassuntiva: Tab. 1-1 Quote di mercato dei più importanti sistemi GDS Sistema Market Share Amadeus 26 % Sabre 24% Galileo 22% Worldspan 14% Fonte: Sintesi propria su dati [Sparolin 2005], [WebWatch 2002] e [Wiki ] Dei quattro, sulla scala globale Amadeus risulta notevolmente più diffuso dei concorrenti, soprattutto se si considera il fatto che è attualmente fornitore tecnologico di Travelsky, sistema GDS nato specificatamente per il mercato cinese. La situazione asiatica è, come si può evincere dal diagramma (rappresentato in Fig. 1-1 a pagina 6), la più complessa e variegata, soprattutto a causa delle diversità linguistiche ed alfabetiche di alcuni importanti paesi dell'area (Cina). [Sparolin 2005] Anche nel Nord America tuttavia la stabile situazione attuale, con i quattro grandi GDS dominatori del mercato sembra destinata a cambiare in un futuro non necessariamente remoto, soprattutto in virtù del fatto che emergenti sistemi, basati su nuove tecnologie stanno per affacciarsi sul mercato (Triton Distribution Systems, ITA Software, G2 Switchworks, Farelogix). [Wiki ] Da notare inoltre l'acquisizione di Worldspan da parte di Travelport (già in controllo di Galileo) nel dicembre 2006, con l'ovvia acquisizione di una comunque importante fetta di mercato globale. 5

16 ATTUALI SISTEMI AUTOMATIZZATI PER LA PIANIFICAZIONE E PRENOTAZIONE DI VIAGGI Fig. 1-1 distribuzione globale dei più importanti sistemi GDS. Fonte: Rielaborazione da [Sparolin 2005] Le problematiche dei GDS I quattro grandi GDS sono evoluzioni di sistemi progettati un tempo per sostenere moli di dati che erano frazioni rispetto alle attuali e quindi questi iniziano a scontrarsi con problematiche derivanti dalla scarsa scalabilità permessa, in confronto con la rapidissima e costante crescita dei numeri di mercato. Le loro architetture sono infatti ancora basate su mainframe, estremamente costosi da mantenere ed aggiornare, ma anche non sempre all'altezza di gestire le enormi moli di dati globalmente e quotidianamente prodotti. Ecco quindi che negli ultimi anni i quattro grandi GDS hanno iniziato a migrare i loro processi, dai grandi mainframe a piattaforme service oriented (SOA), così da riuscire a scalare agilmente i propri processi per riuscire a gestire un sempre crescente numero di prenotazioni contenendo i costi. Senza dubbio la diffusione del World Wide Web ha portato significativi incrementi nelle moli di dati scambiati con tali sistemi, anche perché è ora possibile per l'utente finale, direttamente, riuscire ad ottenere informazioni circa la presenza e/o la disponibilità di una certa tratta o di un certo alloggio, oltre che direttamente eseguire la propria prenotazione; questo senza contare il fatto che comunque le agenzie di viaggio continuano ad appoggiarsi nella stragrande maggioranza dei casi ad almeno uno di tali sistemi. Ma, come accennato, i problemi che i GDS stanno affrontando non sono solo di natura tecnologica, ma anzi, anche e soprattutto di natura sociale ed economica. E' probabilmente utile introdurre a questo punto un fatto che bene può illustrare le dinamiche di cambiamento occorse e tuttora in corso; nei primi anni del nuovo secolo, infatti, le quote di mercato di Galileo ed Amadeus hanno iniziato a scendere, mentre Worldspan ha avuto un periodo di crescente popolarità; ciò fu dovuto soprattutto al fatto che lo stesso costituiva il motore alla base di Expedia e Orbitz, ovvero due delle più grandi agenzie di 6

17 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB viaggio on-line. Le cose sono ovviamente cambiate da allora e anche gli altri GDS hanno iniziato a fornire i loro servizi ad importanti agenzie di viaggio online; di seguito viene riportato un riepilogo delle agenzie di viaggio cui ciascun sistema fornisce appoggio. Tab. 1-2 Sistemi web attraverso i quali i più importanti GDS offrono i propri servizi. GDS Amadeus Sabre Galileo Agenzie Online cui viene fornito il proprio servizio ebookers, Expedia, lastminute.com, Opodo Expedia, Travelocity CheapTickets, ebookers, Ixeo Worldspan Expedia, Orbiz, Hotwire, Priceline Fonte: Elaborazione propria su dati [Wiki ], [Wiki ], [Wiki ], [Wiki ] Nonostante tale adeguamento è tuttavia significativo notare come oramai l'interazione diretta da parte degli utenti abbia iniziato a costituire un'importante (se non già la principale) fonte di interrogazioni e prenotazioni (e quindi introiti) per l'industria dei viaggi e del turismo. Un'analisi approfondita di tutte le componenti e dinamiche del fenomeno esula dalla natura del presente documento, ma per meglio comprendere i paragrafi successivi è senza dubbio necessario notare il fatto che la crescita di popolarità del Web non è ovviamente passata inosservata anche ad alberghi e compagnie aree; questi devono infatti una certa commissione ai GDS per ogni prenotazione ricevuta; la possibilità offerta dal World Wide Web di entrare direttamente in contatto con l'utente finale ed evitare quindi tali commissioni di intermediazione ha causato profondi mutamenti, nelle dinamiche di intermediazione tra agenzie, GDS e compagnie aeree/alberghi ma, come sarà più chiaro tra breve, anche nei comportamenti negli utenti finali. Dopo un periodo di costante crescita delle commissioni che i sistemi GDS imponevano alle compagnie aeree, la crescita del web ha permesso a queste di vantare una posizione di maggiore indipendenza nell'ambito delle trattative e riuscire quindi ad ottenere una diminuzione di circa 10-15% dei costi per la prenotazione attraverso GDS, portando il costo medio per tratta ai $4,00; portando in causa le proprie situazioni non sempre floride, l'emergere delle soluzioni lowcost (le quali non si appoggiano ai GDS) e l'emergere di alternative ai GDS queste sono riuscite a portare attorno ai $3,00 il costo medio per tratta nel Interessante comunque notare che, nonostante l'avvento di Internet e della possibilità che ha l'utente di interagire direttamente con il fornitore di servizi, i GDS continuano ad avere un ruolo assolutamente significante nell'ambito delle prenotazioni di viaggi. [Sparolin 2005] 7

18 ATTUALI SISTEMI AUTOMATIZZATI PER LA PIANIFICAZIONE E PRENOTAZIONE DI VIAGGI Sabre Il sistema Sabre è presente sul mercato dei viaggi da più di quarant'anni, ovviamente sempre coinvolto in un costante processo di aggiornamento tecnologico. Con sede a Southlake, Texas negli Stati Uniti, Sabre fornisce la propria piattaforma ad oltre 60,000 agenzie di viaggio nel mondo in circa 50 nazioni, mettendo a disposizione di queste i servizi offerti da circa 400 compagnie aeree, 55,000 alberghi, 52 compagnie di noleggio auto, 9 linee di crociera, 33 enti ferroviari e 229 tour operator. Nel giugno1996, Sabre è diventata una società separata da AMR (l'azienda che controlla American Airlines) ed in seguito circa il 20% del capitale sociale è stato offerto al pubblico. Tra le recenti innovazioni dell'azienda, da segnalare Sabre Virtually There, un sito web personalizzato, che offre al viaggiatore informazioni aggiornate sulle destinazioni prossime, oltre che consigli per la visita o la pianificazione del proprio itinerario. Sabre controlla inoltre Travelocity.com, una delle leader tra le agenzie di viaggio online (nel 2001 furono 32 milioni gli utenti del sito, i quali procurarono introiti per 300 milioni di dollari) e Get There, una soluzione di e-procurement basata su web e destinata alle aziende per la pianificazione di viaggi d'affari. L'abilità di mantenersi tecnologicamente aggiornata e la diversificazione dei metodi di generazione d'introito hanno permesso a Sabre di mantenersi altamente competitiva nel mercato. Amadeus Fondata nel 1987 da Air France, Iberia, Lufthansa e SAS, Amadeus è il più recente tra i grandi GDS, risultando ciò nonostante leader nel settore, grazie alla popolarità conosciuta soprattutto in Europa e nell'america Latina. Nel tempo, le quote possedute da SAS, in numero eguale a quelle possedute dalle altre tre compagnie aeree fondatrici, sono state offerte al pubblico e così la distribuzione del capitale sociale attuale è la seguente: Air France (23.36%), Iberia (18.28%), Lufthansa (18.28%); le azioni rimanenti sono possedute da altri investitori. Il database e l'intero network della struttura risultano probabilmente tra i sistemi informativi più grandi e complessi in Europa, fornendo i propri servizi a più di 57,000 agenzie di viaggio e offrendo i servizi, oltre che della maggior parte delle compagnie aeree del mondo, anche approssimativamente di 58,000 hotel e 50 compagnie di noleggio auto, oltre che traghetti, navi e ferrovie, ma anche assicurazione e tour operator. In qualità di più giovane tra i sistemi GDS, Amadeus ha senza dubbio incontrato un buon successo, pur costituendo in qualche modo un caso anomalo per via dell'alto numero di agenzie fornite e di paesi in cui è diffuso, nonostante offra il numero più basso di destinazioni negli Stati Uniti tra i quattro grandi GDS. E' quindi possibile affermare, senza troppe riserve che, mentre gli altri grandi GDS rivolgono la loro attenzione per lo più al mercato Nord Americano, Amadeus diriga la propria attenzione maggiormente verso le altre regioni del globo. E' questa probabilmente la ragione del successo del sistema che, anziché cercare ulteriori competizioni in un territorio 8

19 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB altamente competitivo, ha voluto portare i propri servizi a zone scoperte. Per quanto riguarda il futuro del sistema, indipendentemente dal proprio mercato di riferimento, Amadeus si trova di fronte alle stesse sfide tecnologiche e sociali affrontate dagli altri sistemi; l'acquisizione di e-travel, Inc. da Oracle nel giugno del 2001 può essere senz'altro visto come un segno della volontà dell'azienda di seguire il trend attuale che sta portando a pubblicare su web le proprie offerte; in questo caso, e- Travel integra in un unico portale la possibilità di prenotare voli, auto a noleggio, hotel e tratte ferroviarie, tutte peraltro con un occhio di riguardo anche alla clientela aziendale. Worldspan Fondata nel 1990 da Delta Air Lines, Inc., Northwest Airlines e Trans World Airlines, Inc (TWA), Worldspan ha sede ad Altanta, Georgia, negli USA. Le quote dell'azienda sono attualmente possedute da Delta Air Lines, Inc. per il 40%, da Northwest Airlines per il 34% e da American Airlines, Inc. per il 26%. Il sistema offre i propri servizi a circa 20,000 agenzie di viaggio in circa 90 nazioni, fornendo la possibilità di prenotare i servizi di circa 421 airlines, 210 catene alberghiere, 40 aziende di autonoleggio e 40 tour operator. Nel tentativo di seguire i trend di mercato e fornire ai propri clienti servizi attraverso tecnologie web-based, Worldspan ha stabilito una serie di partnership con aziende leader nel settore del turismo, di fatto cementando accordi con: Datalex (fornitore di servizi di e-business, in particolare legati all'industria globale del turismo), Digital Travel (tour operator online), Kinetics, Inc (sviluppatore di soluzioni per l'industria aerea), OpenTable.com, (sistema on-line per la gestione delle prenotazioni dei ristoranti) e Viator (importante fornitore di servizi orientati al Web, in termini di hosting, data management, e-commerce e gestione dei contenuti). Nel 2001, è stato inoltre inaugurato Orbitz LLC, il quale usa Worldspan come proprio motore di ricerca e nel 2002 è venuto alla luce epricingsm (disponibile in Italia dal 2006), che basandosi su un'architettura distribuita, permette all'utente finale una gestione particolareggiata delle tariffe che è possibile ottenere. Sotto la direzione di Paul Blackney, Worldspan si è costruito una reputazione di GDS solido a disposizione delle agenzie online, grazie ai servizi prestati a colossi come: Expedia, Priceline, Orbitz e Hotwire, responsabili peraltro di metà del volume d'affari del GDS. Galileo Nel 1971 United Airlines creò l'apollo Reservation System con il preciso intento di contrastare il monopolio acquisito da American Airlines, ottenuto attraverso la manipolazione dei risultati offerti dalle interrogazioni effettuate al sistema Sabre. Nel 1986 la struttura organizzativa che manteneva il sistema Apollo fu nominata Covia e divenne nello stesso anno, un'unità indipendente (anche se ovviamente controllata) da United Airlines. The Galileo Company Ltd (conosciuta anche come Galileo International) fu nel 1993 costituita nel Regno Unito, con la partecipazione di: British Airways, Swissair, KLM 9

20 ATTUALI SISTEMI AUTOMATIZZATI PER LA PIANIFICAZIONE E PRENOTAZIONE DI VIAGGI Royal Dutch Airlines, Alitalia e Covia stessa. Negli Stati Uniti, intanto United Airlines, vendeva il 50% di Covia a: USAir, British Airways, Swissair, KLM Royal Dutch Airlines e Alitalia, creando la cosiddetta Covia Partnership. Tre anni dopo, altre compagnie aeree entrarono in Covia, la quale era quindi controllata ora da 11 compagnie e, nella fattispecie: Aer Lingus, Air Canada, Alitalia, Austrian Airlines, British Airways, KLM Royal Dutch Airlines, Olympic Airlines, Swissair, TAP Air Portugal, United Airlines e US Airways. Come per gli altri GDS, anche Galileo divenne una società per azioni nel 1997, con titoli trattati dalle borse di New York e Chicago Stock. Nell'ottobre del 2001 Cendant Corporation (Travelport) ha acquistato Galileo International per circa $1.8 miliardi. Il datacenter di Galileo si trova attualmente a Denver, Colorado negli USA. L'azienda al momento fornisce servizi a circa 45,000 agenzie di viaggio in 120 nazioni, fornendo possibilità di interazione con 500 compagnie aeree, 220 catene alberghiere, 30 compagnie di noleggio auto e 400 tour operator. L'attuale capacità competitiva di Galileo deriva da una consolidata esperienze, oltre che da una bilanciata presenza globale. L'arretratezza tecnologica della piattaforma (Galileo è l'unico GDS che non offre una completa interfaccia web based) è stata parzialmente superata tramite la sottoscrizione di partnership con diverse aziende fornitrici di servizi di gestione turistica e gestione dei contenuti online. E' probabilmente attraverso l'acquisizione di Worldspan comunque che Travelport conta di allinearsi tecnologicamente agli altri due grandi GDS; sono tuttora sconosciute le intenzioni dell'azienda nei confronti dei due sistemi che, per il momento, continuano a proseguire le loro distinte esistenze. 1.4 Evoluzione del mercato dei viaggi L'avvento e la diffusione delle nuove tecnologie e di Internet in particolare hanno profondamente mutato i rapporti tra i diversi attori che intervenivano ed intervengono nei meccanismi di prenotazione di viaggi (fornitori di servizi, GDS, agenzie di viaggio, utenti finali). Già la liberalizzazione del mercato dei voli negli Stati Uniti del 1978 (Airline Deregulation Act) comportò notevoli conseguenze nel settore, in quanto i fornitori di servizi per cui i prezzi erano precedentemente determinati a priori da un'unica autorità e calcolati in maniera tale da riuscire a coprire i costi di esercizio di ogni tratta, entrarono per la prima volta in competizione tra loro. Questi erano infatti ora soggetti a nuove dinamiche in un mercato in decisa espansione e dovevano cercare di accaparrarsi il numero maggiore possibile di clienti, coprendo ovviamente i loro costi di esercizio. Il volume d'affari potenziale insomma era aumentato, ma più complessa era anche la pianificazione delle proprie strategie di mercato. Al fine di assicurarsi un numero di clienti maggiore possibile, le compagnie aeree cercavano di offrire servizi (voli in particolare) che potessero rispondere in maniera più adeguata possibile alla domanda, ma non solo. Dato che erano alcune delle compagnie aeree a controllare i CRS, oramai comunemente utilizzati dalle agenzie di viaggio, per eseguire le prenotazioni, anche in virtù del fatto che non esistevano legislazioni che regolassero il funzionamento di tali CRS, queste 10

21 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB richiedevano innanzitutto commissioni molto elevate alle compagnie aeree concorrenti (soprattutto nel caso in cui queste offrissero tratte aeree direttamente in competizione con loro) e, nello stesso tempo, facevano in modo che i loro voli comparissero per primi tra i risultati, indipendentemente dalle richieste fatte dalle agenzie. Questo fenomeno, noto come biasing risultava particolarmente significativo, se si tiene conto del fatto che tuttora il 90% delle prenotazioni avvengono utilizzando le tratte proposte nella prima schermata e ben il 70% delle prenotazioni avvengono utilizzando il primo volo presentato a schermo. [Duliba et al. 1996] Certo, ora questi risultati sono probabilmente anche giustificati da effettivi accoppiamenti tra la ricerca e la risposta fornita dal sistema; non doveva essere così a quei tempi, quando nel 1982 venne appositamente costituita una commissione per analizzare e cercare di risolvere il problema. E' così che nel 1984 furono imposte alcune regole che vietavano: la possibilità di utilizzare (senza esplicita richiesta) filtri e ordinamenti per specifica compagnia aerea la possibilità di variare o aggiungere per utenti finali, agenzie e soprattutto compagnie aeree concorrenti, commissioni e spese accessorie. la possibilità per una compagnia aerea di nascondere i voli di compagnie concorrenti dai propri sistemi o non consentire la pubblicazione dei propri dati in altri sistemi CRS. l'imposizione alle agenzie di utilizzo di un unico sistema CRS o la proposta a queste di schemi di compensazione che dessero luogo a fenomeni di indiretta esclusione dei concorrenti. Ciò nonostante, le compagnie aeree che controllavano i CRS continuavano a fare cospicuo utilizzo di biasing andando ad esempio ad utilizzare criteri di filtraggio alternativi o progettando appositi algoritmi di ricerca loro favorevoli; esempio piuttosto tipico era la declassazione delle tratte offerte da compagnie aeree concorrenti, tramite la scelta di voli con scali intermedi di durate esageratamente lunghe (la pratica era così impiegata da meritarsi l'apposita denominazione di "time shaving"); in alcuni casi le soluzioni erano ancora più fantasiose e i criteri di ricerca per far figurare i propri voli tra i primi risultati erano parametri del tutto irrilevanti per l'utente finale, scelti a seconda dei casi (esempio nel caso di volo con uno scalo intermedio era il rapporto tra numero di posti a sedere disponibili nel primo volo e posti a sedere nel secondo). [WebWatch 2002] Come si può quindi evincere da questi esempi, già allora la competizione risultava piuttosto serrata; ad ogni modo essa aveva caratteristiche prettamente orizzontali, dato che riguardava, a diversi livelli, la scelta di uno, piuttosto che di un altro fornitore di servizi. Nella catena che portava l'utente dall'agenzia di viaggio, sino alla prenotazione del servizio desiderato, una volta intrapresa una strada, tutti i nodi intermedi traevano vantaggio. 11

22 ATTUALI SISTEMI AUTOMATIZZATI PER LA PIANIFICAZIONE E PRENOTAZIONE DI VIAGGI Fig. 1-2 sequenza dei passaggi per la prenotazione di un viaggio nel modello classico (anni '80) Fonte: Elaborazione propria Sussisteva in sostanza un equilibrio tra i diversi attori nella scena; le agenzie di viaggio operavano nelle loro rispettive locazioni territoriali, senza eccessivi margine di competizione, percependo percentuali (10% in media) da compagnie aeree e altri fornitori di servizi. Gli stessi corrispondevano un certo importo fisso al sistema GDS che effettivamente aveva effettuato la prenotazione, tenendo poi per loro la parte rimanente del corrisposto dall'utente finale. La situazione in termini di remunerazione delle provvigioni continuava a rimanere stabile, così come i fenomeni di biasing; nel frattempo, tuttavia, a causa della crescente competizione, le tariffe per i singoli servizi venivano necessariamente ribassate, mentre i costi di esercizio continuavano inevitabilmente a crescere, soprattutto a causa dell'inflazione; i soli costi dei CRS che nel 1990 costituivano il 2.1% dei costi di emissione di un biglietto, costituivano nel 1996 l'8% di tali oneri. Sicuramente il fenomeno web ha se non altro limitato la crescita continua di tali spese, che tuttavia continuano a rimanere piuttosto altre, con un costo medio di $3,50 per ogni tratta riservata. Come se ciò non bastasse, il mercato dei GDS negli Stati Uniti venne nuovamente liberalizzato nel 2004, annullando le regole imposte nel 1984 e comportando conseguenze piuttosto serie per compagnie aeree minori, escluse dai meccanismi di biasing. [US Transp. 2004] Il fatto che oramai i sistemi GDS siano globali e che quindi debbano essere seguite le regole più stringenti (regolamenti Europei e Canadesi nella fattispecie) non bastano a tranquillizzare tali compagnie, considerata soprattutto le serrate attività di lobbying attuate dalle compagnie che gestiscono i GDS. E' così che con l'avvento del world wide web, appena fiutata la possibilità di poter prescindere (se non altro 12

23 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB parzialmente) da scomodi intermediari, le compagnie aeree hanno cercato di portare la propria presenza sul web, per cercare di interagire direttamente con il cliente finale. La mossa si è rivelata azzeccata poiché in ogni caso ha permesso di diminuire direttamente (prenotazioni direttamente dai propri siti web) o indirettamente (più forza contrattuale nella negoziazione di accordi con i sistemi GDS) i costi per le prenotazioni dei propri servizi. [Promedia 2006] Interessante in questo senso il caso Ryanair, compagnia inizialmente presente su tutti e quattro i sistemi ma che, anche a seguito di un'azzeccata e ben condotta campagna di marketing è riuscita a rendere il proprio sito web l'unico sistema impiegato per la gestione delle prenotazioni, disdicendo di conseguenza i propri accordi con i sistemi GDS. La situazione attuale si presenta quindi quantomai diversa da qualsiasi contesto precedente, in quanto ora, a seguito della possibilità per ognuno di interagire direttamente con l'utente finale per via telematica, i diversi attori si trovano coinvolti in una competizione che si realizza per la prima volta anche a livello verticale. 1.5 Risorse su World Wide Web Il settore dei viaggi non solamente fu uno dei primi ad approdare online, ma è sicuramente anche uno dei settori ad aver riscontrato maggiore successo negli ultimi anni; secondo Forrester Research, è proprio l'industria del turismo e dei viaggi il segmento più importante nell'e-commerce. [B. Chrispin & S. Fisher 2000] Già nella prima metà degli anni '90 i grandi sistemi GDS avevano iniziato ad intuire le possibilità dello strumento Internet e hanno iniziato a migrare i loro servizi su tale mezzo, prima al solo livello strutturale (reti di comunicazione), poi anche a livello di interfaccia (uso del World Wide Web, in contesti B2B). [Wiki ] Con la diffusione di Internet a tutti i livelli sociali, le potenzialità dello strumento furono considerate qualche anno dopo anche dalle agenzie di viaggio, le quali iniziavano ad intuire le possibilità di business B2C del settore; le aziende di dimensioni minori iniziavano ad utilizzare lo strumento web per la promozione delle loro offerte, mentre grandi portali dedicati nascevano con l'intento di sostituire interamente la presenza fisica di un'agenzia, così da snellire gli iter necessari alla prenotazione di un viaggio e quindi contenere le spese, soprattutto in termini di personale. Risulta abbastanza semplice intuire come l'industria del turismo e dei viaggi, non essendo vincolata da particolari restrizioni logistiche grazie soprattutto all'avvento degli e-tickets e delle prenotazioni elettroniche in genere, non è necessario alcun tipo di consegna fisica di un bene risulti particolarmente predisposta ad intermediazioni virtuali. Nel frattempo, anche i fornitori diretti di servizi (compagnie aeree, navali, ferroviarie, hotel...) comprendevano come il www potesse rivelarsi uno strumento in grado di permettere l'interazione diretta con il cliente finale e quindi la possibilità di evitare di dover corrispondere commissioni e premi ad agenzie e GDS; ecco quindi che anch'essi si dotavano autonomamente di siti web e servizi on-line per la prenotazione dei servizi offerti. Considerate le premesse appena fatte non è quindi difficile capire come si presenti in realtà assolutamente variegato l'insieme di siti e portali che offrono servizi in modo più o meno collegati con l'industria del turismo e dei viaggi. Viene quindi riportata di seguito una classificazione sommaria di tali siti. 13

24 ATTUALI SISTEMI AUTOMATIZZATI PER LA PIANIFICAZIONE E PRENOTAZIONE DI VIAGGI Portali Generici Già considerando i soli portali aggregatori di informazioni assolutamente generiche (About.com, AOL, MSN, Yahoo) e del modo in cui le sezioni Travel sono messe in evidenza, è possibile rendersi conto di come in realtà l'industria del turismo costituisca un settore più importante di quanto si possa immaginare. Probabilmente questi siti non sono i luoghi migliori dove cercare informazioni specifiche in vista di un viaggio o effettuare una prenotazione; ad ogni modo la pubblicità che questi presentano, spesso in forma di offerte last minute o pacchetti vacanze completi attira un numeroso numero di utenti, capitati magari sul sito in cerca di tutt'altro tipo di informazioni. Interessante anche notare il fatto che probabilmente in seguito ai risultati ottenuti grazie alla pubblicità, anche questi portali generici, capita l'importanza del settore turistico nell'e-business, si sono dotati di motori di ricerca specifici per viaggi, spesso e volentieri sotto forma di partnership con motori di ricerca specifici (es. about.com con kayak.com) o agenzie di viaggio online (es. MSN con Expedia). Tab. 1-3 Portali attraverso i quali i più importanti GDS offrono i propri servizi. Portale Sistemi di ricerca specifica per viaggi utilizzati About.com AOL MSN Yahoo Kayak.com Travelocity Expedia Travelocity Fonte: Elaborazione propria su dati reperiti direttamente dai siti web dei sistemi consultati Portali dedicati ai viaggi Portali più specifici, destinati a chi ha già idea di intraprendere un viaggio o cercare informazioni relative ad una determinata località sono quelli che forniscono una serie di informazioni e servizi esclusivamente per turisti e viaggiatori. Sono simili per molti versi alle pubblicazioni cartacee, pubblicizzando anch'essi offerte dell'ultimo minuto e vacanze all-inclusive; allo stesso tempo però permettono la ricerca di alloggi e/o trasferimenti da e per le località che l'utente ha intenzione di visitare. L'impronta di questi siti è per lo più di carattere editoriale e l'enfasi degli stessi è incentrata per lo più sulla destinazione del viaggiatore, più che sull'atto stesso di prenotazione. Una volta selezionata la destinazione di preferenza del viaggiatore, questi siti permettono la ricerca semplice di alloggi e/o tratte, oppure, come nel caso di igougo, l'interrogazione di diversi sistemi per la ricerca della tariffa più conveniente. Interessanti Lonelyplanet e Travelzoo, con il proprio motore di ricerca autonoma e Tripadvisor, sito nel quale la ricerca non avviene solamente per mezzo dei motori di ricerca specializzati, ma anche direttamente nei siti stessi delle compagnie aeree e delle proprietà alberghiere. 14

25 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Tab. 1-4 Maggiori portali dedicati ai viaggi e sistemi di prenotazione consultati Portale Sistemi di ricerca specifica per viaggi utilizzati Fodors.com IgoUgo.com LonelyPlanet.com TripAdvisor.com USAToday.com Virtualtourist Expedia Hotwire, Orbitz, Priceline.com, Travelocity, Kayak.com, Cheaptickets, Sidestep Autonomo Expedia, Hotwire, Hotels.com, FastBooking.com, Venere.com, Sofitel.com, Otel.com, PerfectEscapes.com e molti altri Kayak.com Expedia, Hotelclub, kayak, fastbooking e altri Fonte: Elaborazione propria su dati reperiti direttamente dai siti web dei sistemi consultati Motori di ricerca specifici e aggregatori Un sottoinsieme dei portali dedicati ai viaggi possono essere considerati i motori di ricerca specifici. Questi infatti non forniscono informazioni addizionali su una particolare meta ma si focalizzano nell'individuazione delle tariffe più convenienti per trasferimenti e/ o alloggi, consultando molteplici siti di agenzie di viaggio online e soprattutto fornitori diretti di servizi Famosi esempi di motori di ricerca specifici sono: Travelzoo.com (voli, hotel, crociere, noleggio auto), Dohop.com (voli, hotel), Hotels.com (hotel), cheapflights.com (voli) e Kayak.com voli, hotel, crociere, noleggio auto). Volagratis.it/BravoFly Tra tutti gli aggregatori presenti su Internet, una nozione particolare merita il sito Volagratis.it del gruppo BravoFly, che ha sede in Olanda e dipartimenti in diversi stati europei, tra cui l'italia. La peculiarità principale che contraddistingue il sito dai suoi simili è la possibilità per l'utente di confrontare tra loro tariffe offerte di compagnie aeree tradizionali e compagnie low-cost (circa 100 quelle contemplate), le quali consentono nella maggior parte dei casi di ottenere le proprie tariffe solo dal proprio sito web. Altra peculiarità del sito, forse ancor più interessante dal punto di vista concettuale è la possibilità per l'utente di verificare immediatamente, con un'unica operazione di ricerca, la disponibilità di posto e le tariffe offerte per lo stesso volo in diversi giorni; tale funzionalità, offerta su altri siti per le prenotazioni alberghiere ma non per i voli, consente all'utente in un'unica ricerca di trovare il trasferimento a lui più vantaggioso non solo in termini di compagnia/volo ma anche in termini di date di trasferimento; l'intervallo considerato è di una settimana e ciò permette nella maggior parte dei casi in cui la destinazione sia unica di ottenere l'itinerario migliore (scelta di date di 15

26 ATTUALI SISTEMI AUTOMATIZZATI PER LA PIANIFICAZIONE E PRENOTAZIONE DI VIAGGI partenza/ritorno, hotel in cui effettuare pernottamenti) con un semplice confronto di costi tra le somme dei trasferimenti e dei pernottamenti nei diversi giorni selezionati (numero di confronti uguale al numero di giorni considerati nell'intervallo concesso per la partenza) Agenzie di Viaggio Online Le agenzie di viaggio online si differenziano dai motori di ricerca specifici non tanto per il modo di porsi all'utente, quanto piuttosto per le fonti da cui vengono attinti i dati e soprattutto per il background storico che le contraddistingue. Come le agenzie di viaggio reali, infatti queste hanno inizialmente basato le proprie operazioni sul legame stretto con uno dei grandi GDS, semplicemente sostituendo il canale fisico con quello on-line, ma di fatto continuando ad utilizzare i mezzi tradizionali per la ricerca delle tariffe. Oggi le cose sono cambiate, poiché in quasi tutti i casi sono più di uno i GDS contemplati da ciascuna agenzia di viaggio online, però è comunque significativo notare (ulteriori dettagli nei prossimi paragrafi) come in realtà queste due importanti figure nell'industria del turismo siano in qualche modo cresciute assieme. CheapTickets Fondata nel 1986, sotto forma di agenzia viaggi con un'unica sede ad Honolulu è stata in seguito acquistata da Cendant Corporation (Travelport) nell'ottobre del 2001 e in seguito offerta anche come servizio online, costituendo quindi un'offerta multi-canale (on/off-line). Considerata anche la natura e il background dell'azienda, è naturale comprendere come i servizi offerti possano essere quelli tradizionalmente offerti dalle agenzie di viaggio, con un occhio di riguardo per le soluzioni low cost. edreams edreams è stata fondata nel 1999 nella Silicon Valley dallo spagnolo Javier Pérez Tenessa e l'americano James Hare, con il supporto di gruppi finanziari europei e americani come DCM Doll Capital Management, Apax Partners, Atlas Venture e 3i Group, tra gli altri; E' un'agenzia di viaggi online con sede a Barcellona e filiale a Milano, leader nel settore nell'europa meridionale. La sua attività è basata sull'offerta della migliore selezione di voli, hotel e pacchetti turistici con l'utilizzo di tecnologie per la ricerca, la formazione dei pacchetti e la prenotazione attraverso i suoi siti Internet (in italiano, spagnolo, inglese, francese, portoghese e tedesco);'offerta include compagnie aeree tradizionali e low cost. Più di sei milioni di clienti hanno riservato i loro hotel, voli e pacchetti turistici con edreams dall'inizio delle attività della compagnia. Nell'ottobre 2006 TA Associates, società leader nelle operazioni di buyout e di private equity in USA ed Europa, ha acquisito edreams, concretizzando la prima operazione di LBO (Leveraged Buy Out) nella storia di Internet in Sud Europa. 16

27 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Expedia Lanciata da Microsoft nel 1996 è stata in seguito acquisita da Travelscape.com e VacationSpot.com nel marzo 2000; propone i servizi di oltre 450 compagnie aeree e proprietà alberghiere, oltre che di compagnie di crociera, noleggio auto e altri servizi. OneTravel Di proprietà di Terra Lycos e Amadeus offre i servizi tipici di un'agenzia di viaggio, mettendo a disposizione dei viaggiatori le prestazioni di 500 linee aeree, 54,000 hotel, 50 compagnie di noleggio auto e altri servizi. Oltre a ciò offre informazioni culturali, storiche e anche meteorologiche sulle destinazioni contemplate. Orbitz Agenzia di viaggi online a tuttotondo, offre i servizi di 455 compagnie aeree, 210 catene alberghiere, 42 compagnie di noleggio auto e 18 linee di crociera. Fornisce i servizi del proprio di motore di ricerca a molti altri siti. TravelNow Di proprietà di USA Interactive, fu fondata nel 1995 da due studenti dell'università del Missouri ed è stata, soprattutto agli inizi dell'esplosione del settore turistico online una delle agenzie di viaggio online maggiormente utilizzate da terze parti, sebbene molte delle prenotazioni trovassero effettivamente attuazione offline, a seguito delle richieste ricevute online. Travelocity Di proprietà di Sabre, travelocity ne costituisce in pratica la componente B2C Siti di hotel, compagnie aeree e altri fornitori diretti di servizi per i viaggiatori Anche le aziende alla base della catena turistica, ovvero quelle che direttamente forniscono i servizi per i viaggiatori hanno intuito le potenzialità dello strumento Internet ed hanno così creato i propri siti web, con l'intento di raggiungere direttamente l'utente finale, evitando così di dover corrispondere commissioni e bonus a sistemi GDS e Agenzie di viaggio. E' così possibile, attraverso di essi, non solo ottenere informazioni su tratte e/o alloggi, ma anche effettuare direttamente richieste sulla disponibilità e prenotazioni on-line. Evitare i vari passaggi della catena consente (in molti casi, ma non sempre, causa accordi economici stipulati) a questi siti di offrire tariffe migliori rispetto a quelle che è possibile ottenere attraverso agenzie di viaggio on e off-line. 17

28 ATTUALI SISTEMI AUTOMATIZZATI PER LA PIANIFICAZIONE E PRENOTAZIONE DI VIAGGI 1.6 La situazione attuale Dopo la prepotente irruzione di fine anni '90 (USA) e primi anni del nuovo secolo (Europa), il fenomeno delle prenotazioni on-line è rimasto in costante e continua crescita, di fatto impossessandosi di quote sempre maggiori di un mercato un tempo esclusivamente riservato alle imprese del turismo tradizionale. I dati elaborati da Best Network, società di comunicazione leader nel web marketing, confermano il boom dell etravel anche in Italia, dove il 52 per cento dei viaggiatori ha acquistato on-line almeno una volta almeno un biglietto ferroviario o un volo aereo; la maggior parte dei circa 20 milioni di utilizzatori abituali di Internet ha quindi avuto esperienze dirette, nel settore dei viaggi. Inoltre, ben 500 mila italiani hanno già acquistato on-line un intero pacchetto viaggi. La rete, che nel nostro Paese ha superato i 30 milioni di utenti connessi, dei quali 2/3 sono navigatori abituali, offre spazi di business ancora molto ampi per il settore dei viaggi, con un notevole aumento di offerte sempre più attente alle diverse esigenze del mercato. [Tafter 2007] Gli indubbi miglioramenti che l'avvento di Internet ha portato e sta continuando a portare riguardano la facilità di interagire direttamente con i fornitori da parte dell'utente e la possibilità quindi di ottenere tariffe vantaggiose. Ciò non ha tuttavia risolto tutte le problematiche, di cui si è precedentemente fatto qualche accenno, dato che di fatto l'industria del turismo, anche nella propria veste virtuale, rimane permeata dai favoritismi che l'hanno sempre contraddistinta, nonostante le nuove forme di competizione introdotte dal nuovo mercato. Ecco dunque che l'educazione dell'utente finale rimane fondamentale, in quanto è l'unica arma che questi ha in mano per evitare di abboccare ai molti specchi per allodole che si trovano on-line o semplicemente per ottenere la tariffa a lui più vantaggiosa, magari contemplando l'itinerario per lui migliore. Una citazione se non fedele alla realtà, sicuramente significativa per comprendere le problematiche del caso, viene ripresa da: [WebWatch 2002]: Volendo portare le cose all'estremo, l'esperienza (di acquisto di viaggi on-line) è un po' come scommettere al casinò; i giocatori esperti (e fortunati) hanno buone possibilità di vincere, ma spesso è la casa a vincere. In una valutazione sperimentale di quattro agenzie on-line nel 2000 (Cheap Tickets, Expedia, Lowestfare e Travelocity) evidenti traccie di manipolazione dei risultati furono riscontrati: Su Travelocity le compagnie aeree che venivano pubblicizzate sul sito comparivano in posizioni predominanti anche nei risultati delle ricerche Su Lowestfare molti voli di TWA con itinerari contorti e sicuramente non convenienti per l'utente venivano restituiti prima di altri voli, sicuramente più vantaggiosi. Su tutti e quattro i siti, alcuni voli, sicuramente interessanti per l'utente finale (di compagnie che non avevano acquistato servizi pubblicitari sui siti stessi) non venivano neppure proposti Nessuno dei siti citati in precedenza era in realtà controllato da compagnie aeree, ma tutti 18

29 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB accettavano pubblicità da queste (e probabilmente ricevevano bonus aggiuntivi per la vendita di voli di queste). [WebWatch 2002] Ecco quindi che l'utente per ottenere tariffe vantaggiose deve possedere una certa cultura di base in materia, ma se è vero che l'educazione è un punto cruciale, in grado di assicurare all'utente finale tariffe vantaggiose nella maggior parte dei casi, anche il più esperto degli utenti si deve scontrare con una serie di problematiche attualmente irrisolte; il self-service infatti, assieme alla convenienza e velocità di accesso alle informazioni, ha portato con se anche la necessità di ben strutturare la propria ricerca, richiedendo spesso notevoli sforzi nella consultazione di molteplici risorse e quindi di una notevole quantità di tempo. PhoCusWright, un'azienda che si occupa di tecnologia applicata al turismo afferma infatti che il viaggiatore visita in media 3.6 siti web per il solo acquisto di un biglietto aereo per una singola tratta; in sintonia i dati prodotti da Yahoo (dal portavoce di Yahoo Travel, Malcolmson), secondo cui il 76% degli acquisti online sono preceduti da meticolose operazioni di ricerca. Uno studio condotto nel 2004 da Jupiter Research riporta infine che circa il 40% dei viaggiatori che utilizzano lo strumento Internet non credono esista un unico sito in grado di fornire loro le soluzioni migliori in termini di servizio e convenienza. [Wiki ] E' chiaro che essendo dati medi questi, contemplano anche i casi di utenti meno esperti, ai quali la visita di un unico sito è sufficiente; per l'utente esperto quindi la prenotazione di una singola tratta ad una tariffa vantaggiosa può necessitare della visita di ben più di 4 siti. Nonostante l'esperienza che un utente possa avere acquisito e il numero di fonti che questi consulti, inoltre, non è sempre semplice riuscire ad ottenere una tariffa complessiva vantaggiosa, riuscendo a combinare anche altri aspetti egualmente importanti nella pianificazione di un viaggio (combinazione degli orari dei diversi voli, organizzazione dei pernottamenti, sicurezza della transazione, eventuali servizi post-vendita). Non esiste infatti uno strumento unico in grado di fornire all'utente un'indicazione sulla migliore pianificazione di un itinerario qualora egli abbia un certo numero di tappe da visitare, entro un certo intervallo temporale. Una proposta implementativa di un simile strumento sarà fatta nei capitoli seguenti, attraverso la costruzione incrementale di modelli via via più complessi, articolati e comprensivi. 19

30

31 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Capitolo 2 UN PRIMO MODELLO I sistemi presentati nel capitolo precedente consentono di ottenere diverse possibili opzioni e tariffe (nel caso degli aggregatori, le migliori) per tutti i pernottamenti e gli spostamenti che il viaggiatore intende fare nel contesto di un proprio viaggio. In tutti questi sistemi egli deve tuttavia avere già preventivamente pianificato un proprio preciso itinerario e aver stabilito date di pernottamenti e trasferimenti certe; le singole ricerche e prenotazioni avvengono da parte di questi in maniera indipendente l una dalle altre. Conseguenza negativa immediata di tale approccio è soprattutto il dispendio di tempo richiesto, dato che l utente deve eseguire una singola ricerca per ciascun evento cui egli intenda prendere parte (il termine evento sarà utilizzato d ora in poi per indicare indifferentemente un pernottamento, un trasferimento o l impiego di una qualsiasi altra risorsa che richieda una prenotazione o che abbia una data di inizio e fine certa nel contesto della pianificazione di un viaggio). Solo apparente il miglioramento apportato recentemente da alcuni siti che permettono in un unica operazione di considerare più tratte, dato che questo numero è sempre esiguo (spesso il limite massimo è di 3 o 4 trasferimenti), soprattutto in virtù del fatto che, anche in questo caso l'utente deve aver già prestabilito le date dei propri trasferimenti e dei propri pernottamenti. Non necessariamente però l'utente ottiene la tariffa migliore in assoluto, quale somma dei costi dei diversi eventi selezionati, in questo modo, dato che non tutti questi siti coprono l intera gamma dei voli, alloggi e altri servizi disponibili e anzi, solo attraverso gli aggregatori, l utente è in genere in grado di ottenere buoni risultati per ciascun singolo evento, senza la necessità di dover considerare più siti per ciascun evento di proprio interesse. Difficilmente tuttavia tali aggregatori consentono di effettuare ricerche sui voli che contemplino qualcosa in più rispetto ad una semplice combinazione andata/ritorno, perciò la situazione migliora al massimo di un fattore costante (numero delle singole agenzie di viaggio on-line contemplate da un eventuale aggregatore impiegato); l utente si trova in ogni caso di fronte ad un numero di possibili soluzioni combinate alle ricerche da affrontare che cresce esponenzialmente al variare delle date di viaggio ammissibili e del numero delle tappe considerate. Capita tuttavia spesso che un viaggiatore effettivamente disponga di una certa flessibilità, 21

32 UN PRIMO MODELLO di cui ne farebbe volentieri utilizzo, se ciò si concretizzasse in un risparmio economico o in un vantaggio in termini di tempo guadagnato, ad esempio minimizzando i tempi d'attesa per le coincidenze. Con gli strumenti sino a qui trattati tuttavia la cosa si rivela tutt'altro che semplice, e soprattutto onerosa in termini di tempo richiesto; l'utente dovrebbe infatti tentare diverse ricerche per ciascun evento cui è interessato e combinare assieme i risultati ottenuti, nei diversi modi possibili, ritrovandosi ben presto immerso in uno spazio di ricerca complessivo cresciuto esponenzialmente sul numero degli eventi che lo riguarderanno. Ecco quindi che l obiettivo del presente capitolo è introdurre un modello nel quale la flessibilità di cui può disporre il viaggiatore è considerata come elemento importante e determinante nella ricerca dell'itinerario complessivamente più vantaggioso, intendendo con tale termine quello che più si avvicina alle aspettative dell'utente, sia in termini di costo, che di tempo totale di trasferimento. 2.1 Altri Lavori La pianificazione di itinerari non sembra aver riscontrato molto successo in letteratura sino ad ora; un'analisi agli indici dei contenuti delle più importanti riviste di ricerca operativa degli ultimi anni [EJOR][OR] non ha individuato articoli che trattassero queste problematiche, neppure parzialmente. Molta enfasi viene generalmente data a problemi di Vehicle Routing, Yield Management e tutti quei contesti in cui è il profitto per l'azienda fornitrice di servizi di trasporto o alloggio a dover essere ottimizzato. Anche on-line la ricerca è stata poco fruttuosa: [Ambite et al 2002] affrontano il problema della pianificazione di un viaggio da un diverso punto di vista, sicuramente più specifico; vengono infatti cercate alternative per eventi che si realizzano nello stesso luogo, al medesimo istante (ad esempio vengono analizzati i pro e contro nello scegliere un diverso aeroporto nella medesima città di destinazione, oppure di scegliere un trasporto urbano piuttosto che un taxi per giungere dall'aeroporto selezionato al luogo d'interesse nella città). Il sistema si pone inoltre l'obiettivo di controllare in tempo reale la disponibilità di alternative (se ad esempio vi è uno sciopero dei tassisti, il sistema suggerirà in tempo reale un altro mezzo di trasporto per raggiungere la propria meta), ma impone comunque rigidità nella selezione delle date di spostamento, come evidenziato anche dagli screenshot visibili sull'articolo citato. Più simile per concezione può essere considerato [Dunstall et al 2004]; in questo caso tuttavia l'attenzione degli autori si concentra sulla generazione automatizzata di un itinerario e quindi anche sulla determinazione delle mete ritenute più opportune per il potenziale utente. Anche in sede di determinazione del percorso finale vengono tenuti in considerazione aspetti legati alle preferenze preventivamente espresse dall'utente e al profilo che ne viene conseguentemente generato, mentre non vengono considerati ad esempio i costi di trasferimento e la ricerca di alternative per spostamenti e pernottamenti in giornate diverse. Sicuramente degno di nota infine il lavoro di [Androutsopoulos & Zografos 2008], i quali hanno rivolto la propria attenzione alla pianificazione di itinerari nell'ambito di una stessa città o area, contemplando spostamenti con diversi mezzi; le modellazioni proposte risultano peraltro simili a quelle descritte nel presente documento, essendo anch'esse 22

33 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB basate su programmazione dinamica. Tale lavoro differisce tuttavia dal presente per diversi aspetti: innanzitutto non vengono contemplati i pernottamenti e la pianificazione ha quindi luogo in un intervallo temporale ben definito, corrispondente alla giornata; in secondo luogo non vi è la necessità di considerare gli spostamenti aerei, che come verrà approfondito nei prossimi capitoli costituiscono uno degli aspetti più ostici nella pianificazione di itinerari su scala globale; tale lavoro non tiene infine conto di quanto sarà introdotto al capitolo quattro del presente elaborato, ovvero della possibilità di risparmio in termini di tempo o denaro per l'utente, in base al percorso (inteso come susseguirsi di eventi) effettivamente intrapreso. Benché venga impiegata anche in questo caso la programmazione dinamica, quindi, la diversità in termini di finalità tra i due lavori introduce differenze anche dal punto di vista di obiettivi e quindi di modellazione del problema; menzione alle divergenze tra i due lavori sarà fatta non appena queste saranno incontrate nella descrizione del modello che segue. 2.2 Le misure del problema Prima di affrontare il problema è sicuramente una buona idea comprenderne la struttura; con questo intento, è possibile innanzitutto riformulare lo stesso come: quale successione di eventi intraprendere, potendo disporre di un certo intervallo temporale per la partenza, con il fine di visitare tutti i luoghi di proprio interesse, permanendovi il tempo auspicato e minimizzando sia i tempi di trasferimento tra un luogo e l'altro, sia il costo totale del viaggio?. Ecco che per mezzo di questa formulazione siamo se non altro in grado di identificare facilmente le misure del problema. Le mete da visitare sono diverse località e la scelta delle stesse è operata discrezionalmente dal decisore; ecco quindi che tale elenco deve essere innanzitutto considerato come un parametro decisionale. Le diverse opzioni disponibili per i trasferimenti, così come la durata ed il costo di ciascuna di esse sono ovviamente fuori dal controllo del decisore e vanno quindi intesi come dati del problema; la relazioni tra queste quantità sono ovviamente vincoli strutturali, che legano ciascuna tratta disponibile alla propria durata ed al proprio costo; sono invece variabili decisionali le tratte e i pernottamenti effettivamente considerati nell'itinerario finale suggerito all'utente, dato che questi derivano direttamente dalla ricerca della soluzione compiuta dal sistema. Ulteriori parametri decisionali contemplati sono gli intervalli temporali concessi per la partenza, dato che anche in questo caso possono essere direttamente e soggettivamente modificati dall'utente, nonché il numero di viaggiatori e la città di partenza per l'itinerario. La stessa caratterizzazione può essere fatta anche per la scelta relativa alla necessità di trovare una struttura ricettiva e nello specifico anche nella selezione delle strutture specifiche da considerare per ciascuna meta - oppure di usufruire di un alloggio di cui si può già certamente disporre. La durata di permanenza in ciascun luogo visitato va invece trattata come un vincolo flessibile, modificabile all'occorrenza dall'utente. 23

34 UN PRIMO MODELLO 2.3 L idea di Base Introdotte le grandezze del problema, viene di seguito descritta l'idea fondamentale alla base di questo primo modello, ovvero quella di automatizzare la ricerca della tariffa complessivamente più conveniente per il viaggio che l utente desidera intraprendere visitando una o più tappe, il cui ordine è prestabilito, valutando la convenienza di soluzioni alternative, al variare delle date di trasferimento e delle singole opzioni disponibili (alternative in termini di strutture ricettive e mezzi di trasporto) per gli eventi cui questi intenda prendere parte. Ciascun evento viene quindi rappresentato come il nodo di un grafo G = (N,E), in cui gli archi costituiscono la possibilità che ha un certo evento di essere direttamente seguito da un altro, mentre il costo totale di ogni nodo è dato dalla somma del costo dei singoli eventi che l'hanno preceduto nel corso del cammino percorso sino a quel punto. Fig. 2-1 esempio di grafo impiegato nella modellazione Fonte: Elaborazione propria In figura 3 è rappresentato un primo esempio di struttura che potrebbe assumere un ipotetico grafo per il modello proposto. Si possono notare innanzitutto i nodi A (colore giallo) che rappresentano il luogo di inizio (nodo marginale di sinistra, privo di archi entranti) e conclusione (nodo di destra, privo di archi uscenti) del viaggio; sarà da e verso questi nodi che dovranno rispettivamente partire e giungere tutti i nodi relativi ai trasferimenti verso la prima e l'ultima meta nell'itinerario dell'utente. Rappresentati come univoci in questo caso, i nodi di partenza possono in realtà anche essere molteplici e rappresentare ciascuno una diversa data di partenza per l'utente; non sarà così invece per l'ultimo nodo, che sarà invece sempre unico, così da poter successivamente permettere la ricostruzione del cammino impiegato per raggiungerlo a posteriori, attraverso una visita ricorsiva al predecessore di ciascun nodo, sino a giungere ad uno dei nodi di partenza. Chiaramente l'intento del modello è far pervenire l'utente al nodo finale attraverso il cammino meno costoso, ovvero individuare la successione di eventi con costo complessivo minore. Giunti sui nodi intermedi (i primi ad essere incontrati sono sempre i nodi verdi, che 24

35 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB rappresentano i trasferimenti), si trovano archi che necessariamente conducono ad eventi di diversa tipologia (pernottamenti in questo caso) e così in successione, in un alternarsi di eventi, che conducono sino al nodo finale. Da notare che, come evidenziato dal grafo sopra riportato, in un'unica giornata vi possono essere molteplici eventi dello stesso tipo, dato che è assai probabile una stessa tratta (intesa come coppia luogo di partenza, luogo di destinazione) sia percorribile in diversi modi; considerazione analoga vale anche per i pernottamenti, dato che in uno stesso luogo è tipicamente possibile alloggiare in strutture ricettive diverse. Ribaltando sugli archi il costo degli eventi, è immediato notare come tale modellazione richiami immediatamente i concetti fondamentali della programmazione dinamica ed in particolare la teoria relativa alla determinazione del cammino minimo, di cui sarà effettivamente fatto uso e di cui vengono quindi riportati alcuni brevi richiami. 2.4 Richiami di Programmazione Dinamica Il metodo risolutivo noto come programmazione dinamica è comunemente fatto risalire agli studi iniziati da Richard Bellman nel 1949 e culminati con la definizione formale delle teorie alla base dello stesso nella pubblicazione: Dynamic Programming, Princeton University Press del Tale approccio è tipicamente applicato a problemi di ottimizzazione, in cui vi possono essere molteplici soluzioni, ciascuna contrassegnata da un valore finale e in cui la ricerca si pone l'obiettivo di trovare il migliore di questi valori e quindi la soluzione associata secondo una certa funzione obiettivo; ecco che quindi esso risulta applicabile nel nostro contesto, anche in virtù del fatto che la modellazione proposta rispetta i due prerequisiti fondamentali della programmazione dinamica, ovvero il principio di ottimalità (Optimal Substructure) e quello della ricorrenza dei sottoproblemi (Overlapping Subproblems). [Cormen et al 1990] I principi della programmazione dinamica possono essere riassunti dalla celebre equazione di Bellman: in cui le variabili V1... Vn rappresentano il costo minimo necessario per raggiungere ciascun nodo 1...n. Nel nostro caso, il contesto si presenta peraltro assolutamente favorevole ad una soluzione basata su tale principio ed in particolare su tale equazione, poiché la garanzia di aciclicità (dovuta alla successione in ordine temporale degli eventi e quindi all'impossibilità per un certo evento di succederne ad uno che avrà luogo in un istante temporale successivo) garantisce che le soluzioni dell'equazione di Bellman siano cammini ottimi. I valori di sinistra nell'equazione possono essere così sempre calcolati da valori di destra già calcolati, a partire dai nodi iniziali Si, per i quali Vsi=0. Considerata tale caratteristica ricorsiva è ovviamente anche necessario che i sottoproblemi affrontati includano quelli che saranno effettivamente utilizzati per la formulazione della soluzione finale, vale a dire che tutte le strade parziali ottime devono essere considerate durante la ricerca. Il fatto che vi siano un numero finito di nodi di partenza, che vengono tutti considerati permette di rispettare tale requisito. Qualora il grafo fosse inizialmente definito (ovvero in cui archi, nodi e quindi anche il grado di questi) fossero noti a priori, sarebbe possibile utilizzare direttamente un 25

36 UN PRIMO MODELLO algoritmo di Programmazione Dinamica Aciclica per la determinazione del cammino minimo [Serafini 2000]. La giustificazione di tale affermazione risiede nel fatto che nel nostro contesto i nodi sono contrassegnati da caratteristiche temporali di inizio e fine implicite ma definite e che quindi l'aciclicità possa essere sempre garantita (non è infatti possibile, almeno con le attuali conoscenze, ritornare indietro nel tempo). Nel nostro caso, tuttavia la struttura del grafo non è nota a priori e quindi non lo è neppure il grado di ciascun nodo, motivo per cui un algoritmo specifico debba essere preso in considerazione. 2.5 L'Algoritmo Premesso che rimane comunque possibile sfruttare le caratteristiche temporali del susseguirsi degli eventi, è quindi possibile determinare dinamicamente la struttura del grafo, portando avanti al tempo stesso la ricerca del cammino minimo; il principio di ottimalità e l'assenza di cicli ci garantiscono che le soluzioni parziali trovate (e quindi la soluzione finale fornita) siano ottime. Nella fattispecie, l'algoritmo impiegato è il seguente: Algoritmo 2-1 Costruzione del Grafo e Determinazione Cammino Minimo costo[f] = INF; predecessore[f] = NIL; initialize(n) while N!= O let j = earliest(n); if type(j)!= return i = findcheapestnode(!type(j)) if (i! N) enqueuenode(i,n) else if total(i)< total(j) + costo(j) predecessore(i) = j total(i) = total(j) + costo(j) else if total(f)< total(j) + costo(j) costo(f) = total(j) + costo(j) predecessore(f) = j dequeue(j,n) enqueue(j,f) Fonte: Elaborazione propria 26

37 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB In una prima fase, questo viene inizializzato, associando al nodo finale un costo infinito ed un predecessore NIL. Questo perché qualora non esistano cammini che conducano ad esso, il predecessore rimane NIL e quindi viene data comunicazione sull'assenza di soluzioni. Se al contrario esiste almeno un cammino che conduca ad esso, allora necessariamente il costo di questo sarà inferiore ad infinito e quindi il predecessore dell'ultimo nodo diverrà proprio l'ultimo nodo del cammino, come sarà chiaro tra poco. Segue l'inizializzazione di N, ovvero dell'insieme dei nodi che saranno considerati dall'algoritmo alla ricerca di cammini possibili fino al nodo finale. Partendo dal presupposto che ciascun nodo viene identificato dal luogo e dal momento in cui l'utente vi si trova sopra, nonché dalla tipologia di evento (trasferimento, pernottamento), i nodi iniziali vengono identificati con il luogo da cui l'utente intende intraprendere il proprio viaggio e con la tipologia di nodo impostata a pernottamento (effettivamente si può ragionevolmente supporre l'utente disponga di una propria dimora in cui alloggiare sino al momento della partenza). Tab. 2-1 Attributi dei Nodi ID Nodo Tipologia Nodo Luogo Istante Inizio Istante Fine Fonte: Elaborazione propria La flessibilità nelle date di partenza possibili viene in questo caso modellata per mezzo di differenti nodi iniziali, ciascuno fatto corrispondere alle ore 03:00 della giornata cui l'utente intenda partire. La scelta dell'orario, comunque parametro modificabile nel sistema è dovuta al fatto che partenze in un intorno della mezzanotte vengono tipicamente associate alla serata tarda del giorno precedente e quindi rischiano di portare a partenze in istanti eccessivamente anticipati per l'utente; il costo di tali nodi è ovviamente uguale a 0. Di seguito viene mostrata una rappresentazione grafica relativa ad un esempio di istanze nodi partenza. Sebbene il concetto possa forse risultare immediato e non necessario di un riscontro visuale, si vuole cogliere l'occasione per introdurre la metodologia impiegata per rappresentare visivamente il problema. 27

38 UN PRIMO MODELLO Fig. 2-2 Punti di partenza per la costruzione del grafo Fonte: Elaborazione propria Considerata la bidimensionalità dello spazio di rappresentazione, viene impiegato l'asse X (la larghezza della pagina in questo caso) quale indicatore temporale, mentre l'asse Y (altezza della raffigurazione) per indicare il luogo in cui si trova l'utente. Si noti la direzionalità degli archi, necessariamente da sinistra verso destra, per le ovvie implicazioni temporali di cui si è già fatta menzione. Una volta eseguita l'inizializzazione, entra in gioco l'algoritmo vero e proprio; dall'insieme N dei nodi visitati sino a quel momento (in questo caso i nodi di partenza), ne viene scelto quello con istante di partenza inferiore. Tale scelta è dovuta al fatto che essendo il primo ad iniziare, non potrà più avere archi entranti, dato che tutti gli altri nodi (inclusi tutti quelli che devono ancora essere scoperti) avranno istante di inizio (e quindi ovviamente anche di fine) successivi e non potranno più ricondurre ad esso. Il particolare appena descritto è probabilmente una delle considerazioni più significative del metodo qui proposto, poiché è qui che di fatto si può verificare una significativa differenza con l'algoritmo per la programmazione dinamica aciclica. La scelta di un elemento tra quelli non ancora visitati non è d'altronde un concetto nuovo; considerando il celebre algoritmo di Dijkstra [Cormen et al. 1990], si può notare come effettivamente i due possano essere considerati in qualche modo lontani parenti; in entrambi viene infatti scelto un nodo che sicuramente non potrà essere ulteriormente modificato, anche se l'elemento e le ragioni della scelta sono ovviamente differenti. Mentre nel nostro caso la scelta garantisce aciclicità, nel caso di Dijkstra la scelta è operata proprio per far fronte ad una condizione di possibile ciclicità già presente nel grafo. Scelto quindi il primo nodo, se ne determina il tipo. Dopo i nodi iniziali seguiranno necessariamente dei nodi trasferimento, cui seguiranno nodi pernottamento e così via in 28

39 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB una successione intervallata, sino al nodo pernottamento per l'ultima meta dell'utente. A questi seguirà un nodo di tipo speciale, definito ritorno (o return nell'algoritmo 2-1), poiché sarà sì un evento di trasferimento, ma che non sarà seguito da un ulteriore nodo di tipo pernottamento, bensì dal solo nodo finale. Fig. 2-3 Punto di arrivo nella costruzione del grafo Fonte: Elaborazione propria Qualora esso non sia un nodo di tipo ritorno (ovvero necessariamente un trasferimento, seguito dal solo nodo finale), vengono considerati tutti i possibili nodi seguenti (ovvero nodi che hanno inizio nel luogo medesimo del precedente, in un istante di tempo compatibile e che sono di tipo diverso, nell'ottica di una successione come quella precedentemente citata). Di questi nodi, qualora la loro tipologia, istante ed inizio siano la stesse, ne viene scelto quello dal costo minore, per mezzo della funzione findcheapestnode(), in cui diversi obiettivi vengono considerati nei modi che saranno tra poco esposti. Trovato dunque il nodo dal costo inferiore, se questo non fosse già presente in N, vi viene inserito (da ricordare che il grafo non è costruito a priori e che quindi gli stessi eventi saranno reperiti da ciascun nodo con tipologia, istante di fine e luogo identici). Gli attributi dello stesso vengono così definiti, a seconda del tipo di nodo considerato: Evento Trasferimento: il luogo del nodo viene impostato alla destinazione successiva all'attuale, scelta tra le mete ordinate dell'utente; l'istante di fine nodo viene fatto corrispondere ad un'approssimazione per eccesso dell'istante reale di fine dell'evento, rispetto agli istanti discreti del sistema precedentemente definiti (maggiori dettagli sulla gestione della successione di eventi vengono riportati di seguito). La tipologia di nodo infine viene impostata a trasferimento. Evento Pernottamento: il luogo del nodo viene impostato allo stesso del predecessore; l'istante di fine nodo viene calcolato aggiungendo semplicemente uno o più istanti discreti rispetto all'istante di inizio. La tipologia di nodo infine viene impostata a pernottamento. 29

40 UN PRIMO MODELLO Se invece il nodo era già presente in N (e quindi era già stato raggiunto da un altro cammino) viene effettuato un confronto tra il costo pregresso dello stesso ed il valore ottenuto dal cammino considerato. Arbitrariamente si è deciso che il costo degli archi venga ribaltato sui nodi uscenti e non su quelli entranti; risultati analoghi potrebbero essere ottenuti ribaltando i costi dei nodi sugli archi entranti. Discretizzazione del tempo e successione degli eventi Sebbene nella realtà venga tipicamente impiegato il minuto quale unità minima di misura temporale, rispecchiare tale convenzione nel modello proposto comporterebbe problematiche prestazionali notevoli, oltre che soprattutto una struttura del problema che mal si concilierebbe con i prerequisiti della programmazione dinamica ed in particolare con la necessità di ricorrenza dei sottoproblemi (Overlapping Subproblems). Se venisse infatti utilizzato il minuto come elemento temporale discriminante tra nodi, per ogni trasferimento è assai probabile il numero degli archi uscenti da ciascun nodo di tipo pernottamento coinciderebbe con il numero di opzioni di trasferimento effettivamente disponibili, anche nei casi in cui l'effettiva differenza tra opzioni disponibili fosse tutto sommato ininfluente nella risoluzione del problema (si pensi ad esempio al caso pratico, peraltro assolutamente possibile di due treni che partono con 10 minuti di distanza l'uno dall'altro e che anche giungono a destinazione con uno scarto temporale minimo; sebbene svolgano la stessa funzione, trasportando l'utente nei medesimi luoghi e con differenze temporali tutto sommato ininfluenti, richiederebbero a seguito una nuova completa analisi delle opzioni di pernottamento disponibili per ciascuno di essi). Considerando il fatto che ciò si ripeterebbe per ogni opzione di trasferimento disponibile e successivamente per ogni pernottamento (o sosta) in ogni luogo, si otterrebbe una situazione tutt'altro che auspicabile. Fig. 2-4 Eventi Ridondanti Fonte: Elaborazione propria 30

41 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Ad ogni trasferimento corrisponderebbe infatti un nodo relativo a sosta o pernottamento diverso e questo per ciascuna struttura ricettiva eventualmente disponibile in un aumentare progressivo dello spazio di ricerca, a crescita esponenziale sul numero di eventi, che renderebbe il problema intrattabile con approccio basato su programmazione dinamica, dato che il principio della necessità di ricorrenza dei sottoproblemi verrebbe palesemente invalidato. Se d'altronde fosse utilizzata la giornata intera come elemento discriminante tra gli istanti, potrebbero verificarsi almeno due tipi di problemi, derivati dello stesso fenomeno, ma con conseguenze rispettivamente indesiderabili e assolutamente inaccettabili. Per meglio far comprendere queste possibilità vengono mostrati due esempi. Nel primo caso si supponga un trasferimento che abbia termine alle ore 23:00 della giornata Z. Il giorno seguente l'opzione di trasferimento individuata quale migliore dal sistema è quella che parte alle ore 03:00. Viene ovviamente da chiedersi a questo punto se la meta stessa possa essere effettivamente considerata come tale, dato che l'utente non è stato in grado di assaporarne nemmeno lontanamente le peculiarità (essendo peraltro notte ed avendo probabilmente solo il tempo di trasferirsi dal luogo di arrivo a quello di partenza per la prossima tratta). Fig. 2-5 Inconveniente derivato da cattiva sincronizzazione di eventi Fonte: Elaborazione propria Ancora più grave la situazione che si può verificare quando l'istante di partenza precede quello di arrivo; questo tipo di situazione, apparentemente paradossale trova in realtà giustificazione nel modo in cui è modellata la necessità di reperire alloggio. Viene infatti considerato necessario reperire un luogo dove trascorrere la notte anche se l'arrivo in una certa località avviene dopo la mezzanotte (giunti in una città potenzialmente sconosciuta alle 04:30 è difficile qualcuno abbia la voglia di aggirarsi in luoghi a lui ameni a certe ore della notte). Per considerazioni simili, viene tuttavia considerato necessario disporre di un luogo dove trascorrere la notte anche qualora l'utente parta prima delle 04:30, poiché è quasi certo egli voglia comunque godere di qualche ora di sonno e poiché comunque non è consigliabile essere sprovvisti di un luogo ove alloggiare a certi orari. Ecco quindi che se un ipotetico volo giunge nella 31

42 UN PRIMO MODELLO città A il giorno j alle ore 04:00 il sistema ritiene necessario trovare un alloggio per la notte che viene considerata come relativa al giorno j-1. Ovviamente quando l'utente deve lasciare la città, il sistema individua le opzioni di trasferimento possibili per la giornata j, contemplando potenzialmente anche mezzi con istante di partenza antecedente alle 04:00 e che quindi partono prima che l'utente sia giunto nella città medesima. Fig. 2-6 Problema grave derivato da cattiva sincronizzazione di eventi Fonte: Elaborazione propria Certo, il primo e soprattutto il secondo caso possono essere considerati estremi, dato che la probabilità che queste coincidenze si verifichino è piuttosto bassa. Ad ogni modo il verificarsi della prima situazione decrescerebbe notevolmente l'utilità dello strumento, mentre la seconda lo renderebbe inutilizzabile nei contesti in cui questa si verificasse. Ecco quindi che è necessario evitare il verificarsi di simili situazioni; la strada migliore da percorrere sembra sicuramente quella di discretizzare il tempo in quantità superiori al minuto ed inferiori alla giornata. Con tale accorgimento si è così in grado di far fronte sia alla crescita smisurata del grafo, sia ai problemi di sincronizzazione tra eventi sopra descritti. Valori sensati di ciascuna finestra temporale possono essere considerati ad esempio 1, 4, 8 o 12 ore. Ad una durata inferiore di ciascun evento viene fatta corrispondere anche una durata minima che è possibile garantire per ciascun luogo visitato. Infatti i nodi di tipo pernottamento (che qualora gli istanti temporali assumano valori diversi da 12 ore possono anche essere definiti permanenza) hanno istante di inizio che corrisponde all'istante di fine discreto dell'evento precedente e istante di fine eguale alla somma di un certo numero di istanti discreti, sino a raggiungere la durata minima di permanenza in una località per l'utente. Gli istanti di inizio e fine della permanenza determinano in questo caso se questa sia ammissibile (anche discretizzando il tempo in unità temporali di 4 ore, è immediatamente comprensibile come non avrebbe comunque senso una sosta in una città dalle ore 04:00 alle ore 08:00) e se sia richiesta la contemplazione di una struttura ricettiva ove far alloggiare l'utente. Resta inteso che tale discretizzazione è limitata alla gestione delle successioni tra eventi e che invece vengono impiegati istante di inizio e fine, oltre che quindi durata reali quando si tratta di calcolare il costo di ciascun nodo. 32

43 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Giunto all'ultima meta del proprio itinerario (un'apposita lista di supporto,costruita in base alle preferenze dell'utente, permette di individuare il luogo da visitare successivo a quello dove questi si trova in ogni momento e quindi il susseguirsi delle destinazioni) è necessario trovare dei trasferimenti che riportino l'utente al luogo di partenza iniziale. Sebbene in un contesto reale tali eventi costituiscano dei trasferimenti di natura assolutamente identica agli altri precedentemente intrapresi dall'utente, nel modello proposto questi devono essere necessariamente contraddistinti per fornire all'algoritmo un'indicazione su quando non dev'essere ulteriormente cercata una struttura ricettiva nel luogo di arrivo. Infatti è bene ricordare che nell'elenco delle mete ciascuna di esse può comparire solamente una volta e questo perché per i principi della programmazione dinamica, in ogni nodo conosciamo solo uno dei cammini che possono aver condotto a quel determinato nodo. Così non fosse, ci sarebbe il rischio che le preferenze dell'utente in termini di luoghi da visitare possano non essere rispettate. Se infatti si presupponessero istanti di inizio diversi per il viaggio e tramite diversi cammini si giungesse allo stesso modo, in uno avendo già visitato k luoghi, in un altro k-n (con n>0), è assai probabile il costo del secondo cammino sia inferiore al primo e che quindi nella determinazione della parte successiva del cammino venga considerato in realtà un itinerario che non contempla tutte le destinazioni auspicate; ecco quindi che ogni meta deve comparire necessariamente al più una volta. I nodi relativi a trasferimenti di ritorno vengono infine istanziati quando è richiesto un trasferimento a partire dall'ultima località prevista dall'utente e questi sono trattati in modo diverso dagli altri, fatti seguire nella fattispecie dal solo evento finale. Una volta terminata la costruzione del grafo e annessa ricerca del cammino minimo, questo può essere mostrato ripercorrendo all'indietro il cammino minimo, grazie alle indicazioni sul predecessore di ciascun nodo, a partire proprio dal nodo finale. 2.6 Ottimalità con Molti Obiettivi Al paragrafo 2.5 si è citata la funzione findcheapestnode(), alludendo a come questa selezioni il trasferimento o il pernottamento ritenuti complessivamente più convenienti per l'utente. Nel caso del pernottamento, la scelta tra più alternative avviene unicamente sulla base del costo di una camera per il periodo considerato; tale tipo di modellazione trova giustificazione nel fatto che il decisore seleziona preventivamente gli hotel di proprio interesse, stabilendo in pratica una sorta di equivalenza tra le soluzioni possibili a parità di costo e lasciando conseguentemente quest'ultimo come unico termine di confronto per il sistema. In questo modo gli hotel disponibili vengono considerati come parametri decisionali e lo spazio di ricerca viene limitato secondo le preferenze impostate dal decisore; la ricerca del valore ottimo viene quindi riportata in un'unica dimensione, nella quale il confronto diretto risulta immediato. Agire diversamente e tentare di operare la selezione sull'intera gamma di strutture ricettive disponibili per via algoritmica, secondo il giudizio di chi scrive, non solamente risulterebbe complesso a causa dell'alto numero di parametri in gioco (distanza dell'hotel dai luoghi di interesse per l'utente, categoria dell'albergo, eventuali necessità specifiche come presenza di piscina o altre comodità), ma difficilmente riuscirebbe a tenere in 33

44 UN PRIMO MODELLO considerazione tutti gli aspetti non direttamente esprimibili in termini quantitativi che la scelta di uno piuttosto che di un altro albergo solitamente comporta; si pensi al giudizio che l'utente può essersi fatto relativamente ad una certa struttura, a seguito ad esempio di raccomandazioni ricevute o recensioni lette. Sarebbe certamente possibile, come approccio alternativo, permettere all'utente di dare un ranking a ciascuna struttura e combinare tale aspetto con quello economico in sede di selezione. Non sempre tuttavia le recensioni e le opinioni di terzi sono attendibili, per diversi fattori (diversità di background culturale, di aspettative, di periodo di visita, cambi di management delle proprietà, etc). Basta una rapida occhiata alle numerose recensioni sul sito tripadvisor.com per rendersi conto di come diverse persone possano avere giudizi completamente discordi per la medesima struttura. L'opinione finale dell'utente tenderà quindi sì ad essere univoca ed influenzata dall'una piuttosto che dall'altra recensione, tuttavia trattare in modo algoritmico dati sulla cui attendibilità si hanno comunque poche garanzie sembrava poco sensato; paradossalmente si sarebbe potuto rischiare, per seguire un ranking che potrebbe successivamente rivelarsi inesatto, di indirizzare un utente verso una struttura peggiore rispetto ad un altra, basandosi sul suo errato ranking, con il rischio di comportare anche un costo maggiore per lui. Limitando al fattore economico l'elemento di selezione per l'una piuttosto che l'altra struttura si evita questo problema e anzi, basandosi su un parametro assolutamente oggettivo come il costo, si è se non altro sicuri di non indirizzare l'utente verso una soluzione potenzialmente dominata. Decisamente diversa la questione nel caso dei trasferimenti, dove invece il margine di soggettività di una scelta è tipicamente inferiore, dato che gli aspetti preponderanti nella selezione di uno piuttosto che un altro mezzo sono facilmente esprimibili in termini quantitativi, sotto forma di costo del servizio e durata del trasferimento. Considerato il fatto che spesso il mezzo più veloce difficilmente sarà anche quello meno costoso, ci si trova tuttavia di fronte ad un'usuale ma comunque poco piacevole situazione di obiettivi in contrasto tra loro. In questi casi, considerando più funzioni obiettivo (2 nel nostro caso, n per generalizzare il concetto) del tipo min/max f1... fn, una soluzione y si dice dominata da un'altra soluzione x se fi(x) <= fi(y) Vi ed 3 k tc fk(x) < fk(y). Sicuramente ci si dovrà innanzitutto disinteressare delle soluzioni di questo tipo, ovvero nel nostro caso, delle soluzioni in cui esiste x tale per cui f1(x) < f1(y) e f2(x) <= f1(y) oppure f1(x) <= f1(y) e f2(x) < f1(y); le soluzioni contemporaneamente più costose e che comportano tempi di trasferimento più lunghi rispetto ad altre alternative non saranno sicuramente di alcun interesse per l'utente. La nostra ricerca si dovrà invece concentrare sulle restanti soluzioni, quelle non dominate, ovvero sull'insieme noto come l'insieme degli Ottimi di Pareto. La cardinalità comunque finita dell'insieme delle opzioni disponibili per ciascun trasferimento ci dà garanzia dell'esistenza di almeno una soluzione non dominata, tuttavia non c'è nessun elemento che ci permetta di poter invece stabilire l'univocità della stessa ed è quindi necessario affrontare il problema relativo alla selezione della soluzione finale da fornire all'utente, tra quelle nell'insieme degli ottimi di Pareto. Diversi approcci vengono tipicamente adottati in situazioni come questa: in particolare è possibile trasformare uno dei due obiettivi in un vincolo, ordinare gli obiettivi in ordine lessicografico, oppure aggregare più obiettivi, combinandoli in modo convesso, che di 34

45 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB fatto è quanto avviene nel modello presentato. La scelta che motiva questo approccio deriva dal fatto che, considerata la variabilità delle tariffe aeree soprattutto, sarebbe molto difficile riuscire a trasformare obbiettivi in vincoli in modo efficiente; l'ordine lessicografico risulta invece piuttosto rigido e, secondo il parere di chi scrive, buono strumento solo quando l'ordine di preferenza è assoluto. Volendo esemplificare il concetto, con un caso molto diretto, se l'oggetto di selezione fosse la scelta di un trasferimento aereo, ma le funzioni obiettivo da minimizzare e massimizzare fossero rispettivamente il costo del biglietto e la succulenza dei pasti a bordo, l'ordinamento lessicografico degli obiettivi andrebbe quasi sicuramente bene. Nel nostro contesto, invece, in cui questa condizione non sussiste sarebbe assolutamente rischioso combinare gli obiettivi in questo modo; si pensi ad esempio se ordinando gli obiettivi come spesa minore, durata di trasferimento, venisse suggerito un mezzo di trasporto che costa magari 1 solo euro in più ma che impiega mezza giornata in più per raggiungere la propria destinazione. Certo, il caso qui è estremo, però di fatto nulla esclude che casistiche come questa possano presentarsi e la cosa non può certamente essere tollerabile nel nostro contesto. Ecco quindi che la scelta finale è ricaduta sulla combinazione convessa; questa sembra sicuramente la strada più promettente, seppure non esente da pecche; la perdita di soluzioni è infatti uno dei problemi noti cui si può incorrere facendo uso di questa tecnica; comparando tuttavia gli svantaggi delle altre due tecniche con la possibile perdita di soluzioni, quest'evenienza sembra sicuramente il minore dei mali. Per mezzo della combinazione convessa, ci si riporta ad un'unica funzione obiettivo, tramite un'aggregazione di obiettivi come combinazione lineare, del tipo: L'importanza di ciascun obiettivo viene scandita dall'entità del coefficiente alfa; ad un valore maggiore dello stesso corrisponde una più accentuata predilezione verso il relativo obiettivo nella scelta della decisione. Nel nostro caso all'obiettivo riguardante la minimizzazione del prezzo è sempre associato un coefficiente alfa = 1, mentre a seconda delle preferenze del decisore viene fatto variare il coefficiente relativo alla durata dei trasferimenti. In particolare viene associato un valore per ciascuna ora di viaggio e inconsapevolmente l'utente dà una valutazione del proprio tempo. La determinazione dei valori del coefficiente alfa al variare delle preferenze utente è avvenuta in maniera principalmente empirica, secondo le modalità che saranno descritte nel prossimo capitolo. 35

46 UN PRIMO MODELLO Perdita di soluzioni con combinazione convessa La generazione di diversi ottimi di Pareto avviene nella combinazione convessa variando in tutti i modi possibili i diversi coefficienti alfa. Una problema di tale tecnica è tuttavia che esistono alcuni ottimi di Pareto, che per le proprietà geometriche del metodo non possono essere generati. Fig. 2-7 Combinazione convessa Fonte: Elaborazione propria Risolvere una funzione in cui gli obiettivi sono combinati linearmente è infatti equivalente a minimizzare una funzione lineare su un insieme S; come rappresentato in figura, i minimi della funzione apparterranno necessariamente alla frontiera dell'inviluppo convesso dell'insieme S; per questo motivo, gli ottimi di Pareto che non si trovano tra questi punti non potranno essere mai generati. 2.7 Correttezza e complessità del modello proposto La correttezza dell'algoritmo presentato deriva dai principi della programmazione dinamica ed in particolare dal fatto che, considerata l'aciclicità del grafo, costruito sulla base del susseguirsi degli eventi, le soluzioni dell'equazione di Bellman coincidono con i valori ottimi dei cammini per ogni nodo del grafo. Garanzia di terminazione è data dalla necessità di intervallarsi di eventi tra permanenze e trasferimenti. Ciascun trasferimento deve condurre ad una località successiva alla seguente in una lista ordinata e finita di mete predefinite e quindi dopo un numero finito di passi il nodo finale sarà raggiunto. Tale garanzia non può ovviamente essere fornita qualora una meta venga ripetuta più di una volta nella lista delle destinazioni inizialmente fornita dall'utente, poiché ci sarebbe il rischio di innescare meccanismi di visita ciclica 36

47 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB sulle stesse mete e quindi cammini di lunghezza infinita. Il requisito fondamentale che le mete dell'utente siano uniche e che la città di partenza/destinazione del viaggio non compaia tra le tappe intermedie scongiurano questa possibilità. Dal punto di vista della complessità computazionale, il problema appartiene sicuramente alla classe dei problemi P, ovvero risolvibili in tempo polinomiale sull'input. In particolare, per ciascun giorno dell'intervallo consentito per la partenza g, per ciascuna meta da considerare m, avviene l'interrogazione al database ed il reperimento di eventi compatibili in base a data ed ora; l'impiego di indici (specificatamente B-Tree, come sarà esplicato nel prossimo paragrafo) permette l'individuazione di record compatibili in tempo logaritmico rispetto al numero degli eventi disponibili (x); a questo punto viene comunque fatta una scansione lineare di questi per capirne l'effettiva compatibilità (c). La complessità finale dell'algoritmo diventa quindi: O(m g (log x + c)). 37

48

49 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Capitolo 3 IMPLEMENTAZIONE Sulla base del modello presentato nel precedente capitolo è stato realizzato un prototipo di sistema web-based, raggiungibile presso l'url: in grado di fornire all'utente un'indicazione su quello che è l'itinerario per lui più conveniente. Scopo di questo capitolo è quello di descrivere quanto realizzato e di motivare le scelte intraprese, oltre che menzionare le difficoltà implementative riscontrate e le soluzioni proposte. Il codice sorgente di questo capitolo sarà in forma rivista, privo di commenti (dato che questi saranno forniti in forma estesa nella descrizione dello stesso) e di costrutti specifici del linguaggio (es. il precedere del simbolo $ ad ogni nome di variabile); si rimanda il lettore in appendice per le parti significative di codice sorgente originali, commentate. 3.1 Architettura del prototipo Il prototipo realizzato si basa su di una tipica struttura 3-tiered, in cui le interfacce utente sono presentate attraverso comune browser. Fig. 3-1 Architettura del sistema Fonte: Elaborazione propria 39

50 IMPLEMENTAZIONE Attraverso chiamate GET o POST su protocollo http, vengono fatte richieste per le risorse presenti sul web server remoto. A seconda della tipologia di file richiesto (la determinazione avviene sulla base dell'estensione del file nel URL), il web server capisce se deve fornire direttamente la risorsa oppure far eseguire il parsing e quindi l'esecuzione della stessa ad un interprete; lo Zend Engline II, questo il nome commerciale di tale interprete (comunque distribuito con licenza GPL), esegue i file di tipo php che di fatto contengono la logica dell'applicazione, fornendo in risposta al client i dati richiesti, in forma di documenti html, interpretabili quindi dai browser che ne hanno fatto richiesta. Considerata la mole di dati trattati, si è deciso di utilizzare un DBMS per la memorizzazione degli stessi; tra le alternative Open Source si è deciso di utilizzare Mysql nella versione 5, che attraverso le tabelle di tipo INNODB è comunque in grado di fornire strumenti quali indici ed integrità referenziale, offrendo peraltro discrete prestazioni. 3.2 Interazione con l'utente Considerato il fatto che il sistema è stato sviluppato attorno ad un algoritmo e che lo scopo dello stesso è quindi univoco, l'interazione con l'utente risulta quantomai immediata. Fig. 3-2 Use Case Fonte: Elaborazione propria In un tipico scenario di utilizzo l'utente dapprima fornisce indicazioni al sistema su quelle che sono le mete che intende visitare, per poi impostare i parametri relativi alle proprie preferenze, quindi selezionare le strutture ricettive di proprio interesse e quindi consultare i risultati proposti. 40

51 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Fig. 3-3 Diagramma di sequenza interazione utente Fonte: Elaborazione propria La prima interfaccia cui l'utente si trova di fronte è quindi quella in cui egli inserisce le mete di suo interesse nell'ordine di visita. Contestualmente egli può anche selezionare se per ciascuna meta necessiterà di una struttura ricettiva che sarà quindi reperita automaticamente per lui dal sistema oppure se dispone già di un luogo in cui pernottare. 41

52 IMPLEMENTAZIONE Fig. 3-4 Interfaccia inserimento mete Fonte: Elaborazione propria Per ciascuna meta egli indica inoltre il numero di notti minimo e massimo che intende trascorrere. Per le considerazioni fatte al capitolo precedente, ogni meta può essere specificata univocamente e la città di partenza / ritorno dell'itinerario non può comparire anche tra le mete da visitare. Tali selezioni vengono memorizzate in una tabella del database utilizzato da supporto all'applicazione; da notare che l'identificativo della sessione in corso, nonché l'identificativo della destinazione costituiscono una chiave primaria della tabella, impedendo così, già a livello strutturale la possibilità che un utente ripeta la stessa meta più di una volta nell'impostazione delle proprie scelte. ID_Sessione ID_Meta Ordine Min Max Servehotel Un ulteriore campo ordine tiene conto dell'ordine di visita impostato dall'utente, mentre nei campi Min e Max vengono memorizzati rispettivamente il numero di notti minime e massime che l'utente intende spendere in ciascuna località; Servehotel è un campo di tipo booleano in cui viene memorizzata la preferenza dell'utente relativa alla necessità o meno di reperire una struttura ricettiva in una particolare meta. Si noti che, qualora sembrasse poco sensato permettere all'utente di impostare un numero variabili di notti, se l'obiettivo della ricerca è comunque una funzione da minimizzare, si pensi che c'è innanzitutto da tenere conto che potrebbero non esservi ad esempio voli o treni quotidiani tra la meta in oggetto e la successiva ed inoltre che la sosta di una notte in più sommata al trasferimento successivo, potrebbe costare meno che il solo trasferimento 42

53 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB successivo anticipato; un soggiorno da 7 notti potrebbe inoltre costare uguale o meno di uno da 6, per le promozioni sulle permanenze settimanali che talvolta fanno gli hotel. Completata la propria selezione in questa prima interfaccia, ad ogni modo, l'utente è diretto ad un'ulteriore maschera per l'inserimento di parametri. Fig. 3-5 Interfaccia inserimento opzioni di viaggio Fonte: Elaborazione propria In questa seconda interfaccia l'utente specifica le date valide per la partenza, la città dalla quale inizierà e nella quale si concluderà il proprio itinerario, il numero di viaggiatori, la classe preferita per gli spostamenti e le categorie da considerare per gli alberghi. Per mezzo di una casella a scelta multipla egli può inoltre indicare in quale misura egli è interessato a minimizzare il costo del proprio viaggio, rispetto a minimizzare il tempo necessario per gli spostamenti. Come si accennava nel paragrafo precedente e come sarà comunque ripreso in seguito, è in questo istante che viene impostato il valore del coefficiente alfa per la combinazione convessa dei diversi obiettivi da minimizzare. Un'ulteriore opzione disponibile per l'utente è la possibilità di indicare istanti temporali in cui egli preferirebbe tendenzialmente evitare trasferimenti. Anche tutti questi parametri sono salvati in una tabella temporanea chiamata datisessione e che presenta la stessa struttura; in questo caso i campi ID_Sessione e Parametro non sono intesi da soli come chiave primaria, dato che l'utente può definire molteplici valori 43

54 IMPLEMENTAZIONE preferenziali per alcuni attributi (es. intervalli orari da evitare per gli spostamenti). ID_Sessione Parametro Valore L'univocità dei record relativi a parametri che prevedono un solo valore è garantita a livello software controllando la cardinalità delle tuple corrispondenti ad una certa coppia ID_Sessione, parametro e a livello database da tutti i campi di ciascun record. Un'ultima opzione disponibile in questo prototipo è inoltre il livello di verbosità dell'output, che può variare da un livello standard (emulando gli output forniti dai tipici sistemi informatizzati per la prenotazione di voli e alberghi) ad un livello debug, in cui vengono mostrate le singole query effettuate al database; tra i due livelli c'è il livello verboso, attraverso il quale vengono tralasciati gli aspetti relativi alla comunicazione con il database ma vengono invece riportati i valori intermedi di ciascun nodo. In base ai parametri impostati durante questa fase, all'utente viene data la possibilità di selezionare una o più strutture ricettive da considerare nella ricerca per ciascuna città. La scelta di prospettare una preventiva selezione per l'utente deriva dal fatto che spesso alla selezione di una struttura ricettiva piuttosto che di un'altra concorrano molteplici fattori, spesso difficilmente quantificabili, come ad esempio la posizione o le raccomandazioni ricevute. 44

55 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Fig. 3-6 Interfaccia selezione strutture alberghiere Fonte: Elaborazione propria Ecco dunque che dando all'utente la possibilità di scegliere tra un certo numero di strutture preventivamente filtrate si ha comunque la sicurezza di trovare la tariffa migliore per l'utente, limitatamente a strutture in cui si sia certi egli sia disposto a trascorrere pernottamenti. Contestualmente a ciascun albergo vengono resi disponibili i parametri che tipicamente sono considerati nella selezione dell'una piuttosto che dell'altra struttura; in particolare viene fornita un'indicazione sulla categoria, una descrizione della struttura, indicata la posizione, citati i servizi che questa offre e soprattutto riportato il prezzo medio e specifico di ciascuna notte, così da fornire all'utente un numero sufficiente di informazioni per poter fare le proprie scelte. Questo tipo di approccio è peraltro lo stesso adottato dalle agenzie di viaggio online, che forniscono un elenco di strutture con relativi prezzi, piuttosto che scegliere indipendentemente per l'utente finale; il beneficio del prototipo proposto, in questo caso è che di fronte a molteplici scelte equivalenti per l'utente (così sono effettivamente le 45

56 IMPLEMENTAZIONE selezioni fatte), questi restituisce sicuramente la soluzione più economica. Interessante considerare in questo contesto una pratica funzionalità offerta dal linguaggio php 5 utilizzato in sede implementativa, ovvero la possibilità di creazione dinamica di variabili e reperimento del relativo valore. Uso di tale tecnica è stato necessario per la selezione degli hotel, dato che il numero degli stessi non era predeterminato, così di conseguenza il numero dei controlli sulla form di selezione e quindi di riflesso il numero delle variabili da trattare nella pagina successiva. Per fare uso di tale tecnica, nella pagina di selezione delle strutture ricettive si è creata dinamicamente ciascuna check box, per mezzo del costrutto: <input name="h<?php echo $x;?>" type="checkbox" value="<?php echo $id[$x];?>"> con il contatore x a tenere traccia del numero di controlli creati e memorizzazione del dato stesso in un controllo di tipo INPUT: <input name="limite" type="hidden" id="limite" value="<?php echo $x;?>"> Il contatore è stato quindi impiegato per definire il numero massimo di controlli creati e costituire il limite di un ciclo for nella pagina successiva, in cui le variabili hn con N indice d'iterazione nel ciclo venivano costruite dinamicamente e appunto attraverso le peculiarità del linguaggio php ne veniva estratto il valore. for ($c=0; $c<$_get['limite']; $c++) { $nomevar = "h".$c; $hotel = $_GET[$nomevar]; if (strlen($hotel)>0 && is_numeric($hotel)) $hotels[] = $hotel; } Reperito il valore di queste variabili, se esso assumeva valore NULL, allora significava che l'albergo alla posizione N nella pagina precedente non era stato selezionato e non andava quindi considerato; altrimenti se questo valore era diverso da NULL, esso conteneva proprio l'id della struttura ricettiva da considerare in seguito nella costruzione delle soluzioni. 46

57 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Una volta terminata la selezione delle strutture ricettive di proprio interesse, viene avviata la ricerca vera e propria e l'utente viene quindi portato alla pagina con i risultati, preceduta eventualmente da una schermata animata in cui egli viene avvisato della possibile attesa per la soluzione, dato che la ricerca potrebbe impiegare qualche secondo. Fig. 3-7 Schermata di notifica possibili attese nella presentazione dei risultati Fonte: Elaborazione propria L'adozione di una simile tecnologia evita che altrimenti l'utente non vedendo caricare la pagina dopo alcuni secondi abbandoni l'utilizzo del sistema, magari proprio quando la soluzione stava per essergli fornita. Una volta che il sistema ha portato a termine l'elaborazione dei dati e ricavato una soluzione, questa viene presentata all'utente come un susseguirsi di eventi, sui quali vengono fornite le informazioni principali; a seconda del tipo di evento vengono riportate: per gli hotel: il nome, la città e l'ubicazione dello stesso, le date precise di pernottamento, la categoria, nonché il prezzo per ciascuna notte e complessivo. per i trasferimenti: vengono forniti gli estremi del viaggio (città di partenza, arrivo), l'ora di partenza e la durata del viaggio. 47

58 IMPLEMENTAZIONE Fig. 3-8 Schermata di presentazione dell'output Fonte: Elaborazione propria 3.3 Strutture dati Oltre alle strutture dati proprie del DBMS impiegato, su cui saranno in ogni caso riportate alcune considerazioni in seguito, ma che comunque rimangono esterne all'applicazione, il tipo di struttura dati maggiormente impiegato nell'applicazione è sicuramente l'array associativo. Un array associativo ( detto anche associative container, map, mapping, hash, dictionary, finite map o lookup table) è un tipo di dato astratto composto da una collezione di chiavi e valori, in cui ogni chiave è associata ad un valore, in una relazione tipicamente detta di mapping o binding. 48

59 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Da notare che nell'implementazione utilizzata, ovvero quella del linguaggio php5, anche i valori possono essere degli array, eventualmente a loro volta associativi. Fig. 3-9 Rappresentazione array associativi Fonte: Elaborazione propria L'operazione di ricerca di un valore associato ad una chiave è chiamato lookup ed è sicuramente la più importante messa a disposizione da questo tipo di strutture, nonché quella di cui ne sono sfruttate le potenzialità nel nostro contesto. Gli array associativi possono essere infatti considerati come degli indici; non ci sono limitazioni sulla definizione dinamica delle chiavi, in base ad esempio alle proprietà dell'elemento (o degli elementi, se si ha a che fare con array contenuti in array). Questo importante dettaglio permette di individuare in maniera diretta un elemento contenuto all'interno di un array in base alle proprie proprietà, anziché in base all'offset della posizione di memoria dove questo è contenuto, come avviene solitamente con gli array tradizionali. Quando non si conosce a priori la posizione dell'elemento che si vuole considerare, ma si conoscono le caratteristiche dello stesso, attraverso gli array associativi è quindi possibile un rapido reperimento (costruendo la chiave sulla base delle caratteristiche stesse dell'elemento e di conseguenza del proprio contenuto). Questo è quanto avverrà nel nostro contesto, in sede di confronto tra nodi attuali e nodi già visitati, nella maniera esposta nei prossimi paragrafi, consentendo peraltro un notevole miglioramento prestazionale, dato che altrimenti, come sarà sicuramente più chiaro in seguito, per ciascun nodo si sarebbero dovuti scandire tutti gli elementi precedenti ed individuare eventi compatibili, prima di poter effettuare un confronto sul costo dell'evento stesso e quindi applicare i principi della programmazione dinamica. 49

60 IMPLEMENTAZIONE 3.4 Inizializzazione delle variabili relative a mete e preferenze Attraverso le interfacce considerate nel paragrafo 3.3 vengono definiti e memorizzati in tabelle temporanee tutti i parametri necessari ad effettuare la ricerca. Ecco quindi che precedentemente all'esecuzione dell'algoritmo queste preferenze vengono reperite, decodificate e quindi rese disponibili all'algoritmo nei modi che seguono. Viene quindi creato un array pref in cui la chiave identifica il parametro considerato e in cui il valore dello stesso è a sua volta un array; nel caso di parametri dal valore univoco (es. numero di persone coinvolte nel viaggio, classe desiderata per gli spostamenti) tale array interno ha un solo elemento, mentre nel caso di parametri che prevedono più valori (nella fattispecie le fasce orarie da evitare per gli spostamenti), il numero degli elementi dipende direttamente dalle preferenze dell'utente. Tale meccanismo è implementato tramite una chiamata di questo tipo: for (c=0; c<tuple_tabella_datisessione; c++) { } pref[parametro[c]][] = valore[c]; Si noti l'impiego del costrutto [], il quale indica al linguaggio php di accodare il valore reperito in coda all'array corrente e invece l'indicazione parametro relativa alla prima chiave dell'array, che indica in quale posizione vada inserito l'elemento. Una simile implementazione riguarda il reperimento delle mete per l'utente; anche per queste viene utilizzato un array in cui la chiave è l'identificativo della città considerata, mentre il valore definito come array associativo (con chiavi 'min', 'max', 'servehotel'), contiene rispettivamente il numero di notti minime e massime, come già introdotto al paragrafo 3.2. for (c=0; c<tuple_tabella_mete; c++) { } mete[citta[c]]['min'] = valore[c]; mete[citta[c]]['max'] = valore[c]; mete[citta[c]]['servehotel'] = valore[c]; Per velocizzare operazioni di successivo accesso ai dati, viene inoltre creato un array tradizionale in cui sono contenuti come elementi gli identificativi delle città da visitare, ovvero le chiavi dell'array mete. A tale array viene preposto l'identificativo della città di partenza. 50

61 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Considerata la bassa cardinalità dell'insieme delle città, per migliorare le prestazioni in sede di presentazione dei risultati, evitando costose operazioni di JOIN tra più tabelle, viene inizialmente anche definito un array denominato località, nel quale all'id di ciascuna città è fatto corrispondere la propria denominazione. In questo modo, in sede di visualizzazione è sufficiente richiedere l'elemento dell'array località nella posizione corrispondente all'identificativo della città considerata, così da avere un reperimento immediato del dato. Ovviamente con insiemi di cardinalità superiore tale metodologia non potrebbe essere applicata, dato il consumo di memoria spropositato che richiederebbe. 3.5 Implementazione Algoritmica Considerata la semplicità dell'interazione con l'utente ed anche la specificità delle finalità del sistema, senza alcun dubbio la parte maggiormente meritevole di descrizione è quella algoritmica, dato che è in questo contesto che si è maggiormente concentrata l'attenzione di chi scrive. A partire dallo pseudocodice presentato nel capitolo precedente vengono ora descritti passo per passo i dettagli implementativi delle soluzioni adottate. costo[f] = INF; predecessore[f] = NIL; initialize(n) In questo primo insieme di istruzioni avviene l'inizializzazione dell'array associativo denominato $processati in sede implementativa; questo viene semplicemente definito come un array (nelle specifiche del linguaggio php impiegato non è necessario indicare esplicitamente si tratti di un array associativo) e ne viene contemporaneamente creato un elemento, nonché definita una delle proprietà che lo caratterizzano; nella fattispecie l'elemento è chiamato 0-finale e il valore INFINITO (una costante con valore arbitrariamente elevato, tale da essere comunque maggiore al costo di qualsiasi itinerario proponibile) viene associato a questo elemento. Così facendo si crea l'ultimo nodo di qualsiasi cammino di ricerca e vi si associa valore infinito; se questo sarà raggiunto da un qualsiasi cammino, allora il valore di questo sarà sicuramente inferiore rispetto ad INFINITO e quindi il predecessore del nodo $processati[ 0-finale ] sarà impostato sull'ultimo nodo del cammino. Le specifiche righe di codice che implementano quanto descritto sono di seguito proposte: processati = array(); processati['0-finale']['totale'] = INFINITO; 51

62 IMPLEMENTAZIONE Si noti che invece l'impostazione esplicita di predecessore nullo evidenziata nello pseudocodice per chiarezza, non è necessaria in php, dato che la mancata creazione esplicita di un elemento chiamato [ predecessore ] in senno all'array $processati['0- finale'], automaticamente ne determina il valore NULL. Dopo avere quindi inizializzato il nodo finale, si passa all'inizializzazione di quelli che sono i nodi iniziali; sarà da almeno uno di questi che l'eventuale cammino sino al nodo finale (la parola eventuale è utilizzata in questo caso poiché un simile cammino potrebbe non esistere) avrà inizio. giorno_partenza = preferenza[giorno_partenza_min] intervallo_partenza = preferenza[giorno_partenza_max] - preferenza[giorno_partenza_min] for (x = 0; x<(intervallo_partenza+1); x++) { id_nodo_iniziale = PERNOTTAMENTO. "-".preferenza[luogo_partenza]. "-0-".(giorno_partenza+x); } nodi[id_nodo_iniziale]['id'] = id_nodo_iniziale; nodi[id_nodo_iniziale]['tipo'] = PERNOTTAMENTO; nodi[id_nodo_iniziale]['predecessore'] = "I"; nodi[id_nodo_iniziale]['totale'] = 0; nodi[id_nodo_iniziale]['luogo']= preferenza[luogo_partenza]; nodi[id_nodo_iniziale]['inizio'] = 0; nodi[id_nodo_iniziale]['fine'] = istante_partenza+x; nodi[id_nodo_iniziale]['costo'] = 0; nodi[id_nodo_iniziale]['tipo_servizio'] = 0; nodi[id_nodo_iniziale]['id_servizio'] = 0; nodi[id_nodo_iniziale]['ritorno'] = 0; Per ciascun giorno di partenza ammissibile viene generato innanzitutto un identificativo di nodo; gli attributi che compongono tale identificativo sono nell'ordine: un ID del tipo di nodo (PERNOTTAMENTO in questo caso), un ID del luogo in cui ci si trova nel nodo, l'istante di inizio dell'evento contemplato dal nodo (0 in questo caso) e un istante di fine per il nodo stesso (in questo caso ciascun giorno ammissibile). Si noti che per semplicità, in questa descrizione la giornata è stata assunta quale elemento discretizzante per eventi successivi dello stesso tipo dallo stesso luogo, nonostante le problematiche che una tale scelta può comportare a livello pratico; una descrizione specifica sul trattamento delle coincidenze e quindi sulla discretizzazione temporale così come sono state effettivamente implementate nel prototipo presentato avverrà in un prossimo paragrafo; una discretizzazione più densa in questo contesto avrebbe d'altronde inutilmente complicato questa prima prima descrizione. All'inizializzazione segue dunque il ciclo che rappresenta di fatto la parte significativa dell'algoritmo. Considerata la stretta correlazione tra le operazioni contenute all'interno del ciclo, una trattazione completa delle stesse in ordine sequenziale rischierebbe di rendere difficoltosa la comprensione dell'algoritmo nel suo insieme. Ecco dunque che seguirà un'analisi con approccio di tipo top-down; sarà dapprima analizzato il ciclo nel suo complesso, mentre poi successivamente saranno approfondite le singole operazioni. 52

63 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB while N!= O let j = earliest(n); if type(j)!= return i = findcheapestnode(!type(j)) if (i! N) enqueuenode(i,n) else if total(i)< total(j) + costo(j) predecessore(i) = j costo(i) = total(j) + costo(j) else if total(f)< total(j) + costo(j) costo(f) = total(j) + costo(j) predecessore(f) = j dequeue(j,n) enqueue(j,f) Un loop controllato da costrutto while esegue un certo numero di istruzioni fino a che l'array associativo nodi, precedentemente introdotto, risulta vuoto. Uno alla volta viene estratto dall'array il nodo con inizio antecedente rispetto a tutti gli altri presenti e considerato quale punto di partenza per l'esplorazione degli elementi che possono immediatamente succederlo, reperiti in maniera dinamica, attraverso interrogazione a DBMS esterno. La garanzia che nessun altro nodo possa portare a quello correntemente analizzato è data dal fatto che iniziando prima di tutti gli altri, non ve ne potrà essere sicuramente un altro che abbia terminazione antecedente, né potrà ovviamente così essere per tutti i relativi successori di questi. Per ciascun nodo progressivamente considerato (denominiamo in questo caso nodo A il nodo corrente) vengono quindi accodati nell'array nodi quegli eventi che risultano compatibili con esso, ovvero quei nodi che hanno inizio nel luogo medesimo in cui il nodo considerato termina e istanti di inizio immediatamente successivi a quello di fine dell'evento del nodo attualmente considerato. A dire il vero non sono aggiunti tutti i nodi trovati, ma per mezzo dell'utilizzo degli array associativi (questo è uno dei punti specifici in cui il loro utilizzo si rivela particolarmente utile), attraverso una discretizzazione temporale, uno solo tra gli eventi estratti dal database troverà spazio nella struttura del grafo e si concretizzerà quindi in un nodo (per future referenze, chiamiamo questo nodo B). La selezione dell'evento più conveniente avverrà tra gli eventi compatibili, ovvero tra quelli estratti dal database a seguito di query specificamente formulate per restituire eventi compatibili con il nodo A; tra tutti gli eventi considerati, per ciascuna terna luogo,istante inizio, istante fine evento nel grafo rimarrà un unico nodo (l'evento selezionato sarà quello a costo complessivo minore); è in questo momento che entra in gioco la procedura 53

64 IMPLEMENTAZIONE findcheapestnode(), selezionando il nodo migliore per l'utente per ciascun intervallo di tempo discreto considerato. Nell'applicazione prototipizzata realizzata, in particolare tali slot temporali hanno durata di 12 ore (è quindi possibile vi siano al massimo due nodi trasferimento nell'arco di una stessa giornata da un luogo ad un altro); dettagli su come avverrà la selezione degli eventi selezionati per questi intervalli saranno forniti di seguito. Ad ogni modo, è bene notare quanto si rivelino particolarmente utili gli array associativi in questo caso, poiché permettono attraverso i tre attributi sopra menzionati, oltre che il tipo di nodo, di riferirsi direttamente ad uno specifico nodo nel grafo, anziché doverli visitare tutti, effettuando le necessarie verifiche sui relativi attributi. id_nuovo_nodo = PERNOTTAMENTO. -".nodo['luogo']."-".inizio."-".fine; Individuato quindi l'evento più conveniente ed associato ad esso un ID sulla base dei propri attributi, lo step successivo dell'applicazione, come sarà mostrato nei dettagli in un prossimo paragrafo, sarà quello di individuare l'esistenza di un nodo con ID uguale a quello generato ed in base a ciò capire se inserire il nodo o eventualmente limitarsi a modificarne i parametri ove ritenuto necessario. L'esistenza di un simile nodo implicherebbe infatti che il nodo fosse stato preventivamente raggiunto da altri cammini ed in questo caso ne viene eseguito un confronto per verificare se il costo totale di tale nodo (B) è superiore al costo che si avrebbe sommando al costo del cammino sino al nodo A, il costo del nodo A stesso. Qualora tale valore risulti inferiore a quello correntemente associato al nodo B, quest'ultimo nodo viene aggiornato negli attributi costo e precedessore con quelli derivati dal nodo A; in caso contrario non avvengono aggiornamenti e il cammino termina sul nodo A, di fatto decretando la fine di una possibile strada di ricerca. Nodi di tipo pernottamento e trasferimento si succedono in ordine alternato, a partire dai nodi partenza, trattati come comuni pernottamenti, sino a quando un confronto tra il nodo attualmente considerato e la lista delle mete da visitare non rivelerà che ci si sta trovando all'ultima meta da considerare; in questo caso viene creato un nodo trasferimento di tipo particolare, che segnala il fatto di essere all'ultimo evento del viaggio. Quando nodi di questo tipo vengono selezionati dalla procedura earliest sulla lista N dei nodi ancora da considerare, gli viene fatto succedere il nodo finale inizialmente creato e avviene il consueto controllo sul costo, aggiornando quindi l'eventuale migliore cammino. Da notare che tutti i nodi analizzati, vengono inseriti nell'array denominato processati e questo perché l'array nodi viene in realtà consumato mano a mano e quindi al termine del cammino, se ci si basasse esclusivamente su questo, non si sarebbe altrimenti in grado di ricostruire il percorso effettuato. processati[nodo['id']] = nodo; 54

65 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB 3.6 Fetching dei dati Per ogni nodo visitato si è precedente accennato alle interrogazioni effettuate su database, per il reperimento di eventi compatibili in successione a quello attuale; i risultati di queste query vengono memorizzate in strutture temporanee in memoria, cui è stato dato il nome di eventi e implementate per mezzo di array associativi. La struttura di ciascun evento, indipendentemente dalla tipologia dello stesso è la seguente: Attributi di ogni evento id_evento inizio durata costo Il campo id_evento contiene l'id della specifica tratta o specifico hotel presso il quale l'evento si compie; l'inizio e la durata dell'evento sono i relativi valori reali relativi all'evento (rappresentazione in forma di data per il primo; numerica intera, in minuti per il secondo) ed il costo assume l'ovvio valore. I valori di ciascun evento sono ottenuti attraverso query SQL. Di seguito viene riportata una descrizione delle query eseguite, suddivise per tipologia di eventi reperiti. Si noti che i parametri preceduti da simbolo * sono parametri forniti alla query al runtime. nel caso degli hotel l'interrogazione al database cerca la disponibilità ed il relativo costo costo complessivo nel periodo considerato per le camere messe a disposizione da uno degli alberghi preventivamente selezionati dall'utente nel periodo interessato; la finestra temporale è generata sulla base della data di arrivo e del numero di notti che l'utente intende spendere in un certo luogo. Chiaramente dove siano presenti un numero di notti minime e massime da spendere, il numero di nodi restituiti e quindi di query effettuate sarà pari a: notti massime notti minime. SELECT hotel.id as albergo, sum(costo) as totale, min(giorno) as arriva, max(giorno) as lascia FROM hotel,citta, tariffe_hotel WHERE tariffe_hotel.hotel_id = hotel.id AND numpersone= *numero_persone AND hotel.citta_id = citta.id AND giorno >= *giorno_arrivo AND giorno < *giorno_partenza AND citta.id = *id_città AND (hotel.id = *hotel_1 OR [..] OR hotel.id = *hotel_n) GROUP BY hotel.id ORDER BY totale ASC 55

66 IMPLEMENTAZIONE LIMIT 0,1 Vengono quindi restituite tuple di questo tipo: id_hotel costo arriva lascia che riportano indicazioni sull'id dell'albergo cui la quotazione si riferisce, del costo della camera per il numero di persone richiesto per il periodo e delle notti rispettivamente di inizio e fine soggiorno. Da notare che l'elenco di condizioni sull'id degli hotel da considerare, concatenate per mezzo di OR è generata ovviamente in modo dinamico e che considerata l'equivalenza tra hotel selezionati, solo la prima tupla restituita sarà presa in considerazione, in quanto la più conveniente, a seguito delle istruzioni ORDER BY e LIMIT. nel caso dei trasferimenti aerei, la query esegue la ricerca di tratte a partire dalla città attuale, verso la prossima meta, nell'arco della giornata in cui ci si trova nel nodo attuale, in uno slot temporale discreto successivo (questo per evitare le problematiche di sovrapposizione di eventi incontrate nel paragrafo precedente). La query inizialmente ideata prevedeva l'impiego di una SELECT annidata e di un selettore IN. I risultati ottenuti, prestazionalmente inaccettabili hanno tuttavia evidenziato alcune problematiche da parte nell'ottimizzatore di MySql e richiesto la suddivisione della query in due di esse, da eseguirsi indipendentemente. Anche in questo caso l'impiego di array associativi ha permesso una facile integrazione dei risultati nella maniera di seguito esposta. SELECT DISTINCT(fares.id) as fareid, fares.costo FROM mezzi_trasporto, fares, citta as a, citta as b, aziende_trasporti, voli, voli_has_fares WHERE voli.citta_da = a.id AND voli.citta_a = b.id AND voli.id_azienda = aziende_trasporti.id AND voli_has_fares.voli_id = voli.id AND voli_has_fares.fares_id = fares.id AND voli.id_mezzo = mezzi_trasporto.id AND sat=0 AND fda=*verify14_days AND voli.g*giorno_corrente=1 AND classe =*classe_preferita AND mfpu=0 AND da = *citta_provenienza AND a = *citta_destinazione AND datat = *giorno_corrente AND orapartenza > *fine_intervallo_temporale_corrente 56

67 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB SELECT voli_has_fares.fares_id as ident, min(a.orapartenza) as decollo, addtime( max(a.orapartenza), concat(floor(max(a.durata)/60),":",(max(a.durata)%60)) ) as atterraggio FROM voli as a, voli_has_fares WHERE voli_has_fares.voli_id = a.id AND fares_id = *fare_reperita1 UNION SELECT [...] UNION SELECT voli_has_fares.fares_id as ident, min(a.orapartenza) as decollo, addtime( max(a.orapartenza), concat(floor(max(a.durata)/60),":",(max(a.durata)%60)) ) as atterraggio FROM voli as a, voli_has_fares WHERE voli_has_fares.voli_id = a.id AND fares_id = *fare_reperita_2 Da notare nella prima query le numerose condizioni, derivanti dalle complesse strutture con cui sono tipicamente rappresentate le fare aeree (maggiori dettagli in merito nel capitolo 5 e in appendice). In particolare, vengono richieste le fare che non necessariamente prevedano altre fare all'interno dello stesso biglietto con rispetto della Saturday Night Rule (sat=0); che rispettino o meno la Fourteen Days Advance Rule (fda=*verify14_days ), a seconda del giorno in cui viene effettuata la ricerca, rispetto al giorno per cui il volo viene cercato; che si riferiscano alla classe prediletta dall'utente; che non richiedano altre fares all'interno dello stesso biglietto; che partano e giungano nelle città di interesse dell'utente nel giorno specificato dopo l'ora coincidente con l'istante di inizio della successiva finestra temporale discreta (datat, orapartena) e soprattutto che per la giornata prevista vi siano voli disponibili. (gn=1) Tale controllo viene effettuato generando un identificativo numerico (X) per ciascun giorno della settimana, a partire dal lunedì, in cui tale numero assume valore 1, fino alla domenica, cui corrisponde il 7 e viene verificato nella tabella dei voli che il campo gx abbia valore 1, ovvero che il volo selezionato sia disponibile per quella specifica giornata. 57

68 IMPLEMENTAZIONE Vengono quindi restituite tuple di questo tipo: fareid fares.costo Alla query successiva si ricavano ora di partenza e durata complessiva di ciascuna fare. La struttura restituita è la seguente: fareid decollo atterraggio Anche in questo caso, un array associativo è impiegato per stabilire la corrispondenza tra fare, relativo costo e relativi dati su orario di decollo e atterraggio e soprattutto mettere in relazione tra loro i risultati provenienti da due query diverse. Sulla base dei dati di decollo e atterraggio viene stabilita la durata dell'evento che viene memorizzata nella struttura evento precedentemente introdotta. nel caso dei trasferimenti su rotaia e navali, la query eseguita è la seguente e medesima: SELECT costi_trasporto.id, trasporti_terra_mare.datapartenza, trasporti_terra_mare.durata, costi_trasporto.costo FROM costi_trasporto, trasporti_terra_mare, mezzi_trasporto, tipologie_trasporto, citta AS a, citta AS b WHERE a.id = citta_da AND b.id = citta_a AND citta_da = *citta_attuale AND citta_a = *prossima_meta AND mezzi_trasporto_id = mezzi_trasporto.id AND tipologie_trasporto.id = tipologie_trasporto_id AND costi_trasporto.id_tratta = trasporti_terra_mare.id AND datapartenza >= *istante_temporale AND datapartenza < *istante_temporale + (24 ore) AND classe =*preferenza_classe_utente AND tipologie_trasporto_id =*mezzo_di_trasporto ORDER BY datapartenza le tuple restituite assumono questa forma: id_tratta datapartenza durata costo Ovviamente il valore del parametro *mezzo_di_trasporto cambierà a seconda che si stiano cercando trasferimenti navali oppure su rotaia. 58

69 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB nel caso di ricerca autoveicoli a noleggio, in fine, la query eseguita è la seguente e medesima: SELECT tariffe_noleggio_auto.id, mezzi_trasporto.consumo FROM mezzi_trasporto, tariffe_noleggio_auto, rental_locations, aziende_trasporti, citta AS a WHERE a.id = rental_locations.id_citta AND aziende_trasporti.id = rental_locations.id_azienda AND durata_min <=1 AND rental_locations.id_citta =*citta_dove_avviene_il_noleggio AND tariffe_noleggio_auto.id_location = rental_locations.id AND classe =*classe AND mezzi_trasporto.id = classe ORDER BY costo ASC In questo caso le tuple restituite assumono la seguente struttura: id_tratta datapartenza durata costo Viene restituito innanzitutto il campo Id della tariffa per una specifica categoria di veicoli da una specifica locazione di noleggio, accompagnato dal consumo medio per la categoria di veicoli in questione. Non ha ovviamente senso parlare in questo caso di partenza e durata del viaggio, dato che queste non sono collegate con l'azione stessa di noleggio e vanno cercate altrove; viene invece restituito il consumo medio dell'autoveicolo considerato, utile per determinare il costo reale del noleggio nel suo complesso. La partenza dell'utente viene arbitrariamente associata all'istante zero del successivo intervallo temporale discreto, mentre la durata del viaggio è stimata tenendo in considerazione le tabelle con le distanze chilometriche e i tempi di percorrenza medi descritte in appendice. Da notare che tutti i risultati restituiti sono al netto delle reali tempistiche associate al prendere parte ad un evento; benché la durata di un trasferimento aereo tipicamente non superi i 60 minuti (per lo meno nello scenario considerato), è sempre necessario presentarsi anticipatamente per il check-in; alla stessa stregua è opportuno presentarsi con alcuni minuti d'anticipo quando ci si auspica di salire su un treno, per evitare di incorrere in rari ma comunque possibili passaggi anticipati ed infine lo stesso discorso vale per i mezzi di trasporto marini che, nel caso considerato richiedono tipicamente minuti di anticipo per le operazioni di carico dei passeggeri. 59

70 IMPLEMENTAZIONE Ecco dunque che la durata degli eventi reperiti attraverso le query viene maggiorata dei seguenti fattori (qui espressi in minuti): Tab 3-1 Tempi di carico e scarico da mezzi di trasporto Mezzo di Trasporto Carico Scarico Aereo 90 Minuti 30 Minuti Treno 15 Minuti 10 Minuti* Nave 45 Minuti 15 Minuti Fonte: Elaborazione propria * rappresentanti più che un reale tempo di scarico un simbolico simbolico ritardo, tipicamente riscontrabile. Per quanto riguarda i costi dell'auto a noleggio, inoltre, considerando il fatto che anche la benzina ha un certo costo, che tipicamente sedi di compagnie di noleggio auto diverse da quelle in cui l'auto è stata noleggiata hanno tariffe di così detto drop-off, nel caso del noleggio auto, anche il costo dell'evento stesso subisce una maggiorazione: costocarburante = ((distanza/(100/consumo)) * COSTOFUEL; costo_evento = costo_base + costo_carburante + dropoff_surcharge Una volta reperiti i dati relativi a tutti gli eventi disponibili in una determinata situazione questi vengono inseriti nelle strutture nodo sopra introdotte. E' necessaria in questa fase un'opera di normalizzazione dei dati, dato che, come si sarà forse potuto notare, ciascuno di essi presentava una propria formattazione, soprattutto in relazione agli aspetti temporali. Ecco dunque che nell'evento la durata degli eventi viene rappresentata in minuti, il costo in euro, mentre il tempo d'inizio in forma di stringa del tipo OO:MM. Tale formato ben si presterà al calcolo del costo complessivo di ciascun nodo, combinando i costi in termini economici e temporali, mentre del tutto inadatto diverrà nel momento in cui dovrà essere trasformato in nodo; ecco che in quell'occasione delle opportune trasformazioni di formato si renderanno necessarie. 3.7 Combinazione Convessa Come si è quindi potuto evincere dal paragrafo precedente, per ogni evento reperito, ne vengono anche considerati costo e durata, ovvero le due misure del problema che ci interessa analizzare. Il passo successivo è stato la determinazione di un coefficiente alfa per la combinazione lineare convessa degli obiettivi legati a queste due misure. Più che la determinazione di un parametro, effettivamente il problema era in questo caso quello di costruire una scala di valori plausibili per alfa, in maniera tale da dare buoni risultati con tutte le possibili selezioni di rapporto costo/velocità dei trasferimenti 60

71 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB selezionate dall'utente. Lo spettro di pubblico cui vuole essere rivolto lo strumento vuole essere ampio quanto possibile e risultare utile tanto al rilassato giramondo, impassibile di fronte a qualche ora in più spesa in treno, ma assolutamente attento anche allo spicciolo, quanto al ricco uomo d'affari per il quale uno spostamento della durata superiore ad un altro si traduce in una pressoché diretta perdita economica. Ecco che, considerati questi due estremi si sono determinati i valori che ciascuna delle due figure avrebbe probabilmente fatto corrispondere ad un ora di tempo; al vagabondo è stato associato il valore uno (che di fatto stabilisce un ordine lessicografico tra prezzo e durata, evitando venga scelto il viaggio di durata maggiore a parità di prezzo minimo, dando luogo ad una soluzione dominata). D'altro canto è possibile il ricco uomo d'affari riesca a percepire anche /ora ed è quindi su questo valore che si è tarato il limite massimo della scala impiegata. La generazione dei valori intermedi per i 10 possibili valori selezionabili dall'utente attraverso lo slider delle preferenze non si è basata su scala lineare e questo perché altrimenti il valore minimo associato ad un ora sarebbe stato di ben 100/ ; sicuramente vi sarebbero utenti disposti a spendere un'ora in più a bordo di un mezzo di trasporto per risparmiare una cifra anche inferiore a tale valore. Si è dunque fatto ricorso ad una scala logaritmica, moltiplicata in seguito per un fattore costante. Un valore che si è dimostrato opportuno nei casi di utilizzo e test effettuati, ottenuto quindi a seguito di un iniziale ragionamento, ma attraverso raffinamenti empirici è il seguente: costo_ora = (selezione_utente^3) I valori ottenuti dalla funzione per le opzioni selezionabili dall'utente sono quindi: Alfa /Ora Al parametro costo del trasferimento viene quindi associato costantemente coefficiente alfa=1, mentre a seconda della preferenza dell'utente, il valore alfa per il valore durata assume uno dei valori sopra riportati, ovviamente riferito alle ore di viaggio (durata / 60). Operato della funzione calcolacosto() chiamata all'interno di findcheapestnode() per 61

72 IMPLEMENTAZIONE trovare l'evento più conveniente tra quelli disponibili è quindi la restituzione del costo finale di un evento sulla base del costo economico e della durata dello stesso; tale valore viene successivamente impiegato da findcheapestnode() in un confronto tra il valore predeterminato dell'evento attualmente selezionato e un evento considerato come possibile alternativa. Indici del Database Sebbene la loro natura ed ambito di utilizzo li renda concettualmente più vicini a trattati specificatamente dedicati alle basi di dati piuttosto che implementazioni algoritmiche qual'è la presente, i drastici miglioramenti prestazionali ottenuti dal loro utilizzo farebbero si che il presente documento risultasse incompleto senza nemmeno una breve citazione agli stessi. Gli indici sono strutture opzionali messi a disposizione dalla maggior parte dei DBMS ed associati alle tabelle; come immediatamente suggerito dalla loro denominazione, il loro utilizzo principale è la facilitazione del reperimento delle informazioni; infatti come avviene per l'indice di un libro, il quale indica al lettore la pagina in cui reperire un certo contenuto, così gli indici servono a dirigere il DBMS in maniera rapida verso la locazione su disco dov'è memorizzato il dato; attraverso un indice, un record può essere direttamente reperito dalla zona di disco in cui è memorizzato il dato, senza necessità di scorrere l'intera tabella. Gli indici possono a dire il vero essere di diverso tipo; nel nostro caso meritano citazione quelli di tipo PRIMARIO, che servono ad indicizzare i dati nella maniera sopra citata e al tempo stesso a garantire l'univocità di un certo record, gli indici di tipo UNIQUE, che svolgono solo quest'ultimo compito e gli INDEX semplici, che svolgono la funzione di indice appunto. Nello storage engine (INNODB) [Mysql ] utilizzato per memorizzare i dati relativi allo scenario di esempio presentato in appendice e quindi per eseguire la sperimentazione del prototipo qui descritto le chiavi primarie (PRIMARY KEYS) sono mantenute attraverso un clustered index [Sybase 2007]; ciò significa che ad essere ordinati sono direttamente i dati stessi e non, come avviene con altri storage engine (come ad esempio MyISAM) le sole strutture ad indice; vedendo la situazione in modo diverso, è possibile affermare che con INNODB i dati costituiscono le foglie dell'indice clustered stesso. I miglioramenti prestazionali offerti da questo tipo di indice possono essere notevoli, considerato che basta scorrere l'indice per ottenere direttamente il dato, anziché effettuare un nuovo accesso su disco; ovviamente però, per le caratteristiche stesse di questo tipo di indice, una tabella può contenerne al massimo uno, utilizzando poi indici tradizionali ove più di un indice sia richiesto. 62

73 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Fig Rappresentazione clustered index Fonte: Rielaborazione di [Sybase 2007] e [Mysql ] Nello scenario di test per ogni tabella è stato creato un campo ID, che ne è PRIMARY KEY e quindi clustered index. Ciò ha garantito un rapido accesso al dato, una volta che questo era già stato individuato (ad esempio in sede di presentazione dei dati, come vedremo tra poco e anche nelle numerose operazioni di JOIN tra tabelle), ma si rivelava di fatto ancora insufficiente per poter offrire prestazioni accettabili soprattutto nelle operazione di filtraggio (WHERE) su tabelle con numerosi records (fares, voli_has_fares) ed ordinamento (in questo caso sono comunque ancora necessarie tabelle temporanee). Ecco quindi che è stato necessario creare degli indici secondari (che ovviamente non potevano essere clustered, ma che in ogni caso si sono dimostrati assai utili nel permettere rapidi accessi ai dati e quindi accettabili prestazioni complessive del sistema). Tali indici secondari sono stati creati su uno o più campi di ciascuna tabella (tipicamente sui campi su cui avvengono contemporaneamente molteplici operazioni di filtraggio si pensi al caso considerato prima, di query sulle fares in cui è necessario considerare tutte le limitazioni imposte dalle compagnie). Tipicamente nelle tabelle troviamo quindi la chiave primaria (ovvero l'id) di ciascun record che è un clustered index, più un numero variabile di indici dipendente dal numero di colonne su cui vengono generate tipicamente operazioni di filtraggio (WHERE) e/o ordinamento (ORDER BY). Le tabelle fares e voli_has_fares con numeri di record nell'ordine dei milioni hanno 63

74 IMPLEMENTAZIONE trovato particolare giovamento da questi e permesso di ridurre il tempo di esecuzione dall'ordine del secondo a quello del centesimo di secondo. Fig Rappresentazione non-clustered index Fonte: Rielaborazione di [Sybase 2007] e [Mysql ] L'output del comando MySql EXPLAIN su una query sopra menzionata (prima query selezione fares) torna questo output: 64

75 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB 65

76 IMPLEMENTAZIONE Come si può notare non compaiono JOIN di tipo ALL e questo è sicuramente dovuto all'impiego di indici, che quindi velocizzano l'operazione. Unico elemento di disturbo ancora presente (i cui effetti comunque si dimostrano in maniera pressoché nulla) è la dicitura using temporary nella sezione Extra. Ove possibile sarebbe auspicabile evitare di far impiegare all'ottimizzatore tabelle temporanee; in questo caso, tuttavia, considerata l'assenza di effetti indesiderati riscontrabili si sono evitati ulteriori provvedimenti in merito. Ovviamente gli indici devono essere creati con una certa razionalità e parsimonia, dato che per ogni operazione di inserimento e aggiornamento questi devono essere aggiornati (nel caso di clustered index ciò porta peraltro ad operazioni di accesso al disco non trascurabili); nel nostro contesto, tuttavia, dove sono esclusivamente operazioni di tipo SELECT ad essere eseguite e si ipotizza in un contesto produttivo gli aggiornamenti possano avvenire sporadicamente, in modalità batch, sicuramente l'impiego di un numero di indici sufficiente ad ottimizzare tutte le operazioni di selezione è non solo giustificato ma anche consigliabile. Tutti gli indici sino ad ora introdotti si basano su B-tree [Mysql ]; queste strutture dati permettono di mantenere i dati ordinati, garantendo quindi l'esecuzione di ricerche in tempo logaritmico [Cormen et al 1990]. Una trattazione completa dell'argomento esula sicuramente dall'obiettivo del presente elaborato; vale tuttavia la pena di ricordare che i B-Tree sono alberi con le seguenti caratteristiche: ogni nodo ha un numero di figli minore o uguale a m ogni nodo, eccetto la radice, ha un numero di figli maggiore o uguale a m/2 la radice ha almeno 2 figli, a meno che non sia una foglia tutte le foglie sono allo stesso livello un nodo che non sia una foglia e che abbia k figli, contiene k-1 chiavi Nello storage engine InnoDB impiegato, le chiavi primarie costituiscono direttamente le foglie dell'albero, in cui sono contenuti i dati. Gli indici secondari, ovvero quelli creati per migliorare le prestazioni nelle operazioni di filtraggio, join e ordinamento hanno nelle loro foglie puntatori ai dati. Altri tipi di indici utilizzabili, ma non impiegati Non impiegati nel nostro contesto poiché non messi a disposizione dal DBMS utilizzato (e di fatto disponibili solo su costosi strumenti proprietari), i bitmap index [Wiki ] rappresentano in genere [Burleson 2007] una buona tecnica di indicizzazione per attributi con bassa cardinalità del dominio; vengono costruiti a partire dai valori distinti di una colonna di una tabella e sono costituiti da un distinto vettore di bit, per ogni possibile valore del dominio. Quando viene istanziata una query, vengono considerati gli indici che soddisfano la condizione (bit posto a 1), combinandola con le altre 66

77 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB clausole: in questo modo, se una query deve soddisfare condizioni poste su due o più attributi, le righe di risultato possono essere calcolate con l'ausilio di semplici operazioni logiche sulle sequenze di bit ottenute dalla scansione parallela degli indici. Il vantaggio derivante dall'uso di indici bitmap cresce nelle colonne nelle quali la proporzione tra il numero di valori distinti e il numero totale di records è inferiore al 1%. Un ottimo esempio di questo tipo è dato, nel nostro contesto, ad esempio, da un'ipotetica colonna CLASSE, dove a fronte di milioni di potenziali records, vi sono tipicamente solamente due gradi di cardinalità dei servizi (prima e seconda). Un'indicizzazione di questo tipo può essere notevolmente più performante rispetto ad una ottenuta per mezzo dei B-tree, soprattutto quando la colonna considerata viene interrogata congiuntamente ad altre colonne indicizzate (come nel nostro caso) e quando le operazioni di fetch sono in numero significativamente superiore alle operazioni di inserimento o modifica dei records [Burleson 2007]. L'utilizzo di tali indici può quindi velocizzare le interrogazioni (si citano miglioramenti che superano anche l'8.5% in fatto di velocità di esecuzione); vi sono tuttavia alcune considerazioni da fare in merito a tale tipologia di indici: Nelle interrogazioni SQL contenenti una selezione WHERE, non vi debbono ovviamente essere referenze a colonne che non sono contenute nell'indice (nell'ambito della selezione stessa) Bisogna considerare che l'overhead derivante dall'aggiornamento degli indici bitmap è sostanziale; tipicamente gli indici bitmap vengono quindi distrutti e ricostruiti nell'ambito delle normali procedure batch di manutenzione del database, che seguono l'importazione dei dati. Come per gli indici Bit Map, anche gli indici di tipo bitmap join [Sharma 2002] non erano disponibili nell'implementazione di DBMS utilizzata, ma possono risultare utili nell'ambito delle interrogazioni che prevedono JOIN tra più tabelle. Un indice join è un metodo efficiente (e salvaspazio) per ridurre il volume dei dati da sottoporre a join, andando ad effettuare preventivamente le selezioni sui records da correlare; per ogni valore nella colonna di una tabella, l'indice join tiene conto del numero di riga corrispondente, in una o più altre tabelle. 67

78 IMPLEMENTAZIONE 3.8 Inserimento dei Nodi Una volta reperiti gli eventi compatibili con il nodo correntemente considerato e selezionato l'evento più conveniente per l'utente, questo diviene un nodo a tutti gli effetti e viene inserito nell'elenco dei nodi da analizzare successivamente. Tale nodo è composto da una serie di attributi, che come si è visto, vengono utilizzati per la selezione degli eventi che lo succedono e che ne costituiranno quindi i nodi successivi in un cammino. Id Tipo Predecessor e Tab. 3-2 Attributi di Ciascun Nodo/Evento Attributi del Nodo Stringa formata da: Tipo-Luogo-Inizio-Fine Intero con valori: 0 - Pernottamento 1 - Trasferimento Stringa con Id del predecessore Nel caso di nodi di partenza assume il valore particolare I Id del nodo, formato da unione da altri attributi, in maniera tale da essere immediatamente reperibile, per mezzo di array associativi. Numero che identifica il tipo di nodo e quindi anche il tipo dei nodi che dovranno succedervi Id del predecessore, utilizzata in sede finale per mostrare il cammino minimo Totale Intero Costo del cammino sino al nodo, escluso il costo del nodo stesso Luogo Intero Id del luogo in cui ci si trova o in cui ci si sta trasferendo Inizio Fine Intero (conto in giorni giuliani) Intero (conto in giorni giuliani) Rappresentazione del giorno di inizio dell'evento in forma di giorno giuliano Rappresentazione del giorno di fine dell'evento in forma di giorno giuliano Costo Numero Intero Costo dell'evento Tipo_Servizio Intero con valori: 0 - Pernottamento in hotel 1- Pernottamento in risorsa propria 2 Trasferimento in aereo 3 Trasferimento in treno 4 Trasferimento in nave 5 Trasferimento in auto Flag con il tipo di servizio dato dal nodo stesso ID_Servizio Intero Id dell'hotel, fare, tratta navale o ferroviaria, azienda fornitrice auto a noleggio. Nel caso di pernottamento in risorsa propria o dove non sia previsto assume valore 0. Serve per ricostruire il percorso dell'utente in sede di visualizzazione Ritorno Booleano 0 Non si tratta di uno spostamento di ritorno Indica se il nodo è uno spostamento che riposta l'utente a casa e serve per identificare 68

79 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB 1 Si tratta di uno spostamento che quando si è raggiunto il nodo riporta l'utente a casa finale. Fonte: Elaborazione propria La maggior parte degli attributi dovrebbe risultare auto-esplicativa e quindi non ci si dilungherà ulteriormente su questi; menzione particolare meritano invece gli attributi costo e totale sui quali potrebbero sorgere fraintendimenti. E' opportuno far notare a tal proposito che l'attributo totale di ciascun nodo tiene conto del costo complessivo del cammino impiegato per raggiungerlo, senza considerare il costo del nodo stesso; quando un nodo viene scoperto dalle procedure precedentemente introdotte, se ne analizza il totale e se questo è superiore alla somma del totale e del costo del predecessore, allora gli attributi totale e predecessore ne vengono aggiornati. Fig Applicazione Programmazione Dinamica Fonte: Elaborazione propria Altro particolare degno di menzione è la gestione delle successioni temporali degli eventi; questa è basata sugli attributi fine di un nodo e inizio dell'evento successivo. In particolare, denominando A il nodo in cui ci si trova, se ne considera l'istante di fine. A questo punto, si determinano gli eventi temporalmente compatibili in grado di seguirlo, tra i quali avviene poi la sopraccitata selezione. La trattazione seguente si basa sulla soluzione implementata con due intervalli temporali discreti quotidiani, ciascuno di 12 ore ed inizio e fine alle ore 03:00 e 15:00; nel caso di suddivisioni discrete del tempo più fitte, le considerazioni fatte rimangono comunque valide, ovviamente a meno di opportune regolazioni sulla durata di un pernottamento; in questo caso interessante peraltro notare come potrebbe essere possibile contemplare non solo pernottamenti, ma anche soste intermedie di qualche ora tra tappe diverse. Il confronto in questo caso andrebbe fatto in maniera analoga a come presentato di seguito e l'unico accorgimento aggiuntivo da prendere sarebbe la necessità di dover decidere volta per volta se ad una specifica sosta deve anche corrispondere un pernottamento o meno. Ad ogni modo, il metodo di base per operare è lo stesso, ovvero quello descritto di seguito che, come in altre situazioni, diverso si presenta a seconda del tipo di evento incontrato: Nel caso di pernottamenti, si tiene semplicemente conto dell'istante in cui termina 69

80 IMPLEMENTAZIONE A e ci si comporta di conseguenza: se A termina ad un orario antecedente le 04:01 allora viene cercato un alloggio per la notte precedente al giorno attuale (ci si comporta in pratica come si fosse arrivati la sera prima) e la fine dell'evento pernottamento viene fatta corrispondere alle ore 15:00 del giorno seguente; ciò significa che l'utente non potrà lasciare la meta attuale prima delle 15:00, di fatto concedendo allo stesso la possibilità di godere almeno una mattinata nel luogo prescelto. Se invece il trasferimento conduce l'utente nel luogo di pernottamento dalle ore 04:01 alle ore 15:00 allora si considera che lo stesso avrà a disposizione l'intero pomeriggio e quindi la sua partenza viene cercata a partire dalle ore 03:00 (considerando la durata lorda del trasferimento) del giorno successivo. Se infine un utente giunge a destinazione dalle ore 15:01 alle ore 00:00, allora ci si riconduce al primo caso, eccezion fatta per la notte considerata, che rimane l'attuale anziché essere quella del giorno prima. Gli orari esatti di partenza e arrivo dei trasferimenti vengono trattati con la codifica normale di rappresentazione degli orari (OO:MM:SS), mentre gli istanti discreti sono trattati per comodità (dato che questi si estendono su più giorni) come timestamp UNIX. In particolare, nel caso di giorni multipli, viene sommato all'istante di fine dell'evento per il primo giorno una quantità pari a: giorni X 60 * 60 * 24, dato che il timestamp UNIX è rappresentato in secondi (maggiori dettagli sull'argomento vengono comunque forniti di seguito). Fig Sincronizzazione degli eventi Fonte: Elaborazione propria Più semplice è la situazione nel caso di trasferimenti, dato che le tratte possibili vengono semplicemente cercate a partire dalla data di fine dell'evento precedente (pernottamento), entro l'arco della giornata stessa e l'istante di fine delle stesse viene fatto corrispondere all'inizio dell'intervallo temporale discreto successivo. 70

81 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB La Gestione delle Date Oltre al problema del reperimento dei dati da fonti esterne, cui si è dato ampio spazio in precedenza, un altro aspetto piuttosto delicato in sede implementativa è stata la gestione delle date, ovvero dei formati di rappresentazione ad esse collegati; ciò innanzitutto in virtù del fatto che tipicamente la data non è un tipo di dato di base di un linguaggio (o per lo meno così non è in php), in secondo luogo per le irregolarità del calendario Gregoriano comunemente utilizzato per misurare il tempo. Tale calendario, di cui si fa comunque necessario utilizzo in sede di presentazione dei risultati, fu introdotto nel 1582 al posto del calendario Giuliano e permette di misurare il tempo, garantendo anche il rispetto delle stagioni; sebbene l'impiego dello stesso nella vita quotidiana sia pratico, oltre che oramai assodato, la trattazione numerica del calendario risulta sicuramente più immediata. Ecco che quindi per misurare la durata degli eventi, nonché gli istanti di inizio e fine di ciascun nodo, si fa impiego dello Unix Timestamp, ovvero un numero intero che conta i secondi trascorsi a partire dalla cosiddetta Unix Time Epoque (00:00:00 UTC del 1 gennaio 1970); sicuramente questo modo per descrivere una data comprensiva di ore minuti e secondi è più favorevole a trattazioni automatizzate, dato che è sufficiente svolgere operazioni prettamente numeriche per calcolare o gestire il trascorrere del tempo. Un giorno è infatti composto da secondi, l'ora da 3600 secondi e quindi definendo tali valori come costanti (come è stato effettivamente fatto nel prototipo realizzato), è anche facile decrescere o progredire la data e ora corrente di quantità comunemente impiegate come l'ora ed il giorno. Un altro sistema di numerazione che poteva essere impiegato per gestire le date e di cui si è effettivamente valutato l'utilizzo era il giorno giuliano, ovvero il numero conto dei giorni trascorsi dal 1 gennaio del 4713 a.c. Secondo il calendario gregoriano. Il sistema dei giorni giuliani è stato progettato per fornire agli astronomi un singolo sistema di date che potesse essere usato per lavorare con differenti calendari, e per unificare differenti cronologie storiche e per queste caratteristiche, oltre che per il fatto di essere lui stesso un numero intero, ben si presterebbe ad essere utilizzato per la gestione del tempo con strumenti informatici; ad ogni modo la bassa precisione dello stesso avrebbe richiesto che gli intervalli discreti considerati avessero la durata minima di una giornata, causando quindi i problemi sollevati nel presente capitolo. Ecco dunque che, sebbene meno diretto per il calcolo dei giorni, sia stato lo UNIX timestamp ad essere selezionato quale unità di misura standard per il calcolo del tempo nel prototipo qui presentato. 71

82 IMPLEMENTAZIONE 3.9 Presentazione dei Risultati Una volta costruiti i cammini con le metodologie sin qui introdotte e conseguentemente aver individuato il cammino minimo, l'ultima cosa che resta da fare è presentare i risultati ottenuti all'utente. Ciò di cui si dispone infatti non sono già dati completi direttamente presentabili, ma solo una successione di eventi con gli attributi sopra esposti. Per poter presentare i risultati nella forma precedentemente incontrata all'utente è quindi necessario per ciascun nodo del cammino effettuare una nuova query al database alla ricerca dell'evento individuato dagli attributi Tipo_Servizio e ID_Servizio. Tipo servizio in particolare individua una tabella o comunque una tipologia di query da formulare, mentre Id Servizio identifica specificamente la tupla da considerare all'interno della tabella selezionata. Vengono quindi reperiti per ciascun evento istanti di inizio e fine esatti (che quindi non era necessario mantenere anche tra gli attributi di ciascun nodo), oltre che tutti i dettagli relativi al servizio, tra i quali vi è anche il costo economico netto (si ricordi che nella nostra formulazione, all'attributo costo di ciascun nodo corrispondeva invece il costo complessivo, dato dal costo economico ma anche dalla penalità eventualmente derivante dal tempo di trasferimento per l'evento stesso). Ecco dunque che scorrendo uno ad uno i nodi del cammino ed effettuando un pari numero di query al database si reperiscono tutti i dati necessari per la presentazione dei risultati all'utente. Sembrasse strano questo tipo di approccio, in quanto richiedente un'esecuzione di query tutto sommato inutile, in ultima istanza, dato che tutti i dati relativi a ciascun nodo potrebbero essere preventivamente reperiti e conservati in memoria per una successiva visualizzazione, c'è da notare come però questo approccio richiederebbe innanzitutto un maggior dispendio di spazio, in quanto dati comunque inutili si dovrebbero memorizzare per ciascun nodo; in secondo luogo e forse cosa ancor più importante, in questo caso i risultati provenienti da database (e quindi memorizzati su disco e fatti transitare su socket UNIX o TCP) avrebbero dimensioni decisamente più elevate, causando sicuri rallentamenti, peraltro senza corrispettivi vantaggi; c'è da pensare infatti che le query restituiscono eventi che devono appena essere filtrati, prima di diventare nodi, prima ancora di essere selezionati tra facenti parte al cammino ottimo. Mantenendo in RAM le informazioni relative a tutti questi aventi si avrebbe un sicuro inutile dispendio di memoria, a fronte di miglioramenti prestazionali che, per la necessità di trasferimento dati da disco, probabilmente non avverrebbero. Tutto ciò senza considerare che le ultime query avvengono sulla base dell'id dell'elemento, ovvero la chiave primaria, ovvero un indice clustered; condizione questa in cui il reperimento del dato risulta pressoché immediato Estensioni del Modello Sebbene il modello proposto, già nella forma assunta sino a questo punto, desse incoraggianti risultati pratici, si è deciso di apportare un'ulteriore miglioramento e aggiunta di funzionalità permettendo all'utente di specificare anche gli intervalli temporali a lui meno graditi per i trasferimenti. Ciò tenendo in considerazione che persone anziane potrebbero non gradire di trasferirsi ad ore tarde della notte o che invece qualche appassionato fotografo come lo scrivente potrebbe invece prediligere questo tipo di spostamenti, per poi godere di un maggior numero di ore utili nei luoghi di destinazione. 72

83 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Ecco dunque che la modellizzazione e l'implementazione di tale ulteriore aspetto sono avvenute considerando la preferenza espressa come un ulteriore obiettivo, nella fattispecie, come la minimizzazione della sovrapposizione tra fasce orarie indicate come poco gradite per i trasferimenti e istanti temporali che un trasferimento effettivamente impiega. Come per gli altri due obiettivi sono ad ora contemplati è quindi sorta la necessità di considerare questo ulteriore aspetto, includendolo nella funzione che dev'essere complessivamente minimizzata. Sebbene la combinazione convessa potesse essere applicata senza eccessive problematiche in relazione alla minimizzazione dei costi economici, la dipendenza che dopotutto legava durata dei trasferimenti e durata dei trasferimenti in un orario poco gradito ha richiesto maggior attenzione. E' probabilmente vero infatti che intervalli da evitare e durata complessiva potessero essere ordinati in ordine lessicografico, in questo caso, però a questo punto sarebbero sorti problemi di integrazione dell'aspetto legato al costo. Si è dunque agito in maniera simile a quando si era cercato di assegnare un valore a ciascuna ora trascorsa in viaggio, e ciò che è stato quindi operato, è stata l'assegnazione di un peso k di 2 volte (valore determinato empiricamente, dopo diverse iterazioni ed aggiustamenti) superiore al peso di un'ora comune alle ore individuate come poco favorite per i trasferimenti. In questo modo, simulando in un certo qual modo un ordine lessicografico (si noti che la simulazione sarebbe completa se la costante k=2 selezionata fosse maggiore rispetto alla durata del trasferimento disponibile più lungo e se tutta la durata del viaggio si svolgesse in fasce da evitare), si stabilisce un netto rapporto di preferenza per le ore che non sono da evitare rispetto alle altre nei trasferimenti. Tale modellazione ha peraltro permesso di rispettare le aspettative di chi dava anche importanza al budget, dato che di fatto se volare in ore poco indicate per gli spostamenti costasse troppo, allora verrebbe selezionata comunque la soluzione di costo inferiore. Un'altra possibile estensione del modello, derivata peraltro dalle osservazioni dirette di persone che hanno sperimentato e condotto test sul sistema, è dare la possibilità di escludere in sede di impostazione dei parametri preferenziali un certo tipo di mezzo di trasporto, così da venire incontro anche alle preferenze di chi mal tollera l'aereo, la nave e soprattutto di chi non si sente a proprio agio alla guida di un veicolo in terra straniera. Tale aspetto non è stato contemplato nel sistema realizzato, ma sicuramente l'aspetto evidenziato potrebbe essere utile in un eventuale contesto reale. 73

84 IMPLEMENTAZIONE 3.11 Prestazioni del Sistema Vengono di seguito proposti alcuni dati relativi al tempo di esecuzione della soluzione implementata e ricavati da 50 interazioni ciascuna, considerando i medesimi itinerari di base, selezionando un intervallo di giorni possibili per la partenza variabile da 5 a 20 giorni, selezionando sempre un albergo come soluzione per i pernottamenti e aggiungendo progressivamente una meta all'elenco precedentemente considerato: Numero di Mete Tab. 3-3 Prestazioni del sistema Tempo Medio di Esecuzione Numero Medio di Nodi Analizzati Query a database Tempo medio esecuzione query* 1 1,22 159,40 307,05 0, ,44 293,20 588,50 0, ,88 384,00 887,25 0, ,55 480, ,40 0, ,45 543, ,10 0, , ,00 0,0030 Il tempo medio di esecuzione delle query è stato ottenuto dai dati relativi alle altre misurazioni, piuttosto che da specifiche misurazioni; considerato l'attestarsi del rapporto tra secondi impiegati e query eseguite è da presumere tale valore si attesti attorno ai secondi in ogni caso, e che i primi due risultati siano frutto del tempo computazionale comunque richiesto per la costruzione e l'analisi del grafo costruito. Dai risultati emersi è possibile affermare che lo strumento rispetta i tempi di risposta comunemente accettati per le soluzioni on-line con simili caratteristiche. Senza l'impiego di indici le prestazioni sarebbero tuttavia state le seguenti (misurazione effettuata rimuovendo temporaneamente tutti gli indici creati, eccezion fatta che per la chiave primaria di ciascuna tabella): Numero di Mete Tab. 3-4 Prestazioni del sistema senza indici Tempo Medio di Esecuzione Numero Medio di Nodi Analizzati Query a database Tempo medio esecuzione query* 1 43,49 159,40 307,05 0, ,35 189,23 488,50 0, ,43 371,00 823,25 0,197 74

85 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Come è possibile evincere dai dati riportati alla Tab. 3-4, l'introduzione delle ottimizzazioni apportate all'algoritmo e alle strutture dati interrogate ha comportato notevoli miglioramenti prestazionali e di fatto reso il sistema utilizzabile Qualità delle soluzioni fornite Meno immediata rispetto all'analisi prestazionale, la valutazione delle soluzioni fornite. In questo caso per la valutazione sono stati considerati alcuni itinerari pianificati manualmente da 10 tester, attraverso motori di ricerca tradizionali (ovvero le riproduzioni degli stessi di cui si trova menzione in appendice) e si sono confrontati i risultati con quelli invece ottenuti utilizzando il prototipo realizzato. Si sono suddivisi i confronti tra casistiche in cui andava minimizzato il tempo di trasferimento, casistiche in cui andava minimizzato il costo complessivo dell'itinerario e casistiche in cui l'aspetto era soggettivamente selezionato bilanciando i due aspetti (slider posto sul valore 3). Per ciascuna casistica sono state effettuate un numero di ricerche pari al triplo del numero dei tester (si sono ideati tre scenari di utilizzo di versi per ciascuna casistica), per due persone, nel medesimo periodo, con alloggiamento nel medesimo hotel, a due stelle, per una notte e per le medesime tappe. Minimizzazione del costo - Itinerari ad una sola tappa Tipo di Ricerca Media Costo Media Durata Modello 1 162, Tradizionale 175, Minimizzazione del costo - Itinerari a due tappe Tipo di Ricerca Media Costo Media Durata Modello 1 274, Tradizionale 302, Minimizzazione del costo - Itinerari a tre tappe Tipo di Ricerca Media Costo Media Durata Modello 1 334, Tradizionale 413,

86 IMPLEMENTAZIONE Come si può evincere dai risultati sopra riportati, in ogni caso il prototipo presentato consente di ottenere dei risparmi (8%, 10%, 20% rispettivamente); inaspettatamente attraverso l'utilizzo dello stesso viene spesso restituito un itinerario che è più breve (risparmio in termini di tempo rispettivamente del 7%, 13% e 12%) rispetto ai risultati effettuati con metodi tradizionali; se ciò può apparire strano a prima vista, c'è in realtà da considerare il fatto che la ricerca automatizzata spazia su un lasso temporale tipicamente più grande di quello che l'utente è possibilitato a considerare manualmente e che quindi il sistema spesso reperisce voli o treni poco frequenti e particolarmente vantaggiosi, anche in termini di velocità di trasferimento (es. voli operati solo una volta nell'arco della settimana). Minimizzazione della durata - Itinerari ad una sola tappa Tipo di Ricerca Media Costo Media Durata Modello 1 315, Tradizionale 367, Minimizzazione della durata - Itinerari a due tappe Tipo di Ricerca Media Costo Media Durata Modello 1 328, Tradizionale 348, Minimizzazione della durata - Itinerari a tre tappe Tipo di Ricerca Media Costo Media Durata Modello 1 672, Tradizionale 746, Nel caso della ricerca del trasferimento di durata inferiore, il prototipo offre risultati meno evidenti rispetto alla ricerca per prezzo, rispettivamente con un risparmio di 0%, 6% e 3%. Il motivo di tale apparente insuccesso va ricercato probabilmente nel fatto che non è difficile reperire il volo più rapido per ciascuna tratta, selezionando peraltro una tratta riproposta quotidianamente. Come si può tuttavia evincere dai risultati sopra riportati, il prototipo ottiene un successo anche in questo secondo caso, dato che per trasferimenti di durata eguale o minore a quelli reperiti attraverso ricerca tradizionale è in grado di offrire tariffe migliori (14%, 6% e 10% rispettivamente). 76

87 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Bilanciamento costo/durata trasferimento - Itinerari ad una tappa Tipo di Ricerca Media Costo Media Durata Modello 1 248, Tradizionale 257, Bilanciamento costo/durata trasferimento - Itinerari a due tappe Tipo di Ricerca Media Costo Media Durata Modello 1 275, Tradizionale 324, Bilanciamento costo/durata trasferimento - Itinerari a tre tappe Tipo di Ricerca Media Costo Media Durata Modello 1 477, Tradizionale 526, Nel caso di ricerche che richiedessero un compromesso tra velocità di trasferimento e costi il prototipo ha continuato ad offrire soluzioni migliori di quelle reperite con ricerca manuale; in particolare il tempo di trasferimento ha ottenuto miglioramenti rispettivamente di 15%, 10% e 11% nei tre casi, mentre il miglioramento economico è stato del: 4%, 15% e 10% rispettivamente nei tre casi. E' possibile quindi rendersi conto di come in misura più o meno accentuata l'impiego del sistema possa permettere di risparmiare tempo e denaro a chi lo impiega, spesso sia in termini economici che di durata dei trasferimenti, indipendentemente dall'obiettivo dell'utente; ciò è sicuramente dovuto al fatto che il sistema ha la facoltà di analizzare e confrontare tra loro opzioni di alloggio e trasferimento di gran lunga superiori a quelle individuabili manualmente e quindi reperire anche spostamenti che riescano ad essere al tempo stesso più economici e veloci. 77

88

89 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Capitolo 4 IL SECONDO MODELLO Sebbene il modello presentato nel capitolo precedente possa apportare un già significativo contributo al viaggiatore in procinto di pianificare il proprio itinerario, questo non tiene ancora conto di un'ulteriore flessibilità di cui l'utente possa effettivamente godere; è frequente infatti che soprattutto un turista, ma un viaggiatore in genere, possa avere l'obiettivo di visitare un certo numero di luoghi, senza aver necessariamente prestabilito un ordine nell'itinerario da seguire. Conseguenza di tale flessibilità, il fatto che un particolare ordine di visita nelle mete potrebbe rivelarsi più conveniente, rispetto ad altri e che se adottato comporterebbe quindi un risparmio per il viaggiatore.. Ecco dunque che nel presente capitolo viene introdotta una modellazione, comunque basata su quanto considerato nei precedenti capitoli, ma che tiene conto anche di questo ulteriore aspetto.. Considerata la stretta attinenza con quanto già presentato, saranno in un unico capitolo trattate la modellazione e l'implementazione dello stesso. 4.1 Idea La capacità di eseguire ricerche che contemplino molteplici fonti è oramai, grazie ad agenzie di viaggio online e aggregatori di tariffe, un consolidata realtà; altre aziende, seppur non costruendo direttamente l'itinerario per l'utente, lo aiutano nella pianificazione del proprio itinerario, qualora egli abbia le idee già chiare sull'ordine di visita, in quanto offrono dettagli sul costo dei trasporti in un lasso temporale che supera la giornata; nessuno di questi sistemi, né si è stati in grado di trovare cosa simile in rete, tiene tuttavia conto della possibile flessibilità di cui può godere un viaggiatore che si appresta a pianificare un viaggio. Nella maggior parte dei casi, non considerare la possibilità di permutare l'ordine delle mete del viaggiatore, qualora egli non abbia particolari esigenze o vincoli in termini di precedenze nelle tappe da fare, si traduce di fatto nell'impedire a questi di ottenere la tariffa per lui effettivamente più conveniente, poiché di fatto anche il semplice scambio nell ordine di due tappe potrebbe rivelarsi per lui vantaggioso Nel caso del turista quasi sempre l ordine di visita di più luoghi è ininfluente e questa 79

90 IL SECONDO MODELLO considerazione vale in molti casi anche per il viaggiatore d affari: si pensi ad esempio ad un rappresentante che deve visitare un certo numero di clienti in un certo lasso temporale, senza vincoli di precedenza, in quanto visite indipendenti tra loro; eventualmente il vincolo potrà essere costruito tramite contatto diretto con il cliente, ma intrinsecamente non vi sono vincoli che lo costringano a stabilire preventivamente un ordine certo per il proprio viaggio. Considerando tale aspetto, è possibile ipotizzare quindi che la tariffa complessiva migliore per la pianificazione di un intero viaggio possa essere non solamente individuando la somma dei valori minimi di tutti gli eventi richiesti esplicitamente dall utente, come avviene ora in tutti i sistemi analizzati nel capitolo 1 o nel prototipo considerato nei precedenti capitoli, ma anche andando a determinare l ordine con cui gli eventi debbono susseguirsi, nell intento di portare un vantaggio al viaggiatore. Un esempio in cui si può percepire in maniera immediata il vantaggio di non dover necessariamente dipendere da un itinerario prefissato è il seguente; si pensi a due luoghi che l utente intende visitare: nel primo, durante tutta la durata del proprio alloggio i costi di alloggio si mantengono stabili (HOTEL 1 nella figura 4-1), mentre in un altro luogo (HOTEL 2) la permanenza può avvenire in un periodo di bassa (in verde) oppure alta (rosso) stagione. Fig. 4-1 Cambiamento di costi al variare dell'itinerario seguito Fonte: Elaborazione propria E chiaro che l utente potrebbe non conoscere a priori questo dettaglio relativo alle tariffe degli alloggi che quindi dovrebbe manualmente effettuare due ricerche, per trovare l ordine di visita a lui più vantaggioso (SOLUZIONE 2), oppure prestabilire un ordine arbitrario di visita e quindi rischiare di effettuare una prenotazione a lui poco vantaggiosa (SOLUZIONE 1). L esempio in questo caso è semplice e con due ricerche distinte l utente potrebbe già essere in grado di determinare l itinerario per lui migliore, ma si pensi al caso in cui le tappe sono più di due e anche al fatto che anche la diversa combinazione di opzioni selezionate per il trasferimento da un luogo all altro possano comportare vantaggi o svantaggi per il viaggiatore. Ecco che in questo caso la ricerca per l utente non è più così 80

91 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB immediata e questi e quindi costretto a dover effettuare manualmente un numero di ricerche progressivamente crescente, che subito diventa fuori dalla sua portata, considerando la natura fattoriale del numero stesso (già con sole 4 tappe e numero di giorni prefissato per ciascuna di queste, il numero di ricerche da fare per i soli pernottamenti è 24, assai difficile pensare che un utente sia disposto ad effettuare 120 ricerche, nel caso di 5 tappe); a questi risultati andrebbero poi aggiunte le ulteriori ricerche e considerazioni per gli spostamenti, che complicherebbero ulteriormente le cose ampliando lo spazio di ricerca. Sulla base di tali considerazioni è quindi possibile affermare l'utente non sia in grado autonomamente di pianificare un itinerario che contempli diverse mete, potenzialmente con un intervallo di partenza variabile e numero massimo e minimo di notti per ciascuna meta variabile, considerando tutte le permutazioni possibili. C'è da dire, che il problema effettivamente rimane difficile anche dal punto di vista matematico ed informatico (nella fattispecie il problema può essere visto come una particolare istanza del TSP; maggiori dettagli in merito saranno comunque forniti in seguito) ed è per questo che difficilmente sarà applicabile a qualsiasi contesto e richiederà anzi che il numero delle mete selezionate si mantenga limitato; ai fini pratici c'è da considerare il fatto che tuttavia difficilmente quando viene intrapreso un viaggio con mezzi pubblici si decida di visitare più di 3-4 luoghi diversi. Ecco dunque che con questi numeri e anzi, con qualche numero in più, grazie ad accorgimenti citati di seguito è possibile pensare ad un approccio algoritmico, anche semplice, ovvero di ricerca esaustiva, per la soluzione del problema. L'idea molto semplice alla base del modello proposto è quindi quella di generare tutte le possibili permutazioni per l'insieme di mete specificate dall'utente ed eseguire il modello presentato nel capitolo precedente per ciascuna di esse, ovvero per un numero di volte pari al fattoriale della cardinalità dell'insieme delle mete. Chiaramente tale numero crescerà molto velocemente, così da permettere l'impiego di tale tecnica solo per una casistica limitata a poche mete; per riuscire ad estendere le casistiche in cui la flessibilità dell'utente può essere impiegata a vantaggio di una tariffa migliore o tempi di trasferimento più rapidi, considerando il fatto che il collo di bottiglia del primo algoritmo era rappresentato dall'ingente numero di query a database, ovvero dai costi dell'i/o, è sensato cercare di escludere gli itinerari meno promettenti o, detto in maniera più corretta, di rivolgere la propria attenzione esclusivamente agli itinerari più promettenti. La strada pensata per ottenere ciò è il calcolo effettivo del costo complessivo in termini chilometrici dell'itinerario generato attraverso permutazione dell'insieme delle mete e quindi l'esecuzione del modello introdotto nel capitolo precedente al sottoinsieme di permutazioni che si rileva più promettente (distanze chilometriche inferiori). Essendo in grado di calcolare tale somma interamente in memoria, si avranno soluzioni sicuramente più rapide rispetto all'esecuzione del modello precedente su tutte le permutazioni, seppur ovviamente con i limiti della complessità computazionale intrinseca del problema (trovare il percorso minimo corrisponde in pratica a risolvere il noto problema del TSP). 81

92 IL SECONDO MODELLO 4.2 Algoritmo L'idea di base di questo secondo modello è quindi la generazione delle permutazioni sull'insieme delle mete inserite dall'utente ed la conseguente applicazione del modello visto nel capitolo precedente su ciascuna di queste istanze. Per generare tali permutazioni si fa impiego dell'algoritmo proposto da [Dijkstra 1971], sotto riportato in linguaggio C (l'implementazione nel prototipo implementato, invece è anch'essa in php, così come il resto del software; ad ogni modo le modifiche rispetto alla versione sotto riportata sono di secondaria importanza e di livello prettamente sintattico), il quale genera permutazioni in ordine lessicografico. void getnext() { int i = N - 1; Algoritmo 4-1 Generazione di permutazioni while (Value[i-1] >= Value[i]) i = i-1; int j = N; while (Value[j-1] <= Value[i-1]) j = j-1; // swap values at positions (i-1) and (j-1) swap(i-1, j-1); } i++; j = N; while (i < j) { swap(i-1, j-1); i++; j--; } Fonte: Elaborazione propria In seguito, per ciascuna delle permutazioni realizzate (trattate ciascuna come array), viene innanzitutto preposto il luogo di partenza e ritorno per il viaggio e poi si procede con il metodo analizzato nel capitolo precedente, basato su cammini minimi, ovviamente mantenendo un unico nodo finale, il quale sarà impiegato anche in questo caso per la costruzione del cammino ottenuto all'indietro. Il problema principale del metodo di ricerca proposto (che sino a questo punto rimaneva comunque esatto) è che al crescere del numero di mete si ha un numero di permutazioni equivalente al fattoriale del numero stesso e chiaramente, per insiemi di mete superiori a 5, il metodo proposto non può essere impiegato on-line per i lunghi tempi d'attesa cui metterebbe di fronte l'utente. Il numero di iterazioni cui sarebbe infatti soggetto, al crescere del numero n delle mete 82

93 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB sarebbe: n n! Gestire un maggior numero di mete Ecco dunque che, con l'intento di riuscire a mettere in grado di utilizzare il sistema anche chi avesse in mente la visita di un numero di mete superiore a 4, si è pensato di trovare una soluzione che limitasse il numero di query poste al database e di conseguenza il numero di volte in cui il modello precedente viene chiamato in causa, tentando comunque di trovare una soluzione vantaggiosa per l'utente. Il metodo proposto va certamente intesto come un'euristica piuttosto che una tecnica di ricerca certa, come lo erano invece stati i metodi sino qui analizzati, dato che non si è sicuri di trovare la soluzione ottima; il problema rimane inoltre computazionalmente difficile e quindi è in grado di essere risolto on-line in tempi d'attesa accettabili per un numero massimo di nodi pari a 9. Ad ogni modo, l'operato dell'algoritmo è il seguente: si calcolano innanzitutto le distanze complessive per ciascuna permutazione generata (il tempo impiegato dall'operazione è riportato nella tabella seguente) e, di seguito si applica il modello del capitolo precedente solo ad un numero prefissato di itinerari (ovviamente quelli con somma delle distanze inferiore), la cui cardinalità può essere variata a seconda delle esigenze e della potenza degli strumenti di calcolo impiegati. 83

94 IL SECONDO MODELLO n Calcolo costi itinerari , , , , , , , , ,1109 In questo modo si escludono dalla ricerca quei percorsi poco sensati, ovvero con spostamenti privi di logica e si è in grado di aumentare il limite massimo di mete su cui è contemporaneamente possibile pianificare un itinerario flessibile. 4.4 Impegni Nel Viaggio Un osservazione che è possibile fare nell'ambito di tale modello è che un viaggiatore potrebbe godere sì di flessibilità, limitata tuttavia da alcuni eventi che hanno luogo e data di svolgimento certi e a cui questi deve quindi prendere parte (si pensi ad un workshop, ad un concerto, ad una manifestazione sportiva, ad una crociera o altro evento nell'ambito di una vacanza). Ecco che è dunque necessario contemplare anche tale aspetto nei modelli proposti; la cosa risulta pressoché immediata nel primo modello e nel secondo quando la ricerca viene fatta in modo esaustivo (per un numero massimo di mete pari quindi a 5); questo perché è sufficiente interrompere i cammini che non hanno inizio antecedente e fine successiva all'intervallo temporale in cui è previsto l'impegno dell'utente, nella città dell'impegno stesso. Interrompendo tutti i cammini non promettenti, la soluzione trovata (se esistente) lo mette necessariamente in grado di prendere parte all'evento cui intende partecipare. Tale aspetto nel prototipo realizzato è stata realizzata in maniera simile alle preferenze sulle fasce orarie da evitare per gli spostamenti, ovvero indicando una città, un istante di inizio e uno di fine; i periodi devono ovviamente essere unici per ciascuna sessione, altrimenti il sistema non è in grado di reperire soluzioni, dato che, si ricorda, un prerequisito fondamentale dei modelli presentati è che le mete possono essere visitate solamente una volta nell'ambito dello stesso viaggio. Nel caso esteso con ricerca euristica e considerazione dei soli cammini più promettenti, dato che i percorsi minori potrebbero non contenere cammini che soddisfino le esigenze 84

95 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB dell'utente, una soluzione proposta (ma non implementata) è quella di sostituire alla selezione basata su cammini, una selezione basata su effettiva possibilità che ha una certa permutazione di permettere all'utente di prendere parte all'evento in programma. Anche in questo caso, qualora tali permutazioni superino comunque un numero nell'ordine di grandezza del centinaio (appurato come numero limite di iterazioni che possono essere eseguite del primo modello, in tempi d'attesa ragionevoli per l'utente), si rende necessario il filtraggio delle opzioni già compatibili con il filtraggio altrimenti immediatamente adoperato. 4.5 Considerazioni su correttezza e complessità L'algoritmo si basa su quello presentato al capitolo precedente e sulla permutazione di numeri, attraverso un algoritmo consolidato e pertanto la correttezza di quanto proposto nel presente capitolo deriva in maniera diretta dalle garanzie fornite da tali strumenti impiegati. Per quanto riguarda la complessità, invece, la polinomialità non è più garantita, dato che il problema presenta le caratteristiche dei problemi NP-Hard. Per rendersene conto è sufficiente ignorare i costi di pernottamento e considerare i costi per ciascuna tratta o spostamento come non mutabili nel tempo, di fatto riconducendo il problema al problema del TSP (Traveling Salesman Problem); sicuramente l'introduzione di costi variabili nel tempo sugli archi non rende più semplice il problema; in particolare, se m! è il numero delle permutazioni sulle mete considerate e O(m g (log x + c)) era la complessità del precedente algoritmo, la complessità del presente è: O(m! g (log x + c)). 85

96 IL SECONDO MODELLO 4.6 Prestazioni del Sistema Vengono di seguito proposti i dati relativi al tempo di esecuzione della soluzione implementata (escluse le considerazioni di cui al punto 4.3) e ricavati da 25 interazioni ciascuna, considerando i medesimi itinerari di base, selezionando un intervallo di giorni possibili per la partenza variabile da 2 a 6 giorni, selezionando sempre un albergo come soluzione per i pernottamenti e aggiungendo mano a mano una meta: Numero di Mete Tab. 4-1 Prestazioni del secondo modello Tempo Medio di Esecuzione Numero Medio di Nodi Analizzati Query a database Tempo medio esecuzione query* 1 1,19 162,36 313,25 0, ,51 322,44 623,46 0, ,54 853, ,23 0, , , ,116 0, , , ,54 0,0033 Valgono le considerazioni fatte nel capitolo precedente, in sede di presentazione dei risultati (par. 3.9). In questo caso il crescere del tempo di interrogazione medio al db non è da attribuire ad effettivo allungarsi dei tempi richiesti per il fetch dei dati ma piuttosto dal notevole impiego di memoria da parte del sistema e quindi dalla necessità dello stesso di fare impiego di memoria di swap, con i relativi rallentamenti dovuti ad I/O su periferiche di memoria di secondo livello. Dai risultati emersi è possibile rendersi conto di come effettivamente l'appartenenza dell'algoritmo presentato alla classe di problemi NP-Hard peggiori drasticamente le prestazioni; ecco dunque che già con 4 mete i tempi d'attesa per l'utente crescono drasticamente e già con 5 mete questi diventano inaccettabili. Da questi derivano le considerazioni del paragrafo 4.3, con miglioramento delle prestazioni dipendente dal numero di permutazioni che si decide di considerare. 86

97 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB 4.7 Qualità delle soluzioni fornite Vengono di seguito riportati alcuni risultati, ottenuti a partire dagli stessi dati considerati al paragrafo Minimizzazione del costo - Itinerari a due tappe Tipo di Ricerca Media Costo Media Durata Modello 1 274, Modello 2 271, Tradizionale 302, Minimizzazione del costo - Itinerari a tre tappe Tipo di Ricerca Media Costo Media Durata Modello 1 Modello 2 312, Tradizionale 413, Come si può evincere dai risultati sopra riportati, nel caso di due sole tappe i benefici del sistema si rivelano relativi, in quanto presumibilmente questo ha agito in maniera conforme a quanto già eseguito dal precedente modello e quindi dalla scelta operata dall'utente; con due sole destinazioni, lo spazio di ricerca non si presenta d'altronde molto ampio. Interessante notare invece, come nel caso di tre mete, la soluzione proposta migliori in maniera piuttosto netta i risultati già peraltro apprezzabili del modello precedente. A fronte dei risparmi rispettivamente del 10% e 20% rispettivamente, il presente modello consente risparmi del 10% e 25%; Per quanto riguarda la durata dei trasferimenti, questa presenta differenze con il primo modello insignificanti nel primo caso (0,002%) e comunque ridotte, anche se in eccesso, in questo caso, nel secondo (1,4%). Minimizzazione della durata - Itinerari a due tappe Tipo di Ricerca Media Costo Media Durata Modello 1 328, Modello 2 388, Tradizionale 348, Minimizzazione della durata - Itinerari a tre tappe Tipo di Ricerca Media Costo Media Durata Modello 1 672, Modello 2 673, Tradizionale 746,

98 IL SECONDO MODELLO Anche nel caso della ricerca del trasferimenti di durata inferiore il secondo prototipo offre risultati paragonabili a quelli offerti nel caso precedente; contenuta la differenza rispetto al precedente modello nel caso di due sole mete (3%), più significativa quella nel caso di tre mete (13%). Bilanciamento costo/durata trasferimento - Itinerari a due tappe Tipo di Ricerca Media Costo Media Durata Modello 1 275, Modello 2 265, Tradizionale 324, Bilanciamento costo/durata trasferimento - Itinerari a tre tappe Tipo di Ricerca Media Costo Media Durata Modello 1 477, Modello 2 454, Tradizionale 526, Anche nel caso di ricerche che richiedessero un compromesso tra velocità di trasferimento, le differenze tra il secondo prototipo ed il primo risultano meno nette nel caso di due tappe, più marcate nel caso di tre. Nel primo caso, a fronte di un miglioramento in termini di risparmio del 4% è corrisposto un peggioramento del 2% nei tempi di trasferimento, mentre nel secondo caso sono migliorati sia il risparmio in termini di denaro (5%), che di tempo (0,1), seppure in misura minima in quest'ultimo caso. E' possibile rendersi quindi conto di come in misura più o meno accentuata l'impiego di questo secondo modello possa ulteriormente migliorare i risultati offerti dal primo, aumentando peraltro progressivamente il divario nelle soluzioni proposte al crescere delle mete, a fronte comunque di un tempo d'attesa per l'utente inevitabilmente crescente, in modo non lineare rispetto alle mete selezionate. 88

99 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Capitolo 5 DETERMINAZIONE DEI COSTI DEI TRASFERIMENTI AEREI Sebbene in grado di apportare già un buon contributo all'utente che intenda pianificare un viaggio, i modelli sino a qui proposto non possono purtroppo essere considerati ottimi (come del resto neppure nessun altro sistema attualmente proposto), in quanto non sono in grado di tenere conto delle reali metodologie con cui vengono determinati i prezzi per le tratte aeree quando uno stesso viaggio contempla più di uno spostamento con tale mezzo. Sino a qui si sono infatti considerati, alla stregua di ciò che fanno tutte le agenzie on-line, oltre che i siti stessi delle compagnie aeree, tutti i trasferimenti aerei come indipendenti tra loro, mentre nella realtà vi sono complesse relazioni che legano diverse tratte tra loro e che comportano nella maggior parte dei casi variazioni di prezzo anche sostanziali (e quindi anche eventuali relativi risparmi per il viaggiatore), a seconda della combinazione delle tariffe e dei diversi voli scelti per portare a termine il viaggio nella sua interezza. Tali regole di composizione di fare sono quasi sempre messe a disposizione solamente alle agenzie di viaggio reali, attraverso i sistemi GDS, introdotti nel primo capitolo e la determinazione del prezzo finale per un biglietto aereo avviene in pratica manualmente, ad opera di un agente di viaggio. Tale limitazione, oltre alla complessità stessa dei meccanismi di determinazione di tali tariffe, come si vedrà tra poco, rendono attualmente assai ardua l'impresa di riuscire a ricavare la tariffa ottima per un itinerario in cui compaiano anche tratte aeree. Scopo di questo capitolo è introdurre i modelli utilizzati per la determinazione dei prezzi delle tratte aeree, sia nella loro individualità, sia nel contesto più complesso di un intero viaggio e di delinearne gli aspetti intrinsecamente complessi che impediscono a qualsiasi tipo di sistema automatizzato di essere in grado di fornire sicuramente la migliore tariffa possibile per un certo itinerario. In una prima parte, maggiormente descrittiva, sarà introdotto lo Yield Management da un punto di vista più che altro storico e descrittivo, così da introdurre i motivi che hanno portato a modelli di determinazione dei prezzi così complessi, mentre nella seconda parte del capitolo saranno invece analizzate in maggior dettaglio le conseguenze in termini di complessità che questo comporta nella determinazione di un itinerario ottimo. Il capitolo si concluderà infine con alcune riflessioni su come i modelli sino a qui proposti possano comunque ritenersi validi e di come questi possano essere ulteriormente 89

100 DETERMINAZIONE DEI COSTI DELLE TRATTE AEREE migliorati nel tentativo di fare fronte alle problematiche introdotte. 5.1 Yield Management Con il termine Yield Management (o anche Revenue Management, d'ora in poi abbreviato RM) si intendono tutti quei processi di comprensione, revisione, anticipazione e reazione ai comportamenti dei consumatori con l'intento di massimizzare i profitti derivanti dalla vendita di prodotti o più spesso servizi di un'azienda. Le industrie in cui tale fenomeno è maggiormente diffuso sono proprio quelle legate ai viaggi ed in particolare ne fanno cospicuo utilizzo le compagnie aeree, le strutture ricettive e le aziende che noleggiano autoveicoli; è per questo motivo che ne è opportuna se non altro una breve trattazione in questa sede. Tab. 5-1 Alcune grandezze che intervengono nell'ambito del RM nel settore dei viaggi Parametro Compagnia Aerea Hotel Compagnia Noleggio Unità di Base Posto a Sedere Camera Veicolo Tipi di Risorsa 2-3 (classi) 2-10 (tipi camere) 5-20 (tipi veicolo) Capacità Fissata Fissata Variabile Numero di possibili classi di prezzo per la stessa risorsa Durata di utilizzo della risorsa 4-10 (fares) Fissato Variabile Variabile Fonte: Elaborazione propria Le complicazioni introdotte dalle metodologie dello RM, soprattutto per quanto riguarda gli spostamenti aerei, hanno notevolmente incrementato la complessità del problema della pianificazione di un itinerario ed hanno pertanto suscitato nel tempo commenti anche piuttosto significativi, come ad esempio: Management Scientists have Wrecked the Airline Industry (Joseph F. Coates, intellettuale, scrittore) e "When we started we assumed it was path planning. You think you'll write your algorithm in a day in a half and you're done but then you see the prices and you realize you have another ten years of work ahead." (Carl de Marcken, co-fondatore di ITA Software). Il fenomeno del RM venne citato per la prima volta nel 1962 da C.J. Taylor, quando fu introdotto per la prima volta il fenomeno dell'overbooking, ovvero della possibilità di generare profitti in seguito alla vendita di un numero superiore di biglietti rispetto all'effettiva disponibilità di posti su un aeromobile, in previsione dei no-shows ovvero di quei passeggeri che non avrebbero effettivamente preso parte al volo [Bell 2007]. Il RM incontrò comunque la popolarità che lo rende ancora oggi un imprescindibile strumento per la determinazione dei prezzi legati al settore dei viaggi solo nella prima 90

101 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB metà degli anni '80, quando Robert Crandall, Tom Cook (American Airlines, SABRE) e Robert Cross (Delta) in particolare proposero i primi modelli per l'adeguamento dinamico dei prezzi dei voli, per lo più come contromossa alla crescente popolarità che le compagnie low-cost stavano iniziando ad incontrare a seguito della liberalizzazione del mercato aereo. L'impatto di tali tecniche si rivelò immediatamente determinante non solo nella quotidiana competizione tra le diverse aziende, ma addirittura come elemento fondamentale per permetterne la profittabilità a lungo termine e quindi la sopravvivenza (American Airlines, Delta, National Car Rental) o determinarne la bancarotta (Peoples' Express Airlines) [McAfee & te Velde 2005]. I calcoli a posteriori di American Airlines hanno rivelato che l'intensivo utilizzo di tecniche di RM hanno permesso all'azienda di generare 1.4 miliardi di dollari in aggiunta ai ricavi tradizionali tra il 1989 ed il 1991; nel frattempo, Donald Burr, ex manager di People Express, commentava con le seguenti parole la bancarotta della propria azienda: "We were a vibrant, profitable company from 1981 to 1985, and then we tipped right over into losing $50 millions a month. We were still the same company. What changed was American s ability to do widespread Yield Management in everyone of our markets. We had been profitable from the day we started until American came at us with Ultimate Super Savers. That was the end of our run because they were able to underprice us at will and surreptitiously. There was nothing left to defend us." Tra gli altri, l'elemento che maggiormente contraddistingue il RM è sicuramente la cosiddetta price discrimination, spesso nota anche come Dynamic Pricing, ovvero la differenza nel corrispettivo richiesto per la medesima vendita di prodotto o prestazione di servizio, a seconda del momento e del contesto in cui essa avviene. Il punto chiave della price discrimination è che la quantità di risorse di un certo tipo disponibili in un certo istante di tempo sono impiegate per determinare in maniera dinamica il prezzo della risorsa stessa; lo scenario tipico è quello in cui inizialmente vi sono un certo numero di risorse disponibili allocate a classi di prezzo inferiori, che quando vengono saturate costringono l'utente successivo a pagare di più se desidera comunque avvalersi di quel servizio. Inizialmente viene impostato il cosiddetto booking limit, ovvero il massimo numero di risorse che possono essere vendute a prezzo scontato; una volta raggiunto tale limite, i clienti futuri saranno costretti a pagare il prezzo pieno se sono interessati a godere lo stesso della risorsa in questione; le risorse riservate per la classe di prezzo superiore sono così protette dal cosiddetto protection level, dove: protection level = disponibilità risorsa booking limit La problematica che quindi il fornitore di servizi si pone è quindi quello di determinare il protection level più opportuno, per evitare di rimanere con porzioni di risorsa invenduta in un caso o vendere porzioni di risorsa ad un basso prezzo, quando magari vi sarebbero stati clienti disposti a pagare un prezzo maggiore per lo stesso servizio; la domanda chiave che questi si pone è in sostanza: quante risorse allocare alla classe inferiore, sperando di avere poi un numero sufficiente di clienti disposti a pagare il prezzo della classe superiore per la medesima risorsa una volta raggiunto tale limite? Oppure, analogamente: quante 91

102 DETERMINAZIONE DEI COSTI DELLE TRATTE AEREE risorse allocare alla classe di prezzo maggiore, sperando che vi siano clienti disposti a pagare tanto, rischiando di perdere invece clienti che sicuramente avrebbero sicuramente effettuato una prenotazione ad un prezzo minore, ma non sono invece disposti a pagare il costo della classe di prezzo maggiore?. Risposte a queste domande sono nella maggior parte dei casi determinate con approcci probabilistici e un certo numero di risorse vengono quindi riservate alle classi di prezzo superiori secondo considerazioni storiche o aspettative legate a particolari eventi (es. maggior probabilità di avere un numero di clienti considerevole e quindi di utenti disposti a pagare un prezzo più alto in un giorno festivo per una struttura ricettiva rivolta prevalentemente alle famiglie, maggior probabilità di avere un numero maggiore di clienti nei giorni feriali per un hotel rivolto a clientela che viaggia per affari). Accade inoltre spesso che negli istanti temporali imminentemente precedenti alla prestazione del servizio, vengano eventualmente rese nuovamente disponibili risorse alle classi di prezzo inferiori, così da massimizzare ad ogni caso i profitti, invogliando un numero maggiore di potenziali utenti ad occupare in ogni caso risorse che altrimenti rimarrebbero vuote (fenomeno del last-minute). Per eventuali approfondimenti sull'argomento è possibile consultare i lavori iniziali di Rothstein e Litttlewood [Bitran & Caldentey 2002], oltre che soprattutto [Belobaba 1987] in cui viene introdotta la EMSR Heuristic (Expected Marginal Seat Revenue), teoria alla base di molti lavori seguenti; ulteriori spunti e considerazioni in merito possono essere ricavate anche ad esempio da [Netessine & Shumsky 2002], oltre che da un certo numero di altre pubblicazioni nei giornali di ricerca operativa (citazioni agli articoli sono reperibili sia in [Bitran & Caldentey 2002], sia in [McAfee & te Velde 2005]). L'importanza del dynamic pricing è peraltro così rilevante che il termine viene spesso impiegato per indicare l'intero RM, che ne costituisce in realtà un vasto soprainsieme. Oltre al dynamic pricing, vi sono infatti tutta una serie di altre problematiche e considerazioni che da sole necessiterebbero una trattazione specifica piuttosto corposa: ad esempio, nell'ambito delle aziende che forniscono noleggio di veicoli, tecniche di RM sono adottate non solo per stabilire il prezzo di una certa risorsa, ma anche e soprattutto per determinare i costi dei vari servizi accessori offerti (assicurazioni, proposte di veicoli di categoria superiore, etc); sempre nello stesso ambito, così come in quello del mercato degli alloggi sono spesso previste scontistiche per utilizzi prolungati di una medesima risorsa (i modelli descritti nel presente documento considerano implicitamente questo aspetto); in tutti i settori sta inoltre diventando sempre più frequente il fenomeno dei Premi Fedeltà con cui ad un utente sono garantite agevolazioni qualora questi utilizzi di frequente i servizi offerti dalla medesima azienda. Ma gli esempi potrebbero continuare a lungo ed una trattazione approfondita sul RM esula dallo scopo di questo documento ed è per questo che nei paragrafi seguenti saranno richiamati solamente quegli aspetti che direttamente comportano problematiche anche piuttosto rilevanti nella pianificazione di un viaggio ed in particolare nella ricerca e determinazione della tariffa migliore per l'acquisto di un certo numero di biglietti aerei corrispondenti ad un certo numero di trasferimenti. Dato che lo scopo finale del presente lavoro è costruire un prototipo di sistema software in grado di dare risposte immediate a ricerche effettuate dall'utente, il fenomeno del dynamic pricing non verrà anzi ulteriormente considerato, se non marginalmente, dove necessario per introdurre altri concetti. 92

103 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Considerare infatti il dynamic pricing nell'ambito del presente lavoro implicherebbe per il sistema la necessità rimanere in ascolto per captare eventuali variazioni di prezzo favorevoli nel tempo, con il conseguente aggiornamento costante dell'itinerario per il viaggiatore; ciò in ovvio contrasto con l'obiettivo dello scrivente di realizzare un prototipo in grado di fornire una risposta alla ricerca sottoposta dall'utente entro un numero ragionevole di secondi. Risulta peraltro intuitivo comprendere come le modellazioni che tengano in considerazione il dynamic pricing rischino di generare un altissimo numero di insuccessi nella restituzione di risultati all'utente, poiché soprattutto quando è previsto un numero di voli piuttosto consistente, è decisamente bassa la probabilità che tutti siano effettivamente disponibili nel momento in cui è più alta la possibilità di ottenere tariffe migliori (last minute). Ecco quindi che l'unico momento in cui eventuali considerazioni riguardanti il dynamic pricing possono rientrare nel contesto del presente lavoro è in sede di utilizzo del sistema, peraltro in modo piuttosto intuitivo e forse scontato; osservando infatti i risultati studiati da [Bitran & Claentey 2002] e [McAfee & te Velde 2005] è possibile rendersi conto di come in realtà una maggior probabilità di trovare una risorsa disponibile, alla classe di prezzo minima disponibile corrisponda semplicemente ad una maggiore anticipazione nell'atto di ricerca e prenotazione. 5.2 Voli, Fares, Fare Components, Regole e Priceable Units Tra tutti gli aspetti contemplati dal RM, quello più importante nel nostro contesto è sicuramente quello relativo alla determinazione del prezzo di un biglietto aereo quando più voli sono previsti nell'ambito dello stesso viaggio. Questo ambito presenta infatti caratteristiche di complessità molto più accentuate rispetto a quelli relativi praticamente ad ogni altro prodotto o servizio, presentando peraltro aspetti assai poco intuitivi e costituendo, l'aspetto più difficile nella determinazione di un viaggio. [de Marcken 2003] Prezzi e voli hanno infatti relazioni molto complesse tra loro ed algoritmi polinomiali, come ad esempio quelli basati su programmazione dinamica precedentemente introdotti non possono essere impiegate per risolvere un problema che di fatto NP-Hard, dato che i prezzi di ciascuna tratta dipendono dall'intero itinerario del viaggio; è quindi necessario considerare tutti gli interi percorsi alternativi per poter determinare quello migliore, con le ovvie conseguenze dal punto di vista della complessità computazionale. E' immediato notare come tale considerazione risulti particolarmente importante nel nostro caso, poiché di fatto toglie la sicurezza di ottimalità che si poteva avere nel modello sino a qui proposto. Maggiori considerazioni in merito verranno fatte nei prossimi paragrafi; di seguito vengono invece introdotti gli aspetti che apportano al problema simili livelli di complessità, preceduti dal seguente elenco di definizioni, necessario per la comprensione di quanto segue: Market : si definisce con questo termine una coppia di città tra le quali deve avvenire uno spostamento attraverso l'impiego indifferentemente di uno o più voli. 93

104 DETERMINAZIONE DEI COSTI DELLE TRATTE AEREE Volo : con questo termine si intende il singolo spostamento fisico di un aereovelivolo dall'aeroporto di decollo a quello dell'atterraggio. Fare : si definisce fare il prezzo per uno spostamento da un luogo ad un altro (market), indipendentemente dal numero di voli effettivamente impiegati per effettuare lo spostamento Fare Basis: con questo termine si intende il codice alfanumerico che identifica una particolare Fare. Fare Component : Una fare si riferisce al trasferimento tra un luogo ed un altro, ma non necessariamente contempla i costi per un solo volo; ecco quindi che con il termine Fare Component si intende la Fare, ovvero il costo per il trasferimento più l'insieme di tutti i voli effettivamente necessari per operare questo trasferimento. Priceable Unit: Con questo termine si intende un raggruppamento di diverse fare in una delle diverse combinazioni geometriche possibili. Un itinerario è in genere costituito da una o più PU, ciascuna contente un certo numero di fares. Considerando l'elenco sopra riportato, dovrebbe risultare quindi chiaro come l'elemento di base per la determinazione della tariffa relativa ad uno spostamento aereo sia la fare, ovvero il prezzo legato a quello che è stato sin qui definito un trasferimento tra due dei diversi luoghi che l'utente intende visitare nel proprio viaggio. Da notare però che la nozione di Fare non è necessariamente in relazione 1-1 con il concetto di volo; infatti le relazioni che intercorrono tra le due quantità sono le seguenti: ogni volo dev'essere contemplato da una ed al più una fare una Fare può coprire più voli (solitamente consecutivi) una o più fare sono impiegate per pagare il costo di un intero viaggio La Fare costituisce in pratica l'unità atomica in termini di prezzo per il mercato aereo ed è l'insieme di diverse fare che determinano l'importo complessivo dovuto per un intero viaggio. Nell'esempio che segue, il concetto di fare viene maggiormente chiarito, così come viene messo in evidenza il fenomeno dell'irregolarità nel rapporto tra costi e ricavi nel mercato aereo. 94

105 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Fare Esempio ID Da A Basis Costo 1 A B Y B A Y A C AP C B AP Fonte: Elaborazione propria Nelle illustrazioni sopra riportate vengono raffigurati in forma grafica e tabellare un certo numero di voli e Fare. Supponendo che un generico utente desideri raggiungere la città di A a partire da B è immediato notare come vi siano una sola fare ed un solo volo disponibili, ragione per la quale l'utente sicuramente dovrà corrispondere un importo pari a 1000 alla compagnia, volando sul volo 3, in una classe Y (fare 2). Supponendo ora lo stesso utente voglia tornare indietro da A a B, ha a questo punto diverse possibilità. Sicuramente potrà acquistare la fare 1 come tratta singola (in maniera analoga a come aveva acquistato 2) corrispondendo altre 1000 unità di denaro alla compagnia aerea per un totale di 2000 unità di denaro; è però anche possibile gli sia concesso acquistare 2 Fare ulteriori anziché una (in questo caso la Basis della Fare impone che l'acquisto del biglietto avvenga con almeno 14 giorni di anticipo), spendendo meno di quanto avrebbe speso acquistando una sola Fare per il ritorno. E' quindi possibile notare che indipendentemente dalla fare selezionata, per raggiungere la città B dalla città A l'utente sarà ad ogni modo costretto a prendere parte al volo 3 e al volo 4. Ad ogni modo l'utente, a seconda delle fare che seleziona può spendere 2000 unità di denaro scegliendo le fare 1 e 2, oppure spenderne solo 1600, acquistando le Fare 2,3 e 4. L'esempio in questo caso illustra anche lo strano fenomeno prima introdotto della non proporzionalità nel rapporto tra costi e ricavi per le compagnie aeree. 95

106 DETERMINAZIONE DEI COSTI DELLE TRATTE AEREE Come si può notare dall'esempio, una fare è quindi contraddistinta da una Basis e accompagnata da una serie di regole; è così possibile, anzi, praticamente sempre verificato, che esistano più fare per lo stesso trasferimento, con importi diversi, a seconda delle varie regole che le riguardano. Tipici fattori discriminanti (regole) che permettono o meno la prenotazione tra le diverse Fare disponibili sono riconducibili a: generalità del passeggero (età, nazionalità, frequent flyer) dati relativi al trasferimento (data di partenza, compagnia aerea, durata) dati relativi alla priceable unit (tipo di price unit, altre fare nella priceable unit) nazione in cui viene effettuato l'acquisto del biglietto dati relativi al biglietto (possibilità di rimborso, anticipo nell'acquisto) Tra le regole più frequenti vi sono quelle che impediscono il rimborso nel caso in cui il viaggiatore non prenda parte ad un trasferimento, la necessità di acquistare il biglietto con almeno 14 giorni di anticipo (come nell'esempio sopra riportato) o la richiesta che la fare sia accompagnata nello stesso viaggio, da una identica, in verso opposto ( round trip - andata e ritorno), magari contemplando un soggiorno per una notte di sabato nel mezzo. Tale regola è stata istituita per scoraggiare gli uomini d'affari e chi viaggia per lavoro in genere di usufruire di queste tariffe, tenendo in considerazione che tale tipologia di viaggiatori preferisce tendenzialmente spendere i fine settimana con i propri familiari. Una prima difficoltà concettuale può essere a dire il vero colta già analizzando il contenuto del precedente paragrafo; considerando infatti le diverse regole che accompagnano le Fare e i diversi importi che queste hanno è possibile infatti notare che il concetto di tariffa migliore è tutt'altro che chiaro e univoco. Di fatto la fare migliore per un utente potrebbe non esserlo per un altro (ad esempio ad un utente potrebbe interessare la possibilità di rinuncia al volo, mentre ad un altro no) e quindi anche nella costruzione del modello proposto nel prossimo capitolo tale aspetto dovrà essere opportunamente trattato. Un altro insieme di regole frequentemente presenti sui biglietti è noto con il nome di routing e sono regole che restringono le possibilità di geometria della priceable unit (maggiori dettagli tra poco) in cui la fare è inserita, influendo quindi sul modo in cui diverse priceable units costituiscono il biglietto per un itinerario completo. Le caratteristiche del modello appena descritto non sono ovviamente esenti da imperfezioni che permettano agli utenti più avveduti di raggirare in qualche modo le limitazioni imposte dalle compagnie aere per le fare più convenienti; conosciuto è il fenomeno del back to back ticketing (vietato in realtà dalle compagnie aeree, ma allo stesso tempo praticamente inevitabile e quindi frequente) con cui biglietti aerei non vengono usati di proposito, nonostante regolarmente acquistati, per risparmiare comunque sulle spese di un viaggio. Ecco di seguito un esempio di tale impiego irregolare di biglietto: Supponendo che l'utente X voglia viaggiare da A a B in una certa data e ritornare il giorno seguente; in questo caso egli avrebbe a disposizione una fare 1000 utilizzabile sia per l'andata che per il ritorno, da usarsi in combinazione round- 96

107 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB trip. La stessa compagnia offre poi una fare di 400 a tratta per il round trip, se tra le due tratte passa un sabato notte. Ecco allora che l'utente intenzionalmente acquista 2 biglietti round trip, posticipando il giorno di ritorno del primo ed anticipando il giorno di partenza nel secondo. In questo caso, anche se non utilizzerà mai due tratte (peraltro regolarmente corrisposte) pagherà = 1600 che sono comunque a lui più convenienti rispetto al prezzo regolare di 2000 che avrebbe dovuto altrimenti corrispondere. Come si può notare quindi, quello delle tariffe per i voli è un mondo parecchio complesso e per certi versi bizzarro; inoltre, come se le Fare da sole non costituissero una complicazione non indifferente al problema della determinazione dell'itinerario più conveniente, tra le singole Fare e l'acquisto di un biglietto aereo vi sono altre strutture sicuramente degne di nota: le Priceable Unit o semplicemente PU, ovvero il dominio in cui si verificano gli effetti delle Fare. Per poter essere emesso un biglietto deve contenere una o più fare divise in una o più priceable units che rispettano una delle tipologie sotto raffigurate: Come è lecito aspettarsi, le restrizioni che regolano Fare diverse avvengono tipicamente all'interno della stessa Priceable Unit (tipico esempio che nel caso di un round trip vi sia un pernottamento in una notte di sabato nel mezzo per poter avere accesso alla fare migliore e non dover ad esempio ricorrere all'acquisto separato di due priceable unit oneway quasi sempre più costose), ma è anche possibile che fare all'interno di una certa priceable unit influiscano sulle fare di un'altra priceable unit all'interno dello stesso biglietto. Effettivamente, considerando il fatto che le fare già contengono limitazioni sulle geometrie che è possibile utilizzare, una semplificazione concettuale del modello potrebbe essere fatta andando semplicemente a considerare le regole di una fare come: Regole Fare = Regole Proprie n Regole Generiche Priceable Unit Le Priceable Unit infatti regolano le combinazioni di geometrie che è possibile considerare indipendentemente dalle fare specifiche considerate. Ad ogni modo, nonostante questa ed eventuali altre semplificazioni notazionali, dovrebbe essere chiaro come la complessità introdotta da queste modellazioni risulti già così notevole, peraltro senza le complicazioni addizionali come ad introdotte dagli IATA checks (controlli sui voli internazionali) e i confronti tra biglietti di più passeggeri (ad esempio alcune fare 97

108 DETERMINAZIONE DEI COSTI DELLE TRATTE AEREE economiche pensate per i bambini potrebbero richiedere l'emissione congiunta di un biglietto di classe superiore per poter essere effettivamente utilizzate nell'ambito di un viaggio). Anche in questo caso una trattazione esaustiva di questi fenomeni, peraltro alquanto particolari e peculiari esula dallo scopo del presente documento e pertanto in sede di modellazione saranno fatte assunzioni in grado di permettere la considerazione delle fare tipicamente adatte nella maggior parte dei casi, in maniera tale a come queste vengono proposte dai comuni motori di ricerca per voli. A partire da un profilo di viaggiatore medio, si cercherà quindi di determinare le fare migliori per l'utente sulla base di un set di trasferimenti (e quindi anche di voli) già fissati; anche tale attività apparentemente semplice, cela in realtà le complessità dei problemi NP completi [de Marcken 2003] e ovviamente tali considerazioni dovranno essere tenute a mente nel cercare di migliorare i risultati offerti dai modelli presentati nei precedenti capitoli. 5.3 Complessità nella Determinazione delle Fare Prima ancora di poter determinare la convenienza di un certo gruppo di fare, rispetto ad altre possibili combinazioni, bisogna ovviamente poter determinare se il gruppo di fare stesso può esistere o se invece viola qualche regola prevista per almeno una delle fare da cui è composto. Sebbene tale verifica possa essere fatta in tempo polinomiale, la costruzione di un gruppo di fare (in grado di rispettare le regole di ciascuna singola fare e quindi di costituire un valido biglietto) è più difficile, considerato il fatto che lo spazio di ricerca della stessa risulta esponenzialmente crescente sul numero delle fare considerate. Le caratteristiche del problema sono quelle tipiche dei problemi appartenenti alla classe dei problemi NP ed è pertanto ragionevole tentare di ridurre un problema NP-Completo noto al problema di creare un'insieme di fare. Di seguito viene proposta una riduzione dal problema dell'independent Set al nostro problema, chiamato VFG, ovvero Valid Fare Group. 98

109 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Spunto di Dimostrazione: VFG è un problema NP Hard. La dimostrazione viene fatta in maniera intuitiva attraverso la riduzione di un istanza del problema IS (ovvero independent set) [Garey & Johnson 1979] ad un'istanza di VFG, nell'intento di dimostrare che IS = VFG. Si consideri dunque un grafo, in cui ogni nodo è rappresentato da una coppia di numeri; nella fattispecie facciamo corrispondere al primo di essi il market (ovvero la coppia città di partenza, città di arrivo), mentre il secondo indica una delle opzioni possibili per tale tratta (una fare). Se nell'istanza di grafo sotto rappresentata siamo in grado di trovare un istanza di IS, allora siamo anche in grado di trovare un insieme di fare compatibili tra loro. Nell'istanza sottostante viene rappresentato un grafo il cui IS di dimensione maggiore è 3, cui corrisponde una combinazione di 3 fare compatibili tra loro. E' ovvio che per percorrere il medesimo tragitto potrà essere impiegata in maniera mutualmente esclusiva soltanto una delle fare previste ed è per questo che ciascuna fare sarà connessa con tutte le altre fare dello stesso market, così da far si che non tutte possano far parte dello stesso IS. Fig. 5-1 Selezione fare compatibili Fonte: Elaborazione propria A questo punto un set indipendente di dimensione pari al numero dei voli che si intende fare già contemplerebbe uno ed al più uno spostamento in ciascun market. La compatibilità tra fare riesce anche ad essere espressa attraverso IS; nel nostro caso, ad esempio la compatibilità di V11 con V22 e V23, ma non con V21 viene espressa proprio attraverso l'arco (V11,V21); ecco quindi che per effettuare i due spostamenti il viaggiatore può scegliere o la fare V11 e poi una tra V22 o V23, oppure una tra V12 e V13, potendo poi scegliere rispettivamente V22 o V23 oppure V21 o V22. Simili considerazioni valgono per le restrizioni tra la tratta 2 e la tratta 3 e anche tra la tratta 3 e la tratta 1. Ecco quindi che la costruzione di un gruppo di fare valide per lo stesso biglietto è possibile solo se esiste, nel grafo sopra indicato un independent set di 99

110 DETERMINAZIONE DEI COSTI DELLE TRATTE AEREE cardinalità k, dove k indica il numero di voli previsti. Qualora non sia raggiunto il numero di spostamenti previsti, significa che non tutti gli spostamenti possono stare sullo stesso biglietto ed è quindi necessario acquistare più biglietti separati. L'independent set di dimensione massima determina in pratica il numero di voli massimo che possono comparire in un biglietto. Un problema che questo spunto di dimostrazione non considera, è che effettivamente le regole sulle fare possono anche prevedere vincoli mutualmente esclusivi sulla geometria dei tragitti considerati; ad esempio, in un itinerario a tre tappe si può verificare il caso in cui non vi siano fare che permettano a tutte queste di essere considerate all'interno della stessa Priceable Unit e quindi di dover necessariamente avere un minimo di due Priceable Unit, in cui una copre due trasferimenti, una uno solo (viene qui richiamato il concetto anche se essendo indipendenti tra loro di fatto più Priceable Units possono essere fatte corrispondere a diversi biglietti, anziché essere considerate come tali). Nello spunto di dimostrazione che segue le prime due cifre dell'identificativo di ciascun nodo assumono lo stesso significativo che avevano in precedenza, mentre la terza cifra è utilizzata per indicare l'appartenenza di un volo ad una priceable unit/biglietto, piuttosto che ad un'altra/o. Come prima viene costruito un grafo in cui si cerca l'is di dimensione massima, cui corrisponderanno fare compatibili tra loro. Fig. 5-2 Combinazione Price Units Fonte: Elaborazione propria 100

111 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB La stessa struttura di fare viene costruita per ciascuna PU ed archi tra i rispettivi voli; l'is di dimensione massima in questo caso contemplerà sicuramente tutti i voli previsti, eventualmente uno per ciascuna PU se non vi sono all'interno della stessa PU voli compatibili tra loro. La complessità appena introdotta, soprattutto se aggiunta agli aspetti NP hard considerati nel capitolo precedente danno quindi poche speranze per i tentativi di realizzazione di sistemi di ricerca automatizzata della tariffa complessivamente più conveniente in un itinerario, che preveda una certa flessibilità. Tale affermazione consegue anche dal fatto che contrariamente ad altri problemi noti appartenenti alla classe NP, l'assoluta imprevedibilità, sregolatezza e frequenza di aggiornamento con cui le tariffe relative ai trasferimenti aerei vengono create, aggiornate e successivamente rese indisponibili, rendono problematica anche la sola formulazione ed impiego di euristiche, comuni o appositamente studiate. 5.4 Altre problematiche Oltre alle problematiche computazionali di cui si è appena fatto accenno, la complessità dei sistemi di prenotazione delle tratte aeree comporta tutta un'ulteriore serie di problematiche; innanzitutto un problema da affrontare in sede di realizzazione di sistemi B2C online è il filtraggio delle combinazioni di volo disponibili quando più voli si rendono necessari per soddisfare un unico market; nel nostro scenario esemplificativo (vedi appendice A) le fare erano infatti già state preparate così che una semplice interrogazione a database potesse direttamente fornire un dato utile; nella realtà le cose sono ben diverse, dato che per costruire trasferimenti all'interno di uno stesso market è necessario trovare voli compatibili, dalla cui combinazione risulti il trasferimento cercato. Una tale ricerca si dimostra tutt'altro che semplice, dato che la combinazioni di volo sono spesso elevatissime (si pensi che per la sola tratta Boston San Francisco nell'arco della stessa giornata vi sono più di 2000 possibili combinazioni); il problema tuttavia non deve spaventare eccessivamente in questo caso, dato che vi sono già aziende specializzate nel filtraggio di tali tipi di dato, così da fornire i sistemi automatizzati risultati immediatamente fruibili. Ulteriori problematiche di cui non si tiene tipicamente conto nella realizzazione di sistemi B2C online, ma che sembra doveroso citare se non altro per completezza, sono gli IIATA checks, ovvero i controlli per allineare i prezzi nel mercato mondiale (ad esempio dall'italia non può essere emesso un biglietto destinato al mercato indiano, che a sua volta, non potrà risultare eccessivamente ribassato nel prezzo, rispetto ad una soglia minima internazionale prestabilita); i multi-trip coupons, ovvero biglietti spendibili per un certo numero di voli, anche non nello stesso viaggio; i loyalty programs e i prezzi personalizzati, ovvero quelle opzioni e fasce tariffarie riservati ai clienti che utilizzano spesso i voli della stessa compagnia; non da ultimo, contemplando in un sistema B2C tutte le problematiche relative alle fare bisognerebbe anche prevedere i possibili raggiri operati 101

112 DETERMINAZIONE DEI COSTI DELLE TRATTE AEREE dagli utenti esperti per ottenere in modo poco trasparente tariffe migliori (ad esempio acquistando in mercati esteri, oppure acquistando tratte aeree di cui non si farà utilizzo per abbassare il costo totale dell'itinerario, potendo godere di sconti su altre tratte). Com'è possibile notare quindi, il mondo delle tariffe aeree è contrassegnato da complessità intrinseche che attualmente nessun sistema contempla e che permette unicamente ai bravi agenti di viaggio di ottenere le tariffe migliori per una specifica tratta, ovviamente senza lasciare nessuna speranza nella ricerca della tariffa sicuramente più vantaggiosa per un itinerario completo. 5.5 Conseguenze sui modelli proposti Considerando il fatto che con la programmazione dinamica non vengono considerati tutti i possibili cammini in un grafo, ma solo il migliore di essi, per le caratteristiche dei modelli di pricing delle tratte aeree citati nel presente capitolo e di come il prezzo di un certo numero di tratte dipenda dalle fare selezionate per ciascuna di esse, è immediato notare come l'ottimalità di una soluzione possa essere garantita solo per le ricerche di itinerari più brevi, ma non più economici. Per quanto riguarda la minimizzazione del costo complessivo di un itinerario, invece, non è possibile fornire alcuna garanzia di ottimalità; è possibile tuttavia intervenire a posteriori, dopo che la ricerca di una prima soluzione è avvenuta con tecniche di programmazione dinamica, per selezionare le fare da utilizzarsi per ciascun trasferimento aereo; questa è ottenibile attraverso una ricerca esaustiva della migliore soluzione tra quelle ammesse per le combinazioni delle varie fare coinvolte nell'itinerario. Benché ciò non garantisca il risultato ottimo, sicuramente la soluzione fornita sarà comunque migliore di quelle fornite dai modelli presentati nei precedenti capitoli e di conseguenza, decisamente superiore a quella ottenuta con gli strumenti attualmente disponibili on-line. 102

113 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Conclusioni Al di là delle problematiche doverosamente presentate nel quinto capitolo del presente elaborato, ci sono tuttavia una serie di debite considerazioni da fare, a supporto del lavoro eseguito, che altrimenti potrebbe sembrare perdere buona parte del suo significato; in primo luogo c'è da considerare il fatto che la diffusione sempre più accentuata delle piattaforme online B2C sta tendendo a rendere sempre più obsolete e meno utili le complesse combinazioni consentite per l'acquisto di molteplici fare nello stesso biglietto. Le compagnie low-cost innanzitutto, ma anche alcune compagnie di linea, seguendo l'esempio dato inizialmente da Air Canada e Southwest hanno anche già iniziato a semplificare notevolmente i loro modelli di pricing, continuando sicuramente nell'impiego di Dynamic Pricing e 14 Days Advance Booking, ma abbandonando le complesse Saturday Night Rule e combinazioni delle Fare in Priceable Units, a favore di tariffe associate a cosiddette One-Way Fare. Tale fondamentale semplificazione di fatto svincola tratte diverse all'interno dello stesso viaggio e, tra le altre conseguenze, permette peraltro di utilizzare i modelli presentati nei capitoli precedenti con garanzia di trovare la soluzione ottima. In secondo luogo, ed in ogni caso, i risultati ottenuti dagli esperimenti di cui si sono presentati i risultati nei precedenti capitoli, sebbene potenzialmente non ottimi, hanno dimostrato come i prototipi realizzati possano comunque fornire un significativo aiuto agli utenti che decidessero di pianificare in modo autonomo il proprio viaggio (senza peraltro dovere quindi corrispondere commissioni ad agenzie di viaggio). In conclusione, sarà probabilmente necessario attendere una semplificazione generalizzata dei modelli di pricing delle tratte aeree e quindi qualche anno prima che i modelli presentati possano dare garanzia di ottimalità della soluzione fornita; ad ogni modo, già ad oggi, questi modelli sembrano assolutamente promettenti nel permettere un notevole risparmio economico e anche in termini di tempo all'utente finale. 103

114

115 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Appendice A SCENARIO SU CUI SONO STATI EFFETTUATI I TEST In questo appendice viene descritto lo scenario utilizzato nei capitoli precedenti per i test. Vengono descritti gli elementi presi in considerazione, forniti gli elementi necessari a capire il perché di queste scelte e descritti i principi alla base degli algoritmi con cui sono stati generati i dati sintetici su cui si sono svolti i test. A1.1 Il contesto geografico Per eseguire i test di cui sono stati riportati i risultati nei paragrafi precedenti è stato preso in considerazione un insieme di 15 città Italiane, direttamente o indirettamente collegate tra loro attraverso rete stradale, ferroviaria o per mezzo di tratte aeree o navali. La selezione dei luoghi è avvenuta a seguito della consultazione di diversi siti web stranieri, i quali offrivano visite guidate alle medesime e dai quali si è quindi potuto desumere e rafforzare eventuali convinzioni su quali fossero le mete effettivamente predilette dagli stranieri nel nostro paese. A queste sono state aggiunte alcune mete di interesse principalmente commerciale ed economico (Milano) e mete remote rispetto all'area comunemente più visitata dai turisti stranieri (Olbia, Palermo, Trieste) con l'intento di permettere l'effettuazione di test anche in scenari geograficamente più ampi. 105

116 APPENDICE A SCENARIO SU CUI SONO STATI EFFETTUATI I TEST Fig. A1-1 Contesto Geografico di Riferimento Fonte: Elaborazione propria I dati relativi alle distanze stradali tra le tratte, così come il tempo impiegato per i trasferimenti (e di conseguenza la velocità media di percorrenza) sono stati ricavati tramite google maps. 106

117 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB A1.2 Periodo Temporale Il periodo considerato è dal 03/01/2008 al 30/06/2008. All'interno di tale periodo vi sono per ciascuna città delle date che segnano l'inizio dell'alta stagione e che comportano rincari sui prezzi delle strutture ricettive. 107

118 APPENDICE A SCENARIO SU CUI SONO STATI EFFETTUATI I TEST A1.3 Collegamenti tra le mete Le mete citate al paragrafo precedente sono state collegate tra loro in maniera piuttosto fedele a come esse lo sono nella realtà; anche nei dati sintetici utilizzati nei test, infatti, reti stradali e ferroviarie mettono in comunicazione le città effettivamente collegate tra loro, così come le tratte aeree e navali riproducono gli itinerari tipicamente percorsi da voli di linea, voli lowcost o servizi di trasporto marittimo. A questo scopo sono stati presi in considerazione gli itinerari proposti da note compagnie navali, così come gli orari ufficiali degli aeroporti contemplati nell'esempio e da questi si è ricavata la frequenza con cui ciascuna città è messa in contatto con ciascun'altra; orari e tariffe precisi non sono stati considerati per duplice motivo: in primo luogo poiché la riproduzione di uno specifico contesto esulava dallo scopo del presente lavoro e poteva anzi risultare limitativa, a causa di alcune limitazioni dello scenario italiano, rispetto a quello globale (maggiori dettagli in seguito); in secondo luogo il fenomeno del dynamic pricing soprattutto per le tratte aeree e comunque la variabilità degli orari ufficiali avrebbe reso il lavoro subito obsoleto. Si è quindi deciso di considerare la frequenza con cui vengono offerti voli o servizi di trasporto navale, trascurando invece orari e costi specifici precisi. Maggiori dettagli su come questi dati siano stati generati vengono riportati nel paragrafo A1.4 che segue. A1.4 Dati Contemplati La memorizzazione di luoghi, collegamenti tra questi, distanze, aziende fornitrici di servizi per il trasporto di persone, nonché ogni altro dato necessario a formulare con una certa completezza lo scenario appena descritto è avvenuta per mezzo di un database relazionale, la cui struttura viene riportata nella pagina seguente. In ordine di chiamata in causa di chiavi esterne troviamo le tabelle di cui ne viene in seguito riportato un dump di struttura, corredato da breve descrizione. Tipologie di Trasporto CREATE TABLE tipologie_trasporto ( id TINYINT UNSIGNED NOT NULL AUTO_INCREMENT, nome VARCHAR(24) NULL, PRIMARY KEY(id) ) TYPE=InnoDB; Semplice tabella in cui sono contenute le diverse tipologie di trasporto disponibili. Id ne è chiave primaria, numerica, per maggiore efficienza nelle ricerche, mentre nome assume l'ovvio significato; la tabella è popolata dai seguenti record: 1) noleggio auto, 2 trasporto navale, 3 trasporto su rotaia, 4 trasferimento aereo. 108

119 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Fares CREATE TABLE fares ( id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, costo FLOAT NOT NULL, classe TINYINT UNSIGNED NOT NULL DEFAULT 2, fda TINYINT UNSIGNED NOT NULL DEFAULT 0, sat TINYINT UNSIGNED NOT NULL DEFAULT 0, aly TINYINT UNSIGNED NOT NULL DEFAULT 0, datat DATE NOT NULL, da TINYINT UNSIGNED NOT NULL, a TINYINT UNSIGNED NOT NULL, PRIMARY KEY(id) ) TYPE=InnoDB; Come riportato nel capitolo 4, una Fare rappresenta il costo di una tratta aerea tra un Market, ovvero tra due città. Come è ovvio attendersi, in questa tabella troviamo: un id numerico impiegato per velocizzare le operazioni di ricerca, un prezzo (campo costo) associato al record, la data cui tale prezzo si riferisce, i campi da e a che individuano il market e una serie di altri campi che individuano le restrizioni che tipicamente regolano una Fare (classe con ovvio significato, fda = fourteen days advance, sat = saturday night rule, aly = fare combinabile con altre di compagnie differenti ma nella stessa alleanza). Città CREATE TABLE citta ( id TINYINT UNSIGNED NOT NULL AUTO_INCREMENT, nome VARCHAR(20) NOT NULL, alta_stagione DATE NOT NULL, hotels TINYINT UNSIGNED NOT NULL, n BOOL NOT NULL DEFAULT 1, PRIMARY KEY(id) ) TYPE=InnoDB; Altra semplice tabella in cui sono riportati l'identificativo oltre che il nome di ciascuna città considerata, oltre che una data di entrata in vigore dell'alta stagione (utilizzata per la determinazione delle tariffe relativi agli alloggi della città stessa), il numero di strutture ricettive effettivamente presenti nella citta (campo hotels) e un campo in cui viene indicata la presenza o meno di una sede di un'azienda che si occupa di autonoleggio. Sebbene considerando le tabelle che seguono i campi appena citati possano risultare ridondanti (e così effettivamente è), è comunque bene tenere a mente che i risultati seguenti sono stati generati proprio da questi numeri e sarebbe stato quindi improbabile prescinderne. Gli stessi vengono quindi riportati più che altro per rendere più comprensibili le considerazioni del prossimo paragrafo e non perché effettivamente vi sia la necessità di mantenere gli stessi. 109

120 APPENDICE A SCENARIO SU CUI SONO STATI EFFETTUATI I TEST Fig. A1-2 Struttura del Database 110

121 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Alleanze Tra Compagnie Aeree CREATE TABLE alleanze ( id TINYINT UNSIGNED NOT NULL AUTO_INCREMENT, nome VARCHAR(45) NULL, PRIMARY KEY(id) ) TYPE=InnoDB; Altra semplice tabella in cui sono riportate le alleanze (nel nostro caso una sola) tra compagnie aeree. I campi della tabella hanno significati ovvi e non vengono quindi ulteriormente descritti. Alberghi CREATE TABLE hotel ( id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT, citta_id TINYINT UNSIGNED NOT NULL, nome VARCHAR(45) NULL, classe TINYINT UNSIGNED NULL, PRIMARY KEY(id), INDEX hotel_fkindex1(citta_id), FOREIGN KEY(citta_id) REFERENCES citta(id) ON DELETE CASCADE ON UPDATE CASCADE ) TYPE=InnoDB; Tabella contenente gli alberghi, in cui i campi hanno tutti significati facilmente desumibili dalla loro nomenclatura. Tariffe Alberghi CREATE TABLE tariffe_hotel ( id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, hotel_id SMALLINT UNSIGNED NOT NULL, numpersone INTEGER UNSIGNED NULL, costo FLOAT NULL, giorno DATE NULL, PRIMARY KEY(id), INDEX tariffe_hotel_fkindex1(hotel_id), FOREIGN KEY(hotel_id) REFERENCES hotel(id) ON DELETE CASCADE ON UPDATE CASCADE ) TYPE=InnoDB; Tabella contenente le tariffe degli alberghi sopra menzionati. Per ogni notte nel 111

122 APPENDICE A SCENARIO SU CUI SONO STATI EFFETTUATI I TEST periodo considerato (01/03, 30/06) viene riportato il prezzo di ciascuna sistemazione disponibile in ciascun hotel; per sistemazione si intende il tipo di camera che, nel nostro contesto si traduce ai fini pratici nel numero massimo di persone effettivamente ospitabili. Aziende Fornitrici di Servizi di Trasporto Persone CREATE TABLE aziende_trasporti ( id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT, tipologia TINYINT UNSIGNED NOT NULL, nome VARCHAR(45) NULL, PRIMARY KEY(id), INDEX aziende_trasporti_fkindex1(tipologia), FOREIGN KEY(tipologia) REFERENCES tipologie_trasporto(id) ON DELETE CASCADE ON UPDATE CASCADE ) TYPE=InnoDB; Tabella contenente le aziende fornitrici di servizi di trasporto. Tale tabella è utilizzata in sede di presentazione dei dati per fornire risultati pertinenti con la realtà e quindi apprezzabili anche da un punto di vista pratico oltre che eventualmente teorico. Mezzi di Trasporto CREATE TABLE mezzi_trasporto ( id TINYINT UNSIGNED NOT NULL AUTO_INCREMENT, tipologie_trasporto_id TINYINT UNSIGNED NOT NULL, nome VARCHAR(32) NULL, supplemento INTEGER UNSIGNED NULL, consumo FLOAT NULL, PRIMARY KEY(id), INDEX mezzi_trasporto_fkindex1(tipologie_trasporto_id), FOREIGN KEY(tipologie_trasporto_id) REFERENCES tipologie_trasporto(id) ON DELETE CASCADE ON UPDATE CASCADE ) TYPE=InnoDB; Tabella contenente le tipologie di veicoli (quindi autovetture, aeromobili, navi) utilizzate negli esempi, corredate da indicazioni relative al mezzo ove utile (es. consumo per le auto a noleggio per determinare la spesa complessiva reale di un noleggio auto, anche dal punto di vista del carburante, velocità di crociera degli aeromobili per determinare il tempo di spostamento approssimativo di ciascuna tratta aerea). 112

123 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Sedi Compagnie di Noleggio Auto CREATE TABLE rental_locations ( id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT, id_azienda SMALLINT UNSIGNED NOT NULL, id_citta TINYINT UNSIGNED NOT NULL, costo_dropoff INTEGER UNSIGNED NULL, PRIMARY KEY(id), INDEX rental_locations_fkindex1(id_citta), INDEX rental_locations_fkindex2(id_azienda), FOREIGN KEY(id_citta) REFERENCES citta(id) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY(id_azienda) REFERENCES aziende_trasporti(id) ON DELETE CASCADE ON UPDATE CASCADE ) TYPE=InnoDB; Tabella che semplicemente serve ad indicare quelle città che dispongono di sedi di noleggio auto. Le chiavi esterne hanno gli ovvi significati, mentre il campo costo_dropoff indica il costo aggiuntivo cui è soggetto un cliente che riportasse presso una determinata locazione un'auto presa a noleggio presso una città diversa. Distanze temporali (spostamenti su strada) tra città CREATE TABLE distanze_tempo ( citta_da TINYINT UNSIGNED NOT NULL AUTO_INCREMENT, citta_a TINYINT UNSIGNED NOT NULL, distanza INTEGER UNSIGNED NULL, PRIMARY KEY(citta_da, citta_a), INDEX distanze_tempo_fkindex1(citta_da), INDEX distanze_tempo_fkindex2(citta_a), FOREIGN KEY(citta_da) REFERENCES citta(id) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY(citta_a) REFERENCES citta(id) ON DELETE CASCADE ON UPDATE CASCADE ) TYPE=InnoDB; Tabella che riporta le distanze temporali di percorrenza tra ciascuna coppia di città raggiungibile esclusivamente su strada. Fonte Google Maps. 113

124 APPENDICE A SCENARIO SU CUI SONO STATI EFFETTUATI I TEST Distanze Chilometriche (strada) tra città CREATE TABLE distanze_chilometriche ( citta_da TINYINT UNSIGNED NOT NULL, citta_a TINYINT UNSIGNED NOT NULL, distanza INTEGER UNSIGNED NULL, PRIMARY KEY(citta_da, citta_a), INDEX citta_has_citta_fkindex1(citta_da), INDEX citta_has_citta_fkindex2(citta_a), FOREIGN KEY(citta_da) REFERENCES citta(id) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY(citta_a) REFERENCES citta(id) ON DELETE CASCADE ON UPDATE CASCADE ) TYPE=InnoDB; Tabella che riporta le distanze chilometriche di percorrenza tra ciascuna coppia di città raggiungibile esclusivamente su strada. Fonte Google Maps. Distanze Chilometriche in linea d'aria tra città CREATE TABLE distanze_linearia ( citta_da TINYINT UNSIGNED NOT NULL, citta_a TINYINT UNSIGNED NOT NULL, distanza INTEGER UNSIGNED NULL, PRIMARY KEY(citta_da, citta_a), INDEX citta_has_citta_fkindex1(citta_da), INDEX citta_has_citta_fkindex2(citta_a), FOREIGN KEY(citta_da) REFERENCES citta(id) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY(citta_a) REFERENCES citta(id) ON DELETE CASCADE ON UPDATE CASCADE ) TYPE=InnoDB; Tabella che riporta le distanze in linea d'aria tra ciascuna coppia di città contemplate nell'esempio. 114

125 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Flotta veicoli a disposizione di ciascuna azienda di trasporti persone CREATE TABLE possiede ( id_mezzo TINYINT UNSIGNED NOT NULL, id_azienda SMALLINT UNSIGNED NOT NULL, PRIMARY KEY(id_mezzo, id_azienda), INDEX aziende_trasporti_has_mezzi_trasporto_fkindex1(id_azienda), INDEX aziende_trasporti_has_mezzi_trasporto_fkindex2(id_mezzo), FOREIGN KEY(id_azienda) REFERENCES aziende_trasporti(id) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY(id_mezzo) REFERENCES mezzi_trasporto(id) ON DELETE CASCADE ON UPDATE CASCADE ) TYPE=InnoDB; Tabella che mette in relazione ciascuna azienda di trasporti persone con i veicoli da questa posseduti. Tali dati saranno impiegati nell'assegnamento di un certo velivolo per ciascun volo, piuttosto che nella selezione e nella determinazione del prezzo / consumo di auto a noleggio. Membri alleanza tra compagnie aeree CREATE TABLE membri_alleanza ( alleanze_id TINYINT UNSIGNED NOT NULL, aziende_trasporti_id SMALLINT UNSIGNED NOT NULL, PRIMARY KEY(alleanze_id, aziende_trasporti_id), INDEX alliances_has_aziende_trasporti_fkindex1(alleanze_id), INDEX alliances_has_aziende_trasporti_fkindex2(aziende_trasporti_id), FOREIGN KEY(alleanze_id) REFERENCES alleanze(id) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY(aziende_trasporti_id) REFERENCES aziende_trasporti(id) ON DELETE CASCADE ON UPDATE CASCADE ) TYPE=InnoDB; Tabella in cui vi è un'associazione tra ciascuna alleanza tra compagnie aeree e azienda di trasporto che ne fa parte. 115

126 APPENDICE A SCENARIO SU CUI SONO STATI EFFETTUATI I TEST Voli CREATE TABLE voli ( id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, id_azienda SMALLINT UNSIGNED NOT NULL, id_mezzo TINYINT UNSIGNED NOT NULL, citta_da TINYINT UNSIGNED NOT NULL, citta_a TINYINT UNSIGNED NOT NULL, orapartenza TIME NULL, durata INTEGER UNSIGNED NULL, g1 TINYINT UNSIGNED NULL, g2 TINYINT UNSIGNED NULL, g3 TINYINT UNSIGNED NULL, g4 TINYINT UNSIGNED NULL, g5 TINYINT UNSIGNED NULL, g6 TINYINT UNSIGNED NULL, g7 TINYINT UNSIGNED NULL, codice VARCHAR(6) NULL, PRIMARY KEY(id), INDEX voli_fkindex2(citta_da), INDEX voli_fkindex3(citta_a), INDEX voli_fkindex3(id_mezzo, id_azienda), FOREIGN KEY(citta_da) REFERENCES citta(id) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY(citta_a) REFERENCES citta(id) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY(id_mezzo, id_azienda) REFERENCES possiede(id_mezzo, id_azienda) ON DELETE RESTRICT ON UPDATE RESTRICT ) TYPE=InnoDB; Questa importante tabella contiene informazioni relative a tutti i voli presenti nello scenario. I campi id, id_azienda, id_mezzo, citta_da, citta_a, orapartenza e durata hanno gli ovvi significati, mentre i campi denominati gn con n=1...7 indicano i diversi giorni della settimana in cui il volo viene operato (valore 1) oppure no (valore 0). Il campo codice, infine, viene utilizzato durante la visualizzazione per simulare il codice di volo utilizzato nella realtà, in sostituzione del meno verosimile codice id. 116

127 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Trasporti su rotaia e tratte navali CREATE TABLE trasporti_terra_mare ( id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, mezzi_trasporto_id TINYINT UNSIGNED NOT NULL, id_azienda SMALLINT UNSIGNED NOT NULL, citta_da TINYINT UNSIGNED NOT NULL, citta_a TINYINT UNSIGNED NOT NULL, datapartenza DATETIME NULL, durata INTEGER UNSIGNED NULL, PRIMARY KEY(id), INDEX trasporti_terra_mare_fkindex1(citta_da), INDEX trasporti_terra_mare_fkindex2(citta_a), INDEX trasporti_terra_mare_fkindex3(id_azienda), INDEX trasporti_terra_mare_fkindex4(mezzi_trasporto_id), FOREIGN KEY(citta_da) REFERENCES citta(id) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY(citta_a) REFERENCES citta(id) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY(id_azienda) REFERENCES aziende_trasporti(id) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY(mezzi_trasporto_id) REFERENCES mezzi_trasporto(id) ON DELETE CASCADE ON UPDATE CASCADE ) TYPE=InnoDB; Tabella contenente le tratte navali o ferroviarie che mettono in comunicazione tra di loro due città. I campi hanno significati ovvi, quindi non saranno ulteriormente descritti; interessante invece notare l'utilizzo degli indici, sia quali elemento in grado di mantenere l'integrità referenziale, sia per velocizzare le ricerche. Costi per il trasporto su rotaia o tratta navale CREATE TABLE costi_trasporto ( id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, id_tratta INTEGER UNSIGNED NOT NULL, classe TINYINT UNSIGNED NULL, costo FLOAT NULL, PRIMARY KEY(id), INDEX costi_trasporto_fkindex1(id_tratta), FOREIGN KEY(id_tratta) 117

128 APPENDICE A SCENARIO SU CUI SONO STATI EFFETTUATI I TEST REFERENCES trasporti_terra_mare(id) ON DELETE CASCADE ON UPDATE CASCADE ) TYPE=InnoDB; Tabella complementare alla precedente, che contiene le informazioni relative al costo di ciascuna tratta ferroviaria, assieme ad un'indicazione sulla classe di servizio cui l'importo stesso si riferisce. In questo caso il campo id (potenzialmente superfluo) viene utilizzato quale chiave primaria e quindi quale indice per questione di prestazioni. Relazione tra voli e fare CREATE TABLE voli_has_fares ( voli_id INTEGER UNSIGNED NOT NULL, fares_id INTEGER UNSIGNED NOT NULL, ordine TINYINT UNSIGNED NULL, PRIMARY KEY(voli_id, fares_id), INDEX voli_has_fares_fkindex1(voli_id), INDEX voli_has_fares_fkindex2(fares_id), FOREIGN KEY(voli_id) REFERENCES voli(id) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY(fares_id) REFERENCES fares(id) ON DELETE CASCADE ON UPDATE CASCADE ) TYPE=InnoDB; Tabella fondamentale (di gran lunga la più popolata) per il sistema che associa in una relazione MxN voli e relative fare tra loro. Un volo dev'essere contemplato almeno da una fare, altrimenti non vi sarebbe modo di determinare il costo del biglietto per i passeggeri che vi salirebbero. Allo stesso modo, per ogni fare dev'esservi almeno un volo associato, altrimenti si rischierebbe che un'utente acquisti il biglietto per una tratta non coperta da nessun volo. Si noti che l'associazione è MxN poiché per ciascun volo vi possono essere tariffe differenti tra loro, a seconda delle restrizioni imposte all'acquirente; allo stesso modo, per ciascuna fare vi possono essere più voli associati, in quanto ciò che è in realtà importante è il cosiddetto market (luogo di partenza e luogo di destinazione) piuttosto che il percorso intermedio e quindi il numero dei voli effettivamente compiuti. 118

129 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Tariffe per il noleggio di autoveicoli CREATE TABLE tariffe_noleggio_auto ( id INTEGER UNSIGNED NOT NULL AUTO_INCREMENT, classe TINYINT UNSIGNED NOT NULL, id_location SMALLINT UNSIGNED NOT NULL, costo TINYINT UNSIGNED NULL, durata_min SMALLINT UNSIGNED NULL, PRIMARY KEY(id), INDEX tariffe_noleggio_auto_fkindex1(id_location), INDEX tariffe_noleggio_auto_fkindex2(classe), FOREIGN KEY(id_location) REFERENCES rental_locations(id) ON DELETE CASCADE ON UPDATE CASCADE, FOREIGN KEY(classe) REFERENCES mezzi_trasporto(id) ON DELETE CASCADE ON UPDATE CASCADE ) TYPE=InnoDB; Tabella che permette il calcolo delle tariffe per il noleggio di un autoveicolo. Id rappresenta il solito indice numerico, comodo nelle ricerche, classe e costo hanno gli ovvi significati, mentre i campi id_location e durata_min rappresentano nell'ordine la chiave esterna verso la tabella rental_locations (ovvero sedi di compagnie di noleggio auto) e la durata minima in giorni per cui è possibile applicare tale tariffa. Questo campo permette di simulare in maniera abbastanza verosimile il comportamento delle compagnie di noleggio che tipicamente su noleggi di sei giorni o una settimana regalano il sesto o settimo giorno. A1.5 Generazione dei dati d'esempio Dopo aver introdotto le strutture dati (database) contenenti i dati dello scenario, di seguito vengono brevemente descritte le modalità con cui sono stati generati tali esempi, corredate ove ritenuto opportuno da considerazioni sulle assunzioni e semplificazioni adottate in sede di progettazione e realizzazione. L'approccio utilizzato sarà discorsivo, con riferimento a qualche frammento di codice sorgente ove ritenuto opportuno. Generazione di hotel e relative tariffe Attraverso la consultazione di diversi siti dedicati alla prenotazione di hotel e agenzie di viaggio online sono stati innanzitutto reperiti nomi comuni per hotel e strutture ricettive e, per ognuno di essi è stato attribuito un range di categoria alla quale il nome stesso era tipicamente associato. Sono stati considerati gli hotel nella fascia dalle 2 alle 5 stelle nelle 15 città italiane dello scenario e i nomi ricorrenti con maggiore frequenza sono stati inizialmente riportati in un elenco temporaneo. Considerata la scarsa 119

130 APPENDICE A SCENARIO SU CUI SONO STATI EFFETTUATI I TEST importanza di questo tipo di dettagli ai fini degli esperimenti, non vengono presentati in questa sede i risultati precisi di tale analisi, svolta peraltro con l'unico intento di poter fornire a chi volesse utilizzare il prototipo prodotto risultati verosimili, anche nel contesto di un'eventuale simulazione di utilizzo. Considerati i dati ottenuti nella seppure superficiale analisi appena citata, si è innanzitutto desiderato generare strutture ricettive di classi diverse in proporzioni verosimili; a tale proposito si sono utilizzati il numero di alberghi n di ciascuna citta (tabella città) ed un valore percentuale che indicava la frequenza di ciascuna classe. Si è quindi generato un numero n di nomi per ciascuna città e per ciascuno di essi, veniva creato un hotel, la cui classe veniva selezionata, tra quelle cui il nome scelto era comunemente associato, in modo tale da rendere più possibile vicina la distribuzione con quella attesa. Se quindi, come è realmente avvenuto, si suppone che la distribuzione di classe per gli hotel sia la seguente: Numero di Stelle Percentuale 2 30% 3 40% 4 20% 5 10% e dopo una serie di alberghi già creati viene selezionato un nome associato tipicamente ad alberghi di 4 o 5 stelle, viene verificato tra quelli creati nella località considerata quale delle due classi si distacca maggiormente dalla probabilità sopra riportata e l'albergo appena creato viene quindi associato a tale classe. Terminata la creazione degli hotel vengono sono state quindi generate le tariffe per gli stessi. La generazione è avvenuta per mezzo di una serie di cicli innestati e nella fattispecie, il seguente frammento di pseudocodice rappresenta la strada intrapresa: for (x hotels) for (i mesi) for (j giorni(i)) for (k tipi_camera) generaprezzo(); endfor endfor endfor endfor La procedura generaprezzo() generava un valore pseudo-casuale tenendo in considerazione i seguenti fattori: la categoria dell'albergo, il periodo (alta/bassa stagione), eventuali sconti week-end per gli hotel comunemente destinati a clientela d'affari (un sottoinsieme degli hotel a 4 stelle casualmente predeterminato), eventuali 120

131 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB rincari per il week-end per un sottoinsieme di hotel considerabili come comunemente destinati a turisti e quindi in grado di aumentare le tariffe quando è prevista maggiore affluenza. Ciò avviene per ogni tipo di camera (un hotel può fornire almeno una tra singola, doppia, camera da 3 o 4 persone) e quindi per giorno di ogni mese considerato. Generazione di dati relativi a noleggi auto La prima azione compiuta per la generazione di dati relativi a noleggio auto è stata le ricerca online delle aziende che fornivano questo tipo di servizio e l'osservazione della loro distribuzione sul territorio,. delle gamma di veicoli di cui disponevano, nonché delle politiche di pricing attuate. In maniera simile a quanto è avvenuto per gli hotel si è provveduto quindi a generare le sedi di tali compagnie (tabella rental_locations) nelle città in cui esse erano effettivamente presenti. Per ciascuna di esse si è quindi determinato in maniera pseudocasuale un certo costo di drop-off, ovvero il costo dovuto dall'utente qualora la macchina fosse stata presa a noleggio presso un'altra agenzia della stessa compagnia. A questo punto le diverse sedi sono state scandite e per ognuna sono stati creati due tipi di veicoli, cui è stato associato un costo, determinato in maniera pseudocasuale, in un intervallo di valori tipicamente utilizzato nella realtà e un numero minimo di giorni cui tale costo era riferito. E' così che sono state quindi generate tariffe valide per noleggi da 1-n giorni oppure per un numero maggiore di tale n, fattispecie nella quale l'utente incorreva in uno sconto sull'importo totale dovuto. Generazione di tariffe relative a spostamenti su rotaia La generazione dei treni è stata ottenuta a partire dalla tabella con i tempi di percorrenza attraverso i tratti stradali tra le località. Senza dubbio i dati relativi a questo mezzo di trasporto sono quelli simulati con meno accuratezza e che quindi maggiormente si discostano dalla realtà. D'altro canto se da una parte è vero che sarebbe stata un'impresa molto complessa simulare con accurata fedeltà tale dettaglio, c'è anche da dire che l'effettiva utilità della stessa operazione potrebbe essere stata fortemente vanificata da fenomeni trasversali (coincidenze, diverse tratte, etc) che comunque rendono il trasporto ferroviario tra luoghi distanti tra loro soggetto a notevoli margini di variabilità. Al contrario, per ciò che concerne le tratte di breve distanza, in questi casi è difficile tratti stradali e ferroviari possano effettuare percorsi drasticamente diversi e quindi è verosimile anche i dati sintetici generati siano fedeli con la realtà. 121

132 APPENDICE A SCENARIO SU CUI SONO STATI EFFETTUATI I TEST Sono state generate innanzitutto diverse tipologie di treno, ognuna con un indice di aumento in termini di prestazioni (velocità) e prezzo. Sono poi state generate per ciascuna tratta esistente (nella rete ferroviaria italiana tutte le città considerate, tranne Olbia sono direttamente raggiungibili tra loro) un certo numero di treni, in numero inversamente proporzionale alla distanza tra i punti di partenza e destinazione (questo perché tipicamente per le tratte brevi è più frequente trovare treni regionali o semplicemente perché più treni percorrono una tratta condivisa tra più linee, che hanno quindi punti di partenza remoti diversi tra loro). Nel caso di tratte distanti tra loro, proprio per considerare la possibilità assai frequente di dover effettuare dei cambi di treno sono stati introdotti dei tempi di attesa variabili in un intervallo variabile tra 15 minuti e 10 ore, comunque proporzionale alla distanza tratta (l'attesa massima di una coincidenza per una tratta di 500km, ad esempio non può superare le 4 ore). Il costo del biglietto è stato determinato quindi in base alla distanza tra il luogo di partenza e destinazione, del tipo di treno (maggiorazione sopra citata) e alla classe (per ogni treno sono disponibili nel nostro scenario vagoni di prima e seconda classe) e la stessa cosa, tenendo ovviamente in considerazione i soli primi due parametri citati è avvenuta per il calcolo del tempo di percorrenza della tratta. Per aumentare il realismo e quindi la variabilità dell'offerta in base anche ai diversi giorni settimanali, per ciascun treno si è determinata una tipologia, in maniera analoga a quanto avviene nella realtà, distinguendo treni attivi sempre, solo nei giorni festivi o solo in quelli feriali. Generazione di tariffe relative a spostamenti navali Benché la struttura a livello tabellare in cui sono memorizzati i dati relativi alle tratte navali sia la stessa utilizzata anche per le tratte ferroviarie, decisamente più semplice è stata la generazione dei dati relativi a questo tipo di servizio, anche perché molto più semplice era lo scenario da riprodurre. In prima istanza si sono individuate le tratte 122

133 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB marine su cui sono presenti servizi di trasporto e le compagnie fornitrici di tali servizi. In seconda istanza si sono anche in questo caso analizzati il costo medio di servizio, i tempi di percorrenza e i giorni in cui il servizio veniva effettuato, con eventuali variazioni nei periodi di picco. Si è quindi proceduto con l'inserimento di ciascuna tratta, corredata dalle informazioni relative al costo del servizio, della compagnia che lo forniva e del tempo di percorrenza della tratta. Generazione di voli A causa delle complessità dei modelli di pricing del settore, ma anche dell'importanza dello stesso e della conseguente necessità di trattare questo aspetto in maniera quanto più possibile verosimile, la generazione di voli e fare è stata senza dubbio l'attività di generazione dati più ostica. In prima istanza si sono considerati tutti gli aeroporti delle 15 località contemplate (anzi 12, dato che Assisi, Mantova e Siena non dispongono di aeroporti propri) e si sono quindi annotati i voli nazionali tra i medesimi aeroporti, considerando le compagnie che offrivano il servizio, il numero di voli quotidiani offerti e la frequenza settimanale di ciascuno di essi. Si sono quindi individuati i voli operati esclusivamente nei week-end, nei giorni feriali o sempre disponibili e si sono quindi creati degli schemi, con apposite variabili binarie g1 g7 impostate a 0 o 1 a seconda che rispettivamente il volo venisse proposto o meno durante un certo giorno settimanale (con la convenzione che al lunedì era associato indice 1, alla domenica indice 7). A questo punto i voli relativi alla stessa tratta (ma potenzialmente a compagnie diverse) venivano distribuiti all'interno dell'arco di una giornata e per ciascuno ne veniva determinata la durezza del viaggio, tenendo in considerazione il velivolo impiegato (e quindi la velocità di crociera media, con dati reperiti da.. e...), la distanza chilometrica in linea d'aria ed il tempo necessario per il decollo e l'atterraggio. Coerentemente con la realtà, per ogni volo è stato anche generato un codice identificativo, basato sul codice IATA (fittizio) associato a ciascuna compagnia e al numero progressivo del volo creato. 123

134 124 APPENDICE A SCENARIO SU CUI SONO STATI EFFETTUATI I TEST

135 ALGORITMI PER LA PIANIFICAZIONE DI ITINERARI SU WEB Generazione di fare per compagnie aeree low-cost Terminata la generazione dei voli, l'attenzione è stata riposta nella generazione delle fare, suddividendo in particolare quelle delle compagnie di linea da quelle low cost. Queste ultime infatti utilizzano modelli di pricing decisamente semplificati rispetto a quelli introdotti in precedenza e quindi permettono alcuni approcci di generazione, anche computazionalmente, convenienti. Ciascuna fare è infatti associata ad un solo volo e a ciascun volo è associata un'unica fare (almeno nel nostro contesto). Con una scansione lineare dei voli è quindi possibile anche creare una fare, iterando opportunamente sul numero dei giorni di ciascun mese nel periodo considerato e generando in maniera pseudocasuale i costi del volo (anche in questo caso mantenendosi entro certi margini ricavati analizzando i siti delle compagnie aeree considerate). Il parametro più influente in questo caso è senza dubbio l'avvicinarsi della data di partenza ed è così che la generazione pseudocasuale è stata basata su valori perturbati generati a partire dalla funzione di ackermann con primo parametro 2 e secondo variabile in maniera inversamente proporzionale con la distanza tra la data in cui i dati sono stati generati e la data del volo. E' stata fatta inoltre una distinzione tra compagnie realmente low-cost e compagnie per le quali il termine low-cost indica pressoché esclusivamente l'adozione di modelli di pricing semplificati. Tale distinzione è stata tenuta in considerazione ed anzi, è stata fondamentale nella determinazione del prezzo delle varie fare. Generazione di fare per compagnie aeree di linea Decisamente più complessa è stata la generazione delle fare per i voli di linea. Elemento considerato come base, sia per la determinazione della durata del trasferimento, sia per la determinazione del costo del biglietto (seppure con opportune doverose osservazioni, riportate tra poco) è stata la distanza chilometrica in linea d'aria tra le diverse località in cui è effettivamente presente un aeroporto. 125