verticale

Progettazione e sviluppo di software di supporto alla logistica dei trasporti

Uno dei problemi più diffusi, nell'ambito della logistica, è rappresentato dai costi di trasporto. La gestione dei flussi merci, l'approvvigionamento dei clienti, e la relativa pianifcazione della movimentazione dei veicoli, hanno incidenze notevoli sui costi di gestione aziendali, i quali vengono stimati mediamente nel 45% dei costi logistici. A ragione di questo, sono sempre di più le aziende che ricorrono all'impiego di uffici dedicati alla pianifcazione delle consegne e la gestione dei trasporti in generale. Sebbene le voci di bilancio relative al trasporto raggiungano cifre rilevanti, fno al 4% del fatturato annuo, il tema della pianifcazione viene spesso sottovalutato. Infatti la soluzione a problemi di pianifcazione e monitoraggio dei costi, è spesso demandata a procedure manuali senza supporto informatico.

Scarica il PDF Scarica il PDF
Aggiungi ai preferiti Aggiungi ai preferiti


Articoli tecnico scientifici o articoli contenenti case history
Tesi di Laurea, Università degli Studi di Bologna, Anno Accademico 2012- 2013

Pubblicato
da Alessia De Giosa
VerticaleSegui aziendaSegui




Settori: 

Parole chiave: 


