Un'applicazione web di supporto alla risoluzione di problemi di Arc Routing

216 Pages·2014·6.2 MB·Italian

UNIVERSITÀ DEGLI STUDI DI BRESCIA
DIPARTIMENTO DI INGEGNERIA DELL’INFORMAZIONE
CORSO DI LAUREA MAGISTRALE IN INGEGNERIA INFORMATICA
Un’applicazione web di supporto
alla risoluzione di problemi
di Arc Routing
Laureandi:
Emanuele Barbeno Matricola 86274
Nicola Bombardieri Matricola 86888
Relatore:
Chiar.ma Prof.ssa Renata Mansini
Correlatore:
Dott.ssa Daniela Fogli
ANNO ACCADEMICO 2012/2013
Indice
Introduzione IV
1 Stato dell’arte 1
1.1 Introduzione ai problemi di arc routing . . . . . . . . . . . . . 2
1.2 Chinese Postman Problem (CPP) . . . . . . . . . . . . . . . . 4
1.3 Rural Postman Problem (RPP) . . . . . . . . . . . . . . . . . 4
1.4 Capacitated Arc Routing Problem (CARP) . . . . . . . . . . . 5
1.5 Il modello utilizzato: variante del DCARP . . . . . . . . . . . 5
2 Il problema di ottimizzazione: DCARP 8
2.1 Descrizione del problema . . . . . . . . . . . . . . . . . . . . . 8
2.2 Modellizzazione matematica . . . . . . . . . . . . . . . . . . . 10
2.3 L’algoritmo implementato . . . . . . . . . . . . . . . . . . . . 12
2.3.1 La strategia generale . . . . . . . . . . . . . . . . . . . 13
2.3.2 Inizializzazione delle strutture dati . . . . . . . . . . . 15
2.3.3 Il generatore di soluzioni iniziali . . . . . . . . . . . . . 17
2.3.4 La fase di ricerca locale . . . . . . . . . . . . . . . . . . 19
2.3.5 Il valutatore/ricostruttore della soluzione completa . . 22
2.3.6 Parametri di configurazione . . . . . . . . . . . . . . . 25
2.3.7 Pseudocodice dell’algoritmo completo . . . . . . . . . . 28
2.4 Risultati ottenuti e conclusioni . . . . . . . . . . . . . . . . . . 31
2.4.1 GDB . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.2 KSHS . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.3 EGLESE . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.4 VAL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.4.5 Risultati e conclusioni . . . . . . . . . . . . . . . . . . 33
3 Analisi preliminare e progettazione 36
3.1 Definizione dei requisiti di progetto . . . . . . . . . . . . . . . 36
3.1.1 Specifica informale in linguaggio naturale . . . . . . . . 37
3.1.2 Specifica semi-formale tramite casi d’uso e UML . . . . 41
I
INDICE II
3.2 Il modello di processo . . . . . . . . . . . . . . . . . . . . . . . 55
3.3 La scelta del Web . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.4 Il database . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.4.1 Il modello E/R . . . . . . . . . . . . . . . . . . . . . . 61
3.4.2 Il modello relazionale . . . . . . . . . . . . . . . . . . . 67
3.5 Progettazione dell’interfaccia utente . . . . . . . . . . . . . . . 67
3.5.1 Schermate derivanti dai casi d’uso . . . . . . . . . . . . 67
3.5.2 Schermate ulteriori di gestione . . . . . . . . . . . . . . 78
3.5.3 Diagramma delle pagine . . . . . . . . . . . . . . . . . 82
3.5.4 Prototipazione in HTML . . . . . . . . . . . . . . . . . 86
4 Implementazione 87
4.1 Hibernate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.1.1 Configurazione . . . . . . . . . . . . . . . . . . . . . . 88
4.2 Modifiche al risolutore del DCARP . . . . . . . . . . . . . . . 92
4.2.1 Adattamento del DCARP al problema . . . . . . . . . 94
4.2.2 Interfacciamento con l’applicazione finale . . . . . . . . 101
4.3 Server JSP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.3.1 Strumenti di supporto . . . . . . . . . . . . . . . . . . 119
4.3.2 Struttura di una pagina JSP . . . . . . . . . . . . . . . 123
4.3.3 Classi create . . . . . . . . . . . . . . . . . . . . . . . . 124
4.4 Integrazione di tutti i componenti . . . . . . . . . . . . . . . . 130
4.4.1 Risolutore come pacchetto Jar . . . . . . . . . . . . . . 133
4.4.2 Pattern MVC . . . . . . . . . . . . . . . . . . . . . . . 135
4.4.3 Apache Tomcat . . . . . . . . . . . . . . . . . . . . . . 139
4.5 L’architettura finale . . . . . . . . . . . . . . . . . . . . . . . . 140
5 Manuale d’uso 142
5.1 Cos’è Super Route Optimizer . . . . . . . . . . . . . . . . . . 142
5.2 Schermata principale . . . . . . . . . . . . . . . . . . . . . . . 144
5.2.1 Gestione Servizi . . . . . . . . . . . . . . . . . . . . . . 145
5.2.2 Gestione Veicoli . . . . . . . . . . . . . . . . . . . . . . 147
5.2.3 Risoluzioni in corso . . . . . . . . . . . . . . . . . . . . 148
5.3 Configurazione iniziale . . . . . . . . . . . . . . . . . . . . . . 149
5.3.1 Configurazione preliminare delle tipologie di servizio
erogabili . . . . . . . . . . . . . . . . . . . . . . . . . . 150
5.3.2 Definizione dei veicoli disponibili . . . . . . . . . . . . 152
5.4 Lavorare con Super Route Optimizer . . . . . . . . . . . . . . 154
5.4.1 Creazione e definizione di un nuovo servizio . . . . . . 154
5.4.2 Visualizzazione e modifica di un servizio salvato . . . . 163
INDICE III
5.4.3 Creazione dei percorsi per l’erogazione di un nuovo
servizio . . . . . . . . . . . . . . . . . . . . . . . . . . 165
5.4.4 Visualizzazione dei percorsi salvati . . . . . . . . . . . 173
5.4.5 Eliminazionediunveicolo, diunservizioodiunpercorso175
5.5 Note Conclusive . . . . . . . . . . . . . . . . . . . . . . . . . . 177
5.5.1 Importanza del tempo di esecuzione nella risoluzione
dei percorsi . . . . . . . . . . . . . . . . . . . . . . . . 177
6 Testing 179
6.1 Raccolta organico porta-a-porta . . . . . . . . . . . . . . . . . 180
6.2 Pulizia stradale . . . . . . . . . . . . . . . . . . . . . . . . . . 189
6.3 Conclusione sui test effettuati . . . . . . . . . . . . . . . . . . 192
7 Conclusioni e sviluppi futuri 194
7.1 Possibili sviluppi futuri . . . . . . . . . . . . . . . . . . . . . . 194
7.1.1 Calcolo intelligente delle stime . . . . . . . . . . . . . . 195
7.1.2 Priorità nell’erogazione del servizio . . . . . . . . . . . 196
7.1.3 Introduzione di più magazzini . . . . . . . . . . . . . . 197
7.1.4 Supporto alla navigazione per i veicoli . . . . . . . . . 198
7.1.5 SAAS (Software As A Service) . . . . . . . . . . . . . . 199
7.2 Conclusioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
A Strumenti utilizzati 203
Bibliografia 207
Introduzione
L’obiettivo di questa tesi è lo sviluppo di un’applicazione web di supporto
alla risoluzione di problemi reali di arc routing.
I potenziali utenti richiedono la risoluzione di un problema che prevede
la fornitura di un servizio sulla rete stradale (si pensi alla raccolta dei rifiu-
ti porta-a-porta, al servizio di pulizia stradale o alla spalatura della neve).
Principali fruitori di questo servizio potrebbero essere le amministrazioni lo-
cali, quindi i comuni. Per questo motivo si è cercato di ottimizzare l’usabilità
dell’applicazione proprio per questo target di utenti.
L’intero lavoro si articola in diverse fasi e il fine ultimo è la creazione di
un’applicazione che sia effettivamente usabile durante ogni fase della risolu-
zione del problema, dalla definizione dello stesso alla fase di generazione e
visualizzazione della soluzione.
Latesiillustralosvolgimentodiognifasedelprogetto, ilqualeèstatogui-
datodaltipicoapprocciotop-downdell’ingegneriadelsoftware, suddividendo
quindi l’intero lavoro in sotto-problemi e procedendo secondo un approccio
a livelli. Questa branca dell’ingegneria non è l’unica sfruttata. Il progetto
si sviluppa in una proporzionata collaborazione di diverse discipline, alcune
delle quali trasversali fra loro. Una porzione consistente è infatti occupata
dalla progettazione ed implementazione del software in grado di risolvere il
problema sottostante (detto appunto risolutore), il quale è di tipo NP-Hard
e richiede quindi la realizzazione di un algoritmo di tipo euristico: questa
parte si pone pertanto nell’ambito della ricerca operativa. Tuttavia la crea-
zione ed implementazione di questo algoritmo è stata solo la parte iniziale
del progetto. Un’altra sezione di rilevante interesse è stata infatti la proget-
tazione dell’interazione con l’utente, ovvero la fase in cui è stato definito il
programma da un punto di vista puramente funzionale. Dal momento che
l’applicazione è stata creata ex-novo, per di più non disponendo di appli-
cazioni simili su cui effettuare delle prove preliminari, anche questa fase ha
presentato delle complessità non trascurabili. Questa parte è stata guidata
da un’altra disciplina ingegneristica chiamata interazione uomo-macchina.
Da un alto livello di astrazione quindi l’intero progetto può essere imma-
INTRODUZIONE V
ginato come un intrecciarsi di diverse fasi, ciascuna guidata e semplificata
da una specifica disciplina, ma tutte gestite e coordinate dall’ingegneria del
software, la quale ha permesso di mantenere in ogni momento una visione di
progetto ordinata e compatta.
Questo lavoro di tesi è stato interamente sviluppato da un team di due
persone. Tutte le fasi di progettazione ed in generale le fasi più complesse
sono state affrontate in coppia. Le varie fasi di implementazione e program-
mazione sono state invece sviluppate per lo più indipendentemente, ovvia-
mente dopo aver definito le specifiche della sezione in questione, al fine di
ottimizzare le tempistiche di sviluppo. Grazie a questo approccio lo sviluppo
dell’applicazione è proceduto in modo molto efficace ed efficiente.
L’ideadiquestatesiènatadaunsoftwaresviluppatoperilcorsoalgoritmi
di ottimizzazione durante lo svolgimento della laurea magistrale. L’obietti-
vo del lavoro consisteva nel progettare e implementare un’euristica per la
risoluzione di un problema di arc routing chiamato Capacitated Arc Routing
Problem (CARP). Essendo il problema di tipo NP-Hard era ovviamente ri-
chiestodiimplementareun’euristicarisolutrice, ovverounalgoritmochefosse
in grado di fornire una buona soluzione (non ottima, data l’impossibilità teo-
rica) in un tempo ragionevole. Anche questo progetto è stato sviluppato in
coppia, dalle stesse persone che hanno portato a termine questo lavoro di
tesi. Il software creato implementa un algoritmo di ricerca locale molto effi-
ciente, il quale è stato confrontato con altri algoritmo presenti in letteratura,
fornendo risultati molto positivi ed incoraggianti. Una delle caratteristiche
più interessanti dell’algoritmo è la sua capacità di adattarsi all’istanza del
problema che si vuole affrontare, riuscendo sempre a fornire in output una
soluzione che sia un buon compromesso tra la complessità dell’istanza da un
lato e le risorse a disposizione dell’utente dall’altro. Quando si affronta un
problema NP-Hard infatti, la sua complessità cresce in modo esponenziale
all’aumentare delle dimensioni del problema dato in input. In termini pra-
tici questo significa che la complessità aumenta drasticamente all’aumentare
del numero di archi con richiesta positiva e del numero di veicoli a dispo-
sizione. Un algoritmo pensato per risolvere istanze di piccola complessità
potrebbe funzionare bene, addirittura trovare la soluzione ottima, entro la
categoria di problemi per il quale è progettato, ma al contrario potrebbe di-
ventare inutilizzabile su istanze di maggior complessità. L’algoritmo che è
stato sviluppato invece considera da un lato la complessità dell’istanza da ri-
solvere, dall’altro il tempo che l’utente è disposto a spendere, adattando così
il proprio meccanismo di funzionamento. In questo modo è possibile risolve-
re un’istanza di piccole dimensioni con altissima probabilità di trovare una
soluzione molto vicina all’ottimo; d’altro canto è possibile fornire in input
un’istanza molto più complessa ed ottenere comunque una soluzione buona,
INTRODUZIONE VI
anche se ovviamente non così vicina all’ottimo. Naturalmente vale la regola
generale secondo la quale, indipendentemente dalla complessità dell’istanza,
all’aumentare del tempo di esecuzione dell’algoritmo (tempo a disposizione
dell’utente)aumentanoancheleprobabilitàditrovareunasoluzionemigliore.
L’algoritmo appena introdotto, per la risoluzione del CARP, è proprio
il punto di partenza di questa tesi. Il software che era stato sviluppato in-
fatti, sebbene funzionasse correttamente, poteva essere meramente usato per
risolvere istanze date in input tramite file di testo, formattato secondo un’op-
portuna sintassi. Da un lato questa modalità di interazione è estremamente
utile, in ambito di ricerca, per permettere la condivisione di set di istanze
noti e dei relativi risultati; d’altro canto però questa tipologia di interazione
è assolutamente inutilizzabile, da parte di un normale utente, per la risolu-
zione di problemi reali legati alla rete stradale. Per di più l’utilizzo di tale
algoritmo per la risoluzione di problemi di arc routing reali è limitato alle ca-
ratteristiche del problema matematico CARP su grafo non orientato, il quale
non è sufficiente a rappresentare una categoria generale di problemi di eroga-
zione dei servizi su strada. Fra le varie modifiche progettate ed implementate
infatti c’è anche l’aggiunta di nuove caratteristiche, la più importante delle
quali è l’introduzione di un grafo orientato, necessario al fine di rappresenta-
re correttamente la rete stradale. Questa considerazione sancisce di fatto il
passaggio ad un nuovo modello matematico, chiamato DCARP.
Lo scopo di questa trattazione è guidare il lettore attraverso le varie
fasi che hanno portato alla realizzazione di un sistema finale in grado di
supportare l’utente nella risoluzione di una vasta categoria di problemi reali
legati all’erogazione di servizi sulla rete stradale. Di seguito viene quindi
spiegata la struttura generale della tesi.
Nel Capitolo 1 viene data una breve introduzione ai problemi di arc rou-
ting, la quale porta alla scoperta del problema di ottimizzazione sottostante
ai problemi reali che ci si propone di risolvere. Nel Capitolo 2 tale proble-
ma viene descritto formalmente e soprattutto viene presentato l’algoritmo
progettato ed implementato per la sua risoluzione. Con il Capitolo 3 si ab-
bandona momentaneamente il problema di ottimizzazione, per passare alla
fase di analisi preliminare e progettazione dell’applicazione finale: un soft-
ware concepito ex-novo in grado di supportare graficamente l’utente nella
definizione e risoluzione di problemi di erogazione di servizi sulla rete stra-
dale. Nel Capitolo 4 viene invece mostrata l’implementazione del sistema
finale, fase che comprende un vasto set di modifiche apportate al risolutore
nonché la realizzazione del server web in grado di ospitare l’applicazione vera
e propria. Ad implementazione terminata, nel Capitolo 5 è finalmente pos-
sibile mostrare il prodotto finale, ovvero il software Super Route Optimizer,
presentato attraverso il relativo manuale d’uso. Infine, in accordo con i cano-
INTRODUZIONE VII
ni dettati dall’ingegneria del software, nel Capitolo 6 viene presentata la fase
di testing, condotta in collaborazione col comune di Lonato del Garda, nel-
la quale viene dimostrato il corretto funzionamento del sistema sviluppato.
La trattazione si chiude con il Capitolo 7 in cui vengono proposti possibili
sviluppi futuri dell’applicazione, volti principalmente a migliorare l’usabilità
del sistema, per poi chiudere con delle conclusioni sul lavoro svolto.
Capitolo 1
Stato dell’arte
Il punto di partenza del progetto è un software sviluppato precedentemente
per la risoluzione del Capacitated Arc Routing Problem. D’altro canto però
l’obiettivo di questo lavoro è creare un supporto concreto alla risoluzione di
problemi reali di arc routing, ovvero in cui l’istanza è rappresentata da un
problema concreto su una porzione di rete stradale esistente. Per questo
motivo è necessario analizzare da un lato le caratteristiche di alcuni fra i più
noti problemi di arc routing, dall’altro lato le peculiarità dei problemi reali
da risolvere, al fine di trovare un punto d’incontro fra teoria e realtà.
Nella sezione corrente sarà data una breve introduzione ai problemi di
arc routing in generale, in modo da poter capire quale sia il miglior modello
matematicoperrappresentarelarealtà. Inquestafaseinfattinonsonoancora
state ben definite le caratteristiche dell’applicazione in termini di tipologie
di problemi che dovrà essere in grado di risolvere.
L’excursus che verrà presentato ha una struttura concepita volutamente
per far fronte alle due esigenze principali di questo capitolo iniziale:
introdurre i problemi di arc routing, presentando alcuni problemi ma-
•
tematici noti e le relative complessità;
attraverso i problemi presentati, guidare l’utente alla comprensione di
•
un modello matematico in grado di rappresentare e risolvere le esigenze
reali dei problemi che ci si propone di risolvere.
Al termine di questa sezione infatti, dopo aver illustrato le caratteristiche
generali dei principali problemi di arc routing, saranno elencate le caratte-
ristiche che il software (quindi l’algoritmo) risolutore finale dovrà possedere.
Questo permetterà di trovare un punto di incontro fra le esigenze reali e i
modelli matematici noti.
1
CAPITOLO 1. STATO DELL’ARTE 2
1.1 Introduzione ai problemi di arc routing
In termini il più generale possibile, i problemi di arc routing (ARP) consi-
stono nel determinare un attraversamento a costo minimo di un insieme di
archi di un grafo, soggetto ad alcuni vincoli [1]. In termini più formali, sep-
pur molto generali, si può anche darne la seguente definizione:
Dato un grafo G=(V,A), orientato o meno, con V insieme dei vertici e A
insieme dei lati con un costo di attraversamento associato a ciascuno e da-
to un sottoinsieme di archi R da attraversare obbligatoriamente, il problema
consiste nel trovare un percorso a costo minimo che passi per tutti gli archi
di R ed (eventualmente) soddisfi anche altri vincoli di ammissibilità.
Il primo ARP presente storicamente in letteratura [2], il quale fra l’altro
ha gettato le basi della moderna teoria dei grafi, è il problema dei ponti
della città di Königsberg. In questa cittadina attraversata da un fiume erano
presenti alcuni ponti: la domanda che ci si poneva era se fosse possibile o
meno partire da un ponte, percorrere tutti gli altri ponti una ed una sola
volta per poi ritornare all’inizio. In questo primo ARP dunque sussiste il
vincolo secondo il quale il sottoinsieme tutti gli archi del grafo devono essere
passatiunaedunasolavolta(passaggimultiplidallostessopontedunquenon
erano ammessi per risolvere il problema). Dopo che molte persone cercarono
invano di risolvere il problema, Eulero nel 1736 dimostrò che era impossibile
fornirne una soluzione. Per arrivare a questa conclusione, Eulero modellizzò
i ponti ed i relativi collegamenti tramite un grafo indiretto. In pratica egli
introdusse un vertice per ciascuna area (4 in totale) distinta della città e li
collegò con un arco per ciascun ponte presente (7 in totale). In Figura 1.1 è
presente una rappresentazione della città con i relativi ponti e le 4 aree che
si vengono a formare, corredata dalla sua trasposizione su grafo.
Partendo da questa modellizzazione Eulero dimostrò che, al fine di po-
ter percorre tutti gli archi una ed una sola volta, condizione necessaria era
il fatto che tutti i nodi del grafo fossero di grado pari, dove per grado si
intende il numero di archi incidenti al nodo. Questa condizione non era ov-
viamente soddisfatta dal grafo relativo all città di Königsberg. Si consideri
inoltre che la condizione di Eulero è in realtà necessaria e sufficiente, anche
se quest’ultima proprietà venne dimostrata più tardi (non da Eulero).
Nella maggior parte dei problemi di arc routing moderni non sussiste il
vincolo di passare per gli archi di R una ed una sola volta: al limite esiste il
vincolo di effettuare un servizio una ed una sola volta su quegli archi (questo
però non vieta il passaggio multiplo laddove è necessario). Tuttavia la condi-
zione trovata da Eulero riveste una grandissima importanza dal momento che