Estratto del testo
Alma Mater Studiorum - Universit` a di Bologna CAMPUS DI CESENA SCUOLA DI SCIENZE Corso di Laurea in Scienze dell''Informazione PROGETTAZIONE E SVILUPPO DI SOFTWARE DI SUPPORTO ALLA LOGISTICA DEI TRASPORTI Relazione finale in Ricerca Operativa Relatore:
Ill.mo Prof. Aristide Mingozzi
Correlatore:
Dott. Andrea Valletta Presentata da: Luca Canella III Sessione Anno Accademico 2012/2013 Ringraziamenti Vorrei ringraziare il prof. Aristide Mingozzi e il dott. Andrea Valletta, per la costante disponibilit`a, l''aiuto e le conoscenze che mi hanno trasmesso. Inoltre vorrei ringraziare il dott. Roberto Roberti, per la disponibilit`a concessa, e per i consigli condivisi in merito a questa tesi. Ringrazio GESP srl, per l''opportunit`a accordatami di partecipare allo sviluppo del progetto NST, inserendomi in un gruppo di lavoro giovane e preparato, ed avendomi accolto con grande disponibilit`a e professionalit`a. Ringrazio il Team Trasporti, cio`e la business unit preposta allo sviluppo di NST, ed in particolare i miei colleghi Sandra Golfarelli, Federico Foschini e Fabio Colombo. Un caloroso ringraziamento va a mia madre Silvia e mio padre William, ai miei nonni, ed agli zii, che mi sono stati vicini, credendo in me, con incrollabile pazienza, durante questi anni di studio. Infine vorrei ringraziare mio fratello Giulio, la mia compagna Mina, ed i miei amici, con i quali il tempo vola, e senza i quali passa troppo lentamente. Luca Canella c Introduzione Uno dei problemi pi` u diffusi, nell''ambito della logistica, `e rappresentato dai costi di trasporto. La gestione dei flussi merci, l''approvvigionamento dei clienti, e la relativa pianificazione della movimentazione dei veicoli, hanno incidenze notevoli sui costi di gestione aziendali, i quali vengono stimati mediamente nel 45% dei costi logistici. A ragione di questo, sono sempre di pi` u le aziende che ricorrono all''impiego di uffici dedicati alla pianificazione delle consegne e la gestione dei trasporti in generale. Sebbene le voci di bilancio relative al trasporto raggiungano cifre rilevanti, fino al 4% del fatturato annuo, il tema della pianificazione viene spesso sotto- valutato. Infatti la soluzione a problemi di pianificazione e monitoraggio dei costi, `e spesso demandata a procedure manuali senza supporto informatico. Nasce da qui l''esigenza di proporre uno strumento informatico che suppor- ti gli addetti preposti alla pianificazione, sviluppando un sistema che copra esigenze di pianificazione dei viaggi, controllo e consuntivazione dei costi di trasporto, e monitoraggio dei mezzi in tempo reale. La proposta di Gesp srl, Geographic Information Systems, azienda italiana che opera da anni nel campo delle applicazioni software geo-spaziali, prende il nome di Nuovo Sistema Trasporti, o pi` u semplicemente, NST. In quest''ambito prende corpo questa tesi, la quale si pone l''obiettivo di il- lustrare le fasi di nascita, analisi, progettazione e sviluppo di un software generico per il supporto alla logistica. Saranno cos`ı analizzati: ' le problematiche affrontate nella fase di definizione, e kick-off (avvio), del progetto; i ii Introduzione ' il problema del routing, o Vehicle Routing Problem e le tecniche di Ricerca Operativa che vengono applicate per la sua risoluzione; ' le moderne metodologie di gestione e sviluppo di un software; ' l''architettura e le tecnologie impiegate per la distribuzione dell''appli- cativo. Questa tesi si articola in cinque capitoli. Nel capitolo 1 verr`a introdotto il progetto software NST, i casi d''uso cui si applica, e la fase di kick-off del progetto. Il capitolo 2 `e dedicato alla formulazione matematica del problema dei trasporti: verranno qui introdotti gli algoritmi risolutivi, con i quali viene affrontato, e ne sar`a fornito il relativo stato dell''arte ad oggi. Nel capitolo 3, saranno introdotte alcune problematiche relative alle fase di approccio alla realizzazione del software. Saranno qui introdotte le me- todologie adottate dal team di sviluppo, gli strumenti impiegati e i processi che caratterizzano le fasi di implementazione dell''applicativo. Il capitolo 4, introduce l''architettura software di NST, e le tecniche con le quali vengono approcciati alcuni problemi comuni nello sviluppo del software. Infine, il capitolo 5, `e incentrato sulla progettazione e lo sviluppo dell''in- terfaccia utente, partendo dalle problematiche di design, fino alla descrizione delle tecnologie impiegate per la sua implementazione in ambito web. Indice Ringraziamenti c Introduzione i Indice v 1 Il software, NST 1 1.1 Casi d''uso reali . . . . . . . . . . . . . . . . . . . . . . . . . . 1 1.1.1 GDO, grande distribuzione organizzata . . . . . . . . . 2 1.1.2 Aziende di servizi . . . . . . . . . . . . . . . . . . . . . 3 1.1.3 Enti ambientali, la raccolta dei rifiuti . . . . . . . . . . 5 1.2 Business plan . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.3 Deliverable . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 1.4 Struttura dell''applicativo . . . . . . . . . . . . . . . . . . . . . 8 1.4.1 Infrastruttura server . . . . . . . . . . . . . . . . . . . 9 1.4.2 Il lato client . . . . . . . . . . . . . . . . . . . . . . . . 10 1.5 Analisi e scelte . . . . . . . . . . . . . . . . . . . . . . . . . . 11 1.6 Domini applicativi del VRP . . . . . . . . . . . . . . . . . . . 12 1.6.1 L''ottimizzatore . . . . . . . . . . . . . . . . . . . . . . 14 2 Introduzione al problema del routing, il VRP 17 2.1 Formulazione matematica del VRP . . . . . . . . . . . . . . . 18 2.1.1 Notazione della Teoria dei Grafi . . . . . . . . . . . . . 19 2.1.2 Capacitated VRP . . . . . . . . . . . . . . . . . . . . . 20 iii iv Introduzione 2.1.3 Modello di programmazione lineare per CVRP . . . . . 22 2.2 Varianti e metodi risolutivi per il VRP . . . . . . . . . . . . . 23 2.2.1 VRP con Time Windows e Formulazione Set Partitioning 23 2.2.2 Metodi risolutivi esatti . . . . . . . . . . . . . . . . . . 24 2.2.3 Metodi euristici . . . . . . . . . . . . . . . . . . . . . . 27 2.2.4 Metodi metaeuristici . . . . . . . . . . . . . . . . . . . 28 2.2.5 Metaeuristici a ricerca locale . . . . . . . . . . . . . . . 30 3 Approccio alla fase realizzativa 33 3.1 Metodologie di sviluppo, Scrum . . . . . . . . . . . . . . . . . 33 3.2 Test Driven Development e Continous Integration . . . . . . . 36 3.3 Strumenti di sviluppo . . . . . . . . . . . . . . . . . . . . . . . 38 3.3.1 Macchina virtuale di sviluppo . . . . . . . . . . . . . . 39 3.3.2 Versioning del codice sorgente . . . . . . . . . . . . . . 40 3.3.3 IDE, ambiente di sviluppo integrato . . . . . . . . . . . 42 3.3.4 CI server . . . . . . . . . . . . . . . . . . . . . . . . . . 42 4 Architettura del sistema 45 4.1 Stratificazione e Multi-tier architecture . . . . . . . . . . . . . 46 4.1.1 La stratificazione di NST . . . . . . . . . . . . . . . . . 47 4.2 Pattern di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . 48 4.2.1 Model View Controller, MVC . . . . . . . . . . . . . . 50 4.2.2 Model View View-model, MVVM . . . . . . . . . . . . 51 4.2.3 Provider model . . . . . . . . . . . . . . . . . . . . . . 52 4.2.4 Adapter, decorator e fa¸cade patterns . . . . . . . . . . 53 5 L''interfaccia utente 57 5.1 Metodologia collaborativa: Wireframing, mockups e prototyping 58 5.2 UI guidelines e Metro design language . . . . . . . . . . . . . 59 5.3 Web applications e web UI . . . . . . . . . . . . . . . . . . . . 61 5.4 Server side UI, ASP.NET MVC . . . . . . . . . . . . . . . . . 63 5.4.1 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . 65 INDICE v 5.4.2 Views . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.4.3 Controllers ed API controllers . . . . . . . . . . . . . . 68 5.5 Client side UI . . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.5.1 HTML5, CSS3 e Javascript . . . . . . . . . . . . . . . 71 5.5.2 Il DOM, Document Object Model . . . . . . . . . . . . 74 5.5.3 AJAX, accesso asincrono ai dati . . . . . . . . . . . . . 75 5.5.4 MVVM con KnockoutJS . . . . . . . . . . . . . . . . . 80 Conclusioni 85 Bibliografia 87 Elenco delle figure 1.1 Struttura web-based dell''interfaccia . . . . . . . . . . . . . . . 11 1.2 Il problema del routing . . . . . . . . . . . . . . . . . . . . . . 14 3.1 Scrum Agile . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3.2 Fasi del Test Driven Development . . . . . . . . . . . . . . . . 36 3.3 Una schermata di configurazione progetto di TeamCity . . . . 43 4.1 Architettura n-tier di NST . . . . . . . . . . . . . . . . . . . . 49 4.2 La struttura Model-View-Controller . . . . . . . . . . . . . . . 50 4.3 Ripartizione delle funzionalit`a in MVC . . . . . . . . . . . . . 51 4.4 Struttura di una UI basata su MVVM . . . . . . . . . . . . . 53 4.5 Diagramma di un decorator, e un adapter, per la classe User . 55 4.6 Diagramma di una fa¸cade per servizi di geolocalizzazione . . . 55 5.1 UI design tramite wireframing, mockup e prototipazione . . . 59 5.2 Schermata di Outlook.com, con email aperta. . . . . . . . . . 60 5.3 Riepilogo della struttura, e delle tecnologie, di una UI basata sul web. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62 5.4 Il DOM, Document Object Model, di una semplice pagina HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 vii Capitolo 1 Il software, NST Il progetto software NST, di GESP srl, nasce nel 2013 con l''intenzione di proporsi nel mercato dei software per la pianificazione dei trasporti, come prodotto d''avanguardia. Molti sistemi software, che rispondono ad esigenze logistiche, sono infatti basati su principi di sviluppo e tecnologie sorpassati, e, laddove sono state introdotte nuove piattaforme con caratteristiche pi` u moderne, sono state notate mancanze in termini di adattabilit`a e completezza delle soluzioni fornite. L''acronimo NST sta per Nuovo Sistema Trasporti, nome che palesa l''obiettivo di fornire un software completo e moderno per il supporto alla logistica dei trasporti. Nel seguito di questo capitolo, verranno introdotte le problematiche af- frontate in fase d''approccio al progetto, introducendo: i casi d''uso principali ai quali NST pu`o essere applicato, i principali ambiti aziendali ai quali mi- ra, una descrizione del business plan associato al progetto, ed altri aspetti generali sulle fasi di valutazione preventiva e analisi del progetto. 1.1 Casi d''uso reali NST nasce come prodotto di supporto alla pianificazione dei trasporti, il cui obiettivo `e quello di coprire esigenze relative alla pianificazione dei viaggi, 1 2 1. Il software, NST al controllo e consuntivazione dei costo di trasporto, e al monitoraggio dei mezzi di trasporto in tempo reale. L''idea di base `e quella di un software generico, che si possa adatta- re a molteplici panorami aziendali, integrandosi con software gi`a presenti (ERP, CRM), e fornendo una ampia gamma di personalizzazioni e moduli aggiuntivi, che facciano fronte a richieste specifiche dei singoli clienti. NST deve essere basato sul web, al fine di poter offrire una piattaforma condivisa con supporto di multiutenza e minimo impatto sulle infrastrutture tecnologiche dei clienti. Si richiede quindi che il software sia flessibile e facile da utilizzare, dotato di interfacce personalizzabili e semplici. Le situazioni affrontate dal software, come vedremo in dettaglio nel se- condo capitolo, sono riconducibili ad una classe di problemi identificata dal problema del routing , o VRP. Questo genere di problemi sono applicabili ad una vasta gamma di aziende, ed enti, operanti nell''ambito della logistica, dei quali si riportano tre importanti casi d''uso: aziende di trasporto, aziende di servizi ed enti ambientali. 1.1.1 GDO, grande distribuzione organizzata Per grande distribuzione organizzata, o GDO, si intende una rete di punti vendita al dettaglio, distribuiti sul territorio, operanti sotto un unico marchio. Le aziende della GDO sono caratterizzate da politiche di approvvigionamento centralizzate, e quindi, da un''omogeneit`a nella gestione dei fornitori tra i vari punti vendita. I punti vendita della rete di una GDO possono assumere varie forme, dal tradizionale negozio al dettaglio, all''ipermercato, allo specialist drug store1 , o negozi di vendita all''ingrosso. Gli obiettivi principali riguardano l''ottimizzazione delle operazioni di ap- provvigionamento dei punti vendita e sono legati all''abbattimento dei costi di trasporto ed alla rapidit`a nella consegna di certe categorie merceologi- che. Considerando inoltre, le ampie aree del territorio sul quale operano tali 1Negozi al dettaglio che forniscono principalmente prodotti per la cura della casa e/o della persona 1.1 Casi d''uso reali 3 aziende, e l''impiego di differenti tipologie di rami nella rete stradale, possono essere introdotti obiettivi specifici che riducano l''utilizzo di veicoli pesanti in aree urbane, o l''utilizzo di reti distributive a pi` u livelli. Particolare attenzione va posta nella gestione delle regole applicate ai vei- coli della flotta, dovendo gestire ad esempio caratteristiche quali: la capacit`a dei vani di carico, in genere essere espresse in unit`a di misura differenti, la possibilit`a di percorrere o meno certi tratti della rete stradale e le differen- ti attrezzature disponibili (sponde idrauliche, vani refrigerati, etc.). Spesso sono richiesti servizi di tracciatura e monitoraggio dei mezzi in tempo reale. I vincoli introdotti possono comprendere regole di urgenza sulla consegna di merci deperibili e tabelle orarie per il carico e scarico merci. Un ulteriore esempio di vincolo, sebbene raramente introdotto, comprende la richiesta di minimizzare il numero di svolte a sinistra (nei paesi con guida a destra) per ridurre il numero di attraversamenti della carreggiata di senso contrario, migliorando cos`ı parametri di sicurezza e riducendo i tempi di consegna. 1.1.2 Aziende di servizi Le aziende che operano nell''ambito dei servizi svolgono interventi di assi- stenza e manutenzione presso clienti, sparsi su un territorio prevalentemente urbano. Rientrano in questa casistica le aziende che effettuano servizi di manutenzione agli ascensori, alle caldaie nelle abitazioni private, a macchine professionali per ufficio; per le caratteristiche del modello operativo, ricadono in questo caso d''uso anche le aziende che riforniscono clienti di merci poco voluminose, come prodotti consumabili per ufficio o snack per bar e punti commerciali. Gli interventi sono in genere effettuati da personale specializ- zato che si muove sul territorio con la propria macchina o con un piccolo furgone. In alcune realt`a, dove la macchina `e concessa come benefit al tec- nico che la utilizza anche per uso privato, la giornata di lavoro ha inizio dall''abitazione del tecnico, e non dalla sede aziendale. In particolare per gli interventi di assistenza tecnica, dove non `e prevista la consegna di alcuna merce al destinatario, non `e richiesta la preparazio- 4 1. Il software, NST ne del veicolo prima della partenza; i veicoli sono gi`a equipaggiati con gli strumenti necessari agli interventi, e non `e necessario effettuare alcun carico presso il deposito prima di visitare il cliente. Nel caso di distribuzione di piccoli quantitativi di merce, come il rifornimento di capsule per macchine da caff`e, `e possibile che sul furgone ci sia una scorta sufficiente sia per le visite programmate, sia per supportare eventuali attivit`a di tentata vendita presso nuovi clienti. In luogo dei vincoli di capacit`a dei veicoli, o di compatibilit`a per dimen- sioni con il sito del cliente, in ambito servizi sono predominanti le regole di assegnamento sulla base della compatibilit`a del veicolo (autista) con il cliente. Ad esempio, solo alcuni tecnici sono specializzati nella riparazione di alcune linee di prodotti, e non sono in grado di intervenire su altre. Nel- l''ambito dei tecnici con abilit`a compatibili con l''intervento programmato, `e preferito il tecnico che abitualmente visita il cliente, per motivi di continuit`a e fidelizzazione del rapporto. In genere gli autisti svolgono un solo giro al giorno, dove per giro si intende una sequenza di visite con partenza dal deposito (o dall''abitazione dell''autista). Il giro prevede una sosta per la pausa pranzo, ed un numero di visite che pu`o variare sensibilmente in base ai diversi contesti; mentre la riparazione di una stampante professionale pu`o richiedere un intervento anche di due o tre ore, la consegna di materiale per ufficio `e molto rapida. Il numero di visite giornaliere pu`o variare perci`o da 2/3 visite a pi` u di 20. Una volta programmato il piano viaggi, la realizzazione durante lo svol- gimento della giornata `e molto dinamico. Le aziende di servizi operano pre- valentemente in un contesto urbano, dove il fattore traffico `e spesso determi- nante; sulla base della propria esperienza, e delle condizioni di traffico attuali, gli autisti possono variare la sequenze delle visite programmate, aggiungerne di nuove o non riuscire a completare il giro assegnato. 1.2 Business plan 5 1.1.3 Enti ambientali, la raccolta dei rifiuti Le terza tipologia di aziende comprende gli enti che operano nell''ambien- te operando, ad esempio, raccolta di rifiuti. La raccolta dei rifiuti presenta problemi relativi alla periodicit`a della raccolta, alla capacit`a dei mezzi, al numero di risorse disponibili e all''individuazione dei percorsi ottimali verso le idonee aree di stoccaggio. Tali problematiche si articolano in base alla fase di gestione del rifiuto come la raccolta, lo stoccaggio, il trattamento e lo smaltimento. Tutto ci`o aggiunge complessit`a alla modellazione dei depo- siti, i quali prevedono differenti impianti di gestione dei rifiuti e differente disponibilit`a di risorse. Il cliente in questi casi prende la forma del punto di raccolta, del quale si necessita il salvataggio di informazioni relative alla quantit`a di rifiuti prodotta per unit`a di tempo, la periodicit`a della raccolta e l''eventuale gestione della raccolta differenziata. 1.2 Business plan La valutazione del progetto NST `e iniziata con la stesura di un Business plan, cio´e un documento che espone obiettivi, contenuti e caratteristiche del progetto imprenditoriale. Tale documento `e di supporto ad ogni fase di svi- luppo del software, a partire dall''analisi di fattibilit`a fino alla pianificazione delle attivit`a di sviluppo. Il business plan di NST comprende: ' una panoramica sul problema della gestione trasporti; ' i settori aziendali cui si rivolge NST e le loro principali esigenze; ' gli obiettivi del software, intesi sia come obiettivi funzionali, che come obiettivi economico/commerciali; ' un survey sulle principali soluzioni proposte dai competitors; ' la struttura del software, con particolare enfasi sui punti di forza di NST rispetto agli altri prodotti; 6 1. Il software, NST ' un riassunto dei requisiti funzionali di base del prodotto; ' i requisiti in termini di competenze, richiesti per lo sviluppo del proget- to; ' una descrizione dell''approccio alla fase di sviluppo; ' alcuni possibili scenari reali, all''interno dei quali si andrebbe a collocare NST . A seguito della presentazione del business plan `e stato deciso che il pro- getto sarebbe stato persegubile, dando il via alle successive fasi di project management. 1.3 Deliverable Terminata la definizione degli obiettivi del progetto NST, il processo di pianificazione ha proceduto con l''identificazione delle principali attivit`a di analisi e sviluppo. Ad ognuna di queste attivit`a `e stato associato il rilascio, di documenti o prodotti fisici, detti deliverable. Lo scopo dei deliverable `e quello di fornire prova tangibile, e verificabile, delle attivit`a svolte in merito allo sviluppo del progetto. I principali deliverable prodotti per NST riguardano gli ambiti di: ' Gestione della qualit`a: '' linee guida di scrittura del codice; '' linee guida di progettazione del database. ' Gestione della configurazione: '' creazione di un repository per il versioning dei sorgenti; '' strumenti di condivisione dei documenti; '' configurazione della macchina virtuale di sviluppo. 1.3 Deliverable 7 ' Strategia di comunicazione. ' Pianificazione delle attivit`a. Il documento delle linee guida di scrittura del codice, riporta le di- rettive cui attenersi per la scrittura del codice, derivato da una una sintesi e adattamento delle linee guida Microsoft. Il documento standardizza aspetti quali la scelta dei nomi delle variabili, le opzioni di casing, la gestione dell''in- dentazione, e descrive regole pi` u specifiche riguardo la visibilit`a di metodi, variabili di classe, etc. L''obiettivo `e quello di uniformare la struttura dei sorgenti, per facilitare la leggibilit`a e la comprensione all''interno del gruppo di lavoro. Le linee guida di progettazione del database, sono anch''esse raccolte in un documento, il quale riporta le direttive per la progettazione fisica del database. Qui sono descritte le regole per la scelta dei nomi di tabelle e campi, le convenzioni per le chiavi primarie, la gestione delle relazioni. L''obiettivo del documento `e uniformare le strutture contenute nel database, e ricondurle ad una chiave di lettura condivisa. La regolamentazione nella progettazione del database ha ancora maggior importanza per la comprensione rispetto alla scrittura del codice, dove l''inserimento di commenti possono sopperire alla mancata leggibilit`a. La creazione di un repository per il versioning dei sorgenti, gestito tramite un apposito strumento di controllo, ha lo scopo di fornire una banca dati centralizzata per i sorgenti, abilitare meccanismi di estrazione, modifica e riconciliazione delle versioni, e consentire ai componenti del team di disporre, in qualsiasi momento, della versione pi` u aggiornata del codice. La condivisione dei documenti di progetto di natura tecnica, com- mericale e di riferimento per la qualit`a del progetto, avviene attraverso un sito Sharepoint. Sharepoint `e un CMS, cio`e Content Management System, fornito da Microsoft, che permette di gestire contenuti web in modo rapido e strutturato, fornendo inoltre meccanismi di autenticazione e profilazione de- gli utenti. Tali meccanismi di profilazione permettono l''accesso ai documenti, sia a membri di sviluppo, sia al team di management. 8 1. Il software, NST La strategia di comunicazione impiegata comprende la condivisione degli avanzamenti di progetto all''esterno del team con cadenza di 6 settima- ne; tramite incontro con il Project Board vengono illustrati l''avanzamento tecnico e le opportunit`a commerciali raccolte. Il Project Plan `e un documento che espone la macro-programmazione delle attivit`a. Qui sono individuati i deliverable specialistici di progetto, i quali sono poi suddivisi in work unit. Per ciascuna work unit `e stato definito il perimetro funzionale e fatta una stima in giornate uomo per il completamento. A fronte dell''impegno complessivo il project board ha autorizzato la for- mazione di un team dedicato per il delivery della soluzione; il tempo sola- re per il delivery della soluzione `e stato determinato considerando l''effort complessivo di progettazione e la dimensione del team di lavoro. 1.4 Struttura dell''applicativo NST `e progettato come software basato sul web (web-based ), ci`o significa che le sue funzionalit`a sono distribuite tramite una rete, sia essa una rete aziendale (intranet), o globale (internet). L''accesso tramite network fornisce un supporto naturale alla condivisione dei dati e alla multiutenza, permet- tendo l''accesso simultaneo alla base dati ad un numero elevato di utenti, i quali possono scambiarsi informazioni in tempo reale. L''applicativo si basa su un''architettura client-server classica, e su tec- nologie largamente usate in ambito web, come HTTP e HTML5 ; questo fa s`ı che la complessit`a sia incapsulata il pi` u possibile sul lato server, e che le tecnologie impiegate siano largamente supportate. In pratica per accedere al software `e sufficiente un browser aggiornato, disponibile ad oggi sulla gran- de maggioranza di dispositivi connessi alla rete (computer, cellulari, tablet, palmari, etc.). I principali vantaggi di questo approccio comprendono: 1.4 Struttura dell''applicativo 9 ' impatto estremamente limitato sull''infrastrtuttura tecnologica del clien- te, grazie ai limitati requisiti di hardware; ' accessibilit`a da una grande quantit`a di device connessi alla rete, anche con caratteristiche differenti; ' semplificazione delle procedure di distribuzione ed aggiornamento del software, il quale risiede in un''unica macchina e pu`o essere aggiornato in tempo reale anche da remoto; ' maggior numero di offerte commerciali proponibili al cliente, le quali possono comprendere formule SaaS (Software as a Service) quali ab- bonamenti mensili a forfait, tariffazione a tempo per numero di veicoli, oppure formule personalizzate che possono comprendere l''installazione dell''applicativo sulla rete intranet aziendale. 1.4.1 Infrastruttura server La complessit`a di NST `e in gran parte racchiusa nel lato server, cio`e in quell''insieme di componenti software che vengono gestiti dall''infrastruttura centralizzata. Tale infrastruttura `e spesso composta da uno, o pi` u, server e da altri apparati di rete necessari alla propagazione dei dati nel network. In que- sta infrastruttura sono dispiegati i vari servizi, che comprendono: una base dati, un web-server, un server DNS, una connessione ad internet/intranet. Scopo del web-server `e quello di distribuire il software e i dati, tramite protocollo HTTP, in risposta alle richieste dei client. Il client fa la richie- sta ad un certo indirizzo web sul quale `e pubblicato l''applicativo; a questo punto il server DNS risponde traducendo l''indirizzo testuale nell''indirizzo IP relativo al server oppotunamente configurato all''erogazione del servizio. La richiesta raggiunge cos`ı il web-server, il quale invia in risposta documenti, da- ti e script che verranno rielaborati dal browser del client. Per far fronte ad un numero elevato di richieste si fa uso di una tecnica detta Round-robin DNS. Questa tecnica prevede che l''applicativo sia dispiegato su pi` u web-server, i 10 1. Il software, NST quali risiedono su diverse macchine, ad ognuna delle quali `e assegnato un diverso indirizzo IP. Ogni volta che un client richiede al server DNS l''indi- rizzo dell''applicativo, questo risponde con un indirizzo diverso, bilanciando di fatto, il numero di richieste che raggiungono i differenti server. Un al- tro vantaggio introdotto dall''utilizzo di questa tecnica `e il miglioramento della fault-tolerance del sistema, il quale in caso di malfunzionamento di un web-server, pu`o redirezionare le richieste ai rimanenti web-server funzionanti. Il database invece `e dispiegato su una macchina dedicata, generalmente connessa ai vari web-server tramite segmenti lan ad alta velocit`a. Il database server risponde alle richieste dati, di tutti i web-server, tramite un DBMS (Relational Database Management System) in esecuzione su di esso. Tale macchina deve rispondere a determinati requisiti di prestazioni, affidabilit`a e sicurezza. La configurazione pi` u diffusa, per questo tipo di macchine, prevede l''impiego di un sistema RAID 5. 1.4.2 Il lato client I client accedono ad NST tramite il web utilizzando un semplice browser. Un client pu`o richiedere al server alcuni documenti, dati, fogli di stile, oppure set di istruzioni in formato Javascript, i quali compongono l''interfaccia utente dell''applicativo. I documenti, o pagine, di cui `e composto NST sono ipertesti in formato HTML5 , i quali, corredati da fogli di stile in formato CSS3, determinano il layout dell''interfaccia utente. Gli script in formato Javascript, allegati alle pagine ed interpretati dal browser, permettono di implementare dinamiche di interazione non dissimili da quelle fornite da un applicativo desktop. Questi script possono interrogare il server per ottenere dati in tempo reale, i quali vengono inoltrati in formato XML o Json, elaborati e mostrati all''utente. 1.5 Analisi e scelte 11 Figura 1.1: Struttura web-based dell''interfaccia 1;DOCTYPE/htmlz
1htmlz
///1headz
//////1meta/http)equiv3
////////////rContent)Typer/
////////////content3rtext+html2
////////////charset3utf)wr+z
/////1titlez/NST/1+titlez
///1+headz
///1bodyz
//////{{{
///1+bodyz
1+htmlz Pagina HTML5 function/getCookiebcname./{
////var/name/3/cname/k/r3r2
////var/ca/3/document{cookie{splitbS2S.2
////for/bvar/i/3/'2/i/1/ca{length2/ikk./{
////////var/c/3/ca[i]{trimb.2
////////if/bc{indexOfbname./33/'.
////////////return/c{substringb
////////////////name{length(/c{length.2
////}
////return/rr2
} function/stringMatchbhaystack(/needle(/{{{
////if/b;matchCase./{
////////haystack/3/haystack{toLowerCaseb.2
////////needle/3/needle{toLowerCaseb.2
////}
////switch/bmatchType./{
////////case/SequalsS# {{{ File Javascript html/{
////background)color#/se[e[e[2
////margin#/'2
////padding#/'2
} body/{
////background)color#/sfff2
////border)top#/solid/0'px/s'''2
////color#/s]]]2
////font)size#/{w}em2
////margin#/'2
////padding#/'2
} header(/footer(/hgroup(
nav(/section/{
////display#/block2
} Foglio di stile CSS3 INTERNET Web server Client browser User interface Utente 1.5 Analisi e scelte L''analisi dei requisiti, svolta al fine di individuare le funzionalit`a richieste `e stata condotta tramite interviste, svolte presso potenziali acquirenti del prodotto finale, le quali hanno permesso di individuare un grande numero di casi d''uso e di servizi richiesti al software. Le tre problematiche principali alle quali il sistema deve rispondere comprendono: ' pianificazione dei viaggi; ' controllo e consuntivazione dei costi di trasporto; ' monitoraggio dei mezzi in tempo reale. Tali problematiche si articolano a loro volta in diversi punti: la pianifi- cazione comprende l''ottimizzazione dei giri, la possibilit`a di personalizzarli e il controllo dei vincoli di fattibilit`a per i giri prodotti. Il monitoraggio dei mezzi di trasporto in tempo reale comprende la possibilit`a di segnalare agli autisti i viaggi da effettuare in modo automatico tramite l''interfacciamento 12 1. Il software, NST con specifici terminali bordo mezzo. A questi punti fanno seguito una serie di problematiche derivate quali: ' gestione delle anagrafiche di veicoli, autisti, clienti, ... ' integrazione con erp aziendali ' integrazione con applicazioni di terze parti ' condivisione di informazioni a livello aziendale Allo scopo di far fronte a problematiche cos`ı varie, NST `e stato pensato come software web-based generico, adattabile all''occorrenza alle specifiche esigenze dei clienti. Il prodotto in questione deve quindi avere particolari doti di generalit`a, modularit`a, scalabilit`a e incrementalit`a. 1.6 Domini applicativi del VRP Nonostante la modellazione delle entit`a, coinvolte nella risoluzione del VRP, dipenda dalla specifica istanza del problema, `e possibile individuare alcuni elementi comuni nei vari domini applicativi. Tra questi abbiamo i veicoli, gli autisti, i depositi, i clienti e la rete stradale, che a meno di piccole variazioni mantengono molte caratteristiche tra le varie istanze del problema. La rete stradale viene rappresentata da un grafo, nel quale gli archi rap- presentano i tratti di strada percorribile e i nodi rappresentano incroci o indirizzi di clienti e depositi. Gli archi del grafo possono essere direzionati o non direzionati, e sono caratterizzati da un costo calcolato in base al tempo di percorrenza dal tratto stradale rappresentato. Sul grafo sono localizzati i punti geografici relativi agli indirizzi dei clienti, dei depositi ed eventua- li intersezioni. Per alcune applicazioni `e necessario modellare la tipologia di arco correlata al tipo di strada rappresentato (autostrada, superstrada, strada secondaria, ponti, etc.), per avere informazioni sulle dimensioni mas- sime dei veicoli in transito (peso, altezza, larghezza, lunghezza), eventuali limitazioni dovute al codice della strada (divieti, limiti di velocit`a, etc.) o 1.6 Domini applicativi del VRP 13 pedaggi imposti per il loro attraversamento. Il grafo `e utilizzato per calco- lare un distanziere, rappresentato da una matrice, nella quale gli indici di riga e colonna rappresentano i punti d''interesse del grafo e ogni elemento della matrice rappresenta il costo, in termini di distanza o di tempo, per l''attraversamento della rete stradale che congiunge tali nodi. Le caratteristiche tipiche dei clienti comprendono: ' informazioni geografiche, come l''indirizzo o le coordinate geografiche, i quali determinano anche il nodo del grafo stradale dal quale `e identifi- cato il cliente; ' la domanda, che rappresenta la quantit`a di merce richiesta; ' time windows, o meglio i periodi temporali nei quali il cliente pu`o essere visitato; ' tempo richiesto, sia esso un tempo di caricamento o scaricamento di merci oppure il tempo necessario per erogare un servizio richiesto; ' veicoli ammessi e non ammessi, determinati ad esempio da problema- tiche logistiche o relative alla rete stradale. ' costi o penali in caso di mancato servizio. Per gestire vincoli sul caricamento e lo scaricamento delle merci `e ne- cessario modellare i depositi, anch''essi localizzati geograficamente e quindi rappresentati da un certo nodo del grafo. Ad ogni deposito `e associato un insieme di veicoli e una capacit`a produttiva, intesa come la quantit`a di merce che pu`o essere servita ai clienti dai veicoli del deposito. Per ogni veicolo in flotta `e necessario modellare le seguenti caratteristiche: ' posizione di partenza, che identifica in genere il deposito di partenza o un differente nodo del grafo se previsto dai vincoli del problema; ' capacit`a dei vani di carico, espressa come peso, lunghezza, volume, o numero massimo di colli (o pallet) che il veicolo pu`o trasportare; 14 1. Il software, NST Figura 1.2: Il problema del routing VEICOLI CLIENTI DEPOSITO CARTOGRAFIA RETE STRADALE ' insieme di archi del grafo che il veicolo pu`o attraversare; ' varianti sul costo di trasporto per l''utilizzo del veicolo su una certa tratta stradale, espressi per unit`a di distanza, di tempo o per tipologia di strade attraversate; Gli autisti sono legati ad una serie di vincoli derivati da norme legali e contrat- tuali, e dalla necessit`a di risposo. Si associano quindi ad ogni autista: orari di lavoro, durata massima di guida giornaliera, pause di servizio e disponibilit`a giornaliera. 1.6.1 L''ottimizzatore Il componente software che risolve il problema del VRP, fornendo come soluzione la pianificazione dei viaggi, `e detta Ottimizzatore. L''interfacciamento con l''ottimizzatore `e ottenuto tramite la definizione di opportune strutture dati e formati d''interscambio per l''input, e l''output, dei dati tra l''algoritmo e l''applicativo. Le strutture dati fornite come input al- l''ottimizzatore sono costruite come un elaborato subset dei campi delle entit`a del dominio applicativo, e forniscono all''algoritmo la base dati necessaria al- la risoluzione del problema. L''output fornito dall''ottimizzatore, invece, deve comprendere una serie di informazioni che permettano ad NST di ricostruire, dalla soluzione fornita, una serie di oggetti e relazioni che rappresentino la pianificazione ottimizzata. 1.6 Domini applicativi del VRP 15 La necessit`a di produrre soluzioni con tempo di calcolo ridotto, per pro- blemi complessi, impone l''impiego di metodi veloci di tipo costruttivo, per ge- nerare una soluzione ammissibile, e di tecniche di local search per migliorarla (questo aspetto sar`a approfondito nel capitolo 2). Capitolo 2 Introduzione al problema del routing, il VRP Il Vehicle Routing Problem, o VRP, rappresenta una classe di problemi, relativi alla gestione dei trasporti, che coinvolge tutte le aziende attive nel campo della consegna e raccolta di beni o servizi. Si tratta di problemi per i quali, data una flotta di veicoli e un insieme di clienti, si richiede di calcolare un sistema di percorsi minimizzando i costi e rispettando una serie di vincoli di servizio. Esistono numerose varianti del VRP : possono variare tipologia dei vinco- li, caratteristiche dei veicoli, possono esserci differenti obiettivi da perseguire e diverse categorie di servizio richieste dai clienti. Gli obiettivi, ad esem- pio, possono rieferirsi ai tempi di percorrenza, alla lunghezza complessiva dei viaggi, al numero totale di viaggi effettauti o al costo dei viaggi. I veicoli, invece, possono essere caratterizzati da capacit`a e velocit`a medie differenti, dalla possibilit`a di percorrere o meno un certo tratto stradale o dall''insieme di depositi presso i quali si possono approvvigionare (nel caso di problemi multi deposito). Le categorie di servizio richieste dai clienti possono essere di consegna, ritiro, consegna e ritiro oppure erogazione di un servizio (ad esempio servizi di manutenzione presso il cliente). Si possono infine consi- derare molte tipologie differenti di vincoli quali: vincoli sulla capacit`a dei 17 18 2. Introduzione al problema del routing, il VRP veicoli, lunghezza minima o massima dei viaggi, vincoli di tempo sugli ora- ri degli operatori o sulla disponibilit`a dei clienti, priorit`a o precedenze di determinati clienti. La maggior parte delle formulazioni del VRP appartiene all''insieme dei problemi NP-ardui, che sono quei problemi per i quali il calcolo di una so- luzione esatta richiede tempo polinomiale utilizzando un algoritmo branch- and-bound intelligente, cio`e in grado di valutare ad ogni passo il figlio giusto. I problemi NP-ardui sarebbero pertanto risolvibili, in tempo polinomiale, so- lamente da una macchina di Touring non deterministica. Nella pratica, se- condo la teoria della complessit`a, si dice che questi problemi hanno tempo di risoluzione che cresce in modo esponenziale con la dimensione dell''input. Gli algoritmi risolutivi per questa classe di problemi sono suddivisi in due tipologie: ' Algoritmi esatti, che cercano la soluzione ottima al problema impiegan- do tempo esponenziale. ' Algoritmi euristici, che cercano una soluzione approssimativamente vi- cina a quella ottima operando in tempo polinomiale. La scelta di un algoritmo euristico, in luogo di un algoritmo esatto, `e spesso dettata dall''impossibilit`a di ottenere una soluzione ottima in tempi ragione- voli per certe dimensioni del problema. 2.1 Formulazione matematica del VRP Il VRP `e un problema NP-arduo che estende il tipico problema del com- messo viaggiatore (o Travelling Salesman Problem, o TSP) introducendo una flotta di veicoli in luogo di un singolo veicolo. La formulazione del TSP richiede che, dato un grafo G, si trovi un ciclo di costo minimo, il quale visiti tutti i vertici del grafo una ed una sola volta. Come vedremo ci`o significa cercare il ciclo hamiltoniano di costo minimo in G . 2.1 Formulazione matematica del VRP 19 Introdurremo inizialmente la notazione della teoria dei grafi utile a descri- vere il problema in termini matematici; individueremo poi una formulazione del VRP in forma base per poi enumerare alcune delle sue varianti pi` u famose. 2.1.1 Notazione della Teoria dei Grafi Introduciamo la notazione della teoria dei grafi utile a modellare formal- mente il grafo della rete stradale usato durante la risoluzione del VRP. Sia G = (V, A) un insieme di elementi di cui V = v1, v2, vi, ..., vn sono detti ver- tici e A `e l''insieme degli archi del tipo (i, j), che congiungono i nodi i con i nodi j. Un arco si dice orientato se presenta una connessione diretta da i a j , mentre si dice non orientato se tale connessione non specifica un verso di percorrezza. Individuiamo ora in A i due insiemi D, degli archi orientati, ed E, degli archi non orientati, tali che A = (D ' E). Il grafo G si dir`a quindi orientato se E = ø, non orientato se D = ø, o misto se D 6= ø ' E 6= ø. Se ad ogni arco (i, j) `e associato un costo cij, allora il grafo si dice pesato. Diremo inoltre che G `e connesso se per ogni coppia (i, j) di nodi esiste un cammino in G che li collega. Sia G un grafo misto, definiamo ora: ' stella uscente del nodo i, indicato con ''+(i), l''insieme di tutti i nodi j tali che (i, j) '' D ' grado uscente del nodo i, indicato con d+(i) la cardinalit`a di ''+(i) ' stella entrante del nodo i, indicato con ''''(i), l''insieme di tutti i nodi j tali che (j, i) '' D ' grado entrante del nodo i, indicato con d''(i) la cardinalit`a di ''''(i) ' grado del nodo i, indicato con d(i), la cardinalit`a dell''insieme ''(i) dei nodi j tali che (i, j) '' E. 20 2. Introduzione al problema del routing, il VRP Un viaggio, o ciclo, in un grafo G `e una sequenza di nodi ik e archi ak del tipo (i1, a1, i2, a2, . . . , ik, ak, . . . , in, an, in+1), dove ak `e l''arco (ik, ik+1) e a1 = an+1. Un viaggio `e euleriano (euler tour ) se contiene ogni arco del grafo G esattamente una volta; se il ciclo contiene ogni arco di G almeno una volta allora `e detto postman tour, ed `e detto covering tour se copre tutti gli archi del grafo G. Un ciclo si dice hamiltoniano se visita una ed una sola volta tutti i vertici del grafo. Diremo che un grafo G `e un grafo euleriano se possiede un ciclo euleriano e, analogamente, diremo che `e un grafo hamiltoniano se possiede almeno un ciclo hamiltoniano. 2.1.2 Capacitated VRP La versione di base del VRP `e detta Capacitated Vehicle Routing Pro- blem (CVRP ). Questa formulazione prevede domande deterministiche e non partizionabili (con corrispondenza univoca tra clienti e consegne), singolo deposito di partenza per ogni consegna e vincoli di capacit`a sui veicoli. L''o- biettivo del problema `e quello di minimizzare i costi, in termini di tempo di servizio o distanza effettiva, servendo tutti i clienti. Il problema pu`o essere cos`ı descritto: ' Sia G = (V, A) un grafo completo dove V `e l''insieme dei vertici e A l''insieme degli archi. I vertici di V 1, . . . , n corrispondono ai clienti e il vertice 0 corrisponde al singolo deposito di partenza. ' Sia c la matrice dei costi, dove cij `e il costo non negativo di percor- renza dell''arco (i, j). L''utilizzo di archi del tipo (i, i) non `e permesso associando un costo cii = +'' per ognuno dei vertici. ' Ad ogni cliente i `e associata una domanda di non negativa. Si impone una domanda nulla per il singolo deposito, sia dunque d0 = 0. ' Sia K l''insieme dei veicoli, ognuno dei quali ha capacit`a C. Assumiamo che di ' C''i = 1, . . . , n e che ogni veicolo possa eseguire al massimo un viaggio. Assumiamo inoltre Kmin '' K 2.1 Formulazione matematica del VRP 21 Se il grafo G `e orientato, la matrice delle distanze sar`a asimmetrica; di- remo quindi che il problema `e di tipo ACVRP (Asymmetric Capacitated VRP). Nella pratica spesso la matrice dei costi soddisfa la disuguaglianza triangolare , cio`e vale cij + cjk ' cik In altre parole percorrendo l''arco tra i vertici i e k, cij `e il costo minimo affrontabile e non conviene intraprendere altri cammini tra i due vertici. Laddove la matrice c dei costi rappresenta la distanza euclidea tra vertici geolocalizzati, avremo una matrice simmetrica che soddisfa la disuguaglianza trinagolare. Questa propriet`a pu`o tuttavia essere violata qualora i valori della matrice c vengano arrotondati all''intero pi` u vicino; in questo caso `e preferibile arrotondare tutti gli elementi di c all''intero superiore. Il valore di Kmin pu`o essere determinato risolvendo il problema del Bin Packing (BPP) associato al CVRP, che determina il minor numero di con- tenitori di capacit`a C richiesto per caricare tutti gli elementi con peso non negativo in un certo insieme. Sebbene il BPP sia NP-arduo `e possibile risol- verne istanze di centinaia di elementi in modo ottimale in tempi accettabili [MT90]. Definiamo il costo di un viaggio come la somma dei costi degli archi attraversati dallo stesso. Il CVRP consiste nell''individuazione di una serie di K viaggi con costo minimo in modo che: ' ogni viaggio parte dal deposito; ' ogni cliente `e visitato da esattamente un circuito; ' la somma delle richieste per vertice (cliente) non ecceda la capacit`a C del veicolo. 22 2. Introduzione al problema del routing, il VRP 2.1.3 Modello di programmazione lineare per CVRP Sia xk ij una variabile binaria cos` ı definita: x k
ij :=    1 se nella soluzione l''arco (i, j) `e percorso dal veicolo k 0 altrimenti (2.1) formuliamo il problema in modo da minimizzare la funzione obiettivo z cos`ı definita, z = min X k''K X (i,j)''A cijxij (2.2) rispettando i seguenti vincoli: X k''K X j''V x k
ij = 1, ''i '' V (2.3) X i''V qi X j''V x k
ij ' Ck , ''k '' K (2.4) X j''V x k oj = 1, ''k '' K (2.5) X i''V x k ih '' X j''V x k hj = 0, ''h '' A, ''k '' K (2.6) X i''V x k i, n + 1 = 1, ''k '' K (2.7) xij '' { 0, 1}, ''i, j '' V (2.8) Il vincolo 2.3 assicura che ogni cliente i sia servito da un singolo veicolo. Il vincolo 2.4 si assicura che la domanda soddisfatta da ogni veicolo non ne ecceda la capacit`a. Il vincolo 2.5 imposta il deposito come punto di partenza per ogni veicolo. Il vincolo 2.6 impone al veicolo il transito sull''arco generico h . Il vincolo ridondante 2.7 conferma la struttura della route imponendo al veicolo il ritorno al nodo fittizio n + 1. Infine il vincolo 2.8 definisce la natura binaria delle variabili xk ij . 2.2 Varianti e metodi risolutivi per il VRP 23 2.2 Varianti e metodi risolutivi per il VRP Il modello matematico del VRP pu`o essere adattato in base alle diverse problematiche poste dai clienti, le quali possono introdurre varianti concer- nenti vincoli, obiettivi, caratteristiche di veicoli, clienti e depositi, o modalit`a di erogazione del servizio. Per quanto riguarda i servizi distinguiamo tra tre differenti tipologie quali la consegna, il ritiro, o entrambi (pick-up and deli- very ). Se il problema prevede un singolo deposito parleremo di single depot VRP , altrimenti si parler`a di multi depot VRP. Si possono introdurre vinco- li sul numero dei veicoli utilizzabili e sulla tipologia dei singoli veicoli. Le funzioni obiettivo possono dipendere dalla lunghezza dei percorsi o da pi` u parametri quali: numero dei viaggi, numero di veicoli impiegati, tempo di percorrenza, costo fisso di veicoli ed autisti. Alcuni vincoli, ricorrenti tra le varie istanze, comprendono inoltre: ' lunghezza massima dei viaggi; ' introduzione di time windows, cio`e di intervalli temporali, nei quali `e possibile erogare un servizio; ' precedenze o priorit`a sui clienti; ' penali per parziale o completa inadempienza; ' vincoli sindacali relativi ad orari, pause o straordinari del personale. 2.2.1 VRP con Time Windows e Formulazione Set Par- titioning Il VRPTW, cio`e VRP con Time Windows, `e, assieme al CVRP, uno dei membri della famiglia del VRP maggiormente studiati. Il VRPTW generaliz- za il CVRP imponendo, per ogni cliente, alcuni intervalli di tempo all''intero dei quali esso deve essere visitato. Questi intervalli sono chiamati Time Windows. Come per il CVRP, anche il VRPTW `e un problema NP-arduo. 24 2. Introduzione al problema del routing, il VRP Il VRPTW `e definito su un grafo completo G = (V 0, A), dove V 0 = 0, 1, ..., n `e un set di n + 1 vertici ed A `e l''insieme degli archi. Il sottinsieme V = V 0\{0} corrisponde all''insieme dei clienti, e il vertice 0 rappresenta, come di consueto, il deposito. Ad ogni vertice i '' V 0 `e associata una ri- chiesta qi, assumendo q0 = 0, e una time window [ei, li], della quale ei e li rappresentano gli estremi dell''intervallo di tempo. La formulazione matematica, sulla quale sono basati alcuni dei migliori metodi esatti di risoluzione del VRPTW, `e la formulazione Set Partitioning, o SP: Sia R l''insieme delle routes ammissibili, e ail, i '' V 0, l '' R un coefficiente binario uguale a 1 se i '' V (Rl), 0 altrimenti (assumendo che a0l = 1, ''l '' R). Ogni route l '' R ha un costo associato cl. Sia xl, l '' R, una variabile binaria che vale 1 se e solo se la route l `e nella soluzione ottima. La formulazione del VRPTW, basata sul modello SP, `e: z (F ) =min X l'' R clxl, (2.9) s.t. X l'' R ailxl = 1, ''i '' V (2.10) X l'' R xl ' m (2.11) xl '' {0, 1}, ''l '' R. (2.12) I vincoli 2.10 specificano che ogni cliente i '' V deve essere visitato da esattamente una route. Il vincolo 2.11 richiede che al massimo m routes siano selezionate. 2.2.2 Metodi risolutivi esatti In quanto generalizzazione del TSP, il VRP `e NP-arduo cio`e, al crescere delle dimensioni dell''input, il tempo di risoluzione cresce esponenzialmente. Nella pratica il VRP (nello specifico la sua formulazione base, il CVRP ) si dimostra significativamente pi` u complesso da risolvere rispetto al TSP. I 2.2 Varianti e metodi risolutivi per il VRP 25 migliori algoritmi esatti per il CVRP raramente possono affrontare istanze che coinvolgono pi` u di 100 vertici; `e noto, invece, che per il TSP vengono risolte all''ottimo istanze da migliaia di vertici in tempi accettabili [BL07]. I metodi pi` u diffusi, per risolvere il VRP all''esatto, fanno uso di algoritmi basati su tecniche di branch-and-bound oppure branch-and-cut. La tecnica branch-and-bound `e una tecnica generale per la risoluzione di problemi di ottimizzazione combinatoria, la quale prevede la scomposizione del problema in sottoproblemi pi` u semplici da risolvere. Le procedure branch-and-bound si possono quindi scomporre in procedure di branching, cio`e di partizione ricorsiva dello spazio di soluzioni ammissibile, e bounding, cio`e di risoluzione dei sottoproblemi generati in fase di branching. Le tecniche di branch-and-cut invece sono tecniche miste di branch-and-bound /piani di taglio; tali tecniche prevedono che, ad ogni nodo dell''albero decisionale, si generino tagli allo scopo di individuare una soluzione intera, oppure, un bound pi` u stretto. La generazione dei tagli viene interrotta laddove questi diventano poco efficaci, effettuando a questo punto un branching. Ad oggi gli algoritmi esatti pi` u efficaci, per la soluzione all''ottimo del CVRP, sono dovuti a Baldacci et al. (2004), Lysgaard et al. (2004), Fukasawa et al. (2006) e Baldacci et al. (2008). Baldacci et al. (2004) descrivono un algoritmo branch-and-cut (bc) basato su una formulazione matematica con due tipi di variabili di flusso. Lysgaard et al. (2004) hanno proposto un algoritmo bc che `e un miglioramento del metodo porposto da Augerat et al. (1995). Il metodo Fukasawa et al. (2006) combina la bc di Lysgaard et al. (2004) con un nuovo algoritmo di tipo branch-and-cut- and-price (BCP), basato su formulazioni a due indici e sulla formulazione Set Partitioning (SP). Il lower bound `e calcolato con un metodo di tipo column and cut generation che utilizza il rilassamento q-routes, introdotto da Christofides, Mingozzi, Toth (1981), anzich´e i percorsi elementari e le disuguaglianze valide , proposte da Lysgaard et al. (2004). L''algoritmo decide al nodo radice se utilizzare il bc di Lysgaard et al. (2004), o l''algoritmo BVCP. Baldacci et al. (2008) ha presentato un algoritmo basato sul modello 26 2. Introduzione al problema del routing, il VRP SP rinforzato con disuguaglianze di capacit`a e clique. Questi ultimi autori sono stati i primi a calcolare lower bounds basati sull''uso di percorsi elementari. L''algoritmo di Baldacci et al. (2008) non `e in grado di risolvere tre problemi risolti da Fukasawa et al. (2006), ma `e notevolmente pi` u veloce sui problemi risolti da entrambi i metodi. Baldacci et al. (2012) descrivono il metodo pi` u efficace, pubblicato in letteratura finora, per risolvere sia il CVRP, che il Vehicle Routing Problem con Time di Windows (VRPTW). Questo metodo migliora quello proposto da Baldacci et al. (2008) per il CVRP, basandosi sul modello SP del problema, ed introducendo un nuovo rilassamento dei percorsi elementari, denominato ng-route , utilizzato da diverse euristiche, per calcolare diverse soluzioni duali quasi ottime, del rilassamento lineare della formulazione SP. Essi descrivono un algoritmo column-and-cut-generation per calcolare il lower bound, raffor- zato da disuguaglianze valide, che utilizza una nuova strategia per risolvere il problema del pricing (generazione di nuove colonne). Il nuovo rilassamen- to ng-route, e le diverse soluzioni duali ottenute, permettono di generare un problema di SP ridotto, contenente tutte le soluzioni ottime, il quale `e risolto da un solutore di programmazione intera. Il metodo proposto risolve 4 dei 5 problemi di VRPTW precedentemente non risolti, e migliora significativa- mente i tempi di calcolo degli algoritmi esistenti, sia per VRPTW, che per CVRP. Il primo algoritmo esatto per il VRPTW, basato sulla formulazione SP, `e stato proposto da Desrochers et al. (1992). Questo metodo `e stato in seguito migliorato da Kohl et al. (1999), aggiungendo le disuguaglianze 2-path al rilassamento lineare della formulazione SP. Kohl e Madsen (1997) hanno proposto un algoritmo di branch-and-bound, dove il lower bound vie- ne calcolato con il sottogradiente. Irnich e Villeneuve (2006) descrivono un algoritmo branch-and-price, dove il sottoproblema pricing `e risolto utilizzan- do il metodo dei q-path, con eliminazione di cicli di k vertici consecutivi. Algoritmi basati sul calcolo dei percorsi elementari sono stati proposti dalla Feillet et al. (2004) e Chabrier (2006). 2.2 Varianti e metodi risolutivi per il VRP 27 Jepsen et al. (2008) descrivono un bcp, basato sul modello SP rafforza- to da nuove disuguaglianze denominate Subset Row(SR). Questo metodo `e stato migliorato da Desaulniers et al. (2008), con l''aggiunta di una euristi- ca tabu-search per la generazione rapida di routes di costo ridotto negativo. Questo metodo domina tutti gli altri algoritmi precedentemente pubblicati, riducendo notevolmente il tempo di calcolo, e risolvendo 5 delle 10 istanze non risolte del VRPTW. In generale qualsiasi algoritmo esatto per la VRPTW pu`o essere facil- mente adattato per risolvere il CVRP, semplicemente rilassando i vincoli imposti dalle time windows. Tuttavia, tale semplice adattamento, potrebbe non essere efficace, e nessuno dei metodi finora pubblicati in letteratura per la VRPTW ha dimostrato di risolvere efficacemente il CVRP. In conclusione l''unico metodo esatto pubblicato ad oggi in letteratura che risolve sia il CVRP ed il VRPTW e che domina tutti gli altri metodi `e quello proposto da Baldacci, Mingozzi e Roberti (2012). 2.2.3 Metodi euristici Gli algoritmi euristici forniscono, per problemi complessi, soluzioni sub- ottime in tempi relativamente brevi. Tali soluzioni, seppur non ottime, so- no accettabili e rappresentano, per certe dimensioni dell''input di problemi complessi come il VRP, le uniche soluzioni che si possono ottenere con li- mitati tempi di calcolo. Gli euristici classici, proposti per il problema del VRP , si possono suddividere in metodi costruttivi (o route construction me- thods ), metodi a due fasi (two-phase methods), e metodi migliorativi (route improvement methods ). Gli algoritmi route construction heuristics partono tipicamente da una soluzione vuota e costruiscono iterativamente nuovi viaggi inserendo uno o pi` u clienti alla volta, fino a che tutti i clienti sono serviti. Gli algoritmi costruttivi sono caratterizzati principalmente da tre caratteristiche: i criteri di inizializzazione, i criteri di selezione dei clienti, e i criteri di selezione della posizione del cliente nella route in costruzione. 28 2. Introduzione al problema del routing, il VRP Gli algoritmi two-phase heuristics si basano sulla scomposizione del processo di risoluzione in due sottoproblemi: clustering, cio`e la determina- zione di sottinsiemi di clienti corrispondenti ad un viaggio, e routing, cio`e la determinazione della sequenza con la quale i clienti vengono serviti in ogni viaggio. Negli euristici a due fasi che prevedono inizialmente la fase di clustering (metodi cluster-first-route-second ) la fase di clustering pu`o essere variabile da algoritmo ad algoritmo, mentre la seconda fase si riduce alla risoluzione del TSP. Gli algoritmi route improvement heuristics sono algoritmi a ricerca locale, spesso utilizzati per migliorare soluzioni iniziali, non necessariamente ammissibili, generate da altri euristici. Ad ogni iterazione dell''algoritmo vengono apportate semplici modifiche alla soluzione, come lo scambio di archi o lo scambio di clienti tra i viaggi, allo scopo di ottenere soluzioni locali di costo inferiore. Laddove la nuova soluzione elaborata migliora il costo della soluzione iniziale, allora questa diventa la nuova soluzione al problema, altrimenti la soluzione iniziale viene dichiarata minimo locale. Data la mancanza di garanzie, per quanto riguarda la qualit`a delle so- luzioni fornite da algoritmi euristici, la valutazione delle loro performance `e ottenta empiricamente, confrontandone i risultati computazionali ottenuti, su insiemi di problemi di benchmark. Attualmente, la maggior parte dei pro- blemi reali di routing vengono risolti utilizzando algoritmi euristici, a causa della loro velocit`a e la loro capacit`a di gestire grandi istanze. Tradizione vuo- le che, nel risolvere problemi reali, venga impiegata una funzione obiettivo di tipo gerarchico. La prima priorit`a `e di minimizzare il numero dei veicoli utilizzati e la seconda `e di minimizzare il costo dei percorsi effettuati. Ci`o differisce dagli algoritmi esatti, i quali non considerano il numero di veicoli usati nella funzione obiettivo. 2.2.4 Metodi metaeuristici Negli ultimi dieci anni la ricerca sui metodi euristici per il CVRP e il VRPTW si `e concentrato sulle metodologie metaeuristiche. Gli algoritmi 2.2 Varianti e metodi risolutivi per il VRP 29 metaeuristici possono essere considerati un naturale miglioramento degli eu- ristici classici. Gli approci metaeuristici esplorano le regioni pi` u promettenti dello spazio delle soluzioni, spostandosi iterativamente tra i vicini delle solu- zioni trovate, finch´e esse non soddisfano un certo criterio d''interruzione. Al- cuni metaeuristici prendono in considerazione anche soluzioni non ammissibili e fasi non migliorative. La qualit`a delle soluzioni prodotte da questi algoritmi `e generalmente molto pi` u grande di quella ottenuta con le euristiche classiche ma, in alcuni casi, ci`o comporta tempi di calcolo pi` u lunghi. Si consideri inoltre che l''uti- lizzo di metaeuristici `e spesso dipendente dal contesto, per questo si richiede una raffinata parametrizzazione delle procedure affinch´e questi si adattino alle varie situazioni [TV02]. ` E possibile distinguere tre classi di metaeuristici: ' Metodi a ricerca locale come simulated annealing, deterministic an- nealing, e tabu search; questo tipo di algoritmi prende in considera- zione una soluzione iniziale ammissibile e, ad ogni iterazione, passa ad una soluzione appartenente all''insieme dei neighbors (vicini) finch´e non viene soddisfatto un certo criterio di arresto. Soluzioni trovate duran- te iterazioni successive non sempre sono migliorative, ci`o favorisce la diversificazione ed evita lo stallo intorno ai minimi locali. ' Algoritmi genetici, o population search; questo genere di algoritmi con- sidera ad ogni iterazione una popolazione di soluzioni. Ogni popola- zione `e derivata dalla precedente tramite ricombinazione delle soluzioni migliori ed eliminazione delle peggiori. ' Sistemi esperti, come le reti neurali ed ant systems; nelle reti neu- rali vengono sfruttati meccanismi di auto-regolazione dei coefficienti interni per individuare soluzioni migliori. Gli ant systems invece pro- ducono, ad ogni iterazione, numerose soluzioni, derivate a loro volta, da informazioni raccolte durante le iterazioni precedenti. 30 2. Introduzione al problema del routing, il VRP 2.2.5 Metaeuristici a ricerca locale Il concetto di ricerca locale `e centrale nella discussione delle metodologie metaeuristiche per la risoluzione del VRP. Queste metodologie prevedono il calcolo di una soluzione iniziale, la quale viene via via migliorata, fino alla soddisfazione di un certo criterio d''arresto. Sia t una generica iterazione di un algoritmo metaeuristico, e sia xt la soluzione ad essa associata. Sia N (xt) l''insieme dei vicini (neighbors) di xt, individuati tramite una funzione neighborhood definita. Le funzioni di neighborhood possono essere classificate come segue: ' Intra-route, in cui viene modificata una singola route della soluzione; ' Inter-route, in cui uno o pi`u clienti vengono spostati fra due o pi`u routes; ' LNS, cio`e Large neighborhood search, per i quali si introducono gli operatori destroy e repair. L''operatore destroy disintegra una soluzio- ne, ad esempio rimuovendo uno o pi` u clienti dalle routes, mentre l''ope- ratore repair ricostruisce una soluzione completa, reinserendo i clienti precedentemente rimossi dalle routes. Questi due operatori vengono ripetuti iterativamente per un numero massimo di iterazioni, oppure fino a quando non `e possibile migliorare la corrente soluzione. Individuato l''insieme dei N (xt), dei neighbors della soluzione xt, si pro- cede con la selezione della soluzione xt+1. A questo scopo si illustreranno tre metodologie che comprendono simulated annealing, deterministic annealing, e tabu search. Indichiamo con f (xt) il costo della soluzione xt, e sia f (xt+1) il costo della soluzione xt+1 '' N (xt) calcolata all''iterazione t + 1. Nel simulated annealing viene selezionata casualmente una soluzione x nell''insieme N (xt) e, se f (x) ' f (xt), allora xt+1 := x, altrimenti, 2.2 Varianti e metodi risolutivi per il VRP 31 xt+1 :=    x con probabilit`a pt, xt con probabilit`a 1 '' pt, dove pt `e una funzione di probabilit`a calcolata come pt = exp  '' f (x) '' f (xt) θt  e θt `e una funzione di t chiamata temperatura all''iterazione t. Tale funzio- ne `e parametrizzata nell''algoritmo e decrescente con t, allo scopo di ridurre la probabilit`a di selezionare soluzioni peggiorative al crescere di t. Consideran- do che non vale necessariamente f (xt+1) < f (xt), gli algoritmi di simulated annealing devono implementare meccanismi per evitare cicli infiniti. I criteri d''arresto valutati possono comprendere: ' il numero di cicli durante i quali il valore f(x''), cio`e il costo della migliore soluzione attuale, non diminuisce; ' il numero di mosse accettate, inteso come il numero di volte in cui la soluzione xt viene sostituita con la soluzione x trovata casualmente, il quale deve superare una certa percentuale prefissata durante le ultime iterazioni; ' il numero totale di iterazioni eseguite. Il deterministic annealing si differenzia dal simulated annealing nei criteri di scelta delle soluzioni, le quali vengono selezionate in modo determi- nistico anzich´e casuale. Tali criteri possono essere di tipo: ' threshold accepting, per il quale la soluzione x `e accettata se f(x) < f (xt) + θ1, dove θ1 `e un parametro controllato dall''utente; ' record to record travel, per il quale, definita x'' come la miglior soluzione trovata, x viene accettata se f (x) < θ2f (x''). Anche in questo caso θ2 `e un parametro controllato dall''utente. 32 2. Introduzione al problema del routing, il VRP Nel tabu search, la ricerca `e deterministica e avviene all''interno di un sottinsieme dei vicini N (xt). Ad ogni soluzione valutata durante un''iterazio- ne, viene assegnato un attributo che ne proibisce la selezione per un certo intervallo di iterazioni; tali soluzioni diventano cos`ı soluzioni tabu. L''itera- zione termina con la selezione della migliore soluzione non proibita in N (xt). Grazie a questo meccanismo vengono evitati cicli infiniti e stazionamenti intorno a minimi locali. I migliori algoritmi metaeuristici, che usano le funzioni neighborhood so- pra descritte, sono dovuti a Bent and Van Hentenryck [BH04], Mester and Br¨aysy [MB05], Pisinger and Ropke [PR07], Lim and Zhang [LZ07], Hashi- moto, Yagiura and Ibaraki [HHI08], Hashimoto and Yagiura [HY08], Ibaraki et al. [IIN+08], Repoussis, Tarantilis and Ioannou [PRI09], Prescott-Gagnon, Desaulniers and Rousseau [EPGR09], Nagata and Br¨aysy [NB09], Nagata, Br¨aysy and Dullaert [YND10], Vidal et al. [TVP11], Blocho and Czech [BC12], CM Cordeau and Maischberger [CM12]. Capitolo 3 Approccio alla fase realizzativa L''approccio alla fase realizzativa pone problematiche di tipo organizzativo relative alla gestione del team, dei cicli di sviluppo, delle metodologie con le quali questi vengono affrontati, e agli strumenti di sviluppo impiegati. Saranno cos`ı introdotti il framework Scrum, tramite il quale vengono organizzati i cicli di lavoro, le pratiche di TDD e CI, con le quali si articolano le attivit`a di sviluppo, e la suite di strumenti messi a disposizione dei singoli sviluppatori. 3.1 Metodologie di sviluppo, Scrum Per la gestione dei cicli di sviluppo di NST `e stato scelto di operare secondo una modalit`a agile, facendo uso del framework lightweight Scrum. Scrum consiste in un insieme di pratiche e regole interrelate che ottimizzano l''ambiente di sviluppo, sincronizzando i requisiti emergenti dal cliente con prototipi iterativi, mantenendo ridotto l''overhead organizzativo (da cui il termine lightweight, cio`e leggero). Il metodo Scrum segue un approccio incrementale allo sviluppo del soft- ware, organizzando il lavoro in Sprint, cio`e rapidi cicli di lavoro di 2-4 setti- mane, dove si crea un incremento di prodotto potenzialmente consegnabile, composto di funzionalit`a eseguibili e testate. L''idea di base `e dunque quella di 33 34 3. Approccio alla fase realizzativa apportare continue modifiche al prodotto al fine di farlo evolevere secondo un approccio empirico; l''utilizzo di Scrum si rivela particolarmente utile laddove le specifiche del software rendono complicata una pianificazione preventiva delle operazioni di progettazione e sviluppo, come nel caso di NST. La reale durata degli Sprint `e decisa dal team di lavoro, in base alle atti- vit`a prese in considerazione per il ciclo di lavoro in esame. L''identificazione delle attivit`a che fanno parte di uno Sprint derivano dalla selezione di una serie di documenti dette storie. Le storie sono brevi estratti del documen- to delle specifiche funzionali, stilato durante la fase preliminare di analisi, e descrivono sinteticamente i bisogni del cliente. Le storie possono compren- dere casi d''uso individuati in fase di analisi, oppure migliorie e interventi incrementali richiesti in corso d''opera. L''insieme delle storie `e detto product backlog . Gli attori principali di questo approccio sono: ' gli sviluppatori, o scrum team; ' un coordinatore detto scrum master; ' un product owner che rappresenta il cliente finale durante i confronti sui vari aspetti dell''analisi dei requisiti. Compito del product owner `e anche quello di assegnare alle varie storie una priorit`a in base alle esigenze dei committenti (stakeholders), costituendo di fatto il product backlog. Prima dell''inizio di uno sprint si procede ad uno sprint planning mee- ting, cio`e una riunione del team di sviluppo, presieduta dallo Scrum master e in presenza del product owner. Durante gli sprint planning meeting ven- gono selezionate, dal product backlog, le storie sulle quali organizzare le attivit`a di sviluppo. Tali attivit`a possono comprendere analisi, progettazio- ne o implementazione; in pratica, ogni sprint `e composto da fasi di analisi, progettazione ed implementazione, limitate ad un certo subset di specifiche del programma. 3.1 Metodologie di sviluppo, Scrum 35 Figura 3.1: Scrum Agile BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV PRODUCTCBACKLOG BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV BACKLOG STORY
LoremCipsumCdolorCsitCametYC consecteturCadipisicingCelitYCsedC doCeiusmodCtemporCincididuntCutC laboreCetCdoloreCmagnaCaliquaVCUtC enimCadCminimCveniamYCquisC nostrudCexercitationCullamcoC laborisCnisiCutCaliquipCexCeaC commodoCconsequatVCDuisCauteC irureCdolorCinCreprehenderitCinC voluptateCvelitCesseCcillumCdoloreC euCfugiatCnullaCpariaturVCExcepteurC sintCoccaecatCcupidatatCnonC proidentYCsuntCinCculpaCquiCofficiaC deseruntCmollitCanimCidCestC laborumV SPRINTCBACKLOG SPRINT 'M4Csettimane DAILYCSCRUM giornaliero NUOVAC FUNZIONALIT'CFCPRODOTTO PRODUCTCOWNER SCRUMCTEAM SPRINTCREVIEWY SPRINTCRETROSPECTIVE SCRUMCMASTER Al termine di ogni sprint il team si riunisce per una sprint review, du- rante la quale, ogni sviluppatore effettua una demo del prodotto elaborato durante lo sprint. Lo scopo delle review `e quello di permettere allo Scrum master di individuare eventuali intoppi o impedimenti che influiscono sul lavoro del gruppo o dei singoli membri dello stesso. Scrum prevede inoltre alcune retrospettive (Sprint retrospective), il cui scopo `e quello di individua- re potenziali miglioramenti, individuando i punti forti e i punti deboli nello sprint, in un''ottica di continuo miglioramento del processo di delivery del software. Nel caso di NST sono stati individuati due analisti esperti allo scopo di coprire i ruoli di Scrum master e product owner ; per quest''ultimo ruolo in particolare `e richiesta una notevole esperienza nel dominio dei trasporti, in quanto l''analista deve poter prevedere le richieste di clienti che operano in campi differenti della logistica. La scelta di un analista interno come product owner `e dovuta alla natura generica del software; questo, infatti, non `e svi- luppato in modo specifico, cio`e per coprire le esigenze di un singolo cliente, ma piuttosto come prodotto di larga diffusione, mirato cio`e, alla risoluzione di problemi riconducibili alla pianificazione dei trasporti ed, eventualmente, adattabile a singoli clienti tramite l''introduzione di moduli verticali. 36 3. Approccio alla fase realizzativa Figura 3.2: Fasi del Test Driven Development TEST FALLITI TEST PASSATI REFACTOR AGGIUNTA TEST SCRITTURA CODICE REFACTORING DEL CODICE 3.2 Test Driven Development e Continous In- tegration Il Test Driven Development (abbreviato in TDD) `e un processo di svilup- po del software, nel quale la stesura delle procedure funzionali, `e preceduta (driven) dalla stesura di test automatici. Il TDD si articola in cicli di sviluppo composti da tre fasi: ' Red, cio`e la prima fase, prevede che lo sviluppatore scriva un test au- tomatico per la funzionalit`a da implementare. Tale test fallir`a neces- sariamente in quanto creato preventivamente all''implementazione della funzionalit`a stessa. ' Green, durante questa seconda fase lo sviluppatore scrive la quantit`a minima di codice necessaria al superamento del test. ' Refactor, la terza fase prevede il refactoring del codice, cio`e la sua ristrutturazione. I vantaggi apportati dal TDD riguardano l''affidabilit`a, la solidit`a e la pulizia del codice. La solidit`a `e garantita dai test stessi che vengono ge- 3.2 Test Driven Development e Continous Integration 37 neralmente ripetuti in seguito ad ogni build, garantendo cos`ı che il nuovo codice introdotto non abbia ripercussioni su procedure scritte precedente- mente. La necessit`a di scrivere un test prima della stesura del codice aiuta lo sviluppatore nella comprensione delle specifiche, facendo inoltre emergere preventivamente eventuali errori, incomprensioni o inesattezze, nelle speci- fiche stesse, migliorando quindi l''affidabilit`a del codice. Infine i continui refactoring danno luogo ad un codice pi` u pulito. La Continous Integration (abbreviato CI ) `e una pratica, complemen- tare al TDD, che consiste nel frequente allineamento degli ambienti di svilup- po dei singoli sviluppatori, con la mainline, cio`e l''ambiente condiviso. Scopo del processo di Continuous Integration `e aumentare la qualit`a del software eseguendo in modo continuo, durante tutto il ciclo di sviluppo, i controllo di qualit`a e correttezza del codice, che solitamente sono rimandati dopo la fase di rilascio. La realizzazione di un progetto software complesso richiede lo sviluppo di numerosi moduli software, legati tra loro e interdipendenti. In questo contesto di continua evoluzione `e fondamentale mantenere il controllo delle variazioni apportate al codice verificando che: ' siano rispettate le dipendenze con gli altri moduli; ' sia sempre possibile realizzare una build di tutto il sistema; ' i test automatici, associati ai singoli moduli o a livello di sistema, abbiano successo. La Continuous Integration prevede innanzitutto la centralizzazione del repository dei sorgenti, tramite l''utilizzo di un sistema di versioning dei sor- genti, e l''utilizzo di un sistema, detto CI server, che effettui in automatico la compilazione di tutto il codice e l''esecuzione dei test. ` E richiesto agli svilup- patori di ridurre il lasso di tempo in cui tengono in locale una copia modificata dei sorgenti, per limitare i rischi di conflitti e disallineamenti rispetto la ver- sione del repository centrale. Ad ogni aggiornamento dei sorgenti effettuato dagli sviluppatori, il sistema: effettua una compilazione dell''ultima versione 38 3. Approccio alla fase realizzativa dei sorgenti, esegue in un ambiente di collaudo tutti i test automatici, uni- tari, e di integrazione, e notifica agli sviluppatori l''esito della compilazione e dei test. La scrittura di test sulle singole unit`a software (unit tests) avviene tra- mite l''utilizzo del Test Framework di Microsoft, ed `e effettuata per tutte le principali procedure. Un esempio di unit test `e dato dal frammento di codice 3.2, nel quale `e possibile notare l''utilizzo di alcune annotazioni che marcano i metodi di test. Tali annotazioni possono influenzare l''ordine o le modalit`a con le quali i metodi di test vengono richiamati. [ TestClass ] p u b l i c c l a s s UserProfileTest { [ TestMethod ] [ TestCategory ( ' UILayer ' ) , TestCategory ( ' UserAccount ' ) ] p u b l i c v o i d RegisterNewUser ( ) { // c r e a z i o n e d e l componente da t e s t a r e AccountController controller = new AccountController ( ) ; // C r e a z i o n e d i m o d e l l o d a t i RegisterModel rm = new RegisterModel ( ) ; rm . Password = rm . ConfirmPassword = ' P a s s w o r d C o m p l e s s a 1 2 3 4 5 6 7 8 9 ' ; rm . UserName = ' Mario R o s s i ' ; // t e s t d e l metodo d i r e g i s t r a z i o n e u t e n t i ViewResult result = controller . Register ( rm ) a s ViewResult ; } } 3.3 Strumenti di sviluppo Al fine di fornire ai membri del team un ambiente di sviluppo uniforme, sono stati selezionati una serie di strumenti, per lo svolgimento delle attivit`a di sviluppo del software. Gli strumenti individuati comprendono: macchi- ne virtuali, ambienti di sviluppo integrati (IDE ), sistemi di versioning, CI server, etc. I principali vantaggi, derivanti dall''utilizzo di questi strumenti, sono: 3.3 Strumenti di sviluppo 39 ' condivisione del know how ' interoperabilit`a, grazie all''utilizzo di formati dati ben definiti e me- todologie di sviluppo comuni a tutti i membri del team; ' fast recovery, cio`e recupero veloce da eventuali malfunzionamenti, minimizzando il tempo di improduttivit`a. ' riduzione dei tempi allineamento per l''eventuale introduzione di nuovi membri nel team di progetto. 3.3.1 Macchina virtuale di sviluppo Ai membri del team di sviluppo del progetto NST, `e stata fornita una macchina virtuale, basata su Microsoft Windows7, operata tramite l''u- tilizzo della piattaforma VMWare player. VMware Player `e un software freeware di virtualizzazione, il quale permette di creare ed eseguire macchine virtuali, allocando risorse della macchina fisica in modo arbitrario. La mac- china virtuale `e preconfigurata ed ospita gi`a il software di sviluppo, fornendo agli sviluppatori, un''ambiente funzionante e standardizzato per l''approccio al progetto. I vantaggi addotti comprendono: ' in breve tempo si permette allo sviluppatore di cominciare a lavorare sul prodotto, abbattendo i tempi di installazione degli strumenti di sviluppo; stesso discorso in caso di danneggiamento, e sostituzione, della macchina fisica; ' eventuali malfunzionamenti o infezioni di malware, sulla macchina vir- tuale, non compromettono la macchina fisica, la quale pu`o ospitare una nuova macchina virtuale funzionante, senza costringere gli sviluppatori a interventi tecnici di ripristino; 40 3. Approccio alla fase realizzativa ' la macchina virtuale non impone l''utilizzo di uno specifico sistema ope- rativo, o particolare hardware, sull''host, adattandosi in pratica ad ogni macchina fisica messa a disposizione degli sviluppatori; ' l''applicazione di pratiche di pair programming (programmazione in coppia) `e particolarmente facilitata, in quanto, gli sviluppatori che ri- coprono il ruolo di observer (osservatore), riconoscono immediatamente l''ambiente di sviluppo e possono collaborare senza particolari sforzi. Periodicamente vengono effettuati degli snapshot delle macchine virtuali, cio`e ne viene salvato lo stato, i dati e la configurazione hardware, allo scopo di mantenere un backup sempre aggiornato e funzionante. 3.3.2 Versioning del codice sorgente Il controllo di versione (o versioning) `e, in informatica, la gestione di versioni multiple di un certo insieme di informazioni, riferito in genere al codice sorgente di un applicativo. Per effettuare il controllo di versione di un progetto `e necessario configurare un Repository, cio`e una banca dati centralizzata, che ne ospita i documenti. Il repository `e organizzato in Re- vision, cio`e revisioni, o versioni delle informazioni, memorizzate in catena di modifiche. I moderni sistemi di versioning prevedono che ogni contributo- re intervenga su un set di dati proprio, detto copia locale, propagando le modifiche effettuate, al repository centralizzato, solo in un secondo momento. Un sistema di controllo di versione permette di applicare le pratiche di versioning a progetti informatici, fornendo strumenti per effettuare: ' commit, cio`e propagazione delle modifiche effettuate sui documenti verso il repository centralizzato; ' update, cio`e la sincronizzazione della copia locale con il repository; ' merge, cio`e l''integrazione, in una versione unificata, di modifiche pro- venienti da versioni concorrenti; 3.3 Strumenti di sviluppo 41 ' import, cio`e l''importazione dell''intera copia locale sul repository; ' export, cio`e l''esportazione, di una versione del progetto, dal repository verso una destinazione esterna; ' individuazione e risoluzione dei conflitti, che avviene quando modifiche concorrenti sullo stesso set di dati si sovrappongono; L''utilizzo di un sistema di versioning `e fondamentale per le pratiche di CI . Il sistema di versioning impiegato per il progetto NST `e Subversion, o semplicemente SVN, il quale permette di effettuare: ' versioning di file di testo e file binari; ' versionamento delle directories, mantenendo traccia della struttura con la quale sono organizzati i sorgenti; ' commits atomici, cio`e l''applicazione di un insieme di modifiche in una singola operazione, evitando la generazione di versioni incomplete; ' accesso al repository tramite protocollo HTTP; ' branching, cio`e la separazione di intere versioni dalla mainline del progetto; ' etichettamento o tagging delle versioni, allo scopo di distinguere particolari revisioni; Il modello di versionamento applicato da Subversion `e detto Copy-Modify- Merge, il quale a differenza del modello Lock-Modify-Unlock, prevede che i file in fase di modifica rimangano disponibili anche agli altri sviluppatori, rimandando l''eventuale gestione dei conflitti alla fase di propagazione delle modifiche. Questo approccio, detto anche approccio ottimistico, `e partico- larmente efficace nello sviluppo in team, in quanto non ostacola il lavoro parallelo sui sorgenti. 42 3. Approccio alla fase realizzativa 3.3.3 IDE, ambiente di sviluppo integrato L''IDE impiegato per lo sviluppo di NST `e Microsoft Visual Studio 2012. Visual Studio fornisce gli strumenti necessari alla stesura del codice, alla compilazione, all''integrazione con librerie esterne, ed all''organizzazione dei sorgenti. La versione 2012 di Visual Studio introduce l''utilizzo dell''in- terfaccia Metro (5.2), supporto ad HTML 5 e CSS 3, cos`ı come per le ul- time tecnologie ASP.NET, tra le quali MVC4, largamente impiegate per lo sviluppo di NST (5.4). I sorgenti dell''applicazione sono organizzati in una solution, nella quale sono organizzati a loro volta i vari progetti che costituiscono i vari layer applicativi (4.1.1). Visual Studio fornisce `e ben integrato con il sistema di versioning del codice SVN, permettendo di mantenere rapidamente allineata l''intera soluzione software. 3.3.4 CI server Il sistema scelto per la gestione del processo di CI in NST `e TeamCity di JetBrains. TeamCity `e un software scritto in Java che espone un''interfaccia web tramite la quale `e possibile configurare i processi di compilazione, test e interfacciamento con sistemi di versioning. Integrabile con Visual Studio, NuGet (gestore di package per .NET, in- tegrato in Visual Studio) e SVN, TeamCity permette di eseguire, in maniera automatizzata, build e test per ogni commit sulla mainline. Il software for- nisce inoltre strumenti per l''ispezione del codice e l''individuazione di codice duplicato. In caso di fallimento dei tests, TeamCity `e in grado di segnalare inviare un report dettagliato agli sviluppatori via e-mail. 3.3 Strumenti di sviluppo 43 Figura 3.3: Una schermata di configurazione progetto di TeamCity Capitolo 4 Architettura del sistema Definiamo architettura di un software l''organizzazione basilare di un si- stema, il quale `e rappresentato dalle sue componenti, dalle relazioni che esi- stono tra di loro e l''ambiente circostante, e dai principi che governano la sua progettazione ed evoluzione [IEE00]. Tra le molte roblematiche da affrontare, nello sviluppo dell''architettura di un''applicazione aziendale, le pi` u importanti sono: ' La stratificazione dell''applicazione, cio`e la suddivisione delle funziona- lit`a in aree indipendenti e intercomunicanti tramite interfacce; ' La strutturazione della logica applicativa; ' La persistenza degli oggetti attraverso un database; ' La gestione dello stato delle sessioni in un ambiente stateless; ' La strutturazione dell''interfaccia utente; ' I principi di distribuzione; Si devono inoltre considerare problemi riguardanti la validazione dei da- ti, la tipologia di comunicazione sincrona/asincrona, la gestione dei dati di interscambio, la sicurezza, la gestione di errori/eccezioni, la suddivisione dei dati e l''integrazione con applicativi esterni [Fow02]. 45 46 4. Architettura del sistema In questo capitolo si introdurranno alcune delle soluzioni architetturali impiegate e come esse risolvono le problematiche illustrate. 4.1 Stratificazione e Multi-tier architecture La stratificazione `e una tecniche basata sulla filosofia divide et impera e viene usata dai software designers per suddividere sistemi software comples- si. Le architetture software basate sulla stratificazione sono dette n-tier, o multi-tier , oppure multi-strato. Un esempio pratico, e ampiamente diffuso, di questa pratica `e rappresentato dallo standard ISO/OSI (Open System In- terconnection) , cio`e il modello di pila protocollare dalla quale sono derivate le reti moderne. Internet stessa `e basata sulla suite di protocolli TCP/IP, la quale pu`o a sua volta essere rappresentata tramite il modello OSI. Questo tipo di suddivisione in strati (altrimenti detti layers) comporta una serie di vantaggi: ' ogni layer rappresenta un insieme coerente di funzionalit`a, le quali rispondono ad un insieme limitato di problematiche; ' ogni layer incapsula l''implementazione dei servizi forniti, nascondendo la propria complessit`a agli strati adiacenti; ' le dipendenze tra gli strati sono minimizzate, facendo s`ı che ogni layer sia intercambiabile, al solo costo di rispettare le interfacce degli strati adiacenti; ' la suddivisione in layer incoraggia la riusabilit`a, permettendo a volte, di riutilizzare gli strati in altri applicativi con una quantit`a minima di interventi sul codice. L''applicazione della stratificazione introduce anche alcune complicazioni inerenti le prestazioni del sistema e la possibilit`a di modifiche a cascata. I problemi di prestazioni sono principalmente legati alla necessit`a di passare da una rappresentazione dei dati, strettamente legata ad uno strato, verso 4.1 Stratificazione e Multi-tier architecture 47 un''altra, fruibile da uno strato differente. Sebbene tale operazioni spesso si riduce ad una semplice mappatura, tra diverse istanze di oggetti, diventa onerosa al crescere della quantit`a di dati in transito dallo strato. Il problema delle modifiche a cascata dipende, invece, dall''impossibilit`a di incapsulare tutte le operazioni in modo ottimale. Il risultato che ne deriva `e che mo- difiche, anche semplici e inerenti un singolo strato, si propagano agli strati adiacenti. Un esempio di questo `e l''aggiunta, in un''entit`a della base dati, di un campo che vogliamo mostrare anche nell''interfaccia utente, e che dovremo quindi aggiungere in tutti gli strati intermedi. 4.1.1 La stratificazione di NST NST presenta un''architettura multi-strato, nella quale ogni livello opera indipendentemente dagli altri, incapsulando i dettagli di implementazione del servizio fornito, ed esponendo interfacce, metodi ed oggetti, tramite il quale pu`o essere interrogato dagli altri livelli. Questa pratica favorisce la separation of concerns , cio`e il principio per cui ogni componente software deve potersi concentrate sul suo obiettivo primario, senza preoccuparsi di come sono implementati i servizi dal quale dipende. Il vantaggio derivante da questa separazione `e un incremento della manutenibilit`a, della modularit`a, della scalabilit`a e dell''incrementabilit`a del software. L''architettura di NST `e una generalizzazione della classica architettu- ra a tre strati. L''architettura a tre strati, anche detta 3-tier architecture, suddivide le funzionalit`a del software in tre differenti unit`a: ' interfaccia utente, o UI layer, la quale si occupa dell''interazione con l''utente e della presentazione dei dati; ' lo strato logico, o business layer, il quale si occupa di incapsulare la logica decisionale, i comportamenti e i calcoli sulle entit`a del dominio applicativo; ' lo strato di persistenza, o data layer, il quale supporta la memorizza- zione e il recupero dei dati dell''applicativo. 48 4. Architettura del sistema Il data layer di NST `e composto da un database relazionale, o RDBMS, e da un ORM (Object Relational Mapping), cio`e da un software che favorisce l''integrazione tra un database relazionale e la struttura ad oggetti del sistema. Altro vantaggio indotto dall''utilizzo di un ORM `e la possibilit`a di astrarre le caratteristiche implementative dello specifico RDBMS utilizzato, rendendo di fatto, la base dati intercambiabile. Il business layer, oltre che fornire servizi relativi alle entit`a del dominio verso lo strato di interfaccia, incapsula le interfacce di accesso a servizi esterni e le logiche decisionali. L''UI layer comprende tutte le procedure, i modelli dati e i servizi che permettono l''interazione cn l''utente; trattandosi di interfaccia web, questo strato `e ulteriormente suddiviso in: server-side, cio`e l''insieme di componenti software elaborati dall''infrastruttura server, e client-side, cio`e quell''insieme di script, dati e documenti di layouts eseguiti dal client. NST comprende infine uno strato verticale, detto common layer, che contiene una serie di classi, le quali funzionalit`a sono condivise tra tutti gli altri layer. Questo strato implementa funzionalit`a di uso comune come l''infrastruttura di logging, metodi di utilit`a per la manipolazione dei dati, eccezioni personalizzate, ed una serie di classi per l''integrazione di plugins e moduli aggiuntivi. Il common layer comprende infine un insieme di oggetti leggeri, detti Data transfer objects o DTO, utili per il trasferimento di entit`a complesse all''interno e all''esterno dell''applicativo. Ognuno di questi layer `e compilato come assembly indipendente ed espone agli altri layer solamente i metodi pubblici che gli permettono di interfacciarsi con essi. 4.2 Pattern di sviluppo In questo capitolo sono presentati i principali design pattern impiegati nella progettazione e sviluppo di NST. Il concetto di pattern `e definito come una soluzione progettuale generale a un problema ricorrente . Ogni pattern `e 4.2 Pattern di sviluppo 49 Figura 4.1: Architettura n-tier di NST Strato interfaccia
UI layer Strato di business
Business logic layer Strato di persistenza
Data access layer Strato comune
Common layer Utente Componenti esterni Database caratterizzato da un nome che lo identifica, da una classe di problemi ai quali pu`o essere applicato, dalla descrizione della soluzione proposta, ed infine, da vincoli e risultati introdotti dalla sua applicazione. I pattern di sviluppo si possono suddividere in tre macroaree: pattern architetturali, design pattern e pattern di implementazione, in base all''ambito di applicazione dei pattern che ne fanno parte. I pattern architetturali sono pattern di alto livello e operano sulla struttura del sistema, individuandone insiemi di responsabilit`a omogenee e relazioni di tra esse, allo scopo di partizionarle tra le varie com- ponenti. Un esempio di pattern architetturale `e la n-tier architecture, esposta in precedenza in questo capitolo. I design pattern sono strettamente legati al paradigma object-oriented e si riferiscono alla struttura, e interazione, degli oggetti del sistema. I pattern di implementazione sono invece i pattern di basso livello, legati a specifiche tecnologie, che mirano a sfruttare i punti di forza le caratteristiche peculiari di una certa piattaforma [Gol13]. La descrizione del problema affrontato da un pattern comprende una pa- noramica sulle situazioni cui esso `e applicabile, la quale, pu`o essere pi` u o meno specifica e deve comprendere le precondizioni necessarie alla sua applicazione. La soluzione proposta dal pattern `e riassunta dal suo nome e viene de- 50 4. Architettura del sistema Figura 4.2: La struttura Model-View-Controller MODEL VIEW CONTROLLER UTENTE usa mostra manipola agg iorna scritta come la configurazione degli elementi da esso costituiti affinch`e il problema sia risolto. La soluzione proposta deve astrarre il problema, senza addentrarsi nelle specifiche di implementazione. I vincoli imposti da un pattern sono spesso l''argomento primario per determinarne la scelta, in quanto determinano l''impatto della soluzione pro- dotta sul resto del sistema. 4.2.1 Model View Controller, MVC Il pattern MVC, Model-View-Controller, `e un pattern architetturale le- gato alla programmazione ad oggetti, nato alla fine degli anni 70 come fra- mework per Smalltalk, sviluppato da Trygve Reenskaug. Da allora, il fra- mework MVC, ha giocato un ruolo importante nel design e nello sviluppo di framework per interfacce utente [Fow02]. Il problema affrontato da que- sto pattern `e quello di separare le logiche di business dai dati, e dalla loro rappresentazione. La struttura di MVC `e caratterizzata da tre tipologie di oggetti: 4.2 Pattern di sviluppo 51 Figura 4.3: Ripartizione delle funzionalit`a in MVC VIEW CONTROLLER MODEL VIEW Interfaccia utente MODEL CONTROLLER Logica di business Rappresentazione del dominio ' il Model, rappresenta le informazioni del dominio, contiene i dati, e quindi lo stato di entit`a del sistema; ' la View, che mostra i dati del model adattandosi al suo stato; ' il Controller, gestisce l''interazione con l''utente, ricevendone i comandi e manipolando il model di conseguenza; In questo modo la logica di business viene ripartita tra model e controller, model e view si suddividono il problema della rappresentazione delle entit`a, mentre view e controller compongono l''interfaccia utente gestendo input ed output del sistema. In NST questo pattern `e impiegato, tramite il framework MVC4 di micro- soft, per l''implementazione dell''interfaccia lato server, della quale si tratter`a in modo pi` u approfondito nel capitolo 5. 4.2.2 Model View View-model, MVVM Il pattern MVVM `e una specifica implementazione del pattern MVC se- condo il paradigma dell''event-driven-programming. Questo pattern `e nato appositamente per lo sviluppo di interfacce utente in ambienti .NET, quali WPF e Silverlight, ed `e stato successivamente impiegato per lo sviluppo di interfacce HTML5, con la nascita di librerie Javascript quali KnockoutJS e AngularJS [Wik14b]. Il framework MVVM individua tre componenti principali, dai quali ne deriva anche il nome: 52 4. Architettura del sistema ' il Model, pu`o avere due forme: secondo l''approccio ad oggetti, esso `e rappresentato da un oggetto del domnio mentre, secondo l''approccio centrato sui dati, esso `e rappresentato dal data-layer che fornisce i contenuti; ' la View rappresenta l''aspetto grafico dei dati, cio`e i controlli e i dati che vengono mostrati all''utente; ' il View model, anche detto modello della vista, rappresenta il punto di giunzione tra vista e modello. Esso altera la vista tramite i dati del modello e passa i comandi ottenuti dalla vista al modello. Questo tipo di pattern `e implicitamente legato ad un quarto componente detto Binder, il quale effettua la connessione dai dati del modello verso la vista, e dai comandi della vista verso il modello. La scopo di questo componente `e quello di sincronizzare il view model con la view, evitando al programmatore di scrivere codice ripetitivo. In NST questo pattern viene impiegato per lo sviluppo dell''interfaccia lato client, implementata tramite l''utilizzo della libreria KnockoutJS. I prin- cipali vantaggi derivanti dall''utilizzo di KnockoutJS, e quindi del pattern MV- VM , risiedono nella possibilit`a di mantenere aggiornate interfacce complesse al variare di grandi set di dati, senza dover gestire il binding manualmente. Tale vantaggio deriva dalla possibilit`a di effettuare un binding dichiarati- vo, cio`e integrando le informazioni di binding direttamente nel markup della vista. 4.2.3 Provider model Il provider model `e un design pattern formulato da Microsoft per molti ASP.NET Starter Kits e formalizzato in .NET versione 2.0. Il nome del pattern `e derivato dalla descrizione del problema, il quale riguarda la for- nitura di funzionalit`a (dall''inglese provider, cio`e fornitore) riguardanti una certa API (Application program interface) [How04]. 4.2 Pattern di sviluppo 53 Figura 4.4: Struttura di una UI basata su MVVM MODEL VIEW MODEL VIEW UTENTE mostra usa notifica comanda BINDER binding eventop/ risposta richiesta Nella pratica, un provider, `e un contenitore di oggetti che implementano interfacce comuni fornendo alcune funzionalit`a. Compito del provider `e quello di selezionare quale implementazione impiegare per fornire servizi di business o accesso ai dati. La scelta di tali implementazioni viene effettuata run-time in base alla configurazione dell''applicazione, la quale a sua volta pu`o risiedere in files o su database. Nel business layer di NST `e implementato un particolare provider per l''ac- cesso ai servizi, le cui caratteristiche di funzionamento cambiano sotanzial- mente tra le varie implementazioni, che li seleziona in base a certi parametri di configurazione modificabili a run-time. Il provider pattern, inoltre, `e largamente impiegato all''interno del fra- mework MVC, sul quale si basa lo strato d''interfaccia lato server di NST. L''impiego del provider pattern in MVC4 permette di configurare l''utilizzo di implementazioni personalizzate di servizi di autorizzazione per gli utenti, tra i quali MembershipProvider and RoleProvider, incaricati di riconoscere gli utenti, che accedono al programma, e i ruoli ai quali essi appartengono. 4.2.4 Adapter, decorator e fa¸cade patterns I patterns adapter, decorator e fa¸cade, sono design patterns utilizzati nella programmazione ad oggetti. In genere ci si riferisce agli oggetti proget- tati secondo le soluzioni proposte, con lo stesso nome del pattern che li ha generati. 54 4. Architettura del sistema Un adapter, cio`e adattatore, `e un oggetto che traduce l''interfaccia di un oggetto in un''altra interfaccia compatibile. Per ottenre questo comportamen- to l''adapter espone un''interfaccia e ne implementa i metodi tramite quelli esposti da un''altra interfaccia. L''utilizzo di un adapter permette l''intera- zione tra classi che non potrebbero interagire a causa di incompatibilit`a di interfaccia. Un decorator, invece, `e un oggetto che permette di estendere (quindi deco- rare) le funzionalit`a di un oggetto, senza alterarne il funzionamento iniziale. ` E possibile ottenere un decorator incapsulando un oggetto, caratterizzato da una certa interfaccia, all''interno di un altro oggetto che espone un''interfaccia estesa, nella quale `e inclusa l''interfaccia originale. Il nome fa¸cade infine, deriva dal termine architetturale facciata, e ri- specchia la soluzione proposta, la quale consiste nell''implementazione di un singolo oggetto dall''interfaccia semplice, per l''accesso ad una serie di funzio- nalit`a distribuite su pi` u oggetti con interfacce complesse. Il fa¸cade pattern pu`o essere utilizzato per raggruppare oggetti o metodi, in modo da suddi- viderli per semplici attivit`a, migliorando cos`ı, leggibilit`a, manutenibilit`a e semplicit`a, e riducendo le dipendenze tra i moduli software. Se utilizzato in concomitanza con adapter o decorator, permette di sfruttare la potenza delle espressioni polimorfiche modificando il comportamento di alcune interfacce a run-time. In NST questi patterns sono impiegati, nello strato di business, per espor- re interfacce a servizi complessi, per l''accesso a servizi esterni, e per raggrup- pare task complessi in metodi semplici. Nel lato client dell''interfaccia utente, i patterns decorator e adapter sono utilizzati per estendere le funzionalit`a di alcuni view models e renderli intercambiabili e applicabili ad ambienti differenti. 4.2 Pattern di sviluppo 55 Figura 4.5: Diagramma di un decorator, e un adapter, per la classe User <<interface>> IUser + getUserId() UserDecorator - user : IUser + getUserId()
+ login(username,
password) User - id : int - filiale : Filiale - azienda : Azienda + getUserId() WebuserDecorator - user : IUser - username : string - password : string + getUserId()
+ login(username, password) <<interface>> IEntity + getId() UserEntityAdapter - user : IUser + getId() Figura 4.6: Diagramma di una fa¸cade per servizi di geolocalizzazione <<interface>> IGeolocationService + geolocate(indirizzo : String)
: PuntoGeografico GeolocationServiceImpl + geolocate(indirizzo : String) : PuntoGeografico GoogleGeolocation + geolocate(indirizzo : String) : PuntoGeografico PuntoGeografico + indirizzo : String + civico : int + provincia : String + localita : String + nazione : String + lat : double + lng : double GeolocationFacade + GoogleGeolocate(indirizzo : String) : PuntoGeografico + Geolocate(indirizzo : String) : PuntoGeografico GeolocationServices Capitolo 5 L''interfaccia utente La gestione dell''interazione con l''utente `e un problema molto vasto e complesso, pertanto la progettazione di un''interfaccia utente (in inglese user interface, o UI) diventa un argomento particolarmente delicato. Conside- rando le caratteristiche web-based di NST, e l''obiettivo di trasformarlo in un software ad alta diffusione, la progettazione e lo sviluppo, dello strato di interfaccia, devono tener conto di aspetti relativi a ergonomia e usabilit`a [ISO08], in particolare: ' efficacia ed efficienza nel raggiungimento degli obiettifi prefissi dall''u- tente che utilizza il sistema; ' familiarit`a e facilit`a di apprendimento, per permettere all''utente di ambientarsi rapidamente al software; ' sicurezza e robustezza all''errore, facendo in modo che eventuali errori abbiano impatto minimo sull''utilizzo del sistema. Vanno inoltre considerati aspetti relativi alla portabilit` a e alla mobilit` a. Si intende per portabilit`a la possibilit`a di utilizzare il software su differenti sistemi, ad esempio palmari, tablet e cellulari. Il problema della mobilit`a, invece, concerne la possibilit`a di operare il software in qualsiasi luogo e mo- mento, consentendone la fruizione agli addetti sul campo, cos`ı come agli impiegati amministrativi che operano dall''interno del proprio ufficio. 57 58 5. L''interfaccia utente In questo capitolo saranno introdotte le metodologie di progettazione impiegate per l''interfaccia utente di NST e, conseguentemente, ne verrano illustrate la struttura e le tecnologie impiegate per lo sviluppo. 5.1 Metodologia collaborativa: Wireframing, mockups e prototyping Nell''ambito del web design e della programmazione, si indica con wire- frame la bozza strutturale di un applicativo web. La tecnica del wireframing, applicata alla progettazione di interfacce, consiste nella produzione di bozze della UI che ne riassumono gli aspetti principali, cio`e: ' i contenuti, cio`e cosa `e necessario mostrare all''utente; ' la disposizione dei componenti dell''interfaccia; ' una breve descrizione delle interazioni con l''utente; La produzione di un wireframe `e un processo rapido che si presta particolar- mente bene al processo collaborativo, fornendo ad ogni membro del team la possibilit`a di intervenire sulla struttura della UI. Il pi` u delle volte un wirefra- me `e prodotto a matita su un foglio di carta, oppure su una lavagna, e viene rifinito in un secondo momento in caso si renda necessario un confronto con il cliente. Il passo successivo rappresenta dalla produzione di un mockup, cio`e una rappresentazione statica, ma esteticamente dettagliata, della versione finale dell''interfaccia. In certi casi un mockup pu`o mostrare gi`a l''aspetto estetico finale dell''interfaccia, dando un''idea pi` u completa del risultato finale. Un mockup permette di rappresentare la struttura delle informazioni, visualiz- zare alcuni contenuti e dimostrare le funzionalit`a di base di una UI, senza per`o implementarle. I mockup possono essere sufficientemente accurati da far parte della documentazione tecnica del prodotto e contengono sufficienti informazioni per la produzione di un prototipo funzionante. 5.2 UI guidelines e Metro design language 59 Figura 5.1: UI design tramite wireframing, mockup e prototipazione 1. WIREFRAME 2. MOCKUP 3. PROTOTIPO Il prototipo `e una versione dinamica ed interattiva dell''interfaccia fi- nale. Un prototipo non presenta necessariamente gli aspetti estetici della versione finale, ma deve piuttosto evidenziare dinamicamente i contenuti e le iterazioni della UI in modo simile al prodotto finale. Per ridurre i costi di svi- luppo spesso si rimanda la fase di allacciamento del prototipo con il backend applicativo, corredandolo di un set di dati temporanei ma significativi. 5.2 UI guidelines e Metro design language Steve Krug, information architect e autore del libro Don''t make me think, dice che il layout di un sito web dovrebbe essere auto-esplicativo, cio`e che non dovrebbe richiedere, all''utente che lo osserva per la prima volta, uno sforzo mentale per individuare ci`o che egli si aspetta di trovare nel conte- sto in cui si trova [Kru06]. Questo principio, sebbene inizialmente diretto ai web-designers, `e applicabile anche alle interfacce utente di applicativi web. In pratica Krug ribadisce l''importanza delle caratteristiche che un''interfaccia deve trasmettere all''utente durante il suo utilizzo. Per garantire usabilit`a `e necessario che una UI sia caratterizzata da una certa uniformit`a all''interno dei vari contesti, siano essi viste di elenco, viste di dettaglio o singoli control- li. ` E importante inoltre, affinch´e l''utente possa individuare i contenuti o le funzionalit`a che cerca in brevissimo tempo, che l''interfaccia presenti aspetti di interazione noti all''utente, senza sorprenderlo. Allo scopo di aiutare i designer e gli sviluppatori di NST, nel mantenere tale uniformit`a, `e stato stilato un documento contenente le linee guida dei 60 5. L''interfaccia utente Figura 5.2: Schermata di Outlook.com, con email aperta. componenti e del layout dell''interfaccia. Questo documento comprende con- venzioni estetiche e funzionali, che aiutano nella scelta degli elementi grafici, quali tavolozze dei colori, stili tipografici, utilizzo di bordi e separatori, e direttive per l''utilizzo di componenti per implementare task ricorrenti. Queste linee guida di NST sono ispirate allo stile Metro1 introdotto da Microsoft, a sua volta basato sullo Stile tipografico internazionale (o Stile svizzero ), i cui principi basilari comprendono chiarezza e leggibilit`a. La scelta di ispirarsi a questo linguaggio di design `e stata dettata, innanzitutto, dalla comunanza di obiettivi posti dal team di sviluppo durante la fase di analisi, ed inoltre, dalla volont`a di fornire all''utente un''interfaccia che gli fosse familiare, ispirata all''ormai diffusa interfaccia utente di Windows 8. 1nome in codice del linguaggio di design introdotto da Microsoft per l''interfaccia utente di Windows 8 5.3 Web applications e web UI 61 5.3 Web applications e web UI Il processo di standardizzazione del web, iniziato con la fondazione del W3C Consortium nell''Ottobre del 1994, ha fornito agli sviluppatori una base solida per lo sviluppo di web applications, cio`e applicativi distribuiti tramite il web. La standardizzazione di HTML, CSS, SVG, Javascript, Ajax e altre tecnologie ampiamente impiegate in ambito web, ha permesso di risolvere problematiche legate all''incompatibilit`a tra browser, permettendo quindi ai client di impiegare un qualsiasi browser standard-compliant per l''accesso ai contenuti online, e trasformando cos`ı il web, in un ambiente ideale per la distribuzione di software. Le web applications sono generalmente basate sul paradigma client-server. Il compito del client `e innanzitutto quello di instaurare la comunicazione, inviando richieste tramite appositi protocolli (HTTP, HTTPS, SPDY, Web- socket, ...), ed interpretare le risposte attraverso un normale web browser. Il compito del server, invece, `e quello di elaborare le richieste ottenute dal client tramite un web-server, elaborando le informazioni ottenute dagli strati applicativi che incapsulano la logica applicativa e i dati, ed inviando al client pagine web opportunamente costruite (pagine web dinamiche). Tali pagine web possono essere corredate di script, i quali vengono eseguiti dal browser del client, allo scopo di renderle interattive, fornendo all''utente un''esperienza assimilabile a quelle fornite da applicativi desktop. L''insieme di tecnologie disponibili, per l''implementazione e l''utilizzo di applicativi web, `e molto vasto, cos`ı come sono numerosi i criteri di scel- ta secondo i quali esse vengono impiegate. Gli aspetti pi` u importanti da considerare durante questa fase comprendono: ' Sicurezza, sia lato server che lato client, in quanto ogni applicativo esposto alla rete `e potenzialmente un punto d''attacco per malintenzio- nati. Problematiche relative alla sicurezza possono comprendere: '' criptatura dei dati sensibili e firma dei contenuti contro phishing (falsificazione) e man in the middle attacks; 62 5. L''interfaccia utente Figura 5.3: Riepilogo della struttura, e delle tecnologie, di una UI basata sul web. Client INTERNET Servermweb Webmserver Webm application WEBmPAGES WEBmAPIs TCP+IP IIS Apache nginx GooglemGWS Chrome Firefox InternetmExplorer Safari Opera yyy HTTPX HTTPSX SPDYX Websocket HTMLX XMLX Json ASPyNET PHP Java Python Javascript C+CLLmCGI PerlmCGI yy HTML5X JavascriptX CSSX SVGX Ajax Webmbrowser 5.4 Server side UI, ASP.NET MVC 63 '' politiche di riconoscimento degli utenti (autenticazione) e gestione delle sessioni; '' gestione dei permessi (autorizzazione) e contromisure per direct data access and theft ed information leakage (furto d''informazio- ni); '' procedure di validazione dei dati e controlli contro data poisoning, cio`e manipolazione e danneggiamento dei dati; '' controllo sui files per evitare malicious file execution, cio`e l''esecu- zione di codice malevolo introdotto nel sistema; '' denial of service, o DoS, cio`e la negazione del servizio. ' Affidabilit`a della rete, la quale pu`o impedire agli utenti l''utilizzo del- l''applicativo; malfunzionamenti della rete possono essere causati da apparati di rete o attacchi DoS. ' Performance, inteso come tempo di risposta alle richieste degli utenti; problemi di performance possono essere causati dall''errata gestione di grossi insiemi di dati, o codice poco performante. ' Incompatibilit`a tra i devices, o i browsers, e l''applicativo, la quale pu`o essere causata dall''utilizzo di software non standard compliant, o da mancata attenzione agli standards nella programmazione lato server. [FS04] Nei prossimi paragrafi verranno analizzate le strutture, e le tecnologie, impiegate per i vari componenti dello strato di interfaccia di NST. 5.4 Server side UI, ASP.NET MVC ASP.NET MVC `e un framework per lo sviluppo di applicativi web ba- sato sul pattern MVC 4.2.1 e sulle tecnologie ASP.NET di Microsoft. Per l''implementazione del server side dell''interfaccia di NST, `e stata impiegata 64 5. L''interfaccia utente la versione 4 di ASP.NET MVC, detta appunto MVC4, codificata tramite C# . ASP.NET MVC `e caratterizzato da uno sviluppo fortemente legato al pattern MVC, il quale coinvolge principalmente tre ruoli: i models, le view e i controllers. In ASP.NET MVC (C#)2 i models ed i controllers prendono la forma di classi opportunamente annotate, mentre le views sono particolari documenti di markup, caratterizzati da specifiche sintassi basate su HTML, i quali vengono elaborati da un view engine, ed inviati come risposta al client. MVC4 comprende una serie di componenti per la gestione di problemati- che quali: autenticazione e autorizzazione degli utenti che effetuano richieste all''applicativo (Membership management), mappatura degli URLs e instra- damento delle richieste verso controllers (url mapping e request routing), e gestione delle sessioni. Questi componenti possono essere rimpiazzati da ver- sioni personalizzate tramite l''utilizzo di Dependency Injection e Inversion of Control. La versione 4 di ASP.NET MVC introduce inoltre le ASP.NET Web API , cio`e un framework per la produzione di servizi RESTful3. Il flusso dati di una richiesta, in ambiente ASP.NET MVC, pu`o essere riassunto come segue: 1. IIS riceve la richiesta dal client e la inoltra ad ASP.NET; 2. il sistema di instradamento delle richieste di ASP.NET, esegue un match tra la richiesta e le route disponibili, individuando cos`ı, la route corretta; 3. la richiesta raggiunge cos`ı MVC il quale, tramite una controller facto- ry, istanzia un oggetto di tipo Controller o ApiController, adatto alla richiesta da gestire; 4. a questo punto MVC individua il metodo specifico del controller da invocare; 2progetti ASP.NET MVC codificati con C#
3REpresentational State Transfer (REST) `e un''architettura software per il world wide web centrata sulla descrizione di risorse, sulla loro localizzazione e sul loro trasferimento 5.4 Server side UI, ASP.NET MVC 65 5. prima dell''invocazione del metodo del controller, viene verificato che l''utente sia autorizzato all''esecuzione del metodo stesso; 6. se l''utente `e autorizzato il metodo viene eseguito e viene prodotto un oggetto in risposta, eventualmente elaborando un modello e la relativa vista; 7. se non ci sono state eccezioni la risposta viene inviata al client; Questo flusso rende centrale il ruolo dei controller, i quali hanno il ruolo di coordinatori, interfacciando viste e modelli con il backend applicativo. 5.4.1 Models I models sono oggetti che modellano le entit`a del dominio. In ASP.NET MVC i models sono implementati tramite semplici classi, corredati all''occor- renza da annotazioni (Data Annotations) per specificare regole di validazione, direttive per la visualizzazione e relazioni con altri models. I models vengono utilizzati come base dati delle viste e come input e output per i controllers. p u b l i c c l a s s AziendaModel { [ Display ( Name = ' I d ' ) ] p u b l i c i n t Id { get ; set ; } [ Range ( 0 , UInt32 . MaxValue , ErrorMessageResourceName = ' E r r C o d i c e F i l i a l e ' , ErrorMessageResourceType = t y p e o f ( App_GlobalResources . Validation ) ) ] [ Display ( Name = ' I d F i l i a l e ' ) ] p u b l i c i n t IdFiliale { get ; set ; } p u b l i c i n t ' IdImmagine { get ; set ; } [ Required ( AllowEmptyStrings = f a l s e , ErrorMessageResourceName = ' E r r D e s c r i z i o n e N o n V a l i d a ' , ErrorMessageResourceType = t y p e o f ( App_GlobalResources . Validation ) ) ] [ Display ( Name = ' D e s c r i z i o n e ' , ResourceType = t y p e o f ( App_GlobalResources'- . Archives ) ) ] p u b l i c s t r i n g Descrizione { get ; set ; } 66 5. L''interfaccia utente [ Display ( Name = ' I n d i r i z z o ' , ResourceType = t y p e o f ( App_GlobalResources . '- Archives ) ) ] p u b l i c s t r i n g Indirizzo { get ; set ; } / * . . . */ [ Required ] [ Display ( Name = ' C o d i c e F i s c a l e ' , ResourceType = t y p e o f ( '- App_GlobalResources . Archives ) ) ] p u b l i c s t r i n g CodiceFiscale { get ; set ; } [ Required ] [ Display ( Name = ' P a r t i t a I v a ' , ResourceType = t y p e o f ( App_GlobalResources . '- Archives ) ) ] p u b l i c s t r i n g PartitaIva { get ; set ; } } Il codice mostrato rappresenta il model di un''azienda, e mostra l''utilizzo di alcune data annotations utilizzate da ASP.NET MVC nelle operazioni di validazione, visualizzazione e serializzazione dell''oggetto. Le annotazioni Range e Required sono relative alla validazione dei dati; Required, ad esem- pio, permette di marcare una propriet`a come richiesta, cio`e non opziona- le, e permette inoltre di specificare eventuali messaggi d''errore da mostrare nel caso la propriet`a non venga impostata correttamente. L''annotazione Display invece fornisce alcune informazioni di base per la visualizzazione della propriet`a in fase di rendering delle viste. MVC4 prevede altre anno- tazioni, ad esempio RegularExpressionAttribute, per la validazione tramite espressioni regolari, EnumDataTypeAttribute per la validazione di tipi enum, DisplayFormatAttribute per la formattazione dei dati in fase di rendering, etc. L''utilizzo delle annotazioni permette di mantenere un approccio dichia- rativo durante la codifica dei modelli, ed evita al programmatore di dover gestire compiti ripetitivi di validazione dell''input, ed alla personalizzazione nella fase di rendering dell''output. 5.4 Server side UI, ASP.NET MVC 67 5.4.2 Views Le viste sono rappresentate da templates in formato misto HTML/C#, cio`e un documento HTML con inserti codificati tramite C#, i quali vengono elaborati in fase di rendering. Il componente che determina la sintassi di questi templates, e ne effettua il rendering, `e detto view engine. ASP.NET MVC si pu`o interfacciare con diversi tipi di view engine, anche personalizzati. Dalla release di MVC3, `e stato introdotto il view engine Razor, impiegato per lo sviluppo delle viste di NST. La sintassi Razor, rispetto alle sintassi precedentemente proposte da Mi- crosoft , introduce alcuni vantaggi chiave: ' sintassi basata su linguaggi noti, senza particolari aggiunte; ' riduzione del numero di caratteri che compongono una vista; ' supporto di viste di layout, dette layouts; ' supporto ad IntelliSense (feature di autocompletamento del codice); ' supporto per Unit testing; Il supporto ai layouts, e la possibilit`a di creare viste parziali, permette allo sviluppatore di costituire una gerarchia di viste con caratteristiche estetiche comuni senza ripetere codice, e di creare una serie di componenti grafici ampiamente riutilizzabili. @model Gesp . NST . Models . AziendaModel <d i v c l a s s=' B r i e f B r i e f ''A z i e n d a u n s e l e c t a b l e ' data''b i n d=' c l i c k : $parent . S e l e c t I t e m '> <d i v c l a s s=' I d e n t i f i c a z i o n e '> <span c l a s s=' D e s c r i z i o n e T i t l e ' data''b i n d=' t e x t : D e s c r i z i o n e , c l i c k : $root . EditItemForm'> @Model . Descrizione</ span> <span c l a s s=' I n d i r i z z o ' data''b i n d=' t r i m T e x t : I n d i r i z z o C o m p l e t o , t r i m T e x t L e n g t h : 30 '> @Model . Indirizzo</ span> </ d i v> <d i v c l a s s=' S t a t o '> 68 5. L''interfaccia utente <span data''b i n d=' S t a t o : S t a t o '>@Model . Stato</ span> @Html . LabelFor ( m => m . Stato ) </ d i v> <d i v c l a s s=' T e l e f o n o '> <span data''b i n d=' t e x t : T e l e f o n o '>@Model . Telefono</ span> @Html . LabelFor ( m => m . Telefono ) </ d i v> <d i v c l a s s=' Email '> <span t i t l e ='@Model . Email ' data''b i n d=' t r i m T e x t : Email , t r i m T e x t L e n g t h : 16 '> @Model . Email</ span> @Html . LabelFor ( m => m . Email ) </ d i v> </ d i v> La vista d''esempio, basata sul model illustrato 5.4.1, mostra l''utilizzo sintassi Razor. Il carattere @indica al view engine che quanto segue `e da interpretare come codice, e va dunque elaborato prima del rendering. La prima riga del codice, dichiara il modello sul quale `e basata la vista; in seguito nel codice ci si riferisce ai dati del modello tramite la sintassi @Model. La vista mostrata `e parziale, cio`e rappresenta solamente un frammento di pagina HTML, in questo modo `e possibile riutilizzare questo codice come componente grafico di viste pi` u ampie, ad esempio elenchi. 5.4.3 Controllers ed API controllers I controllers hanno il compito di elaborare le richieste utente e coordinare modelli e viste allo scopo di produrre l''output desiderato. Data la struttura stratificata di NST, ricade sul controller anche la responsabilit`a di interfac- ciarsi con lo strato della logica applicativa. Un particolare tipo di controller `e rappresentato dall''APIController, il quale, anzich´e renderizzare viste, si li- mita a serializzare i dati in un formato di interscambio, come Json o XML, ed inviarli in risposta al client. L''operazione di serializzazione avviene in modo automatico, attraverso il framework MVC4, in base alle direttive dichiarate tramite annotazioni e al tipo di formato richiesto dal client. [ Authorize ( Roles = ' A m m i n i s t r a t o r e ' ) ] 5.4 Server side UI, ASP.NET MVC 69 p u b l i c c l a s s AmministrazioneController : Controller { // / <summary> // / R i c h i e s t a v i s t a p a r z i a l e p e r a z i e n d a . // / </summary> // / <param name=' i d '> I d e n t i f i c a t i v o n u m e r i c o u n i v i c o a z i e n d a </param> // / <r e t u r n s >V i s t a b r i e f a z i e n d a </ r e t u r n s > p u b l i c ActionResult BriefAzienda ( i n t idAzienda ) { // i s t a n z i o m o d e l l o d e l l a v i s t a AziendaModel model ; / * i n o l t r o r i c h i e s t a v e r s o B u s i n e s s L a y e r p e r o t t e n e r e a z i e n d a con i d ' i d A z i e n d a ' e c o m p i l a z i o n e d e l m o d e l l o v i s t a */ // r e n d e r i n g d e l model a t t r a v e r s o v i s t a p a r z i a l e r e t u r n PartialView ( ' '/ Views / A m m i n i s t r a z i o n e / A z i e n d e / B r i e f . c s h t m l ' , '- model ) ; } } Il metodo BriefAzienda, del controller mostrato, si interfaccia con lo stra- to di business e richiede i dati dell''azienda identificata da un certo intero (idA- zienda ), per poi compilare il modello dati ed inviarlo alla vista Brief.cshtml per il rendering. Il seguente controller di tipo ApiController `e analogo a quello mostrato in precedenza ma, anzich´e renderizzare l''azienda in una vista, ritorna il model a MVC4 per la serializzazione. [ Authorize ( Roles = ' A m m i n i s t r a t o r e ' ) ] p u b l i c c l a s s AmministrazioneApiController : ApiController { p u b l i c Azienda GetAzienda ( i n t idAzienda ) { // i s t a n z i o m o d e l l o d e l l a v i s t a AziendaModel model ; / * i n o l t r o r i c h i e s t a v e r s o B u s i n e s s L a y e r p e r o t t e n e r e a z i e n d a con i d ' i d A z i e n d a ' e c o m p i l a z i o n e d e l m o d e l l o v i s t a */ 70 5. L''interfaccia utente // r i t o r n o i l m o d e l l o d a t i r e t u r n model ; } } Entrambi i controller mostrati sono annotati con AuthorizeAnnotation, annotazione che permette ad MVC4 di identificare gli utenti che possono accedere ai metodi del controller. In questo caso la propriet`a Roles dell''an- notazione Authorize permette l''accesso ai controller solamente agli utenti del gruppo Amministratore. 5.5 Client side UI Il client side di un''interfaccia web `e composto da pagine web interattive. Queste pagine vengono elaborate dal client tramite un web browser, e costi- tuiscono il punto d''accesso vero e proprio per il sistema. I sorgenti dei quali necessita il browser, per realizzare l''interfaccia, sono costituiti da: ' documenti di markup, codificati in HTML, forniscono la struttura delle pagine, e dunque dell''interfaccia, e contengono riferimenti agli altri elementi necessari all''interfaccia; ' fogli di stile, cio`e documenti codificati in CSS (Cascading Style Sheets), contenenti direttive di layout che governano l''aspetto grafico all''inter- faccia; ' script, codificati in linguaggio Javascript, interpretati ed eseguiti dal browser per aggiungere aspetti di interattivit`a e dinamicit`a all''inter- faccia. Questi componenti devono rispettare il pi` u possibile gli standard imposti dal consorzio W3C, affinch´e l''interfaccia sia eseguibile sul maggior numero di browser possibile, e sia quindi indipendente dall''architettura hardware del device che accede all''applicativo. 5.5 Client side UI 71 Nei prossimi paragrafi verranno analizzate alcune delle tecnologie impie- gate per lo sviluppo dell''interfaccia lato client di NST. 5.5.1 HTML5, CSS3 e Javascript L''interfaccia utente di NST `e basata sugli standard HTML5, CSS3 e Javascript . Il termine HTML5 `e spesso usato in riferimento ad un insieme di tec- nologie del web moderno, molte delle quali sono sviluppate dal WHAT- WG , cio`e Web Hypertext Application Technology Working Group, talvolta in collaborazione con il consorzio W3C e l''IETF (Internet Engineering Ta- sk Force)[Gro14]. Lo sviluppo di HTML5, `e iniziato nel 2004 ad opera del WHATWG , allo scopo di progettare specifiche per lo sviluppo di applicazio- ni web, ed ha visto l''intervento del W3C solo nel 2007 [Wik14a]. Nel 2012 per`o, il W3C, ha deciso nuovamente di serpararsi dal processo di standar- dizzazione, perseguendo una propria versione di HTML5, che al momento `e presentato in due versioni: la versione HTML living standard, supportata dal WHATWG , e la versione del W3C, che corrisponder`a ad uno snapshot della versione del WHATWG. HTML5 introduce alcune importanti novit`a rispetto alla versione 4: ' maggiore disaccoppiamento tra la struttura del documento, gli stili grafici (fonts, colori, bordi, etc.) e il contenuto della pagina; ' supporto di contesti grafici, rappresentati da elementi di tipo canvas, che permettono di utilizzare Javascript per creare grafica raster; ' supporto alla geolocalizzazione per i device che lo consentono; ' introduzione del WebStorage, in sostituzione ai cookies, per la memo- rizzazione di dati nel browser senza spreco di banda; ' introduzione dei WebWorkers, cio`e script in formato Javascript, esegui- ti in background, indipendentemente dagli script sui quali `e eseguita la pagina. 72 5. L''interfaccia utente La tecnologia di supporto ad HTML5 scelta per NST, per quanto riguar- da le direttive di stile, `e la terza versione di CSS, cio`e CSS3. CSS `e un linguaggio per la formattazione di documenti HTML, XHTML e XML, in- trodotto a partire dal 1996 dal W3C, per migliorare la manutenibilit`a e la riusabilit`a del codice delle pagine web. Il codice CSS `e strutturato in regole, a loro volta suddivise in selettori, proprit`a e valori. Il selettore permette di indicare al browser quali elementi sono soggetti ad una certa regola; propriet`a e valori sono raggruppate per selettori, e indicano le propriet`a da assegnare agli elementi riferiti dai selettori che le comprendono. / * Questo e ' un commento . */ / * I l seguente s e l e t t o r e a p p l i c a l e r e g o l e a t u t t i g l i e l e m e n t i d i t i p o ' a ' */ a { / * foreground d e l l ' elemento c o l o r e 00 00 00 ( nero ) */ c o l o r : #000000; } / * I l seguente s e l e t t o r e a p p l i c a l e r e g o l e a t u t t i g l i e l e m e n t i i l c u i a t t r i b u t o ' c l a s s ' c o n t i e n e l a s t r i n g a ' b l u e ''f g ' */ . blue''fg { c o l o r : #0000FF ; } / * I l seguente s e l e t t o r e a p p l i c a l e r e g o l e a l l ' elemento i d e n t i f i c a t o d a l l ' a t t r i b u t o ' i d ' con v a l o r e ' TitoloGrande ' */ #TitoloGrande { / * c o l o r e bianco d e l foreground */ c o l o r : #FFFFFF ; / * c o l o r e nero per background */ background''c o l o r : #000000; / * padding ( scostamento ) di 5px su t u t t i i l a t i */ p a d d i n g : 5px ; / * Imposta una dimensione d e l t e s t o a l 200% d e l normale */ f o n t ''s i z e : 200%; } CSS3 `e al momento lo standard pi` u recente per i fogli di stile e, pur mantenendo completa retrocompatibilit`a, introduce numerose features quali: selettori pi` u evoluti, box models pi` u elastici, alterazione del contenuto tramite 5.5 Client side UI 73 direttive, effetti al testo, trasformazioni 2D e 3D, layout multi-colonna, etc. L''interattivit`a delle pagine, come di consueto nel web, `e implementa- ta tramite l''utilizzo di Javascript. Javascript `e un linguaggio interpretato, orientato agli oggetti, e caratterizzato da una sintassi simile al Java (dal qua- le prende il nome). A dispetto del nome per`o, le differenze con Java sono molteplici: mentre Java `e fortemente tipizzato, e fortemente orientato agli oggetti, Javascript `e debolmente tipizzato, e gli oggetti sono strutturati pi` u come array associativi, che come oggetti Java o C++. Sebbene venga utiliz- zato anche lato server (ad esempio da piattaforme come NodeJS ), JavaScript `e nato come linguaggio lato client per il web, cio`e per essere eseguito diret- tamente sul browser del client, pertanto per lo scopo di questa trattazione, ci riferiremo a Javascript in riferimento al codice lato client. / **
* Semplice c l a s s e Ja vaScri pt che implementa l e f u n z i o n a l i t `a
* di un cronometro . */ function Cronometro ( ) { // r i f e r i m e n t o p r i v a t o a l l ' oggetto var self = this ; // a t t r i b u t o p r i v a t o var interval = null ; // a t t r i b u t o p u b b l i c o self . ticks = 0 ; // metodo p u b b l i c o self . reset = function ( ) { self . ticks = 0 ; } ; // a v v i o self . avvia = function ( ) { // i m p o s t a z i o n e d i c h i a m a t a t e m p o r i z z a t a interval = setInterval ( function ( ) { self . ticks++; } , // f u n z i o n e r i c h i a m a t a Cronometro . SECOND_IN_MILLISECONDS // i n t e r v a l l o ) ; } ; // s t o p self . ferma = function ( ) { 74 5. L''interfaccia utente // b l o c c a l ' e s e c u z i o n e temporizzata if ( interval ) clearInterval ( interval ) ; } ; // m o s t r a a l l ' utente quanti t i c k s sono p a s s a t i self . alarm = function ( ) { alert ( 'Tempo p a s s a t o : '+self . ticks+' s e c o n d i ' ) ; } ; } / **
* V a r i a b i l e s t a t i c a ( usata come c o s t a n t e ) d e l l a c l a s s e Cronometro */ Cronometro . SECOND_IN_MILLISECONDS = 1 0 0 0 ; // i s t a n z i a z i o n e d i un o g g e t t o var stopWatch = new Cronometro ( ) ; // i n v o c a z i o n e d i un metodo p u b b l i c o stopWatch . avvia ( ) ; // t e m p o r i z z a z i o n e d i c h i a m a t a a f u n z i o n e dopo c i r c a 3 s e c o n d i setTimeout ( function ( ) { stopWatch . ferma ( ) ; stopWatch . alarm ( ) ; } , 3001 ) ; 5.5.2 Il DOM, Document Object Model Il Document Object Model, o DOM, `e un''interfaccia per la manipolazione dinamica della struttura, dei contenuti e degli stili di un documento[W3C09], i cui standard sono definiti dal W3C. In sostanza il Document Object Model, tradotto in modello ad oggetti del documento , `e la rappresentazione di un documento secondo il modello ad og- getti, che permette ai programmi di gestirne gli elementi in tempo reale. Tale rappresentazione `e indipendente da piattaforme o linguaggi, ed `e impiegata da programmi lato server, quanto da script lato client. In particolare, questa rappresentazione ad oggetti, `e supportata nativamente dai browser web, che la impiegano in fase di interpretazione dei documenti HTML, costruendo una struttura ad albero manipolabile, e stilizzabile, tramite JavaScript e CSS. 5.5 Client side UI 75 Il DOM, nei browser, prende tipicamente la forma di una struttura dati ad albero, i cui nodi sono rappresentati da elementi relativi a tags specifici, ad esempio tabelle, forms, collegamenti esterni, immagini, oppure ad attributi e nodi testuali. Il codice 5.5.2 rappresenta una semplice pagina web in HTML, mentre la figura 5.5.2 ne riassume l''interpretazione, e la relativa struttura del DOM. Listing 5.1: Un semplice documento HTML <!DOCTYPE html> <html> <head> <title>titolo documento</title> <script type=' t e x t / j a v a s c r i p t '> / * . . . */ </script> </head> <body> <h1>Intestazione 1</h1> <p>testo del paragrafo . . . < / p> <a href=' h t t p : / / n s t . g e s p . i t / '>testo del link</a> </body> </html> Una volta che il browser ha intepretato il documento HTML, il modello risultante sar`a simile a quello rappresentato in figura 5.5.2. La manipolazione del modello costruito pu`o avvenire tramite script, i quali possono essere in- clusi nel documento stesso sotto forma di codice JavaScript, oppure possono essere referenziati come risorse esterne. Il codice 5.5.2 mostra un esempio di manipolazione del DOM : inserito nel tag script dell''esempio 5.5.2, il codice proposto permette di eliminare dal documento tutti i tag di tipo p. 5.5.3 AJAX, accesso asincrono ai dati Il funzionamento delle prime web applications, legate al funzionamento dei primi web browser, prevedeva che ogni interazione tra utente ed applica- zione (quale l''invio di dati, la richiesta di risorse o una semplice operazione di 76 5. L''interfaccia utente Listing 5.2: Esempio di manipolazione del DOM tramite JavaScript //recupera dal DOM (oggetto document) tutti i tags di tipo "p" var p a r a g r a f i = document . getElementsByTagName ( "p" ) ; //finch´ e ci sono paragrafi da eliminare... while ( p a r a g r a f i . l e n g t h > 0 ) { //prendi il primo paragrafo dall'array di paragrafi var p a r a g r a f o = p a r a g r a f i [ 0 ] ; //ottieni l'elemento padre var p a r e n t = p a r a g r a f o . pa re nt No de ; //rimuovi il paragrafo dal dom attraverso il parent p a r e n t . r e m o v e C h i l d ( p a r a g r a f o ) ; } Figura 5.4: Il DOM, Document Object Model, di una semplice pagina HTML <vDOCTYPEjhtml>
<html> j<head>
j
jj<title>titolojdocumento</title>
jj
jj<scriptjtype=*text/javascript*>
jjj/:j...j:/
jj</script>
jj
j</head> j<body>
j
jj<h1>Intestazionej1</h1>
jj
jj<p>testojdeljparagrafo...</p>
jj
jj<ajhref=*http://nst.gesp.it/*>testojdeljlink</a>
jj
j</body> </html> DOCUMENT ROOT ELEMENT <html> ELEMENT <head> ELEMENT <body> ELEMENT <title> TEXT "titolo documento" ELEMENT <script> TEXT "/* ... */" ATTRIBUTE "type" ELEMENT <h1> TEXT "Intestazione 1" ELEMENT <a> TEXT "testo del link" ATTRIBUTE "href" ELEMENT <p> TEXT "testo del paragrafo..." TEXT "/* ... */" 5.5 Client side UI 77 login), fosse seguito da un nuovo ciclo di richiesta, risposta e rendering della pagina, durante il quale l''interazione dell''utente con l''interfaccia web `e bloc- cata. Questo comportamento viene comunemente detto refresh ed `e derivato dalla struttura dell''ipertesto, la quale prevede semplici documenti referen- ziati tramite collegamenti, sul quale si `e basato il web fin dal principio. Col tempo, e con l''evoluzione delle web applications, questo comportamento `e diventato particolarmente controproducente: l''utente `e infatti costantemen- te interrotto durante la sua interazione, dovendo attendere che il browser proceda ad effettuare le singole richieste sui dati, rompendone la concentra- zione ed eliminando di fatto il parallelismo intrinseco in certe operazioni di manipolazione dei dati. Supponiamo ad esempio di voler eliminare da un elenco di elementi, una serie di elementi selezionati secondo criteri arbitrari. Secondo il suddetto mo- dello di funzionamento le procedure coinvolte nell''eliminazione di un singolo elemento comprendono: 1. l''utente richiede, attraverso il browser, l''elenco degli elementi e attende una risposta; 2. il webserver risponde inviando un documento contenente l''elenco dati; 3. il browser dell''utente riceve il documento e ne effettua il rendering, presentando i dati all''utente; 4. l''utente individua uno o pi` u elementi, da eliminare, ed invia la richiesta di eliminazione tramite il browser; 5. il browser blocca la pagina, bloccando di fatto l''interazione dell''utente, per inviare la richiesta al server; 6. il server riceve la richiesta, effettua l''eliminazione e invia nuovamente tutto l''elenco di elementi al client; 7. il browser ripete il rendering della pagina, sui dati ottenuti dalla rispo- sta, e l''utente pu`o tornare a consultare e manipolare i dati. 78 5. L''interfaccia utente Questa procedura, oltre agli svantaggi gi`a citati, comporta uno spreco di banda, in quanto ad ogni richiesta il server `e costretto a re-inviare l''intero elenco di oggetti al client. Per ovviare a questi problemi vengono impiegate tecniche AJAX, cio`e JavaScript asincrono e XML (Asynchronous JavaScript and XML). Il termi- ne asincrono si riferisce al fatto per cui le richieste avvengono in background, cio`e senza interrompere l''interazione utente, tramite alcuni script javascript, e possono essere effettuate anche in parallelo. L''utilizzo di XML, invece, `e opzionale. Le tecniche AJAX prevedono diverse fasi, cio`e: la richiesta asin- crona, la deserializzazione dei dati ottenuti in risposta, la manipolazione della struttura del documento. A queste fasi si pu`o aggiungere la fase di serializ- zazione, nel caso in cui rappresentazioni di oggetti complesse vengano inviate tramite richieste HTTP POST, secondo un certo formato di interscambio. La procedura illustrata per la manipolazione dei dati (5.5.3), viene percio`o sostanzialmente modificata tramite l''impiego di tecniche ajax: 1. l''utente richiede, attraverso il browser, l''elenco degli elementi e attende una risposta; 2. il webserver risponde inviando un documento contenente l''elenco dati, il quale `e corredato di opportuni script che implementano tecniche AJAX; 3. il browser dell''utente riceve il documento, ne effettua il rendering, ed interpreta gli script allegati; 4. l''utente individua uno o pi` u elementi, da eliminare, e seleziona il co- mando di eliminazione dall''interfaccia; 5. gli script AJAX vengono eseguiti, tramite il browser, e la richiesta viene inviata in background, senza interrompere l''utente, il quale pu`o continuare a selezionare altri elementi da eliminare oppure consultare diversamente i dati; 6. il server riceve la richiesta, effettua l''eliminazione e invia una semplice conferma dell''eliminazione; 5.5 Client side UI 79 7. il browser riceve la conferma dell''eliminazione e pu`o alterare la pagina gi`a renderizzata, confermando eventualmente all''utente l''esito afferma- tivo delle azioni compiute. Grazie a queste tecniche viene reintrodotto il parallelismo nelle operazio- ni, in quanto l''utente pu`o continuare ad utilizzare l''applicativo, come se si trattasse di una normale interfaccia desktop, oppure effettuare pi` u operazioni sui dati contemporaneamente. I formati di scambio pi` u utilizzati sono XML, HTML e JSON. Per NST `e stato scelto JSON, principalmente per le sue doti di leggerezza e sempli- cit`a. L''acronimo JSON significa JavaScript Object Notation, in quanto tale formato `e basato sullo standard ECMA per Javascript. JSON, a differenza di XML, non `e un linguaggio di marcatura e la sua sintassi `e interpretabile rapidamente tramite javascript, permettendo una rapida deserializzazione in oggetti, tramite l''operatore eval(). JSON `e inoltre supportato dal framework MVC4 per quanto riguarda l''interfaccia lato server. I tipi di dato, supportati dal formato JSON sono booleani, numeri interi e a virgola mobile, stringhe, array e array associativi, ed il tipo di dato nullo. { "status" : 2 0 0 , "reason" : "Ok" , "result" : [ { "Id" : 1 , "Descrizione" : "GESP srl" , "Indirizzo" : "Viale Scarampo, 47" "Cap" : "20418" , "Localita" : "Milano" , "Provincia" : "MI" , "Nazione" : "IT" , "Stato" : "Attivo" } ] "headers" : n u l l } 80 5. L''interfaccia utente Il frammento di codice proposto rappresenta una tipica risposta in for- mato JSON, e ne mostra le doti di leggibilit`a. I campi degli oggetti sono facilmente identificabili dal proprio nome, e sono seguiti dal loro valore, sem- pre espresso in formato leggibile, secondo la formattazione richiesta dal tipo di dato rappresentato. L''oggetto rappresentato `e complesso, ed `e composto dai dati di un''azienda, incapsulati in un oggetto che trasporta informazioni di stato riguardanti l''esito della richiesta. Si pu`o notare l''utilizzo di alcuni dei tipi di dati supportati da JSON: i campi status e il campo Id dell''azien- da, assumono valori interi; il loro valore `e rappresentato da cifre espresse in caratteri, senza conversioni in binario o cambiamenti di base. Campi quali Descrizione , indirizzo, o il campo reason, sono campi di tipo stringa, il cui valore `e delimitato da doppi apici. Il campo result `e un array, i cui elementi sono racchiusi tra parentesi quadre e delimiatati da virgole. Infine l''oggetto azienda, compreso nell''array result, `e espresso come un array associativo, e il campo headers presenta un valore nullo. 5.5.4 MVVM con KnockoutJS I dati della UI, scambiati col server tramite richieste AJAX, devono poi essere elaborati, strutturati e mostrati all''utente, sotto forma di elementi del documento HTML. Questa operazione di collegamento, tra i dati e la loro rappresentazione, `e ottenuta nei client di NST, tramite l''utilizzo della libreria KnockoutJS , la quale opera secondo i principi del pattern MVVM. Knockou- tJS fornisce una serie di utilities, e classi, che possono essere utilizzate per effettuare il binding tra i model e le viste, senza doverlo operare manualmente, bens`ı utilizzando una tecnica di binding dichiarativo, che sfrutta informazioni incluse nelle viste per associarvi il view model. L''esempio 5.5.4 mostra un viewmodel associato ad un''azienda. /** * ViewModel per Azienda. */ function AziendaViewModel ( ) { 5.5 Client side UI 81 //riferimento intero oggetto var s e l f = t h i s ; //id intero univoco s e l f . I d = ko . o b s e r v a b l e ( 0 ) ; //altri dati s e l f . D e s c r i z i o n e = ko . o b s e r v a b l e ( "" ) ; s e l f . I n d i r i z z o = ko . o b s e r v a b l e ( "" ) ; s e l f . Cap = ko . o b s e r v a b l e ( "" ) ; s e l f . L o c a l i t a = ko . o b s e r v a b l e ( "" ) ; s e l f . P r o v i n c i a = ko . o b s e r v a b l e ( "" ) ; s e l f . N a z i o n e = ko . o b s e r v a b l e ( "" ) ; s e l f . S t a t o = ko . o b s e r v a b l e ( "" ) ; //campo calcolato , s e l f . I n d i r i z z o C o m p l e t o = ko . computed ( function ( ) { return s e l f . I n d i r i z z o ( ) + ", " + s e l f . Cap ( ) + " " + s e l f . L o c a l i t a ( ) + " - " + s e l f . P r o v i n c i a ( ) + " - " + s e l f . N a z i o n e ( ) ; } , s e l f ) ; //popola il ViewModel in base ai dati azienda //ottenuti dal server. s e l f . fromJSon = function ( a z i e n d a J s o n ) { s e l f . I d ( a z i e n d a J s o n . I d ) ; s e l f . D e s c r i z i o n e ( a z i e n d a J s o n . D e s c r i z i o n e ) ; s e l f . I n d i r i z z o ( a z i e n d a J s o n . I n d i r i z z o ) ; s e l f . Cap ( a z i e n d a J s o n . Cap ) ; s e l f . L o c a l i t a ( a z i e n d a J s o n . L o c a l i t a ) ; s e l f . P r o v i n c i a ( a z i e n d a J s o n . P r o v i n c i a ) ; s e l f . N a z i o n e ( a z i e n d a J s o n . N a z i o n e ) ; s e l f . S t a t o ( a z i e n d a J s o n . S t a t o ) ; } ; } Il ViewModel proposto utilizza le classi di KnockoutJS per gestire varia- zioni sui dati del modello, ed eventualmente, modificare la vista di conse- guenza. I campi di tipo ko.computed hanno valori calcolati, e possono essere derivati da altri campi dell''oggetto, come nell''esempio relativo all''indirizzo dell''azienda. Il metodo fromJson viene richiamato dal client quando ottiene un nuovo modello dati dal server, allo scopo di popolare i dati del ViewModel con i dati ottenuti, per poi legarli alla vista. Un esempio di vista, legata al ViewModel proposto, `e rappresentato dal frammento di codice 5.4.2. Il bin- 82 5. L''interfaccia utente ding dichiarativo si effettua tramite l''utilizzo degli attributi data-bind, che vengono letti ed interpretati da KnockoutJS in fase di rendering. La libreria KnockoutJS fornisce anche supporto per templating, tramite particolari direttive di binding di cui si fornisce un esempio con il frammento di codice 5.5.4. <!'''' Elemento c h e c o n t i e n e una l i s t a d i a z i e n d e r e n d e r i z z a t e s e c o n d o i l t e m p l a t e TmplAzienda ''''> <u l i d="ListaAziende" data''b i n d="foreach: ListaAziende"> < l i data''b i n d="template: { name: TmplAzienda }"></ l i > </u l > <!'''' Template p e r l a v i s u a l i z z a z i o n e in l i s t a d i a z i e n d e ; comprende d e s c r i z i o n e e i n d i r i z z o ''''> < s c r i p t t y p e="text/html" i d="TmplAzienda"> < l i c l a s s="WrapperAzienda" data''b i n d="css: Stato()"> <i n p u t t y p e="hidden" data''b i n d="value: Id" v a l u e="" /> <h3 data''b i n d="text: Descrizione"</h3> <p c l a s s="Indirizzo" data''b i n d="text: IndirizzoCompleto"> </p> </ l i > </ s c r i p t > L''esempio 5.5.4 mostra diverse direttive di binding: ' foreach, indica che il rendering va effettuato per ogni elemento della collection, in questo caso l''array ListaAziende; ' template, indica che il rendering degli elementi va effettuato utilizzando un template, il quale `e contenuto in un tag script, identificato dal nome TmplAzienda; ' text `e probabilmente la direttiva pi`u comune, in quanto permette di impostare il valore di un tag html con il valore del campo collegato; ' value, associa il valore di un campo all''attributo value; molto usata in template relativi a moduli di inserimento (form); 5.5 Client side UI 83 ' css, permette di aggiungere un certo stile, in questo caso associato allo stato dell''azienda. Conclusioni Lo sviluppo di NST `e tuttora in corso, ma `e possibile affermare che questo processo ha finora avuto esito positivo, secondo l''impiego delle metodologie, e delle tecnologie, esposte in questa tesi, seppur con qualche eccezione: Scrum `e stato applicato, ed ha dato degli ottimi benefici nella selezione delle attivit`a secondo priorit`a e importanza funzionale; tuttavia le demo a volte non sono state efficaci, e non `e stato utilizzato il controllo della velocit`a previsto dal metodo. TDD e CI sono stati improntati ma non usati fino in fondo; in alcuni casi le funzionalit`a hanno anticipato i test, e le build automatiche non sono state effettuate. Il team ha seguito le linee guida impostate ad inizio progetto (separazione in layer, linee guida di scrittura codice e progettazione db, progettazione di GUI tramite Mockups), e di questo ne ha beneficiato la qualit`a finale del software. L''applicativo `e al momento interfacciato con un ottimizzatore, dotato di algoritmi all''avanguardia, capace di risolvere in poco tempo, complessi problemi di pianificazione logistica. Durante la fase pre-alfa, NST `e stato interfacciato con ERP aziendali e piattaforme di monitoraggio mezzi, e sar`a presto avviata la fase di beta per un modulo di monitoraggio della tempe- ratura dei vani di carico, di una flotta di mezzi atti al trasporto di merci di consumo per la GDO. L''applicativo pu`o gi`a essere utilizzato tramite interfac- cia web mediante diversi tipi di dispositivi, a partire dai personal computer fino ai cellulari di ultima generazione. Con questo studio sono stati esposti quei temi, selezionati come i pi` u 85 86 5. L''interfaccia utente importanti, necessari per introdurre il lettore al vasto problema della pro- gettazione e sviluppo di software per il supporto alla logistica, illustrando il percorso sostenuto e i mezzi con i quali `e stato affrontato. Bibliografia [ABB+95] P. Augerat, J.M. Belenguer, E. Benavent, A. Corber´an, D. Nad- def, and G. Rinaldi. Computational results with a branch and cut code for the capacitated vehicle routing problem. Technical Report 1 RR949-M, ARTEMIS-IMAG, Grenoble France, 1995. [AGL+04] R. K. Ahuja, J. Goodstein, J. Liu, A. Mukherjee, and J. B. Orlin. A neighborhood search algorithm for the combined th- rough and fleet assignment model with time windows. Networks, 44(2):160''171, 2004. [Aug95] P. Augerat. Approche poly´ edrale du probl` eme de tourn´ ees de v´ ehicules . PhD thesis, Institut National Polytechnique de Grenoble, 1995. [BBM06] R. Baldacci, L. D. Bodin, and A. Mingozzi. The multiple di- sposal facilities and multiple inventory locations rollon-rolloff vehicle routing problem. Computers & Operations Research, 33:2667''2702, 2006. [BBMR10] R. Baldacci, E. Bartolini, A. Mingozzi, and R. Roberti. An exact solution framework for a broad class of vehicle routing problems. Computational Management Science, pages '', 2010. [BC12] M. Blocho and Z.J. Czech. A parallel memetic algorithm for the vehicle routing problem with time windows. Parallel Computing , 2012. 87 88 BIBLIOGRAFIA [BCM08] R. Baldacci, N. Christofides, and A. Mingozzi. An exact algorithm for the vehicle routing problem based on the set partitioning formulation with additional cuts. Mathematical Programming , 115(2):351''385, 2008. [BDG04] O. Braysy, W. Dullaert, and M. Gendreau. Evolutionary al- gorithms for the vehicle routing problem with time windows. Journal of Heuristics , 10(6):587''611, 2004. [BG05a] O. Braysy and M. Gendreau. Vehicle routing problem with time windows, part I: route construction and local search algorithms. Transportation Science , 39(1):104''118, 2005. [BG05b] O. Braysy and M. Gendreau. Vehicle routing problem with time windows, part II: metaheuristics. Transportation Science, 39(1):119''139, 2005. [BH04] R. Bent and P. Van Hentenryck. A two-stage hybrid local search for the vehicle routing problem with time windows. Transportation Science , 38(4):515''530, 2004. [BHM04] R. Baldacci, E. Hadjiconstantinou, and A. Mingozzi. An exact algorithm for the capacitated vehicle routing problem based on a two-commodity network flow formulation. Operations Research, 52(5):723''738, 2004. [BKM07] N. Boland, B. Kallehauge, and O. B. G. Madsen. Path ine- qualities for the vehicle routing problem with time windows. Networks , 49(4):273''293, 2007. [BKY02] J. F. Bard, G. Kontoravdis, and G. Yu. A branch-and-cut procedure for the vehicle routing problem with time windows. Transportation Science , 36(2):250''269, 2002. [BL07] C. Barnhart and G. Laporte. Handbook in OR & MS, Vol. 14. Elsevier B.V., 2007. BIBLIOGRAFIA 89 [BMR08] M.A. Boschetti, A. Mingozzi, and S. Ricciardelli. A dual ascent procedure for the set partitioning problem. Discrete Optimization , 5(4):735''747, 2008. [BMR11] R. Baldacci, A. Mingozzi, and R. Roberti. New route rela- xation and pricing strategies for the vehicle routing problem. Operations Research , 59(5), 2011. [BP76] E. Balas and M. W. Padberg. Set partitioning: a survey. SIAM Review , 18:710''760, 1976. [BS97] J. Bramel and D. SimchiLevi. On the effectiveness of set co- vering formulations for the vehicle routing problem with time windows. Operations Research, 45(2):295''301, 1997. [CE69] N. Christofides and S. Eilon. An algorithm for the ve- hicle dispatching problem. Operational Research Quarterly , 20:309''318, 1969. [Cha05] A. Chabrier. Vehicle routing problem with elementary shor- test path based column generation. Computers & Operations Research , 33:2972''2990, 2005. [CLM01] J.-F. Cordeau, G. Laporte, and A. Mercer. A unified tabu search heuristic for vehicle routing problems with time windo- ws. Journal of the Operational Research Society, 52(8):928''936, 2001. [CLR07] J.-F. Cordeau, G. Laporte, and S. Ropke. Models and branch- and-cut algorithms for pickup and delivery problems with time windows. Networks, 49(4):258''272, 2007. [CM12] J.-F. Cordeau and M. Maischberger. A parallel iterated ta- bu search heuristic for vehicle routing problems. Computers & Operations Research , 39(9):2033''2050, 2012. 90 BIBLIOGRAFIA [CMT79] N. Christofides, A. Mingozzi, and P. Toth. The vehicle routing problem. In N.Christofides, A. Mingozzi, P. Toth, and C. Sandi, editors, Combinatorial Optimization, pages 315 '' 338. Wiley, Chichester, 1979. [CMT81] N. Christofides, A. Mingozzi, and P. Toth. Exact algorithms for the vehicle routing problem based on spanning tree and shortest path relaxation. Mathematical Programming, 10:255''280, 1981. [CPL09] CPLEX. IBM ILOG CPLEX 12.1 callable library. ILOG, 2009. [DDS84] M. Desrochers, J. Desrosiers, and F. Soumis. Routing with time windows by column generation. Networks, 14(4):545''565, 1984. [DDS92] M. Desrochers, J. Desrosiers, and M. M. Solomon. A new opti- mization algorithm for the Vehicle-Routing problem with time windows. Operations Research, 40(2):342''354, 1992. [DHL08] G. Desaulniers, A. Hadjar, and F. Lessard. Tabu search, partial elementarity, and generalized k-Path inequalities for the vehicle routing problem with time windows. Transportation Science, 42(3):387''404, 2008. [DKM+99] M. Desrochers, N. Kohl, O. B. G. Madsen, M. M. Solomon, and F. Soumis. 2-path cuts for the vehicle routing problem with time windows. Transportation Science, 33(1):101''116, 1999. [DLP05] E. Danna and C. Le Pape. Column Generation, chapter Ac- celerating branch-and-price with local search: A case study on the vehicle routing problem with time windows, pages 90'' 130. Desaulniers, G., Desrosiers, J., Solomon, M.M., New York, springer edition, 2005. [EPGR09] G. Desaulniers E. Prescott-Gagnon and L.-M. Rousseau. A branch-and-price based large neighborhood search algorithm BIBLIOGRAFIA 91 for the vehicle routing problem with time windows. Networks, 54(4):190''204, 2009. [FJM97] M. L. Fisher, K. O. Jornsten, and O. B. G. Madsen. Vehi- cle routing with time windows: two optimization algorithms. Operations Research , 45(3):488''492, 1997. [FLL+06] R. Fukasawa, H. Longo, J. Lysgaard, M. Poggi de Arag'ao, M. Reis, E. Uchoa, and R.F. Werneck. Robust branch- and-cut-and-price for the capacitated vehicle routing problem. Mathematical Programming , 106:491''511, 2006. [Fow02] Martin Fowler. Patterns of Enterprise Application Architecture. Addison Wisley, 2002. [FS04] Susan Fowler and Victor Stanwick. WEB APPLICATION DE- SIGN HANDBOOK, Best Practices for Web-Based Software . Morgan Kaufmann, 2004. [GHL94] M. Gendreau, A. Hertz, and G. Laporte. A tabu search heu- ristic for the vehicle routing problem. Management Science, 40(10):1276''1290, 1994. [Gol13] Riccardo Golia. Introduzione ai design pattern. http://msdn.microsoft.com/it-it/library/ cc185081.aspx , 2013. [Gro14] Web Hypertext Application Technology Working Group. Html, living standard. http://www.whatwg.org/ specs/web-apps/current-work/multipage/ introduction.html , Feb 2014. [HHI08] M. Yagiura H. Hashimoto and T. Ibaraki. An iterated local search algorithm for the time-dependent vehicle routing problem with time windows. Discrete Optimization, 5:434''456, 2008. 92 BIBLIOGRAFIA [How04] Rob Howard. Provider model design pattern and specifica- tion. http://msdn.microsoft.com/en-us/library/ ms972319.aspx , March 2004. [HP93] K. Hoffman and M. W. Padberg. Solving airline crew scheduling problems by branch and cut. Management Science, 39:657''682, 1993. [HY08] H. Hashimoto and M. Yagiura. A path relinking approach with an adaptive mechanism to control parameters for the vehicle routing problem with time windows. Lecture Notes in Computer Science , 4972:254''265, 2008. [IEE00] Ieee recommended practice for architectural description of software-intensive systems. Software Engineering Standards Committee, Sep 2000. [IIN+08] T. Ibaraki, S. Imahori, K. Nonobe, K. Sobue, T. Uno, and M. Yagiura. An iterated local search algorithm for the vehicle routing problem with convex time penalty functions. Discrete Applied Mathematics , 156:2050''2069, 2008. [Int14] Internazionalizzazione e localizzazione. http://it. wikipedia.org/wiki/Internazionalizzazione_ e_localizzazione , February 2014. [ISO08] Ergonomic requirements for office work with visual di- splay terminals. http://www.iso.org/iso/catalogue_ detail.htm'csnumber=16883 , 2008. [IV06] S. Irnich and D. Villeneuve. The Shortest-Path problem wi- th resource constraints and k-Cycle elimination for k>=3. INFORMS Journal on Computing , 18(3):391''406, 2006. BIBLIOGRAFIA 93 [JPSP08] M. Jepsen, B. Petersen, S. Spoorendonk, and D. Pisinger. Subset-Row inequalities applied to the Vehicle-Routing problem with time windows. Operations Research, 56(2):497''511, 2008. [Kal08] B. Kallehauge. Formulations and exact algorithms for the vehicle routing problem with time windows. Computers & Operations Research , 35(7):2307''2330, 2008. [KLM06] B. Kallehauge, J. Larsen, and O. B. G. Madsen. Lagran- gian duality applied to the vehicle routing problem with time windows. Computers & Operations Research, 33(5):1464''1487, 2006. [KLMS05] B. Kallehauge, J. Larsen, O. B. G. Madsen, and M. M. So- lomon. Column Generation, chapter Vehicle Routing Problem with Time Windows, pages 67''98. GERAD 25th Anniversa- ry Series. Desaulniers, G., Desrosiers, J., Solomon, M.M., New York, springer edition, 2005. [KM97] N. Kohl and O. B. G. Madsen. An optimization algorithm for the vehicle routing problem with time windows based on lagrangian relaxation. Operations Research , 45(3):395''406, 1997. [Kru06] Steve Krug. Don''t Make Me Think. New Riders, 2006. [LLE04] J. Lysgaard, A. N. Letchford, and R. W. Eglese. A new branch- and-cut algorithm for the capacitated vehicle routing problem. Mathematical Programming Ser. A , 100:423''445, 2004. [LPR08] N. Labadi, C. Prins, and M. Reghioui. A memetic algorithm for the vehicle routing problem with time windows. RAIRO - Operations Research , 42(3), 2008. 94 BIBLIOGRAFIA [LST03] H. C. Lau, M. Sim, and K. M. Teo. Vehicle routing problem with time windows and a limited number of vehicles. European Journal of Operational Research , 148(3):559''569, 2003. [Lys06] J. Lysgaard. Reachability cuts for the vehicle routing problem with time windows. European Journal of Operational Research, 175(1):210''223, 2006. [LZ07] A. Lim and X. Zhang. A two-stage heuristic with ejection pools and generalized ejection chains for the vehicle routing problem with time windows. INFORMS Journal on Computing, 19(3):443''457, 2007. [MB05] D. Mester and O. Br¨aysy. Active guided evolution strategies for large-scale vehicle routing problems with time windows. Computers & Operations Research , 32:1593''1614, 2005. [MBRB99a] A. Mingozzi, M. A. Boschetti, S. Ricciardelli, and L. Bianco. A set partitioning approach to the crew scheduling problem. Operations Research , 47(6):873''888, 1999. [MBRB99b] A. Mingozzi, M.A. Boschetti, S. Ricciardelli, and L. Bianco. A set partitioning approach to the crew scheduling problem. Operations Research , 47:873''888, 1999. [MCH94] A. Mingozzi, N. Christofides, and E. A. Hadjiconstantinou. An exact algorithm for the vehicle routing problem based on the set partitioning formulation. Technical report, University of Bologna, 1994. [Mic06] Guidelines for test-driven development. http://msdn. microsoft.com/en-us/library/aa730844(v=vs. 80).aspx , May 2006. BIBLIOGRAFIA 95 [MT90] Silvano Martello and Paolo Toth. An exact algorithm for large unbounded knapsack problems. Operations Research Letters, 9, 1990. [NB09] Y. Nagata and O. Br¨aysy. Edge assembly based memetic algo- rithm for the capacitated vehicle routing problem. Networks, 54(4):205''215, 2009. [PR07] D. Pisinger and S. Ropke. A general heuristic for vehicle routing problems. Computers & Operations Research, 34:2403''2435, 2007. [PRI09] C.D. Tarantilis P.P. Repoussis and G. Ioannou. Arc-guided evolutionary algorithm for the vehicle routing problem with ti- me windows. EEE Transactions on evolutionary computation, 13(3):624''647, 2009. [Rop05] S. Ropke. Heuristic and exact algorithms for vehicle routing problems . PhD thesis, Computer science department at the University of Copenhagen (DIKU), 2005. [Rop10] S. Ropke. Private communication. 2010. [RS06] G. Righini and M. Salani. Symmetry helps: Bounded bi- directional dynamic programming for the elementary shortest path problem with resource constraints. Discrete Optimization, 3(3):255''273, September 2006. [RS08] G. Righini and M. Salani. New dynamic programming algo- rithms for the resource constrained elementary shortest path problem. Networks, 51(3):155''170, May 2008. [RS09] G. Righini and M. Salani. Decremental state space relaxa- tion strategies and initialization heuristics for solving the orien- teering problem with time windows with dynamic program- 96 BIBLIOGRAFIA ming. Computers & Operations Research , 36(4):1191''1203, April 2009. [Sol86] M. M. Solomon. On the worst-case performance of some heuri- stics for the vehicle routing and scheduling problem with time window constraints. Networks, 16(2):161''174, 1986. [Sol87] M. M. Solomon. Algorithms for the vehicle routing and sche- duling problem with time window constraints. Operations Research , 35:234''265, 1987. [spe05] SPEC: standard performance evaluation corporation. www.spec.org, 2005. [Tsi92] J. N. Tsitsiklis. Special cases of traveling salesman and repair- man problems with time windows. Networks, 22(3):263''282, 1992. [TV02] Paolo Toth and Daniele Vigo. The Vehicle Routing Problem. Society for Industrial and Applied Mathematics, 2002. [TVP11] M. Gendreau T. Vidal, T.G. Crainic and C. Prins. A hybrid ge- netic algorithm with adaptive diversity management for a large class of vehicle routing problems with time windows. Technical report, CIRRELT, Oct 2011. [W3C09] The World Wide Web Consortium W3C. Document object model (dom). http://www.w3.org/DOM/, Jan 2009. [Wik14a] Html5. http://it.wikipedia.org/wiki/HTML5 , Fe- bruary 2014. [Wik14b] Model view viewmodel. http://en.wikipedia.org/ wiki/Model_View_ViewModel , February 2014. BIBLIOGRAFIA 97 [Wik14c] Problema del commesso viaggiatore. http://it. wikipedia.org/wiki/Problema_del_commesso_ viaggiatore , February 2014. [YND10] O. Br¨aysy Y. Nagata and W. Dullaert. A penalty-based edge assembly memetic algorithm for the vehicle routing problem with time windows. Computers & Operations Research, 7:724'' 737, 2010.

Document Outline

Ringraziamenti Introduzione Indice Il software, NST Casi d'uso reali GDO, grande distribuzione organizzata Aziende di servizi Enti ambientali, la raccolta dei rifiuti Business plan Deliverable Struttura dell'applicativo Infrastruttura server Il lato client Analisi e scelte Domini applicativi del VRP L'ottimizzatore Introduzione al problema del routing, il VRP Formulazione matematica del VRP Notazione della Teoria dei Grafi Capacitated VRP Modello di programmazione lineare per CVRP Varianti e metodi risolutivi per il VRP VRP con Time Windows e Formulazione Set Partitioning Metodi risolutivi esatti Metodi euristici Metodi metaeuristici Metaeuristici a ricerca locale Approccio alla fase realizzativa Metodologie di sviluppo, Scrum Test Driven Development e Continous Integration Strumenti di sviluppo Macchina virtuale di sviluppo Versioning del codice sorgente IDE, ambiente di sviluppo integrato CI server Architettura del sistema Stratificazione e Multi-tier architecture La stratificazione di NST Pattern di sviluppo Model View Controller, MVC Model View View-model, MVVM Provider model Adapter, decorator e façade patterns L'interfaccia utente Metodologia collaborativa: Wireframing, mockups e prototyping UI guidelines e Metro design language Web applications e web UI Server side UI, ASP.NET MVC Models Views Controllers ed API controllers Client side UI HTML5, CSS3 e Javascript Il DOM, Document Object Model AJAX, accesso asincrono ai dati MVVM con KnockoutJS Conclusioni Bibliografia


© Eiom - All rights Reserved     P.IVA 00850640186