Document

Università degli Studi di Padova
Dipartimento di Matematica
Corso di Laurea in Informatica
Tesi di Laurea
Tecnologie Google a supporto delle
aziende del settore manifatturiero e
logistico
Laureando
Relatore
Gabriele Spiga
Massimo Marchiori
Gennaio 2014
Alla mia famiglia
Abstract
Il seguente documento ha lo scopo di illustrare il lavoro di stage compiuto presso
l’azienda Nextep srl fornendo una descrizione dettagliata dei due progetti che sono
stati realizzati in collaborazione con lo studente Enrico Brunelli, riportando le
tecnoligie adottate e le scelte implementative più significative.
Per evitare ripetizioni tutti i termini presenti nel documento sono contrassegnati
dall’appendice |g| e riportati nella sezione Glossario alla loro prima occorrenza.
Indice
1 Introduzione
1.1 Profilo Aziendale . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Descrizione del progetto di stage . . . . . . . . . . . . . . . . . . . .
1.2.1 Progetto 1: Applicazione per la navigazione del database
dell’inventario prodotti . . . . . . . . . . . . . . . . . . . . . .
1.2.2 Progetto 2: Applicazione per il calcolo di percorsi e ricerca
punti di interesse . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Metodologia di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1 Il metodo scrum . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Obiettivi del progetto . . . . . . . . . . . . . . . . . . . . . . . . . .
3
4
5
6
2 Sistema per la navigazione del database dell’inventario prodotti
2.1 Descrizione del contesto . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Tipologia di utente . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Classificazione dei requisiti . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Vincoli tecnologici generali . . . . . . . . . . . . . . . . . . .
2.2.2 Ambito utente non autenticato . . . . . . . . . . . . . . . . .
2.2.3 Ambito utente autenticato . . . . . . . . . . . . . . . . . . . .
2.3 Tecnologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 La piattaforma Google App Engine . . . . . . . . . . . . . . .
2.3.2 La tecnologia REST . . . . . . . . . . . . . . . . . . . . . . .
2.3.3 Strumenti di sviluppo . . . . . . . . . . . . . . . . . . . . . .
2.3.4 Principali tecnologie utilizzate . . . . . . . . . . . . . . . . .
2.4 Progettazione del sistema . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1 Design Pattern utilizzati . . . . . . . . . . . . . . . . . . . . .
2.4.2 Specifica del Back end . . . . . . . . . . . . . . . . . . . . . .
2.4.3 Specifica del Front end . . . . . . . . . . . . . . . . . . . . . .
2.5 Test di sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
7
8
9
14
14
15
15
17
17
19
20
20
25
25
30
39
40
3 Applicazione per il calcolo di percorsi e ricerca punti di interesse
3.1 Descrizione del contesto . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Tipologia di utente . . . . . . . . . . . . . . . . . . . . . . . .
44
44
45
7
1
1
1
2
3.2
3.3
3.4
3.5
3.1.2 Casi d’uso . . . . . . . . . . . . .
Classificazione dei requisiti . . . . . . .
3.2.1 Requisiti Obbligatori . . . . . . .
3.2.2 Requisiti Desiderabili/Opzionali
Tecnologie . . . . . . . . . . . . . . . . .
3.3.1 Google Maps API . . . . . . . .
3.3.2 Tecnologie utilizzate . . . . . . .
Progettazione del sistema . . . . . . . .
3.4.1 Design Pattern utilizzati . . . . .
3.4.2 Specifica del Back end . . . . . .
3.4.3 Specifica del Front end . . . . . .
Test di sistema . . . . . . . . . . . . . .
4 Valutazioni retrospettive
4.1 Obiettivi . . . . . . . . . . . . . . . .
4.1.1 Obiettivi minimi dello stage .
4.1.2 Obiettivi massimi dello stage
4.1.3 Obiettivi formativi . . . . . .
4.1.4 Possibili sviluppi futuri . . .
4.1.5 Conoscenze acquisite . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
46
52
52
53
54
54
57
58
58
58
66
68
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
71
71
71
72
72
73
73
Glossario
75
Bibliografia
79
Elenco delle figure
2.1
2.2
2.3
2.4
2.5
2.6
2.7
2.8
2.9
2.10
2.11
2.12
2.13
2.14
2.15
2.16
2.17
2.18
Caso d’uso: Autenticazione Utente Non Google . . . . . .
Autenticazione Utente Google . . . . . . . . . . . . . . . .
Sezione di interazione con il sistema . . . . . . . . . . . .
Sezione di interrogazione al database . . . . . . . . . . . .
Sezione amministrativa . . . . . . . . . . . . . . . . . . . .
Struttura generale di Google App Engine . . . . . . . . .
Struttura dell’architettura REST . . . . . . . . . . . . . .
Struttura generale del design pattern MVC . . . . . . . .
Struttura del design pattern Data Access Object . . . . .
Struttura del design pattern Command . . . . . . . . . . .
Struttura del design pattern Abstract Factory applicato al
Struttura del Controller . . . . . . . . . . . . . . . . . . .
Struttura del design pattern command . . . . . . . . . . .
Struttura del package Managers . . . . . . . . . . . . . . .
Struttura del package Factory . . . . . . . . . . . . . . . .
Struttura del package DataModel . . . . . . . . . . . . . .
Struttura del package DataStoreAccess . . . . . . . . . . .
Struttura del front end . . . . . . . . . . . . . . . . . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
sistema
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
. . . . .
3.1
3.2
3.3
3.4
3.5
3.6
3.7
3.8
3.9
3.10
3.11
Pagina iniziale del sistema . . . . . . . . . . . . . . . . . . .
Ricerca del percorso su strada tra due località . . . . . . . .
Visualizzazione risultati ricerca percorso . . . . . . . . . . .
Ricerca fascia tariffaria . . . . . . . . . . . . . . . . . . . . .
Ricerca elenco distanze chilometriche . . . . . . . . . . . . .
Visualizzazione risultati della ricerca distanze chilometriche
Struttura della componente Controller . . . . . . . . . . . .
Struttura del design pattern command . . . . . . . . . . . .
Struttura del package Managers . . . . . . . . . . . . . . . .
Struttura del package DataModel . . . . . . . . . . . . . . .
Struttura del front end . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
10
11
12
13
17
19
25
27
28
29
30
33
35
36
37
38
39
.
.
.
.
.
.
.
.
.
.
.
46
47
48
49
50
51
58
61
63
64
66
Elenco delle tabelle
2.1
2.2
2.3
2.4
Progetto
Progetto
Progetto
Progetto
1
1
1
1
-
Vincoli tecnologici generali . .
Ambito utente non autenticato
Ambito utente autenticato . .
Test di sistema . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
14
15
16
42
3.1
3.2
3.3
Progetto 2 - Requisiti obbligatori . . . . . . . . . . . . . . . . . . . .
Progetto 2 - Requisiti Opzionali e Desiderabili . . . . . . . . . . . . .
Progetto 2 - Test di sistema . . . . . . . . . . . . . . . . . . . . . . .
53
53
70
CAPITOLO 1. INTRODUZIONE
Capitolo 1
Introduzione
In questo primo capitolo verrà illustrato il contesto generale dell’azienda proponente lo stage e le motivazioni che hanno portato alla realizzazione dello stesso, oltre
ad una breve descrizione dei due progetti affrontati che saranno approfonditi nei
capitoli successivi. Nel secondo capitolo sarà analizzato nel dettaglio il primo dei
due progetti da me affrontati in collaborazione con Enrico Brunelli, compagno del
corso di studi, mettendone in luce le principali caratteristiche e funzionalità oltre
alle scelte implementative più significative.
Il Capitolo 3 conterrà la descrizione del secondo progetto da noi realizzato secondo
le modalità sopra citate ed il Capitolo finale sarà dedicato alle conclusioni, in
particolare alle considerazioni personali sullo stage e sui possibili sviluppi futuri delle
due applicazioni.
1.1
Profilo Aziendale
Lo stage ha avuto luogo presso l’azienda Nextep srl di Carmignano di Brenta
(PD), facente parte del gruppo Allos Spa assieme a Zero12 Srl.
L’azienda, fondata nel 2000, opera nel settore dell’informatica e della comunicazione
ed è specializzata nelle attività di progettazione, realizzazione e gestione di web sites,
web applications e piattaforme di e-commerce|g| , oltre a fornire servizi di consulenza
di web marketing|g| e web analytics|g| .
L’azienda si occupa inoltre della rivendita di servizi a canone come domini, servizi di
cloud computing|g| e SaaS|g| , piattaforme di video streaming e Google Apps|g| , oltre
alla gestione e manutenzione di un gran numero di siti web.
1.2
Descrizione del progetto di stage
L’idea che sta alla base del progetto di stage proposto dall’azienda deriva dalla
necessità di analizzare le potenzialità dei servizi e le tecnologie offerte da Google|g| e
Pagina 1 di 79
1.2. DESCRIZIONE DEL PROGETTO DI STAGE
verificarne l’idoneità al loro impiego per lo sviluppo di applicazioni e siti web che
riescano a soddisfare appieno le richieste dei clienti, nello specifico alcune aziende
operanti nel settore metalmeccanico e dei trasporti.
L’azienda ha ricevuto diverse richieste da parte dei propri clienti riguardo alla
possibilità di integrare servizi già esistenti con funzionalità offerte dalle tecnologie
Google, come ad esempio Maps|g| , Drive|g| e GMail|g| per adattarli alle loro esigenze,
le quali possono essere riassunte nei seguenti punti:
• Integrazione dei dati con database esistenti tramite architetture REST|g|
• Applicazione per il calcolo di percorsi stradali e ricerca di punti di interesse
• Processi di condivisione delle informazioni per ufficio commerciale/customer
Service
• Mantenimento della documentazione inerente qualità e sicurezza aziendale
L’obiettivo minimo dello stage è stato lo sviluppo di almeno uno di questi punti
e la conseguente realizzazione di un prodotto che ne soddisfi le specifiche. Durante il
periodo di stage si è scelto di approfondire due dei punti precedentemente elencati e,
in accordo con il tutor aziendale, sono state sviluppate due applicazioni utilizzando
vari tool che Google mette a disposizione ai programmatori.
Segue la descrizione del contesto dei singoli prodotti.
1.2.1
Progetto 1: Applicazione per la navigazione del database
dell’inventario prodotti
Il primo problema affrontato riguarda lo sviluppo di un’applicazione web che
permetta la navigazione dei dati presenti sul database|g| dell’azienda cliente e la sua
integrazione con alcuni servizi di Google: in particolare è richiesto che l’applicazione
consenta l’accesso allo staff e a determinati utenti previa autorizzazione dell’amministratore del sistema ed inoltre sia accedibile agli utenti per mezzo del proprio account
Google.
L’applicazione deve permettere agli utenti autorizzati di effettuare interrogazioni
al database dei componenti e di visualizzare i risultati, oltre a poter richiedere la
fornitura di una certa quantità di prodotti.
Le funzionalità principali del sistema sono le seguenti:
• Accesso tramite account Google: l’applicazione consente l’accesso agli
utenti provvisti di account Google, previa autorizzazione da parte dell’amministratore
• Accessibilità via web: il prodotto è accessibile e fruibile collegandosi alla
sua pagina web
Pagina 2 di 79
CAPITOLO 1. INTRODUZIONE
• Interazione con il database: l’applicazione consente agli utenti autenticati
di eseguire varie interrogazioni al database, ordinare i risultati secondo i criteri
desiderati, e visualizzare i dettagli di un singolo prodotto
• Richiesta di fornitura: è possibile richiedere la fornitura di una certa quantità
di merce mediante compilazione dell’apposita form
L’azienda necessitava soprattutto di una modalità di interazione con il database
semplice e veloce, in modo da diminuire il tempo necessario alla consultazione dell’inventario ed effettuare la richiesta di fornitura di un prodotto in tempi brevi.
L’integrazione con i Google accounts è stata presa in considerazione in quanto l’azienda fa uso di un dominio Google Apps for Business: era pertanto preferibile l’accesso
al sistema tramite login utilizzando le credenziali del proprio account.
1.2.2
Progetto 2: Applicazione per il calcolo di percorsi e ricerca
punti di interesse
Il secondo prodotto sviluppato è un’applicazione web sviluppata mediante l’uso
delle API|g| di Google Maps|g| che consente all’utente la ricerca di percorsi, distanze
e punti d’interesse e di visualizzare i risultati direttamente sulla mappa.
Il contesto di utilizzo del prodotto è situato in un ambito aziendale, nello specifico
un’azienda di trasporti: l’idea è nata dall’esigenza dell’azienda di fornire in tempi
rapidi al cliente l’elenco delle distanze chilometriche tra una località ed il resto
dei capoluoghi di provincia italiani in modo da poter essere informato sulle tariffe
applicabili al trasporto di merci lungo un determinato percorso.
L’azienda è inoltre interessata al calcolo di percorsi tra due punti e la ricerca di
punti d’interesse lungo il percorso; nello specifico, si desidera ricercare la presenza di
aziende clienti ad una certa distanza dal percorso e visualizzarne la posizione ed i
dettagli sulla mappa.
Le funzionalità principali del prodotto sono riassunte nei seguenti punti:
• Utilizzo del servizio Google Maps: l’applicazione consente di interagire
con varie funzionalità messe a disposizione dal servizio Maps di Google
• Calcolo di un percorso tra due località: è possibile visualizzare un percorso tra due località e relativi dettagli, come eventuali aziende clienti nelle
vicinanze
• Calcolo delle distanze chilometriche: è possibile ottenere l’elenco delle
distanze chilometriche su strada tra una località e tutti i capoluoghi di provincia
italiani
• Accessibilità via web: il prodotto è accessibile e fruibile collegandosi alla
sua pagina web
Pagina 3 di 79
1.3. METODOLOGIA DI SVILUPPO
• Download dei risultati: l’applicazione consente agli utenti di scaricare i
risultati di una ricerca in un formato utilizzabile nei più diffusi editor di fogli
di calcolo
1.3
Metodologia di sviluppo
L’azienda Nextep srl utilizza il metodo agile, nello specifico lo Scrum, per lo
sviluppo di gran parte dei propri prodotti, che consente di produrre in breve tempo
versioni di prodotto funzionante per tenere aggiornato il cliente e rispondere prontamente alle sue esigenze.
La metodologia agile è nata nei primi anni del Duemila con l’obiettivo di ridurre i
tempi di sviluppo del software ed il rischio di fallimenti che affliggono gran parte dei
progetti: basandosi sulla produzione di piccole parti di software in un breve lasso
di tempo si ha un maggior controllo su eventuali difetti che possono essere corretti
tempestivamente evitando sostanziali perdite di tempo e risorse.
Lo sviluppo del prodotto è formato da un certo numero di iterazioni, che comprendono analisi dei requisiti, progettazione e sviluppo di una parte del prodotto finale,
con l’obiettivo di mantenere costantemente aggiornato il committente, il quale può
verificare di persona lo stato di avanzamento del prodotto e fornire dei feedback1
agli sviluppatori: si ottiene così un maggior controllo e reattività nel caso in cui si
verifichi una variazione dei requisiti in corso d’opera.
Il metodo agile si fonda sui seguenti principi:
• Le risorse più importanti del progetto sono le persone e le loro relazioni
• Il software funzionante è più importante della documentazione, che passa in
secondo piano e si limita al minimo indispensabile
• L’obiettivo primario è la soddisfazione del cliente, conseguibile con una costante
collaborazione
• È necessario essere reattivi ed adattarsi alle esigenze di cambiamento per far
parte del team di sviluppo
Uno degli obiettivi dello stage era quello di mettere in gioco lo studente consentendo di sperimentare in prima persona il metodo agile, che al giorno d’oggi è molto
diffuso nell’ambito dello sviluppo del software: per questo motivo, uno dei principali
obiettivi è stato quello di ottenere il prima possibile una versione funzionante del
prodotto richiesto dal committente in modo da poterlo coinvolgere e rispondere
prontamente alle sue esigenze.
1
Il processo per cui l’effetto risultante dall’azione di un sistema si riflette sul sistema stesso per
variarne o correggerne opportunamente il funzionamento: in questo caso si intendono commenti e
considerazioni sulla parte di software finora sviluppata con lo scopo di correggerne eventuali errori e
migliorarla
Pagina 4 di 79
CAPITOLO 1. INTRODUZIONE
1.3.1
Il metodo scrum
Lo Scrum è un metodo di sviluppo agile, iterativo e incrementale, per la gestione
di progetti software basato su su tre punti: Sprint, Backlog e Scrum Meeting.
Gli sprint sono la parte principale della metodologia Scrum e corrispondono ai blocchi
di lavoro in cui il progetto viene diviso e al termine dei quali viene prodotta una
versione non completa ma funzionante del prodotto.
Il backlog e una lista di requisiti ordinata secondo dei parametri, mentre gli Scrum
Meeting sono degli incontri giornalieri interni al team di sviluppo della durata di
15-20 minuti. Questo modello di sviluppo si adatta molto velocemente alle esigenze
dei clienti, che notoriamente non hanno idee ben chiare e definite sul prodotto che
desiderano ed è quindi alta la probabilità di modifica dei requisiti in corso d’opera,
che verrà pianificata e realizzata a partire dallo sprint successivo.
Di conseguenza, dopo un’iniziale studio e valutazione degli strumenti e le tecnologie
di Google che avrebbero potuto essere utilizzate nello sviluppo delle applicazioni, il
lavoro è stato suddiviso nelle seguenti attività per ogni sprint:
• Analisi dei requisiti: con lo scopo di produrre nel più breve tempo possibile
un prototipo del prodotto finale si sono fissati i requisiti minimi da soddisfare
• Progettazione: il sistema e le sue componenti è stato progettato in modo da facilitare la manutenzione e aggiunta di funzionalità successive al soddisfacimento
dei requisiti minimi individuati dall’analisi
• Codifica: l’attività di codifica ha avuto il compito di realizzare il sistema
secondo le specifiche della progettazione
• Documentazione: coerentemente con la filosofia dei metodi agili è stata
prodotta la documentazione di supporto che comprende Analisi dei Requisiti e
Specifica Tecnica
• Verifica: della documentazione e del codice prodotto
Questo metodo risulta particolarmente efficace quando il team di sviluppo è composto da personale dinamico capace di adattarsi ad inevitabili cambiamenti, anche
radicali, dei requisiti in corso d’opera che possono derivare dalla continua interazione
con il committente, aspetto da non sottovalutare in quanto il coinvolgimento del
cliente può contribuire alla buona riuscita del progetto limitando i rischi di fallimenti,
consentendo la modifica del prodotto in fase di sviluppo in tempi rapidi.
I metodi agili presentano tuttavia alcuni aspetti negativi come la scarsa documentazione a supporto del progetto, essendo l’attenzione focalizzata sullo sviluppo di
versioni di prodotto funzionanti piuttosto che sui documenti.
Questo può comportare problematiche di manutenzione nel caso sia necessaria l’aggiunta di nuove funzionalità.
Pagina 5 di 79
1.4. OBIETTIVI DEL PROGETTO
1.4
Obiettivi del progetto
Lo stage proponeva il raggiungimento di vari obiettivi tra i quali:
• Obiettivi formativi per lo studente
– Migliorare le capacità di lavoro all’interno di un team
– Apprendimento di nuove tecnologie
– Apprendimento della metodologia di lavoro Scrum
• Obiettivi minimi del progetto
– Studio dell’idoneità delle Google Apps a supporto dei processi dell’azienda
cliente
– Sviluppo del prototipo dell’applicazione, in modo da soddisfare almeno
una delle quattro richieste elencate in precedenza
• Obiettivi massimi del progetto
– Sviluppo di funzionalità aggiuntive al prodotto
Un ultimo obiettivo opzionale riguardava l’approfondimento di un altro dei quattro punti elencati in sezione 1.2 qualora si fosse riuscito a completare in tempi
relativamente brevi lo sviluppo del primo progetto affrontato: questo è stato reso
possibile dal fatto che il team di sviluppo era composto da due persone oltre al
costante supporto offerto dal personale di Nextep.
Nei capitoli successivi verranno analizzati nel dettaglio i due progetti realizzati, mettendo in evidenza le tecnologie utilizzate e le scelte implementative più
significative.
Pagina 6 di 79
CAPITOLO 2. SISTEMA PER LA NAVIGAZIONE DEL DATABASE
DELL’INVENTARIO PRODOTTI
Capitolo 2
Sistema per la navigazione del
database dell’inventario prodotti
2.1
Descrizione del contesto
In questo capitolo verranno descritte nel dettaglio le attività svolte per lo sviluppo
del primo punto riportato in sezione 1.2, ovvero:
Integrazione dei dati con database esistenti tramite architetture REST
In particolare è stato richiesto lo sviluppo di un’applicazione web che permettesse la
navigazione dei dati presenti nel database del committente come riportato in sezione
1.2.1.
Il suo impiego è collocato in un ambito aziendale e lavorativo ed è ad uso esclusivo
dell’azienda del cliente, pertanto è stato necessario proibire l’accesso al sistema da
parte diutenti non autorizzati.
Segue l’elenco delle principali caratteristiche richieste:
• Necessità di integrare il servizio offerto dall’applicazione con gli account Google
dei dipendenti dell’azienda, in modo da potervi accedere e interagirvi senza
effettuare il login al sistema secondo il metodo tradizionale1 .
• Implementazione di un’area riservata all’amministratore del sistema dedicata
alla gestione degli account utente e dei permessi di accesso all’applicazione
• Implementazione di un sistema di navigazione dei dati del database aziendale,
con la possibilità di visualizzare i dettagli tecnici di un singolo prodotto ed
effettuare richieste di fornitura all’ufficio addetto
L’obiettivo assegnato al team di sviluppo è stato quello di analizzare il problema,
producendo il documento Analisi dei Requisiti, progettare e realizzare un prototipo
funzionante del sistema che implementasse tutti i punti riportati nel precedente elenco.
1
Inserimento di username e password previa registrazione al sistema
Pagina 7 di 79
2.1. DESCRIZIONE DEL CONTESTO
2.1.1
Tipologia di utente
La necessità di dedicare una sezione relativa alla gestione degli account e dei
premessi d’accesso ha portato alla distinzione tra due categorie di utenti:
• Utente Generico: Si definisce Utente Generico un utente che ha accesso al
sistema, suddiviso ulteriormente in due sottocategorie:
– Utente Google: Utente provvisto di account Google che può utilizzare
per effettuare l’accesso
– Utente Non Google: Utente non provvisto di account Google che
può accedere al sistema con le credenziali precedentemente fornitegli
dall’Utente Amministratore
• Utente Autenticato: Si definisce Utente Autenticato un generico utente che
ha il permesso di accedere al sistema ed interagire con le sue funzionalità
• Utente Amministratore: Si definisce Utente Amministratore un utente provvisto di privilegi di Amministratore che gli consente di accedere a funzionalità
aggiuntive rispetto a quelle di un Utente Autenticato, come ad esempio:
– Aggiungere nuovi account utente o rimuovere quelli esistenti
– Gestione dei premessi d’accesso al sistema
– Visualizzazione dei log delle attività
Pagina 8 di 79
CAPITOLO 2. SISTEMA PER LA NAVIGAZIONE DEL DATABASE
DELL’INVENTARIO PRODOTTI
2.1.2
Casi d’uso
Di seguito sono riportati i casi d’uso principali identificati per il progetto, con
particolare attenzione alle due modalità d’accesso al sistema, le modalità di interazione
con il database e la sezione amministrativa.
Ambiente Utente Generico
UCGe 1.1.1: Login non Google
Figura 2.1: Caso d’uso: Autenticazione Utente Non Google
Attori principali: Utente Non Google
Attori secondari: /
Precondizione: Il sistema propone la schermata di autenticazione per Utenti non
provvisti di account Google
Postcondizione: Il sistema ha riconosciuto come validi i dati inseriti
Scenario principale: L’Utente Non Google si trova nella sezione relativa al login e:
• Inserisce indirizzo e-mail (UCGe 1.1.1.1)
• Inserisce la password (UCGe 1.1.1.2)
• Il sistema riconosce l’utente come autenticato
Scenario secondario: I dati inseriti dall’utente non sono validi, pertanto:
• L’autenticazione non va a buon fine
• Il sistema lo segnala all’utente
Pagina 9 di 79
2.1. DESCRIZIONE DEL CONTESTO
UCGe 1.1.2: Login con account Google
Figura 2.2: Autenticazione Utente Google
Attori principali: Utente Google
Attori secondari: /
Precondizione: Il sistema propone la schermata di autenticazione per Utenti
provvisti di account Google
Postcondizione: Il sistema ha riconosciuto come validi i dati inseriti
Scenario principale: L’Utente Google si trova nella sezione relativa al login e:
• Può inserire indirizzo e-mail del proprio account Google(UCGe 1.1.2.1)
• Può inserire la password del proprio account Google (UCGe 1.1.2.2)
• Può effettuare l’accesso diretto se è attiva nel browser la sessione del proprio
account Google (UCGe 1.1.2.3)
• Il sistema riconosce l’utente come autenticato
Pagina 10 di 79
CAPITOLO 2. SISTEMA PER LA NAVIGAZIONE DEL DATABASE
DELL’INVENTARIO PRODOTTI
Scenario secondario: I dati inseriti dall’utente non sono validi, pertanto:
• L’autenticazione non va a buon fine
• Il sistema lo segnala all’utente
Ambiente Utente Autenticato
Di seguito sono riportati i casi d’uso relativi all’ambiente Utente Autenticato
UC 1: Interazione con il sistema
Figura 2.3: Sezione di interazione con il sistema
Attori principali: Utente Autenticato
Attori secondari: Utente Amministratore
Precondizione: Il sistema ha riconosciuto l’Utente e propone le proprie funzionalità
Postcondizione: Il sistema ha permesso l’interazione all’Utente Autenticato
Scenario principale: L’Utente Autenticato si trova nella pagina principale e può:
• Effettuare interrogazioni al database (UC 1.1)
• Effettuare il logout (UC 1.2)
Scenario secondario: L’utente è autenticato come Amministratore, pertanto oltre
alle azioni sopra elencate può:
• Accedere alla sezione di gestione degli utenti (UC 1.3)
• Visualizzare log di attività del sistema (UC 1.4)
Pagina 11 di 79
2.1. DESCRIZIONE DEL CONTESTO
UC 1.1: Interrogazione al database
Figura 2.4: Sezione di interrogazione al database
Attori principali: Utente Autenticato
Attori secondari: Utente Amministratore
Precondizione: Il sistema ha riconosciuto l’Utente e propone le proprie funzionalità
Postcondizione: Il sistema ha permesso l’interazione all’Utente Autenticato
Scenario principale: L’Utente Autenticato si trova nella pagina principale e può:
• Navigare il database inserendo parametri di ricerca oppure ordinando le colonne
della tabella (UC 1.1.1)
• Visualizzazione dettagli di uno specifico prodotto (1.1.2)
• Ordinare la fornitura del prodotto inserendone la quantità richiesta (1.1.3)
Scenario secondario: L’utente è autenticato come Amministratore, pertanto oltre
alle azioni sopra elencate può:
• Accedere alla sezione di gestione degli utenti (UC 1.3)
• Visualizzare log di attività del sistema (UC 1.4)
Pagina 12 di 79
CAPITOLO 2. SISTEMA PER LA NAVIGAZIONE DEL DATABASE
DELL’INVENTARIO PRODOTTI
UC 1.3: Sezione Amministrativa
Figura 2.5: Sezione amministrativa
Attori principali: Utente Amministratore
Attori secondari: /
Precondizione: L’Utente ha effettuato l’accesso come Amministratore
Postcondizione: Il sistema ha permesso l’interazione all’Utente Amministratore
Scenario principale: L’Utente Amministratore si trova nella sezione dedicata
all’amministrazione del sistema e può:
• Inserire un nuovo utente nel sistema (UC 1.3.1)
• Disabilitare temporaneamente l’accesso ad un determinato account (UC 1.3.2)
• Abilitare l’accesso ad un account precedentemente disabilitato (UC 1.3.3)
• Eliminare un account dal sistema (UC 1.3.4)
• Modificare la password di un utente (UC 1.3.5)
• Assegnare o revocare privilegi di amministrazione ad un utente (UC 1.3.6)
Pagina 13 di 79
2.2. CLASSIFICAZIONE DEI REQUISITI
2.2
Classificazione dei requisiti
Le seguenti tabelle riportano i principali requisiti individuati per l’applicazione.
La notazione utilizzata è la seguente:
<R><O><F|T><Ge|A|Ad>2 -X<.Y<.Z> >
Dove:
• R: Requisito
• O: Obbligatorio
• F: Funzionale
• T: Tecnologico
• Ge: Ambito utente generico
• A: Ambito utente autenticato
• Ad: Ambito utente amministratore
• X: Requisito di primo livello
• Y: Sotto-requisito
• Z: Sotto-requisito di un sotto-requisito
I requisiti sono così classificati:
2.2.1
Vincoli tecnologici generali
Codice
Requisito
ROT-1
Il sistema deve essere realizzato mediante l’uso di Google App
Engine
ROT-2
Il sistema deve essere integrato con il servizio Google Accounts
ROT-3
Il sistema deve interfacciarsi con il database del committente
senza duplicare i dati in un altro database
Tabella 2.1: Progetto 1 - Vincoli tecnologici generali
2
La sigla Ge-A-Ad può essere omessa in alcuni requisiti in quanto relativa a diversi ambiti di
utente
Pagina 14 di 79
CAPITOLO 2. SISTEMA PER LA NAVIGAZIONE DEL DATABASE
DELL’INVENTARIO PRODOTTI
2.2.2
Ambito utente non autenticato
Codice
Requisito
ROFGe-1
Il sistema deve consentire all’utente di autenticarsi
ROFGe-1.1
Il sistema deve consentire all’utente di autenticarsi sia tramite il suo account Google sia tramite l’account fornito
dall’amministratore del sistema
ROFGe-1.1.1
Il sistema deve consentire all’utente di autenticarsi inserendo le
proprie credenziali
ROFGe1.1.1.1
Il modulo di login deve richiedere all’utente l’indirizzo e-mail
ROFGe1.1.1.2
Il modulo di login deve richiedere all’utente la password
ROFGe-1.1.2
Il sistema deve consentire all’utente di autenticarsi mediante il
proprio account Google
ROFGe1.1.2.1
Il modulo di login Google deve richiedere all’utente l’indirizzo
e-mail
ROFGe1.1.2.2
Il modulo di login Google deve richiedere all’utente la password
ROFGe1.1.2.3
Il sistema deve consentire l’accesso all’utente Google se è attiva
una sessione nel proprio browser
Tabella 2.2: Progetto 1 - Ambito utente non autenticato
2.2.3
Ambito utente autenticato
Codice
Requisito
ROFA-1.1
Il sistema deve consentire all’utente di effettuare ricerche nel
database
ROFA-1.2
Il sistema deve consentire all’utente visualizzare i dettagli di un
prodotto
ROFA-1.3
Il sistema deve consentire all’utente effettuare l’ordinazione di un
prodotto
ROFA-1.3.1
Il sistema deve consentire all’utente di inserire la quantità di
prodotto desiderata
ROFA-1.2
Il sistema deve consentire all’utente di effettuare il logout
Pagina 15 di 79
2.2. CLASSIFICAZIONE DEI REQUISITI
ROFAd-1.3.
Il sistema deve consentire all’utente amministratore di gestire gli
account
ROFAd-1.3.1
Il modulo di gestione degli account permette all’amministratore
di inserire un nuovo utente nel sistema
ROFAd-1.3.2
Il modulo di gestione degli account permette all’amministratore
di disabilitare temporaneamente l’accesso all’applicazione ad un
utente
ROFAd-1.3.3
Il modulo di gestione degli account permette all’amministratore
di abilitare l’accesso all’applicazione ad un utente
ROFAd-1.3.4
Il modulo di gestione degli account permette all’amministratore
eliminare permanentemente un account dal sistema
ROFAd-1.3.5
Il modulo di gestione degli account permette all’amministratore
di modificare la password di accesso al sistema di un utente
ROFAd-1.3.6
Il modulo di gestione degli account permette all’amministratore
di assegnare o revocare i privilegi di amministrazione ad un utente
ROFAd-1.4
L’applicazione deve permettere all’amministratore di visualizzare
il log delle attività di sistema
Tabella 2.3: Progetto 1 - Ambito utente autenticato
Pagina 16 di 79
CAPITOLO 2. SISTEMA PER LA NAVIGAZIONE DEL DATABASE
DELL’INVENTARIO PRODOTTI
2.3
Tecnologie
In questa sezione sono riportate le principali tecnologie impegate dal team di
sviluppo per la realizzazione dell’applicazione e le motivazioni che hanno portato alla
loro scelta.
Lo scopo principale dello stage era di studiare e sperimentare le funzionalità dei tool
offerti da Google per lo sviluppo di applicazioni web, pertanto si è scelto di realizzare
il sistema utilizzando il servizio dell’azienda di Mountain View Google App Engine.
2.3.1
La piattaforma Google App Engine
Figura 2.6: Struttura generale di Google App Engine
Gogle App Engine (in sigla GAE) è una piattaforma di cloud computing disponibile come servizio PaaS|g| che consente l’esecuzione di applicazioni web nei Google
Data Center|g| offrendo numerosi vantaggi tra i quali la scalabilità automatica, che
esonera gli sviluppatori da oneri derivanti dalla gestione delle risorse hardware e
software dovute al crescere delle dimensioni e l’uso del sistema da parte degli utenti.
Pagina 17 di 79
2.3. TECNOLOGIE
La scelta di impiegare GAE come piattaforma di sviluppo e hosting dell’applicazione è stata dettata principalmente dai seguenti motivi:
• Interesse da parte dell’azienda nella sperimentazione del servizio allo scopo di
valutarne le potenzialità e limitazioni per eventuali usi futuri
• Pieno supporto e compatibilità con tutte le API dei servizi Google, come ad
esempio Contacts, Accounts e Maps
• Disponibilità di ambienti di sviluppo per applicazioni scritte in vari linguaggi
di programmazione tra cui Java, PHP e Python
Il servizio offerto è inizialmente gratuito, in quanto vengono messi a disposizione 1
GB per lo storage di dati e una potenza computazionale sufficiente per l’esecuzione di
applicazioni di medie e piccole dimensioni, che sono risultati adeguati allo sviluppo del
progetto; sono comunque presenti limitazioni nell’uso delle risorse della piattaforma
che, una volta superata la soglia fissata, è soggetto a tassazione da parte di Google.
L’uso di App Engine a mio avviso è molto valido nel caso in cui si vogliano evitare costi
di manutenzione (temporali ed economici) derivanti dalla scalabilità dell’applicazione
e sia necessario utilizzare le API di uno dei tanti servizi resi disponibili da Google: il
programmatore è però soggetto ad alcune costrizioni che verranno analizzate nella
sezione successiva.
Limitazioni dell’ambiente sandbox
Le applicazioni ospitate nei Data Center di Google vengono eseguite in un
ambiente sicuro ed isolato che limita l’interazione con il sistema operativo sottostante
rendendole indipendenti dall’hardware e dall’ubicazione del server nelle quali sono
ospitate.
Se da un lato questo garantisce un’elevata sicurezza dei dati, sono presenti numerose
limitazioni da tenere in considerazione:
• L’applicazione non ha accesso in scrittura al file system sottostante e pertanto
può solamente accedere ai file in lettura previo upload nel sistema utilizzando
il codice dell’applicazione fornito agli sviluppatori3
• L’accesso a sistemi esterni, come ad esempio database o altri computer, può
essere effettuato esclusivamente tramite richieste HTTP|g| e HTTPS al loro
URL|g| oppure mediante il servizio e-mail messo a disposizione dalle apposite
API.
• Come conseguenza del punto precedente lo storage dei dati deve essere effettuato
in uno dei servizi messi a disposizione da Google come App Engine Datastore|g| e
Google Cloud SQL|g|
3
Nel momento in cui un’applicazione web viene caricata e registrata presso la piattaforma App
Engine le viene assegnato un codice che la identifica univocamente
Pagina 18 di 79
CAPITOLO 2. SISTEMA PER LA NAVIGAZIONE DEL DATABASE
DELL’INVENTARIO PRODOTTI
Uno dei problemi principali riscontrati nella realizzazione del sistema è stata la
limitazione nell’accesso a sistemi esterni all’ambiente di App Engine: era richiesto
l’uso del database aziendale del committente per evitare di duplicare inutilmente i
dati nei servizi di storage sopra citati ma la connessione diretta non era un’opzione
possibile e di conseguenza è stato necessario trovare un punto di comunicazione.
Il problema è stato ovviato mediante l’implementazione di un web service che
permette di richiedere i dati necessari tramite la tecnologia REST: in questo modo,
l’applicazione può essere ospitata nei server di Google ma allo stesso tempo di
accedere al database dell’azienda ricevendo le informazioni utili.
Le motivazioni che hanno portato alla scelta di impiegare REST piuttosto che altre
modalità di comunicazione tra sistemi distribuiti sono analizzate di seguito.
2.3.2
La tecnologia REST
Il termine REST, acronimo di Representational State Transfer, è stato coniato
da Roy Fielding, uno dei principali autori del famoso HyperText Transfer Protocol,
nella sua tesi di dottorato nell’anno 2000.
Figura 2.7: Struttura dell’architettura REST
REST identifica un tipo di architettura software che permette la comunicazione
tra sistemi distribuiti nel World Wide Web ed è basato sul semplice uso del protocollo
HTTP senza utilizzare complessi meccanismi come CORBA|g| o SOAP|g| : per certi
versi si può affermare che l’intero web, essendo basato su HTTP, sia un esempio di
architettura fondata su questo principio.
Una delle caratteristiche fondamentali di REST è la risorsa, intesa come fonte di
informazione, che può essere acceduta tramite URI|g| dalle componenti della rete,
i client ed il server, i quali si scambiano una delle sue possibili rappresentazioni,
le quali comprendono una formattazione dei dati in formato SVG, CSV|g| , oppure
JSoN|g| .
Pagina 19 di 79
2.3. TECNOLOGIE
La scelta di impiegare questa tecnologia per implementare la comunicazione tra
la nostra applicazione ed i sistemi dell’azienda cliente è dovuta principalmente dai
seguenti fattori:
• REST è indipendente dal linguaggio di programmazione in cui i due sistemi
che vengono messi in comunicazione sono implementati
• I sistemi operativi installati sui client e sul server non sono rilevanti e non
interferiscono sul corretto funzionamento della tecnologia
• L’uso di HTTP permette il trasferimento di dati in formati comprensibili da
tutti e due i punti di comunicazione, come ad esempio JSoN
• L’accesso ai dati può essere effettuato semplicemente tramite richieste HTTP,
come ad esempio GET e POST, all’URL della risorsa
L’implementazione di un web service basato su REST ha permesso di risolvere il
problema di comunicazione tra la nostra applicazione ospitata sulla piattaforma App
Engine e il database del cliente basato su Microsoft SQL Server 2008, permettendo
l’accesso in lettura ai dati ad esso contenuti e di sviluppare così le funzionalità
richieste dal sistema.
2.3.3
Strumenti di sviluppo
Per lo sviluppo dell’applicazione si è scelto di utilizzare l’IDE|g| Eclipse in quanto
già conosciuto dai membri del team ed estendibile con il plug-in Pydev che offre
l’ambiente di sviluppo per linguaggio Python.
È stato inoltre ritenuto opportuno fare uso di un repository per il controllo di versione
e per facilitare il lavoro di gruppo: la scelta è ricaduta su Bitbucket, strumento già
utilizzato per progetti precedenti.
2.3.4
Principali tecnologie utilizzate
• Google App Engine: piattaforma di cloud computing per lo sviluppo e
hosting di applicazioni web gestite dai Google Data Center
– Vantaggi:
∗ Integrazione con tutti i servizi Google, incluse le librerie di API utilizzabili per implementare funzionalità standard come l’autenticazione
via email
∗ Scalabile: App engine offre una scalabilità automatica per le applicazioni a seconda del numero di richieste d’uso per quella applicazione,
allocando più risorse per gestire la domanda addizionale
∗ Hosting nei Google Data Center: gli sviluppatori sono esenti da oneri
relativi alla manutenzione del server
Pagina 20 di 79
CAPITOLO 2. SISTEMA PER LA NAVIGAZIONE DEL DATABASE
DELL’INVENTARIO PRODOTTI
∗ Supporto a diversi linguaggi di programmazione: App Engine supporta
vari linguaggi di programmazione come Java,Python,PHP
∗ Basi di dati: sono disponibili agli sviluppatori tre tipi di database a
seconda delle esigenze, tra cui App Engine Datastore (schemaless),
Google Cloud SQL (relazionale) e Google Cloud Storage (per grandi
moli di dati)
– Svantaggi:
∗ Ambiente sandbox: un’applicazione sviluppata in App Engine è soggetta a varie limitazioni, come ad esempio l’impossibilità di connettersi
a database esterni all’ambiente Google. L’applicazione può comunicare verso l’esterno solo tramite richieste HTTP e mediante i servizi
e-mail
• Python: linguaggio di programmazione ad alto livello orientato agli oggetti, adatto allo sviluppo di applicazioni distribuite, scripting, computazione
numerica e system testing.
– Vantaggi:
∗ Supportato da Google App Engine: il servizio Google mette a disposizione agli sviluppatori l’ambiente di sviluppo (SDK|g| ) per il
linguaggio Python
∗ Portabilità: il codice sorgente può essere interpretato ed eseguito sulla
gran parte delle piattaforme attualmente utilizzate, siano esse di casa
Apple (Mac) che PC (Microsoft Windows e GNU/Linux)
∗ Open source: Python può essere liberamente modificato secondo le
regole di una licenza pienamente open-source, ed il suo utilizzo è
completamente gratuito
∗ Semplicità d’uso: l’apprendimento di Python è immediato per programmatori che conoscono già altri linguaggi come Java o C++, e
consente di scrivere codice efficiente con minimo sforzo
– Svantaggi: Non sono stati riscontrati svantaggi degni di nota
• HTML|g| : linguaggio di markup ampiamente utilizzato per lo sviluppo di
pagine web
– Vantaggi:
∗ Standard: il linguaggio HTML è definito cone standard dal W3C|g|
∗ Browser: HTML è supportato dalla maggioranza dei browser web
– Svantaggi:
∗ Non sono stati riscontrati svantaggi significativi
• JavaScript: Linguaggio di scripting comunemente usato nei siti web
Pagina 21 di 79
2.3. TECNOLOGIE
– Vantaggi:
∗ Carico del server: Javascript permette di delegare script di calcolo a
livello client-side, diminuendo il carico di lavoro del server che può
essere impiegato in altre operazioni
∗ Pagine web dinamiche: Gli script JavaScript offrono la possibilità
di creare pagine web dinamiche reattive alle azioni dell’utente che le
utilizza
– Svantaggi:
∗ Disattivabile: L’esecuzione degli script può essere disattivata dal
browser dell’utente e in tal caso non si potrà usufruire di eventuali
funzionalità presenti
Pagina 22 di 79
CAPITOLO 2. SISTEMA PER LA NAVIGAZIONE DEL DATABASE
DELL’INVENTARIO PRODOTTI
• CSS3: Linguaggio impiegato per l’aspetto grafico dell’applicazione
– Vantaggi:
∗ Separazione: Si ritiene opportuno usare il CSS in quanto offre una
buona separazione tra presentazione e contenuto. Tale divisione
permette di avere file HTML più leggeri
∗ Manutenibilità: Pagine web che sfrutteranno il medesimo layout potranno appoggiarsi al medesimo file .css, con il vantaggio di apportare
eventuali modifiche una volta sola e non su tutti i rispettivi file .html
– Svantaggi:
∗ Supporto browser: Il CSS in versione 3 non è ancora pienamente
supportato da tutti i browser
• Jinja2: Linguaggio per la realizzazione di template integrabile con Python
– Vantaggi:
∗ Integrazione con Python: Jinja2 permette la realizzazione di template includendo parametri scritti in linguaggio Python e costrutti di
controllo all’interno del codice HTML
∗ Flessibile: il rendering dei template HTML può essere effettuato in
modo dinamico a seconda delle esigenze con parametri personalizzabili
– Svantaggi:
∗ Non sono stati riscontrati svantaggi significativi
• JQuery Data Tables: Plug-in per la libreria JavaScript JQuery
– Vantaggi:
∗ Navigazione tabelle: Data Tables permette la realizzazione di query
di ricerca su di una tabella in modo dinamico lato client diminuendo
il carico di lavoro del server, aumentando in modo significativo la
velocità della ricerca
∗ Personalizzabile: sono disponibili varie opzioni come impaginazione
automatica, filtri di ricerca, resize tabella automatico, sorting di
colonne in base al tipo di dato trattato
– Svantaggi:
∗ Non sono stati riscontrati svantaggi significativi
• Webapp2: Web framework per Python fornito da Google App Engine
– Vantaggi:
∗ Funzionalità: Webapp2 fornisce le API per la gestione delle sessioni
utente e autenticazione tramite account Google
Pagina 23 di 79
2.3. TECNOLOGIE
∗ MVC: webapp2 facilita la realizzazione dell’architettura del sistema
in MVC|g| fornendo la struttura e le funzionalità del controller
– Svantaggi:
∗ L’uso di webapp2 è limitato ad applicazioni sviluppate in Google App
Engine: un eventuale migrazione verso altre piattaforme comporterebbe un onere aggiuntivo per l’adattamento
Pagina 24 di 79
CAPITOLO 2. SISTEMA PER LA NAVIGAZIONE DEL DATABASE
DELL’INVENTARIO PRODOTTI
2.4
Progettazione del sistema
La presente sezione fornisce una definizione dettagliata dell’architettura del sistema attraverso un approccio top-down. Vengono inizialmente elencati e descritti i
design pattern|g| utilizzati, a seguire per ogni sotto-sistema viene presentata dapprima
la struttura dei componenti, poi vengono specificate le classi,ed infine di ogni classe
significativa si indicano metodi e campi dati. In questa sezione l’attenzione sarà
focalizzata sulla parte di sistema da me progettata e realizzate ovvero il back-end
dell’applicazione.
2.4.1
Design Pattern utilizzati
Design pattern architetturali
MVC
Figura 2.8: Struttura generale del design pattern MVC
• Descrizione: Il design pattern MVC è un pattern architetturale molto diffuso
in sistemi software object-oriented che permette di strutturare l’applicazione
mediante la separazione nelle tre componenti Model, View e Controller. In
questo modo si separano le parti che formano l’interfaccia grafica, con il quale
l’utente interagisce, dalle componenti che costituiscono la business logic
• Giustificazione: La scelta del MVC deriva dall’esigenza di fornire una
struttura all’applicazione aumentandone la manutenibilità e distribuendo
adeguatamente le responsabilità alle componenti
• Applicazione: Il design pattern MVC viene utilizzato nell’applicazione per
strutturare il codice scritto in linguaggio Python
• Conseguenze:Applicando questo design pattern si ottiene una separazione
netta tra la business logic e le componenti che si occupano di rendere i dati
comprensibili all’utente. L’applicazione viene dunque divisa in tre parti:
Pagina 25 di 79
2.4. PROGETTAZIONE DEL SISTEMA
– View: Rappresenta l’interfaccia grafica con il quale l’utente interagisce, e
comprende template HTML e fogli di stile CSS
– Controller: Componente che comunica con il front-end ricevendo l’input
dell’utente e restituendo alla view i risultati elaborati dal model
– Model: Rappresenta il modello dei dati sui quali il controller interagisce
e modifica in seguito alle richieste dell’utente. Include inoltre il database
App Engine Datastore dove vengono salvati i dati degli utenti ed i log
delle attività del sistema
L’architettura descritta, oltre a permettere una separazione tra le funzionalità dell’applicazione, aumenta la manutenibilità del prodotto in quanto ogni modifica ad
una delle componenti è circoscritta allo strato stesso influendo il meno possibile
all’esterno ed ottenendo un basso indice di accoppiamento tra le parti.
Essendo richiesta la realizzazione di un prototipo, si è ritenuto strutturare l’applicazione in modo tale da consentire l’aggiunta e la modifica di componenti in modo
agevole.
Pagina 26 di 79
CAPITOLO 2. SISTEMA PER LA NAVIGAZIONE DEL DATABASE
DELL’INVENTARIO PRODOTTI
Design pattern comportamentali
Data Access Object
Figura 2.9: Struttura del design pattern Data Access Object
• Descrizione: Questo design pattern permette di interfacciarsi in modo semplice e trasparente con un database. Data Access Object è un oggetto che
fornisce un’interfaccia astratta alla persistenza dei dati. Mappando le chiamate
dell’applicazione al livello di persistenza, fornisce alcune specifiche operazioni
sui dati senza esporre i dettagli della base di dati sottostante
• Giustificazione: L’utilizzo di questo design pattern minimizza le modifiche
da apportare all’applicazione nel caso in cui sia necessario modificare il meccanismo di persistenza dei dati o la base di dati stessa e nasconde i dettagli
relativi al salvataggio dei dati al resto dell’applicazione. Agisce infatti come un
intermediario tra l’applicazione e il database sottostante
• Applicazione: Tale design pattern è utilizzato nel livello dataStoreAccess del
Model
• Conseguenze: L’utilizzo di tale design pattern è garanzia di buona portabilità
dell’applicazione. Offrendo un buon livello di astrazione, si adatta a molti
linguaggi di programmazione, tipologie di software e tipi differenti di database
Pagina 27 di 79
2.4. PROGETTAZIONE DEL SISTEMA
Command
Figura 2.10: Struttura del design pattern Command
• Descrizione: Il design pattern Command rientra nella categoria dei design
pattern comportamentali e permette di isolare la porzione di codice che effettua
un’azione dal codice che ne richiede l’esecuzione. L’azione è quindi incapsulata
nell’oggetto Command. L’obiettivo è rendere variabile l’azione del client senza
però conoscere i dettagli dell’operazione stessa
• Giustificazione:L’uso del design pattern Command deriva dalla necessità di
poter variare l’azione richiamata da un client senza informare quest’ultimo
su tale variazione. L’interfaccia messa a disposizione dai Command pertanto
deve essere stabile e costante, variando solo l’implementazione effettiva delle
sottoclassi.Il controller infatti vuole poter inoltrare varie richieste, diverse tra
loro, allo strato inferiore, attraverso un’interfaccia unificata e comune alle
diverse richieste
• Applicazione: Questo design pattern è applicato nel lato server dell’applicazione, come collettore tra il controller e il livello model sottostante. Le classi
coinvolte, rispetto alla nomenclatura standard del pattern, sono le seguenti.
– Invoker: src.controller.main
– Command: src.model.command.Command
– ConcreteCommand: tutte le sottoclassi di Command definite nel file
src.model.command.Command
– Receiver: Classi contenute nel package src.model.managers quali usersManager,logManager,mailManager,productManager
• Conseguenze:L’applicazione di questo design pattern disaccoppia l’oggetto
che invoca un’operazione (src.controller.main) da quello che conosce come
portarla a termine (le sottoclassi di src.model.command.Command). Inoltre
risulta semplice estendere tale gerarchia per aggiungere nuovi comandi senza
modificare quelli esistenti
Pagina 28 di 79
CAPITOLO 2. SISTEMA PER LA NAVIGAZIONE DEL DATABASE
DELL’INVENTARIO PRODOTTI
Design pattern creazionali
AbstractFactory
Figura 2.11: Struttura del design pattern Abstract Factory applicato al sistema
• Descrizione:Fornisce un’interfaccia per la creazione di famiglie di oggetti
correlati o dipendenti senza specificare quali siano le loro classi concrete
• Giustificazione:L’uso di tale design pattern permette alla classe che richiede una determinata operazione di ottenere dalla classe factory un’istanza
dell’oggetto richiesto senza bisogno di invocare direttamente la classe concreta
• Applicazione: Questo design pattern è applicato nel lato server dell’applicazione nel package src.model.factory per la creazione di oggetti di tipo UsersModel
e LogModel.
– Client: src.model.managers.logManager e src.model.managers.usersManager
– Concrete factory 1: src.model.factory.UserFactory
– Concrete factory 2: src.model.factory.LogFactory
– Concrete Product 1: src.model.dataModel.UsersModel
– Concrete Product 2: src.model.dataModel.LogModel
Pagina 29 di 79
2.4. PROGETTAZIONE DEL SISTEMA
• Conseguenze: Applicando questo pattern le classi saranno indipendenti dalle
modalità di creazione, composizione e rappresentazione dei loro prodotti, consentendo la possibilità di cambiare, rimuovere o aggiungere famiglie di prodotti
utilizzate ed evitare alle classi che utilizzano gli oggetti la responsabilità della
loro istanziazione.
2.4.2
Specifica del Back end
Il back end è la parte di sistema che riceve i dati in ingresso dal front end e li
restituisce dopo l’elaborazione: nel sistema sviluppato è costituito principalmente da
moduli scritti in linguaggio Python. Segue la descrizione dei package del back-end
dell’applicazione.
Componente Controller
Figura 2.12: Struttura del Controller
• Descrizione: il package src.controller definisce le classi che rappresentano
il Controller dell’applicazione. La classe BaseHandler deriva da
webapp2.RequestHandler ed eredita tutti i metodi necessari alla gestione di
richieste da parte del front-end, fornendo inoltre un’implementazione della
gestione delle sessioni utente delle librerie fornite dal framework webapp2.
Il modulo main.py contiene tutte le classi controller (derivate da BaseHandler)
che gestiscono le varie richieste provenienti dalla view delegando alle classi del
Model l’elaborazione dei dati e fornendo alla View il risultato, oltre a gestire
le autorizzazioni alla visualizzazione delle pagine e l’apertura/chiusura delle
sessioni utente
• Componenti utilizzate: le classi del Controller comunicano con le classi
del package src.model.command per l’elaborazione dei dati e con la classe
TemplateLoader per il passaggio dei risultati e il rendering dei template
• Classi coinvolte:
– BaseHandler: fornisce un’implementazione dei metodi relativi alla creazione, cancellazione e verifica delle sessioni utente. Ogni classe del Controller
deriva da BaseHandler
Pagina 30 di 79
CAPITOLO 2. SISTEMA PER LA NAVIGAZIONE DEL DATABASE
DELL’INVENTARIO PRODOTTI
– TemplateLoader: classe che si occupa del rendering dei template HTML
che rappresentano le pagine che verranno visualizzate dall’utente. La
classe utilizza le librerie Jinja2, che permettono la creazione di template
dinamici contenenti campi dati e costrutti di controllo
– MainPage: gestisce la richiesta derivante dall’URL ’/’, controllando se sia
presente una sessione utente attiva ed eventualmente reindirizzando il
browser alla pagina di login, altrimenti al controller della homepage
– HomePage: gestisce la richiesta derivante dall’URL ’/home’, controllando
se sia presente una sessione utente attiva e conseguentemente l’autorizzazione dell’utente alla visualizzazione della pagina. in caso affermativo, la pagina verrà mostrata all’utente mediante la chiamata del metodo loadHomePageTemplate della classe TemplateLoader del package
src.view
– LoginGoogle: gestisce la richiesta derivante dall’URL ’/loginGoogle’,
delegando il controllo dell’input a CheckLogin. Questa classe si occupa
di gestire l’autorizzazione dell’account di un utente qualora decidesse di
accedere mediante il proprio account Google
– LoginPage: gestisce la richiesta derivante dall’URL ’/login’, affidando al metodo loadLoginPageTemplate della classe TemplateLoader il
caricamento della pagina
– AdminPage: gestisce la richiesta derivante dall’URL ’/admin’,controllando
se esiste una sessione utente attiva e successivamente se l’utente in questione dispone dell’autorizzazione a visualizzare la pagina, affidando infine
al metodo loadAdminPageTemplate della classe TemplateLoader il caricamento della pagina. Nel caso in cui l’utente non sia autorizzato, viene
reindirizzato alla pagina di errore
– RegistrationHandler: gestisce la richiesta derivante dall’URL ’/registration’, ricavando i dati inseriti dalla richiesta HTTP e delegandone l’elaborazione al corrispondente command che si occuperà di effettuare la registrazione di un nuovo utente, affidando infine al metodo loadAdminTemplate
della classe TemplateLoader il caricamento della pagina comunicando
all’utente il risultato dell’operazione
– DeleteAccountRequestHandler: gestisce la richiesta derivante dall’URL
’/delete’, ricavando i dati inseriti dalla richiesta HTTP e delegandone
l’elaborazione al corrispondente command che si occuperà di effettuare la cancellazione dell’account richiesto, affidando infine al metodo
loadAdminTemplate della classe TemplateLoader il caricamento della
pagina comunicando all’utente il risultato dell’operazione
– UpdateHandler: gestisce la richiesta derivante dall’URL ’/update’, ricavando i dati inseriti dalla richiesta HTTP e delegandone l’elaborazione
al corrispondente command, che si occuperà di effettuare la modifica ad
Pagina 31 di 79
2.4. PROGETTAZIONE DEL SISTEMA
un account e affidando infine al metodo loadAdminTemplate della classe
TemplateLoader il caricamento della pagina comunicando all’utente il
risultato dell’operazione
– CheckLogin: gestisce la richiesta derivante dall’URL ’/checkLogin’, delegando al corrispondente command la verifica delle credenziali dell’utente
distinguendo tra utente normale e utente Google. Nel caso in cui le
credenziali si rivelassero valide, verrà effettuato un controllo dell’autorizzazione all’accesso, verrà create una sessione per l’utente corrente ed
il browser verrà indirizzato nella pagina adatta, che può essere la home
oppure admin. Nel caso in cui le credenziali fossero non valide oppure
l’utente non disponga dell’autorizzazione, il browser verrà indirizzato nella
pagina i errore
– LogPage: gestisce la richiesta derivante dall’URL ’/log’, delegando al corrispondente command il caricamento del log delle attività dell’applicazione,
affidando infine al metodo loadLogTemplate della classe TemplateLoader
il caricamento della pagina
– LogoutHandler: gestisce la richiesta derivante dall’URL ’/logout’, cancellando la sessione dell’utente corrente che non potrà più accedere alle
pagine dell’applicazione senza effettuare nuovamente il login. Il browser
dell’utente verrà successivamente indirizzato alla pagina di login
– LogoutHandler: gestisce la richiesta derivante dall’URL ’/logout’, cancellando la sessione dell’utente corrente che non potrà più accedere alle
pagine dell’applicazione senza effettuare nuovamente il login. Il browser
dell’utente verrà successivamente indirizzato alla pagina di login
– WebServiceFailHandler: gestisce la richiesta derivante dall’URL ’/fail’,
che avviene nel caso in cui il tentativo di connessione al web service per
il recupero dei dati dal database aziendale fallisca, affidando al metodo loadFailTemplate della classe TemplateLoader il caricamento della
pagina corrispondente
Pagina 32 di 79
CAPITOLO 2. SISTEMA PER LA NAVIGAZIONE DEL DATABASE
DELL’INVENTARIO PRODOTTI
Componente Model
Command
Figura 2.13: Struttura del design pattern command
• Descrizione: il package src.model.command è costituito dal modulo command, contenente la definizione delle sottoclassi xxxCommand concrete. Ogni
sottoclasse concreta svolge una funzione specifica che varia dalla cancellazione
di un account alla registrazione, al recupero dei dati dal App Engine DataStore
o all’invio di e-mail di notifica
• Componenti utilizzate: le classi concrete di Command comunicano con le
classi del package src.model.managers, delegando lo svolgimento delle funzioni richieste. Inoltre, comunicano con la classe Controller del package
src.controller.Main inviando i risultati delle operazioni
• Classi coinvolte:
– LoginCommand: gestisce la richiesta di login, ricevendo dal controller le
credenziali dell’utente e delegando al corrispondente manager la loro
verifica. Nel caso in cui le credenziali si rivelassero corrette, verrà inoltre
chiamato il logManager corrispondente per la creazione del log di login
– RegisterCommand: gestisce la richiesta di registrazione, ricevendo dal
controller i dati del nuovo utente e delegando al corrispondente manager
il loro salvataggio. Nel caso in cui l’operazione vada a buon fine verrà
inoltre chiamato il logManager corrispondente per la creazione del log di
registrazione
– CheckAdminCommand: gestisce la richiesta di controllo di credenziali di
amministratore, ricevendo dal controller i dati dell’utente e delegando al
Pagina 33 di 79
2.4. PROGETTAZIONE DEL SISTEMA
corrispondente manager il loro controllo, restituendo infine il risultato dal
chiamante
– CheckAllowedCommand: gestisce la richiesta di controllo di credenziali
di accesso, ricevendo dal controller i dati dell’utente e delegando al corrispondente manager il loro controllo, restituendo infine il risultato al
chiamante
– EraseUserCommand: gestisce la richiesta di eliminazione di un account,
ricevendo dal corrispondente controller i dati dell’utente e delegando al
corrispondente manager l’eliminazione dal DataStore, restituendo infine il
risultato al chiamante
– UpdateCommand: gestisce la richiesta di modifica di un account, ricevendo
dal controller i dati dell’utente e delegandone al corrispondente manager
l’aggiornamento. Nel caso in cui la password dell’utente venga modificata, quest’ultimo viene notificato tramite un’ e-mail contenente la nuova
password, e viene creato il log corrispondente
– LoadProductsCommand: gestisce la richiesta di recupero dei prodotti,
delegando al corrispondente manager il completamento dell’operazione,
inviando infine al controller il risultato
– LogCommand: gestisce la richiesta di recupero della lista dei log, delegando
al corrispondente manager il completamento dell’operazione, inviando
infine al controller il risultato
– LogoutCommand: gestisce la richiesta di logout, delegando al corrispondente
manager il completamento dell’operazione, inviando infine al controller il
risultato
– GetUsersListCommand: gestisce la richiesta di recupero della lista degli
utenti, delegando al corrispondente manager il completamento dell’operazione, inviando infine al controller il risultato
– RequestMailCommand: gestisce la richiesta di fornitura di un prodotto,
delegando al corrispondente manager il completamento dell’operazione,
inviando infine al controller il risultato
Pagina 34 di 79
CAPITOLO 2. SISTEMA PER LA NAVIGAZIONE DEL DATABASE
DELL’INVENTARIO PRODOTTI
Managers
Figura 2.14: Struttura del package Managers
• Descrizione: il package src.model.managers è costituito dai moduli userManager,
logManager,mailManager,productManager, che come suggerito dal nome si
occupano di gestire le operazioni relative ad un determinato tipo di dato e
operazione
• Componenti utilizzate: le classi del package managers comunicano con le
classi del package src.model.factory per la costruzione del tipo di oggetto
richiesto e src.model.dataStoreAccess per il salvataggio/recupero dei dati
dal DataStore
• Classi coinvolte:
– UsersManager: la classe contiene tutti i metodi necessari alla gestione dei
dati degli utenti, come login, registrazione, update, verifica autorizzazioni,
verifica di privilegi di amministrazione. Il risultato dell’operazione viene
ritornato al corrispondente command
– LogManager: la classe contiene tutti i metodi necessari alla gestione dei
log, come la crezione di log di login, logout, registrazione nuovo utente,
aggiornamento di un account, modifica di password, eliminazione di un
account. Il risultato dell’operazione viene ritornato al corrispondente
command
– MailManager: la classe contiene tutti i metodi necessari alla gestione delle
e-mail, tra cui la mail di invito al sistema, email di cambio password o
di notifica cancellazione account e l’e-mail di richiesta di fornitura di un
prodotto
– ProductManager: la classe si occupa del recupero dei dati del database
contentente tutti i prodotti che l’applicazione permette di navigare. Il
recupero avviene tramite una chiamata RESTful al web service che espone
il servizio, ottenendo i dati in formato JSoN e restituendoli al chiamante
Pagina 35 di 79
2.4. PROGETTAZIONE DEL SISTEMA
Factory
Figura 2.15: Struttura del package Factory
• Descrizione: il package src.model.factory è costituito dal modulo factories,
che ha il compito di creare l’oggetto richiesto utilizzando i parametri che riceve
in ingresso
• Componenti utilizzate: le classi del package factory comunicano con le
classi del package src.model.dataModel che contengono la definizione del tipo
di dato da costruire
• Classi coinvolte:
– UserFactory: la classe si occupa della creazione di un oggetto di tipo
User, che rappresenta un utente contenente le sue credenziali e i diritti di
accesso
– LogFactory: la classe si occupa della creazione di un oggetto di tipo Log,
che rappresenta un log che registra l’attività richiesta, formata da un
oggetto di tipo DateTime e la descrizione testuale dell’evento
Pagina 36 di 79
CAPITOLO 2. SISTEMA PER LA NAVIGAZIONE DEL DATABASE
DELL’INVENTARIO PRODOTTI
DataModel
Figura 2.16: Struttura del package DataModel
• Descrizione: il package src.model.dataModel è costituito dai moduli usersModel,
dateTimeModel,logModel,exceptionsModel, ciascuna delle quali rappresenta
uno tra i vari tipi di dati manipolati dall’applicazione
• Componenti utilizzate: le classi del package dataModel non comunicano
con altre classi ma vengono solamente utilizzate dalle altre componenti
• Classi coinvolte:
– DateTime: la classe si occupa della rappresentazione di un oggetto di tipo
date e ora, che viene creato mediante librerie Python e successivamente
modificato impostando il fuso orario italiano e modificandone il formato
ottenendo: GG/MM/AAAA - hh:mm
– DuplicateError: la classe si occupa della rappresentazione di un errore
derivante dal tentativo di registrazione di un utente già presente nel sistema.
Contiene un campo dati value che contiene la descrizione dell’errore
– PasswordChange: la classe si occupa della rappresentazione di un’eccezione
relativa alla modifica della password di un utente
– Log: la classe si occupa della rappresentazione di un oggetto di tipo log,
che viene creato con un oggetto di tipo DateTime ed un oggetto di tipo
String contenente la descrizione dell’evento
– User: la classe si occupa della rappresentazione di un oggetto di tipo
User, il quale contiene i campi email, password, abilited, admin. Nel
caso si trattasse di un account Google, il campo password è vuoto, in
quanto non si deve permettere agli amministratori dell’applicazione di
poter modificare la password di un account personale di un utente
Pagina 37 di 79
2.4. PROGETTAZIONE DEL SISTEMA
DataStoreAccess
Figura 2.17: Struttura del package DataStoreAccess
• Descrizione: il package src.model.dataStoreAccess è costituito dai moduli
logStore ed usersStore, che fanno parte dell’implementazione del design
pattern Data Access Object e contengono i metodi necessari all’interazione con
l’App Engine Datastore
• Componenti utilizzate: le classi del package dataStoreAccess comunicano
con le componenti del package src.model.dataModel
• Classi coinvolte:
– UsersStore: la classe si occupa dell’interazione con la corrispondente
tabella nell’App Engine Datastore, salvando/recuperando i dati relativi
agli utenti dell’applicazione
– LogStore: la classe si occupa dell’interazione con la corrispondente tabella
nell’App Engine Datastore, salvando/recuperando i dati relativi ai log
delle attività
Pagina 38 di 79
CAPITOLO 2. SISTEMA PER LA NAVIGAZIONE DEL DATABASE
DELL’INVENTARIO PRODOTTI
2.4.3
Specifica del Front end
Il front end è la parte di un sistema che gestisce l’interazione con l’utente o con
sistemi esterni che producono dati di ingresso: in questa applicazione è costituito dai
template HTML, fogli di stile CSS, e script in JavaScript. A seguire la descrizione
della struttura del front end dell’applicazione
Componente View
Figura 2.18: Struttura del front end
• Descrizione template: I template sono scritti usando il linguaggio di markup HTML e al loro interno contengono costrutti implementati utilizzando
il template engine Jinja2, che permette l’inserimento dinamico di variabili e
blocchi di codice scritti in Python. Il rendering dei template viene effettuato
dal package src.controller, nella classe TemplateLoader che riceve i dati
elaborati dal back end da inserire nella pagina.
L’uso di Jinja2 permette di personalizzare una pagina a seconda del tipo di
utente a cui viene presentata, per esempio nella sezione Home si possono nascondere i link che puntano alle pagine di Amministrazione e Log nel caso in
cui l’utente non disponga di privilegi di amministratore
Pagina 39 di 79
2.5. TEST DI SISTEMA
• Descrizione script: Sono presenti degli script scritti nel linguaggio JavaScript
che si attivano per il controllo del corretto inserimento dei dati nelle form come
ad esempio la sintassi degli indirizzi e-mail.
La sezione amministrativa fa uso degli script nei file modifyUser.js e userType.js
che permettono l’attivazione/disattivazione dinamica delle form di inserimento
oppure di modifica degli account degli utenti.
Nella sezione principale dell’applicazione viene utilizzato il plug-in Data Tables
per le librerie JQuery di JavaScript per consentire all’utente la navigazione
della tabella ed effettuare ricerche a testo libero inserendo le query nell’apposito
box di ricerca.
Si tratta di un sistema particolarmente efficiente in quanto il server viene
interrogato una volta al caricamento della pagina, mentre le ricerche vegnono
effettuate lato client, velocizzando l’operazione e riducendo il carico di lavoro
del server evitando eventuali rallentamenti
2.5
Test di sistema
La presente sezione è dedicata alla descrizione dei test di sistema effettuati sull’applicazione, verificando il soddisfacimento di ogni requisito funzionale obbligatorio da
parte del prototipo al fine di aver completato con successo tutti gli obiettivi minimi
richiesti. La notazione utilizzata è la seguente:
<TS><Ge|A|Ad><Codice requisito>
Dove le sigle Ge,A,Ad indicano l’ambito Utente Generico, Utente Autenticato ed
Utente Amministratore rispettivamente.
Requisito
Codice test
Descrizione
Esito
ROFGe-1
TSGe-1
Si verifica che il sistema con- SUPERATO
senta all’utente di autenticarsi
ROFGe-1.1
TSGe-1
Si verifica che il sistema con- SUPERATO
senta all’utente di autenticarsi
sia tramite il suo account Google sia tramite l’account fornito dall’amministratore del
sistema
ROFGe-1.1.1
TSGe-1.1.1
Si vefica che il sistema de- SUPERATO
ve consenta all’utente di autenticarsi inserendo le proprie
credenziali
ROFGe1.1.1.1
TSGe 1.1.1.1
Si verifica che il modulo di
login consenta all’utente di
inserire l’indirizzo e-mail
SUPERATO
Pagina 40 di 79
CAPITOLO 2. SISTEMA PER LA NAVIGAZIONE DEL DATABASE
DELL’INVENTARIO PRODOTTI
SUPERATO
ROFGe1.1.1.2
TSGe-1.1.1.2
Si verifca che il modulo
di login consenta all’utente
di inserire la password la
password
ROFGe-1.1.2
TSGe-1.1.2
Si verifica che il sistema con- SUPERATO
senta all’utente di autenticarsi mediante il proprio account
Google
ROFGe1.1.2.1
TSGe-1.1.2.1
Si verifica che il modulo di lo- SUPERATO
gin Google richieda all’utente
l’indirizzo e-mail
ROFGe1.1.2.2
TSGe-1.1.2.2
Si verifica che il modulo di lo- SUPERATO
gin Google richieda all’utente
la password
ROFGe1.1.2.3
TSGe-1.1.2.3
Si verifica che il sistema de- SUPERATO
ve consenta l’accesso all’utente Google se è attiva una
sessione nel proprio browser
ROFA-1.1
TSA-1.1
Si verifica che il sistema con- SUPERATO
senta all’utente di effetuare
interrogazioni sul database
ROFA-1.2
TSA-1.2
Si verifica che il sistema con- SUPERATO
senta all’utente di visualizzare
i dettagli di un prodotto
ROFA-1.3
TSA-1.3
Si verifica il sistema consenta SUPERATO
all’utente effettuare l’ordinazione di un prodotto
ROFA-1.3.1
TSA-1.3.1
Si verifica che il sistema SUPERATO
consenta all’utente di inserire la quantità di prodotto
desiderata da ordinare
ROFA-1.2
TSA 1.2
Si verifica che il sistema
deve consenta all’utente di
effettuare il logout
ROFAd-1.3
TSAd-1.3
Si verifica che il sistema de- SUPERATO
ve consenta all’utente amministratore di gestire gli
account
SUPERATO
Pagina 41 di 79
2.5. TEST DI SISTEMA
ROFAd-1.3.1
TSAd-1.3.1
Si verifica che il modulo di ge- SUPERATO
stione degli account permetta
all’amministratore di inserire
un nuovo utente nel sistema
ROFAd-1.3.2
TSAd-1.3.2
Si verifica che il modulo di ge- SUPERATO
stione degli account permetta
all’amministratore di disabilitare temporaneamente l’accesso all’applicazione ad un
utente
ROFAd-1.3.3
TSAd-1.3.3
Si verifica che il modulo di ge- SUPERATO
stione degli account permetta
all’amministratore di abilitare l’accesso all’applicazione ad
un utente
ROFAd-1.3.4
TSAd-1.3.4
Si verifica che il modulo di ge- SUPERATO
stione degli account permetta
all’amministratore eliminare
permanentemente un account
dal sistema
ROFAd-1.3.5
TSAd-1.3.5
Si verifica che il modulo di ge- SUPERATO
stione degli account permetta
all’amministratore di modificare la password di accesso al
sistema di un utente
ROFAd-1.3.6
TSAd-1.3.6
Si verifica che il modulo di ge- SUPERATO
stione degli account permetta all’amministratore di assegnare o revocare i privilegi di
amministrazione ad un utente
ROFAd-1.4
TSAd-1.4
Si verifica che l’applicazio- SUPERATO
ne permetta all’amministratore di visualizzare il log delle
attività di sistema
Tabella 2.4: Progetto 1 - Test di sistema
Come si evince dalla tabella il prototipo dell’applicazione presenta delle funzionalità che soddisfano la totalità dei requisiti obbligatori prefissati.
Ulteriori funzionalità aggiuntive non sono state richieste durante il periodo di stage
e pertanto eventuali requisiti opzionali o desiderabili sono omessi.
Pagina 42 di 79
CAPITOLO 2. SISTEMA PER LA NAVIGAZIONE DEL DATABASE
DELL’INVENTARIO PRODOTTI
La relativa velocità con la quale il team di sviluppo ha portato a termine lo sviluppo
dl prototipo ha consentito di affrontare un nuovo progetto, approfondendo un altro
dei punti fissati in sezione 1.2, che verrà analizzato nel capitolo successivo.
Pagina 43 di 79
Capitolo 3
Applicazione per il calcolo di
percorsi e ricerca punti di
interesse
3.1
Descrizione del contesto
In questo capitolo verranno descritte nel dettaglio le attività svolte per lo sviluppo
del secondo punto elencati in sezione 1.2, ovvero:
Applicazione per il calcolo di percorsi stradali e ricerca di punti di interesse
L’idea che sta alla base del prodotto deriva dalla richiesta presentata all’azienda
Nextep da parte di una ditta che si occupa di trasporto merci su strada.
Come riportato in sezione 1.2.2, lo scopo principale era quello di calcolare in breve
tempo ed in modo efficiente le distanze in km che intercorrono tra una specifica
località ed i capoluoghi di provincia italiani, per consentire all’azienda di fornire ai
clienti informazioni sui costi di trasporto.
Il committente inoltre ha avanzato le seguenti richieste:
• Calcolo del percorso più breve che intercorre tra due località e relativa visualizzazione sulla mappa, con l’opzione di poterlo modificare se necessario
• Calcolo di punti di interesse nelle vicinanze del percorso a partire da un
determinato raggio di ricerca e relativa visualizzazione sulla mappa. Lo scopo
principale di questa funzionalità è quello di identificare eventuali aziende del
portfolio clienti del committente nel caso in cui il percorso selezionato passasse
nelle loro vicinanze per poterle contattare in modo agevole
• Ricerca di una località sulla mappa e visualizzazione delle fasce tariffarie
applicabili al trasporto merci a partire da quel punto.
Pagina 44 di 79
CAPITOLO 3. APPLICAZIONE PER IL CALCOLO DI PERCORSI E RICERCA
PUNTI DI INTERESSE
Il compito assegnato al team di sviluppo è stato quello di analizzare il problema,
producendo il documento Analisi dei Requisiti, oltre a progettare e realizzare un
prototipo funzionante del sistema che implementasse tutti i punti riportati nel
precedente elenco.
A seguito si riportano i risultati prodotti dall’attività di analisi dei requisiti.
3.1.1
Tipologia di utente
Si identifica un solo tipo di utente che potrà usufruire delle funzionalità del
prodotto, in quanto non vi è stata richiesta di limitare gli accessi all’applicazione ad
una determinata utenza; si tratta di una caratteristica che potrà essere implementata
in futuro qualora ce ne fosse la necessità.
• Utente: Si definisce Utente un utente che ha accesso al sistema e può interagire
con le sue funzionalità
La sezione successiva ha lo scopo di illustrare le operazioni che un Utente può
effettuare sul prodotto, per mezzo di diagrammi dei casi d’uso.
La notazione utilizzata si riferisce al linguaggio UML versione 2.0.
Pagina 45 di 79
3.1. DESCRIZIONE DEL CONTESTO
3.1.2
Casi d’uso
Di seguito sono riportato i casi d’uso identificati per il progetto, i quali definiscono
le azioni che un Utente può effettuare durante l’uso del prodotto.
UC 1: Pagina iniziale
Figura 3.1: Pagina iniziale del sistema
Attori principali: Utente
Attori secondari: /
Precondizione: Il sistema si trova nello stato iniziale ed è pronto a ricevere l’input
dell’Utente
Postcondizione: Il sistema ha permesso all’utente di eseguire l’operazione richiesta
Scenario principale: L’Utente si trova nella pagina principale e può:
• Ricercare un percorso tra due località (UC 1.1)
• Ricercare fasce tariffare da una località (UC 1.2)
• Ottenere elenco delle distanze chilometriche tra una località ed i capoluoghi di
provincia italiani (UC 1.3)
Pagina 46 di 79
CAPITOLO 3. APPLICAZIONE PER IL CALCOLO DI PERCORSI E RICERCA
PUNTI DI INTERESSE
• Visualizzare i risultati delle operazioni sulla mappa (UC 1.4)
Scenario secondario:/
L’Utente può in qualunque momento abbandonare il sistema.
UC 1.1: Ricerca di un percorso tra due località
Figura 3.2: Ricerca del percorso su strada tra due località
Attori principali: Utente
Attori secondari: /
Precondizione: Il sistema si trova nello stato iniziale ed è pronto a ricevere l’input
dell’utente
Postcondizione: Il sistema ha riconosciuto come validi i dati inseriti ed ha eseguito
le operazioni richieste, ovvero ha calcolato il percorso e visualizzato correttamente
sulla mappa. Se esistono punti di interesse lungo il percorso, questi verranno mostrati
sulla mappa tramite appositi marker
Scenario principale: L’Utente decide di ricercare il percorso tra due località e
quindi:
• Inserisce località di partenza (UC 1.1.1)
• Inserisce località di arrivo (UC 1.1.2)
• Inserisce raggio di ricerca di punti di interesse dal percorso (UC 1.1.3)
• Visualizza i risultati della ricerca (UC 1.1.4)
Scenari secondari: I dati inseriti dall’utente non sono validi, pertanto:
• Il sistema lo segnala all’utente che potrà ripetere l’operazione
Pagina 47 di 79
3.1. DESCRIZIONE DEL CONTESTO
UC 1.1.4: Visualizzazione dei risultati della ricerca percorso
Figura 3.3: Visualizzazione risultati ricerca percorso
Attori principali: Utente
Attori secondari: /
Precondizione: Il sistema ha elaborato la richiesta dell’utente e mostra a video il
risultato
Postcondizione: L’Utente ha svolto le operazioni disponibili
Scenario principale: Il sistema mostra a video i risultati del calcolo del percorso
tra due località e l’Utente può:
• Visualizzare il risultato sulla mappa (UC 1.1.4.1)
• Modificare il percorso in base alle sue esigenze(UC 1.1.4.2)
• Visualizzare i dettagli del percorso (durata, distanza) (UC 1.1.4.3)
• Visualizzare i dettagli di un punto di interesse che si trova nelle vicinanze del
percorso, se presente (UC 1.1.4.4)
Scenari secondari:/
Pagina 48 di 79
CAPITOLO 3. APPLICAZIONE PER IL CALCOLO DI PERCORSI E RICERCA
PUNTI DI INTERESSE
UC 1.2: Ricerca della fascia tariffaria da una località
Figura 3.4: Ricerca fascia tariffaria
Attori principali: Utente
Attori secondari: /
Precondizione: Il sistema si trova nello stato iniziale ed è pronto a ricevere l’input
dell’utente
Postcondizione: Il sistema ha riconosciuto come validi i dati inseriti ed ha eseguito
le operazioni richieste
Scenario principale: L’Utente decide di ricercare le fasce tariffarie da una località
e quindi:
• Inserisce località (UC 1.2.1)
• Visualizza i risultati della ricerca (UC 1.2.2)
Scenari secondari: I dati inseriti dall’utente non sono validi, pertanto:
• Il sistema lo segnala all’utente che potrà ripetere l’operazione
Pagina 49 di 79
3.1. DESCRIZIONE DEL CONTESTO
UC 1.3: Richiesta elenco delle distanze chilometriche da una località
Figura 3.5: Ricerca elenco distanze chilometriche
Attori principali: Utente
Attori secondari: /
Precondizione: Il sistema si trova nello stato iniziale ed è pronto a ricevere l’input
dell’utente
Postcondizione: Il sistema ha riconosciuto come validi i dati inseriti ed ha eseguito
le operazioni richieste
Scenario principale: L’Utente decide di ottenere l’elenco delle distanze chilometriche tra una località ed il resto delle province italiane e quindi:
• Inserisce località (UC 1.3.1)
• Visualizza i risultati della ricerca (UC 1.3.2)
Scenari secondari: I dati inseriti dall’utente non sono validi, pertanto:
• Il sistema lo segnala all’utente che potrà ripetere l’operazione
Pagina 50 di 79
CAPITOLO 3. APPLICAZIONE PER IL CALCOLO DI PERCORSI E RICERCA
PUNTI DI INTERESSE
UC 1.3.2: Visualizzazione risultati della ricerca distanze chilometriche
Figura 3.6: Visualizzazione risultati della ricerca distanze chilometriche
Attori principali: Utente
Attori secondari: /
Precondizione: Il sistema si trova nello stato iniziale ed è pronto a ricevere l’input
dell’utente
Postcondizione: Il sistema ha permesso all’utente di eseguire le operazioni disponibili
Scenario principale: Il sistema mostra a video i risultati del calcolo delle distanze
tra una località ed i capoluoghi di provincia italiani e l’Utente può:
• Navigare la tabella dei risultati (UC 1.3.2.1)
• Effettuare ricerche sulla tabella dei risultati (UC 1.3.2.2)
• Scaricare tabella dei risultati in formato CSV (UC 1.3.2.3)
Scenari secondari:/
Pagina 51 di 79
3.2. CLASSIFICAZIONE DEI REQUISITI
3.2
Classificazione dei requisiti
Si riportano le tabelle contenenti la classificazione dei requisiti adottata per il
progetto, suddivisi in due categorie:
• Obbligatori: funzionalità attese al sistema che devono essere necessariamente
implementate
• Desiderabili: funzionalità aggiuntive che possono essere integrate qualora ce
ne fosse tempo, che danno un valore aggiunto al prodotto
La notazione utilizzata è la seguente:
<R><O|D|Op><F|T>-X<.Y<.Z> >
Dove:
• R: Requisito
• O: Obbligatorio
• D: Desiderabile
• Op: Opzionale
• F: Funzionale
• T: Tecnologico
• X: Requisito di primo livello
• Y: Sotto-requisito
• Z: Sotto-requisito di un sotto-requisito
3.2.1
Requisiti Obbligatori
Codice
Requisito
ROF-1
Il sistema deve consentire all’utente di accedere alla pagina
principale tramite url
ROF-2
Il sistema deve consentire all’utente di effettuare la ricerca del
percorso tra due località
ROF-2.1
Il sistema deve consentire all’utente di inserire la località di
partenza
ROF-2.2
Il sistema deve consentire all’utente di inserire la località di arrivo
Pagina 52 di 79
CAPITOLO 3. APPLICAZIONE PER IL CALCOLO DI PERCORSI E RICERCA
PUNTI DI INTERESSE
ROF-2.3
Il sistema deve consentire all’utente di visualizzare i risultati del
calcolo del percorso tra due località
ROF-2.3.1
Il sistema deve consentire all’utente di visualizzare la durata del
viaggio
ROF-2.3.2
Il sistema deve consentire all’utente di visualizzare la lunghezza
del viaggio
ROF-3
Il sistema deve consentire all’utente di ottenere l’elenco delle
distanze su strada tra la località inserita e i capoluoghi di provincia
italiani
ROF-3.1
Il sistema deve consentire all’utente di inserire la località da cui
effettuare il calcolo delle distanze
ROF-3.2
Il sistema deve consentire all’utente effettuare il download
dell’elenco delle distanze
ROT-1
Il sistema deve utilizzare le API di Google Maps
ROT-2
Il sistema deve essere sviluppato utilizzando la piattaforma Google
App Engine
Tabella 3.1: Progetto 2 - Requisiti obbligatori
3.2.2
Requisiti Desiderabili/Opzionali
Codice
Requisito
RDF-1
Il sistema deve consentire all’utente di navigare la tabella dei
risultati del calcolo delle distanze da una località
RDF-2
Il sistema deve consentire all’utente di effettuare la ricerca di
aziende ad una determinata distanza dal percorso specificato
RDF-2.1
Il sistema deve consentire all’utente di inserire il raggio di ricerca
dal percorso
RDF-2.2
Il sistema deve consentire all’utente di visualizzare sulla mappa
le aziende presenti nelle vicinanze del percorso
RDF-2.3
Il sistema deve consentire all’utente di visualizzare sulla mappa i
dettagli dell’azienda selezionata
ROpF-1
Il sistema deve consentire all’utente di visualizzare le fasce
tariffarie per il trasporto a partire da una località
ROpF-1.1
Il sistema deve consentire all’utente di inserire la località
desiderata per il calcolo delle fasce tariffarie
Tabella 3.2: Progetto 2 - Requisiti Opzionali e Desiderabili
Pagina 53 di 79
3.3. TECNOLOGIE
3.3
Tecnologie
La presente sezione è dedicata alla descrizione delle tecnologie che il team ha
impiegato per la realizzazione del progetto e le ragioni che hanno contribuito a
valutare il loro impiego.
La maggioranza dei tool utilizzati è analoga a quanto riportato nel precedente capitolo,
in sezione 2.3, con alcune differenze dovute al cambio di contesto.
Coerentemente con lo scopo principale dello stage, ovvero lo studio delle potenzialità
delle tecnologie dell’azienda di Mountain View, e dati gli obiettivi fissati in precedenza,
si è scelto di utilizzare la tecnologia Google Maps per l’implementazione delle principali
funzionalità del prodotto.
Si è scelto di utilizzare la piattaforma App Engine in quanto fornisce una piena
compatibilità con le API di Maps e poter utilizzare i servizi di storage disponibili
per il salvataggio dei dati; per un maggior dettaglio, si rimanda alla sezione 2.3.1.
3.3.1
Google Maps API
Maps è un servizio offerto da Google che permette all’utente di inserire l’indirizzo
di una località e di visualizzarne la posizione sulla mappa, calcolare il percorso tra
due città secondo vari criteri e consultare le informazioni disponibili per le località
stesse, e molto altro.
L’azienda statunitense mette a disposizione degli sviluppatori una serie di API che
consentono l’integrazione del servizio nella propria applicazione, o sito web, e di
usufruire delle varie funzionalità offerte, come ad esempio Geocoding, Directions,
Distance Matrix.
L’utente che usa il prodotto avrà la sensazione di trovarsi di fronte all’applicazione
originale di Google, in quanto sono presenti tutte le features che la caratterizzano, a
partire dalla stessa grafica utilizzata per il rendering della mappa, la visualizzazione
dei percorsi e pop-up informativi, con l’aggiunta di alcune funzionalità come il calcolo
di punti d’interesse lungo un determinato percorso.
Google Maps presenta una vasta gamma di API che permettono di incorporare ogni
funzionalità del servizio originale nella propria applicazione web sito:
• Maps API JavaScript: incorpora una Google Map usando JavaScript,
permettendo di manipolarla aggiungendo contenuti attraverso numerosi servizi
• Google Earth API: permette di incorporare le funzionalità del famoso software che genera immagini virtuali della Terra utilizzando dati satellitari e
fotografie aeree
• Static Maps API: incorpora una semplice immagine di Google Maps, utilizzata prevalentemente nei siti web per includere la posizione di una località
senza consentire altre operazioni, come ad esempio la ricerca di percorsi
Per lo sviluppo del progetto si è scelto di sfruttare Google Maps JavaScript API
v3, in quanto si tratta della versione adatta alla loro integrazione in applicazioni
Pagina 54 di 79
CAPITOLO 3. APPLICAZIONE PER IL CALCOLO DI PERCORSI E RICERCA
PUNTI DI INTERESSE
web-based. La versione 3 di queste API è stata progettata per incrementare la loro
velocità ed usabilità, soprattutto nei dispositivi mobile, ma anche nelle tradizionali
applicazioni web. Tali API forniscono una serie di utilities per la manipolazione
di mappe e l’aggiunta di contenuti personalizzati attraverso una grande varietà di
opzioni, senza trascurare la robustezza dell’applicazione. A differenza della versione
precedente la versione 3 include le seguenti features:
• Riduzione della dimensione dei file JavaScript per la geocodifica e il calcolo dei
percorsi, aumentando le performance dell’intera applicazione
• Cambiamento de namespacing rendendolo più simile ai linguaggi di programmazione Object Oriented
• Eliminazione della richiesta delle API key per l’uso di Google Maps nell’applicazione, rendendolo gratuito
Si è scelto di utilizzare questo ramo della famiglia di API in quanto i servizi messi a
disposizione forniscono, oltre alla funzionalità di geocodifica, anche la funzione di
calcolo del percorso, la quale non è presente in altre versioni come per esempio Static
Maps API.
Servizi Utilizzati
L’applicazione impiega molti dei servizi messi a disposizione dalle API per
soddisfare i requisiti definiti in sezione 3.2 tra i quali:
• Geocoding service: permette di convertire un indirizzo, fornito in formato
testuale, nelle corrispondenti coordinate geografiche, mediante una chiamata
all’apposito web service: tali coordinate verranno utilizzate per identificare la
località nella mappa
• Directions service: permette il calcolo del percorso tra due indirizzi e la
corrispondente visualizzazione sulla mappa. Tale calcolo viene effettuato mediante la chiamata all’apposito web service, inviando i parametri richiesti come
ad esempio opzioni di pedaggio, passaggio per località intermedie (waypoint),
tipologia di veicolo impiegato (auto, mezzo pubblico, bicicletta) e altro ancora
• Distance Matrix: servizio che permette di calcolare le distanze effettive (non
in linea d’aria) tra punti della mappa. A differenza del Directions Service questo
permette il calcolo di più distanze per volta, restituito in forma di matrice
contenente fino a 100 elementi per richiesta
Pagina 55 di 79
3.3. TECNOLOGIE
L’uso delle suddette funzionalità è disponibile in modo completamente gratuito,
con alcune limitazioni che verranno analizzate di seguito. Le API del servizio Google
Maps sono state scelte per i seguenti motivi:
• Funzionalità: Permette di interagire con tutte le funzionalità offerte dal
servizio, come geolocalizzazione e calcolo di percorsi personalizzati
• Personalizzabile: le API offrono un elevato grado di personalizzazione per
quanto riguarda l’aspetto grafico delle componenti della mappa ed aggiunta di
nuove caratteristiche
Il secondo aspetto è stato molto importante in quanto è stato necessario implementare
delle funzioni di ricerca di punti di interesse, non forniti dalla API; tuttavia il servizio
presenta varie limitazioni, come riportato nella sezione successiva.
Problemi riscontrati
L’impiego dei servizi offerti da Google Maps API è soggetto a numerose restrizioni
imposte dalla casa di Mountain View al fine evitare un sovraccarico di richieste ai
web services che si occupano della gestione delle richieste.
Durante lo sviluppo dell’applicazione infatti il team ha riscontrato varie problematiche
dovute al ripetuto uso dei servizi necessari al corretto funzionamento del sistema,
principalmente riguardo al soddisfacimento dei requisiti inerenti al calcolo delle
distanze tra una località e tutti i capoluoghi di provincia d’Italia.
Essendo infatti richiesto il calcolo di circa 115 distanze per ogni singola località si
è dovuto usufruire del servizio Distance Matrix e sottostare a diverse limitazioni,
prima tra tutte il massimo numero di destinazioni inviabili per ogni chiamata al web
service, fissato a 25.
Per il calcolo richiesto è stata necessaria l’implementazione di una funzione che invia
i parametri al servizio in gruppi da 25 elementi: inoltre è stato necessario attendere
circa 2,5 secondi tra un invio dati e l’altro, per evitare di superare i limiti imposti.
Ne consegue che il tempo totale necessario per lo svolgimento dell’operazione è di
circa 12.5 secondi, essendo necessario l’invio di 5 richieste al web service.
Il problema tuttavia si presenta solo la prima volta che viene effettuato il calcolo
delle distanze da una nuova località: infatti il risultato viene salvato nell’App
Engine Datastore per poterlo velocemente recuperare qualora ve ne fosse la necessità,
evitando inutili chiamate al web service e lo spreco di risorse.
Il limite sopra citato può essere superato utilizzando la versione Google Maps API for
Business la quale consente, tra le altre cose, l’invio di più parametri al web service: il
loro uso non è stato ritenuto necessario per lo sviluppo del prototipo dell’applicazione.
Un altro problema riscontrato è dovuto ad una richiesta specifica del cliente, che
riguardava il calcolo di percorsi percorribili da mezzi di trasporto pesanti: ciò non è
stato possibile in quanto al momento le API di Google Maps non consentono tale
opzione. Di conseguenza si è deciso di utilizzare il normale servizio di calcolo percorsi
usando le automobili come veicolo di riferimento.
Pagina 56 di 79
CAPITOLO 3. APPLICAZIONE PER IL CALCOLO DI PERCORSI E RICERCA
PUNTI DI INTERESSE
3.3.2
Tecnologie utilizzate
Nello sviluppo dell’applicazione sono state utilizzate gran parte delle tecnologie
impiegate per la realizzazione del progetto precedente, pertanto per un’analisi dettagliata si rimanda alla sezione 2.3.4.
Segue la descrizione delle nuove tecnologie adottate.
• JQuery AJAX: Asynchronous JavaScript and XML: è ad oggi la tecnica più
utilizzata per sviluppare applicazioni web interattive, consentendo lo scambio di
dati tra client e server senza ricaricare la pagina, il quale avviene in background
tramite chiamata asincrona
– Vantaggi:
∗ Pagine web dinamiche: la tecnologia AJAX consente di sviluppare
pagine web che cambiano dinamicamente a seconda dell’input dell’utente. Ciò consente per esempio di creare siti web costituiti da una
sola pagina
∗ Scambio dati: l’uso di questa tecnologia semplifica la modalità di
scambio dati tra client e server
– Svantaggi:
∗ Navigazione: rende impossibile navigare il sito tramite i tasti Avanti
e Indietro del browser. Ciò può creare frustrazione nell’utente e non
rende possibile segnalare ad altre persone la pagina correntemente
visualizzata, in quanto le modifiche effettuate via Javascript non
vengono memorizzate
• RouteBoxer: libreria per il linguaggio JavaScript compatibile con le Google
Maps API, che permette di generare un set di coordinate che ricopre una
determinata area nelle vicinanze di un percorso calcolato mediante il servizio
Directions
– Vantaggi:
∗ Permette di tracciare una serie di rettangoli che coprono una determinata area nei dintorni di un percorso, permettendo la ricerca di un
punto conoscendone le coordinate geografiche
– Svantaggi: Non sono stati riscontrati svantaggi degni di nota
Pagina 57 di 79
3.4. PROGETTAZIONE DEL SISTEMA
3.4
Progettazione del sistema
La presente sezione fornisce una definizione dettagliata dell’architettura del sistema attraverso un approccio top-down, similarmente a quanto effettuato per il
progetto precedente in sezione 2.4 Inizialmente è riportato l’elenco dei design pattern
utilizzati con relativa descrizione e giustificazione, a seguire per ogni sottosistema
viene presentata dapprima la struttura dei componenti, poi vengono specificate
le classi,ed infine di ogni classe significativa si indicano metodi e campi dati. In
questa sezione l’attenzione sarà focalizzata sulla parte di sistema da me progettata e
realizzata ovvero il front-end dell’applicazione.
3.4.1
Design Pattern utilizzati
Il team di sviluppo ha scelto di riutilizzare gran parte dei design pattern impiegati
per la progettazione del precedente progetto, in quanto la struttura dei due sistemi è
molto simile e le tecnologie adottate sono in gran parte le stesse: si tratta in entrambi
i casi di applicazioni web sviluppate mediante Google App Engine e pertanto si è
ritenuto opportuno mantenere lo stesso stile architetturale, per quanto possibile.
Per una descrizione dettagliata si consiglia pertanto di consultare la sezione 2.4.1.
3.4.2
Specifica del Back end
Il back-end è la parte di sistema che riceve i dati in ingresso dal front end e
li restituisce dopo l’elaborazione. Nel sistema sviluppato il back end è costituito
principalmente da moduli scritti in linguaggio Python e la base di dati situata nell’App Engine Datastore ed il Blobstore. A seguire la descrizione dettagliata delle
componenti del sistema.
Componente Controller
Figura 3.7: Struttura della componente Controller
Pagina 58 di 79
CAPITOLO 3. APPLICAZIONE PER IL CALCOLO DI PERCORSI E RICERCA
PUNTI DI INTERESSE
• Descrizione: il package src.controller definisce le classi che rappresentano
il Controller dell’applicazione. La classe BaseHandler deriva da
webapp2.RequestHandler ed eredita tutti i metodi necessari alla gestione di
richieste da parte del front-end, fornendo inoltre un’implementazione della
gestione delle sessioni utente delle librerie fornite dal framework webapp2.
Il modulo main.py contiene tutte le classi controller (derivate da BaseHandler)
che gestiscono le varie richieste provenienti dalla view delegando alle classi del
Model l’elaborazione dei dati e fornendo alla View il risultato
• Componenti utilizzate: le classi del Controller comunicano con le classi
del package src.model.command per l’elaborazione dei dati e con la classe
TemplateLoader per il rendering dei template
• Classi coinvolte:
– BaseHandler: fornisce un’implementazione dei metodi relativi alla creazione, cancellazione e verifica delle sessioni utente. Ogni classe del Controller
deriva da BaseHandler
– TemplateLoader: classe che si occupa del rendering dei template HTML
che rappresentano le pagine che verranno visualizzate dall’utente. La
classe utilizza le librerie Jinja2, che permettono la creazione di template
dinamici contenenti campi dati e costrutti di controllo
– MainPage: gestisce la richiesta derivante dall’URL ’/’ reindirizzando il
browser alla pagina iniziale dell’applicazione
– ServeProvinceJsonHandler: gestisce la chiamata AJAX effettuata dal
client all’URL ’/serve/province.json’ restituendo al client il file JSoN
contenente l’elenco delle province d’Italia che verranno utilizzate per il
calcolo delle distanze
– Upload: crea la pagina che consente il caricamento di file nel Blobstore,
come il JSoN che contiene l’elenco delle province italiane o gli indirizzi
delle aziende
– UploadHandler: gestisce la richiesta di caricamento di un file nel Blobstore,
delegando l’esecuzione al rispettivo Command
– SearchFromOriginRequestHandler: gestisce la richiesta di ricerca nel
database del JSoN contenente l’elenco delle distanze tra una determinata
origine ed il resto delle province italiane, ricevendo un oggetto JSoN dal
client dove è specificata la località di origine da cercare. L’esecuzione
dell’operazione viene delegata al rispettivo Command
– StoreNewDistancesHandler: gestisce la richiesta di salvataggio nel database di un nuovo JSoN contenente l’elenco delle distanze tra una determinata origine ed il resto delle province italiane come risultato del
calcolo effettuato lato client mediante l’utilizzo delle API di Google Maps.
L’esecuzione dell’operazione viene delegata al rispettivo Command
Pagina 59 di 79
3.4. PROGETTAZIONE DEL SISTEMA
– DownloadCsvHandler: gestisce la richiesta di download del file in formato
CSV dell’elenco delle distanze tra una determinata città di origine ed il
resto delle province italiane. L’esecuzione dell’operazione viene delegata
al rispettivo Command
Pagina 60 di 79
CAPITOLO 3. APPLICAZIONE PER IL CALCOLO DI PERCORSI E RICERCA
PUNTI DI INTERESSE
Componente Model
Command
Figura 3.8: Struttura del design pattern command
• Descrizione: il package src.model.command è costituito dal modulo Command,
contenente la definizione delle sottoclassi xxxCommand concrete. Ogni sottoclasse concreta svolge una funzione specifica che varia dalla creazione di un file
in formato CSV al salvataggio e recupero di oggetti in formato JSoN dall’ App
Engine Datastore
• Componenti utilizzate: le classi concrete di Command comunicano con le
classi del package src.model.managers, delegando lo svolgimento delle funzioni richieste. Inoltre, comunicano con la classe Controller del package
src.controller.Main inviando i risultati delle operazioni
• Classi coinvolte:
– GetDistancesJsonCommand: gestisce la richiesta di recupero dalla base
di dati del file JSoN relativo alle distanze tra l’origine specificata ed il
resto delle province italiane, se presente. La chiamata al metodo execute
delega l’esecuzione dell’operazione al metodo getDistancesJson della
classe JsonManager
– SaveNewDistancesJsonCommand: gestisce la richiesta di salvataggio nella
base di dati del file JSoN contenente le distanze tra l’origine specificata ed
il resto delle province italiane, se presente. La chiamata al metodo execute
Pagina 61 di 79
3.4. PROGETTAZIONE DEL SISTEMA
delega l’esecuzione dell’operazione al metodo saveNewDistancesJson
della classe JsonManager
– GetAllProvincesJsonCommand: gestisce la richiesta di recupero dal Blobstore del file JSoN contenente l’elenco delle province italiane. La chiamata al metodo execute delega l’esecuzione dell’operazione al metodo
getAllProvincesJson della classe JsonManager
– SearchCsvCommand:gestisce la richiesta di recupero dal Blobstore del file in formato CSV contente l’elenco delle distanze da una determinata
origine e le province, nel caso fosse già stato creato e salvato. L’esecuzione dell’operazione viene delegata al metodo searchCsv della classe
CsvManager
– CreateCsvCommand: gestisce la richiesta di creazione del file in formato
CSV a partire dall’oggetto JSoN contente l’elenco delle distanze da una
determinata origine e le province italiane che verrà salvato nel Blobstore e sarà disponibile al download da parte degli utenti. L’esecuzione dell’operazione viene delegata al metodo createCsv della classe
CsvManager
– UploadUrlCommand: gestisce la richiesta creazione dell’URL per l’upload
di un file nel Blobstore da locale. L’esecuzione dell’operazione viene
delegata al metodo createUploadUrl della classe BlobStoreManager
– BlobUploadCommand: gestisce la richiesta di caricamento del file specificato
nel BlobStore. L’esecuzione dell’operazione viene delegata al metodo
uploadBlob della classe BlobStoreManager
Pagina 62 di 79
CAPITOLO 3. APPLICAZIONE PER IL CALCOLO DI PERCORSI E RICERCA
PUNTI DI INTERESSE
Managers
Figura 3.9: Struttura del package Managers
• Descrizione: il package src.model.managers è costituito dai moduli jsonManager,
csvManager,blobManager, che come suggerito dal nome si occupano di gestire
le operazioni relative ad un determinato tipo di dato e operazione
• Componenti utilizzate: le classi del package managers comunicano con le
classi del package src.model.storeAccess per il salvataggio/recupero dei dati
dal DataStore. Inoltre comunicano con i rispettivi command per il ritorno dei
dati. La classe JsonManager comunica inoltre con la classe BlobStoreManager
in quanto è richiesta la manipolazione di oggetti del Blobstore
• Classi coinvolte:
– JsonManager: la classe contiene tutti i metodi necessari alla gestione dei
file Json, come creazione e recupero dal Datastore di JSoN salvati in
precedenza. Il risultato dell’operazione viene ritornato al corrispondente
command
– CsvManager: la classe contiene tutti i metodi necessari alla gestione dei file
CSV, come la crezione ed il salvataggio di un nuovo file a partire da un oggetto JSoN, oltre alla ricerca di un eventuale file già presente nel Blobstore.
La classe CsvManager comunica inoltre con la classe BlobStoreManager
in quanto è richiesta la manipolazione di oggetti del Blobstore. Il risultato
dell’operazione viene infine ritornato al corrispondente command
– BlobStoreManager: la classe contiene tutti i metodi necessari alla gestione dei file contenuti nel Blobstore, oltre alla creazione dell’URL per il
caricamento di nuovi file da locale e la gestione dell’upload. La classe
ritorna al rispettivo command il risultato delle operazioni. La classe viene
inoltre utilizzata da JsonManager e CsvManager in quanto richiedono
l’interazione con il Blobstore
Pagina 63 di 79
3.4. PROGETTAZIONE DEL SISTEMA
DataModel
Figura 3.10: Struttura del package DataModel
• Descrizione: il package src.model.dataModel è costituito dai moduli distancesModel,
provinceModel,exceptionsModel, ciascuna delle quali rappresenta uno tra i
vari tipi di dati manipolati dall’applicazione
• Componenti utilizzate: le classi del package dataModel non comunicano
con altre classi ma vengono solamente utilizzate dalle altre componenti
• Classi coinvolte:
– Distances: La classe definisce il modello di dato relativo alla tabella delle
distanze chilometriche tra una specifica origin e il resto delle province
italiane, rappresentate dal campo destinations. La tabella, situata
nell’App Engine Datastore, contiene i relativi oggetti in formato JSoN,
per facilitarne il salvataggio ed il recupero per l’invio al client
– NotFoundException: la classe si occupa della rappresentazione di un’eccezione che si verifica nel caso in cui l’oggetto cercato nella relativa tabella
dell’App Engine Datastore non sia presente.
Pagina 64 di 79
CAPITOLO 3. APPLICAZIONE PER IL CALCOLO DI PERCORSI E RICERCA
PUNTI DI INTERESSE
DataStoreAccess
• Descrizione: il package src.model.storeAccess è costituito dai moduli
distancesAccess ed blobStoreAccess, che fanno parte dell’implementazione del design pattern Data Access Object e contengono i metodi necessari
all’interazione con l’App Engine Datastore ed il Blobstore rispettivamante
• Componenti utilizzate: le classi del package storeAccess comunicano con le
componenti del package src.model.distancesModel e src.model.exceptionsModel,
oltre ai database di cui si occupano. Inoltre restituiscono i dati ai rispettivi
manager
• Classi coinvolte:
– DistancesAccess: la classe si occupa dell’interazione con la corrispondente tabella nell’App Engine Datastore, salvando/recuperando gli oggetti
Json contenenti le distanze chilometriche tra città italiane
– BlobStoreAccess: la classe si occupa dell’interazione con il Blobstore,
salvando/recuperando i file e caricando i file che vengono inseriti da locale,
come per esempio l’elenco delle province italiane che viene usato per il
calcolo
Pagina 65 di 79
3.4. PROGETTAZIONE DEL SISTEMA
3.4.3
Specifica del Front end
Il front end è la parte di un sistema che gestisce l’interazione con l’utente o con
sistemi esterni che producono dati di ingresso: in questa applicazione è costituito dai
template HTML, fogli di stile CSS, e script in JavaScript. Segue la descrizione del
front-end dell’applicazione.
Componente View
Figura 3.11: Struttura del front end
• Descrizione template: I template sono scritti usando il linguaggio di markup
HTML che consente di definire la struttura degli elementi della pagina ed il loro
posizionamento. Nel caso specifico di questa applicazione, è presente il template
home.html che varia il contenuto dinamicamente a seconda dell’interazione
dell’utente grazie all’utilizzo di JavaScript, ed il template upload.html che
permette agli sviluppatori il caricamento di file nel Blobstore come ad esempio
l’elenco delle province italiane
Pagina 66 di 79
CAPITOLO 3. APPLICAZIONE PER IL CALCOLO DI PERCORSI E RICERCA
PUNTI DI INTERESSE
• Descrizione script: Gran parte delle funzionalità del prodotto sono implementate in linguaggio JavaScript in quanto vengono utilizzate le API di Google
Maps. Gli script gestiscono operazioni come il calcolo del percorso tra località,
la gestione dei punti d’interesse, il calcolo delle distanze chilometriche ed il
controllo dell’input dell’utente, oltre alle chiamate AJAX per il passaggio di
dati con il controller del back-end. Segue una descrizione degli script
– maps.js: qui viene inizializzata la mappa con le impostazioni di default
che viene mostrata all’utente al primo accesso all’applicazione ed inizializzate le funzioni necessarie al corretto funzionamento delle operazioni
che verranno effettuate, come ad esempio l’inizializzazione del servizio di
geocodifica google.maps.Geocoder ed il servizio per il calcolo dei percorsi
google.maps.DirectionsService, oltre alle librerie RouteBoxer per il
calcolo dei punti di interesse lungo un percorso
– placesModel.js: contiene la definizione di oggetti JavaScript per la
rappresentazione dei punti di interesse che vengono visualizzati sulla
mappa, in questo caso si tratta di aziende con relativo nome,indirizzo,
e-mail e coordinate geografiche, oltre alla funzione per estrarre i dati dal
JSoN ricevuto dal server e la creazione dell’oggetto place corrispondente
– route.js: qui sono presenti tutte le funzionalità che permettono di calcolare il percorso tra due località e visualizzare eventuali punti d’interesse
nelle sue vicinanze. Il calcolo del percorso viene effettuato mediante
l’invio di un oggetto request al servizio DirectionService delle API di
Google Maps. La chiamata al servizio è asincrona, pertanto è presente
una funzione di callback che viene invocata non appena il risultato del
calcolo è pronto. Successivamente vengono usate le librerie RouteBoxer
per la ricerca di eventuali punti d’interesse nelle vicinanze del percorso
appena calcolato: se vengono trovati, per ogni punto viene inizializzato un
marker con relativa infoWindow contenente le informazioni del luogo, ed
il tutto viene visualizzato sulla mappa. È presente inoltre la funzione per
il calcolo delle fasce chilometriche a partire da una determinata località
– checkInput.js: si occupa di catturare l’input dell’utente e controllare
il corretto riempimento dei campi, segnalando all’utente eventuali errori
come un campo vuoto o un valore non valido.Nel caso in cui i valori
siano validi viene invocata la funzione necessaria allo svolgimento dell’
operazione richiesta
– province.js: qui viene effettuato il calcolo delle distanze tra una località
e tutte le province italiane mediante l’utilizzo del servizio DistanceMatrix
delle API di Google Maps. La chiamata avviene specificando gli indirizzi
di origine e destinazione, la modalità di viaggio ed opzioni quali l’uso
di autostrade o altri passaggi a pagamento: si tratta di una chiamata
asincrona, per cui è presente una funzione di callback che viene invocata
non appena arriva il risultato, che viene poi inviato al server per il
Pagina 67 di 79
3.5. TEST DI SISTEMA
salvataggio nel database per futuri utilizzi, nel caso non fosse già presente
un file contenente quella specifica località di origine. Il risultato viene
inoltre mostrato sotto forma di tabella all’utente che potrà effettuare
eventuali ricerche, oltre a scaricarla nel formato CSV per utilizzarla
all’esterno dell’applicazione
• Nella sezione relativa alle distanze tra città viene utilizzato il plug-in Data Tables
per le librerie JQuery di JavaScript per consentire all’utente la navigazione
della tabella ed effettuare ricerche a testo libero inserendo le query nell’apposito
box di ricerca.
Si tratta di un sistema particolarmente efficiente in quanto le ricerche vegnono
effettuate lato client, velocizzando l’operazione e riducendo il carico di lavoro
del server evitando eventuali rallentamenti
3.5
Test di sistema
La presente sezione è dedicata alla descrizione dei test di sistema effettuati sull’applicazione, verificando il soddisfacimento di ogni requisito funzionale obbligatorio da
parte del prototipo al fine di aver completato con successo tutti gli obiettivi minimi
richiesti. La notazione utilizzata è la seguente:
<TS><Ob|D|Op><Codice requisito>
Dove:
• Ob: obbligatorio
• D: desiderabile
• Op: opzionale
Requisito
Codice test
Descrizione
Esito
ROF-1
TSOb-1
Si verifica che il sistema con- SUPERATO
senta all’utente di accedere alla pagina principale tramite
url
ROF-2
TSOb-2
Si verifica che il sistema deve SUPERATO
consenta all’utente di effettuare la ricerca del percorso tra
due località
ROF-2.1
TSOb-2.1
Si verifica che il sistema con- SUPERATO
senta all’utente di inserire la
località di partenza
Pagina 68 di 79
CAPITOLO 3. APPLICAZIONE PER IL CALCOLO DI PERCORSI E RICERCA
PUNTI DI INTERESSE
ROF-2.2
TSOb-2.2
Si verifica che il sistema con- SUPERATO
senta all’utente di inserire la
località di arrivo
ROF-2.3
TSOb-2.3
Si verifica che il sistema con- SUPERATO
senta all’utente di visualizzare i risultati del calcolo del
percorso tra due località
ROF-2.3.1
TSOb-2.3.1
Si verifica che il sistema con- SUPERATO
senta all’utente di visualizzare
la durata del viaggio
ROF-2.3.2
TSOb-2.3.2
Si verifica che il sistema de- SUPERATO
ve consentire all’utente di visualizzare la lunghezza del
viaggio
ROF-3
TSOb-3
Si verifica che il sistema con- SUPERATO
senta all’utente di ottenere l’elenco delle distanze su strada tra la località inserita
e i capoluoghi di provincia
italiani
ROF-3.1
TSOb-3.1
Si verifica che il sistema con- SUPERATO
senta all’utente di inserire la
località da cui effettuare il
calcolo delle distanze
ROF-3.2
TSOb-3.2
Si verifica che il sistema con- SUPERATO
senta all’utente di effettuare
il download della tabella delle
distanze in formato CSV
RDF-1
TSD-1
Si verifica che il sistema per- SUPERATO
metta la navigazione della tabella dei risultati del calcolo
delle distanze da una località
RDF-2
TSD-2
Si verifica che il sistema con- SUPERATO
senta all’utente di effettuare
la ricerca di punti di interesse
ad una determinata distanza
dal percorso specificato
Pagina 69 di 79
3.5. TEST DI SISTEMA
RDF-2.1
TSD-2.1
Si verifica che il sistema con- SUPERATO
senta all’utente di inserire l’area di ricerca di punti di
interesse dal percorso
RDF-2.2
TSD-2.2
Si verifica che il sistema con- SUPERATO
senta all’utente di visualizzare
sulla mappa i punti d’interesse trovati nelle vicinanze del
percorso
RDF-2.3
TSD-2.3
Si verifica che il sistema con- SUPERATO
senta all’utente di visualizzare sulla mappa i dettagli
dell’azienda selezionata
ROpF-1
TSOp-1
Si verifica che il sistema con- NON IMPLEsenta all’utente di visualizza- MENTATO
re le fasce tariffarie per il
trasporto a partire da una
località
ROpF-1.1
TSOp-1.1
Si verifica che il sistema con- SUPERATO
senta all’utente di inserire
la località desiderata per il
calcolo delle fasce tariffarie
Tabella 3.3: Progetto 2 - Test di sistema
Come si può notare nella tabella è stata soddisfatta la totalità dei requisiti
fissati durante l’attività di analisi, ad eccezione del requisito ROpF-1 che è stato
implementato parzialmente per questioni di tempo.
Il prototipo è stato completato in breve tempo grazie al riuso di diverse componenti
impiegate per lo sviluppo del progetto precedente e dalla dimestichezza acquisita dai
membri del team nell’uso delle tecnologie, oltre alla valida documentazione fornita
da Google a supporto delle API di Maps.
Pagina 70 di 79
CAPITOLO 4. VALUTAZIONI RETROSPETTIVE
Capitolo 4
Valutazioni retrospettive
Il presente capitolo ha lo scopo di valutare la mia esperienza di stage, confrontando
gli obiettivi prefissati con quelli raggiunti e le esperienze maturate.
4.1
4.1.1
Obiettivi
Obiettivi minimi dello stage
Gli obiettivi minimi dell’esperienza di stage, fissati in accordo con il tutor aziendale, si incentravano sullo studio delle tecnologie messe a disposizione da Google,
valutandone l’idoneità a soddisfare le esigenze di alcuni clienti dell’azienda Nextep e
sviluppando un prototipo di applicazione che concretizzi le idee raccolte.
Una delle richieste a cui l’azienda ha dato priorità era la realizzazione di un’applicazione web che permettesse la navigazione della base di dati del committente e
permettesse l’accesso a personale provvisto di un account Google, come già descritto
nel Capitolo 2: la grande disponibilità ed il costante supporto dimostrati dal personale
dell’azienda, oltre al fatto che il team di sviluppo era composto da due persone, ha
reso possibile il raggiungimento di questi obiettivi in tempi relativamente brevi.
Il risultato è un’applicazione web, attualmente disponibile nello stato di prototipo,
che offre la maggior parte delle funzionalità richieste ma lontana dal prodotto finito
in quanto utilizza molte tecnologie mai usate prima dell’azienda e pertanto richiede
ancora del lavoro per essere perfezionata e completata; in ogni caso, tutti gli obiettivi
minimi sono stati soddisfatti.
Pagina 71 di 79
4.1. OBIETTIVI
4.1.2
Obiettivi massimi dello stage
Gli obiettivi massimi fissati erano i seguenti:
• Sviluppo di funzionalità aggiuntive al prodotto
• Sviluppo di un altro dei punti elencati in sezione 1.2
Una volta completato il prototipo dell’applicazione si è ritenuto sufficiente il lavoro
svolto e pertanto non necessaria l’aggiunta di funzionalità aggiuntive da parte degli
stagisti, compito che è stato assegnato al personale di Nextep.
Di conseguenza è stato possibile focalizzarsi sul secondo obiettivo opzionale ed iniziare
l’approfondimento del secondo punto riportato in sezione 1.2, ovvero:
Applicazione per il calcolo di percorsi stradali e ricerca di punti di interesse
Gli obiettivi minimi fissati per il progetto erano analoghi a quelli del primo progetto,
ovvero l’applicazione delle tecnologie Google più idonee allo sviluppo del prodotto; il
risultato è un’altra web application, anch’essa disponibile nello stato di prototipo,
il cui completamento è stato affidato al personale dell’azienda ospitante in tempi
successivi al completamento dello stage.
È stata inoltre realizzata la documentazione di supporto per entrambe le applicazioni,
nello specifico Analisi dei Requisiti e Specifica Tecnica.
Tutti gli obiettivi prefissati sono stati raggiunti entro i tempi concordati.
4.1.3
Obiettivi formativi
Lo stage è un’opportunità offerta allo studente che ha la possibilità di essere
ospitato per un certo periodo di tempo in un’azienda ed essere inserito in un contesto
lavorativo, mettendo in pratica quanto imparato all’università. Gli obiettivi formativi
erano i seguenti:
• Migliorare le capacità di lavoro all’interno di un team
• Apprendimento di nuove tecnologie
• Apprendimento della metodologia di lavoro Scrum
L’esperienza di stage ha ampliato il mio bagaglio di conoscenze soprattutto riguardo
all’apprendimento di nuove tecnologie, primo tra tutti il linguaggio di programmazione Python, e mi ha permesso di acquisire dimestichezza nello sviluppo di applicazioni
web e l’impiego di alcune tecnologie di casa Google, come ad esempio la piattaforma
App Engine e le API di Google Maps.
Un altro aspetto da non sottovalutare è il miglioramento della capacità di lavorare
in team, già iniziato durante il corso di Ingegneria del Software, che è stato reso
possibile grazie al fatto di aver affrontato lo stage assieme ad un mio collega studente;
è stata quindi possibile una suddivisione dei compiti ed il costante confronto che ha
aggiunto valore all’esperienza di entrambi.
Pagina 72 di 79
CAPITOLO 4. VALUTAZIONI RETROSPETTIVE
4.1.4
Possibili sviluppi futuri
Le due applicazioni realizzate sono attualmente disponibili allo stato di prototipo:
sono presenti tutte le funzionalità minime richieste ed alcune opzionali a scopo
dimostrativo per i clienti ma si è ancora lontani dal prodotto finito.
L’aggiunta di nuove caratteristiche e miglioramenti è stata affidata al personale di
Nextep successivamente al periodo di stage, che avrà modo di usare i prototipi come
punto di partenza per l’evoluzione dei prodotti.
Alcune aggiunte che potrebbero essere effettuate sono:
• Progetto 1:
– Funzionalità di recupero password dimenticata
– Miglioramenti grafici generali
– Diminuzione dei tempi di caricamento
• Progetto 2:
– Implementazione del calcolo fasce tariffarie
– Miglioramenti grafici generali
– Diminuzione del tempo di calcolo delle distanze tra città
– Miglioramento dei pannelli informativi dei punti di interesse con l’aggiunta
di dettagli e possibilità di invio e-mail alle aziende
Si tratta di requisiti classificati come opzionali oppure richiesti in corso d’opera, ed
in accordo con il tutor aziendale si è deciso di delegarne l’eventuale implementazione
al personale nel periodo successivo allo stage.
4.1.5
Conoscenze acquisite
Come già ampiamente riportato nel documento, lo stage riguardava l’uso delle
tecnologie Google e lo sviluppo di applicazioni web.
Gran parte delle tecnologie impiegate mi erano sconosciute, come ad esempio il
linguaggio di programmazione Python e pertanto è stato necessario uno studio preliminare delle stesse per poter affrontare i progetti proposti.
Durante il corso di Ingegneria del Software ho avuto modo di iniziare ad apprendere
la struttura e le tecniche di sviluppo di web applications, cosa che ho potuto ulteriormente approfondire nel periodo di stage.
Una delle difficoltà inizialmente riscontrate è stato l’apprendimento in tempi brevi del
funzionamento dei tool offerti da Google, in quanto la qualità della documentazione
presente online è, a mio avviso, altalenante; per esempio, se le API di Google Maps
ed i tutorial sul funzionamento di App Engine sono completi e ricchi di esempi che
ne facilitano la comprensione, altri aspetti come la documentazione a supporto di
App Engine Datastore sono decisamente poco chiari e incompleti.
Pagina 73 di 79
4.1. OBIETTIVI
Per quanto riguarda i linguaggi di programmazione impiegati, la mia conoscenza
iniziale di Python era quasi nulla: la grande disponibilità della documentazione
presente nel sito ufficiale, unita alla relativa semplicità del linguaggio, mi ha permesso
di impararne le basi in tempi brevi. Inoltre, l’apprendimento di tecnologie in parte
sconosciute come ad esempio AJAX e Javascript si è rivelato proficuo grazie al supporto costante del personale di Nextep e alla grande disponibilità di documentazione
disponibile online.
Infine ho avuto modo di sperimentare in prima persona la metodologia di sviluppo
agile che ben si adatta a progetti di questo tipo, nei quali è richiesta la realizzazione
di prototipi in breve tempo.
Si tratta di un valore aggiunto ad una già completa e soddisfacente esperienza di
stage.
Pagina 74 di 79
Glossario
Glossario
App Engine Datastore: L’App Engine Datastore è un database schemaless che
fornisce un sistema di storage robusto e scalabile all’applicazione web ospitata nella
piattaforma App Engine. Garantisce transazioni atomiche e un sistema di query che
adotta un linguaggio simile a SQL.
API (Application Programming Interface): Insieme di procedure e funzionalità
disponibili al programmatore che consentono di svolgere un certo tipo di compito
all’interno di un programma: in generale il termine identifica le librerie software che
sono messe a disposizione in un determinato linguaggio di programmazione.
CORBA (Common Object Request Broker Architecture): Standard che
permette la comunicazione tra sistemi distribuiti su una rete indipendentemente dal
linguaggio di programmazione con i quali sono implementati.
CSV (Comma Separated Values): Formato di file basato su file testo usato per
l’esportazione e l’importazione di dati da un database ed impiegato prevalentemente
nei fogli di calcolo.
Database: Nell’ambito informatico il termine database (base di dati) indica un
archivio dati in cui le informazioni in esso contenute sono strutturate e collegate tra loro secondo un particolare modello logico e ne permettono la gestione
e interfacciamento dell’utente che può effettuare operazioni di interrogazione ed
inserimento/cancellazione di dati.
Design Pattern: Soluzione progettuale ad un problema ricorrente.Modello logico
da applicare per la risoluzione di un problema che può presentarsi in diverse situazioni
durante le fasi di progettazione e sviluppo del software.
E-commerce: Nell’ambito informatico identifica l’insieme delle applicazioni dedicate
alle transazioni commerciali tramite web.
Google (Azienda): Azienda statunitense che offre servizi online, famosa soprattutto
per il motore di ricerca Google e per il sistema operativo Android largamente usato
nei dispositivi mobile. Google fornisce inoltre una serie di servizi via web tra i quali
figurano Gmail, Google Maps, YouTube, Drive, Calendar.
Pagina 75 di 79
Glossario
Google Apps: Google Apps è un servizio offerto da Google che fornisce strumenti
di cloud computing pensati appositamente per l’uso in ambiti aziendali. I servizi
offerti si basano sugli stessi prodotti offerti da Google ai propri utenti, come GMail,
Drive e Docs.
Google Cloud SQL: Google Cloud SQL permette di usare database relazionali
nelle piattaforme cloud di Google: si tratta di un servizio che mantiene, gestisce
ed amministra i database dell’applicazione sviluppata su App Engine facilitando il
compito degli sviluppatori.
Google Data Center: Il principale centro dati di Google dove sono ospitati
alcuni dei server dell’azienda ed il maggiore centro di elaborazione delle risorse che
costituiscono i servizi di cloud computing.
Google Drive: Servizio di archiviazione e di web hosting offerto da Google, che
permette il file sharing e l’editing collaborativo dei documenti. Può essere utilizzato
collegandosi al sito web oppure tramite l’apposito software installato sul dispositivo.
Google Maps: Servizio messo a disposizione da Google, accessibile dal relativo sito
web, che consente la ricerca e la visualizzazione di mappe geografiche di buona parte
della Terra: tra le funzionalità offerte vi è la possibilità di ricercare singoli luoghi e
percorsi tra due località personalizzabili secondo varie opzioni.
Google Mail (GMail): Servizio gratuito di posta elettronica offerto da Google.
HTTP (HyperText Transfer Protocol): Protocollo di trasferimento di ipertesti
usato come principale sistema per la trasmissione d’informazioni tramite web, le cui
specifiche sono gestite dal World Wide Web Consortium (W3C).
IDE (Integrated Development Environment): Software che aiuta i programmatori nello sviluppo del codice sorgente di un programma.
JSoN (JavaScript Object Notation) : Formato di scambio dati usato in applicazioni distribuite client-server basato sul modello di rappresentazione degli oggetti
nel linguaggio JavaScript. Il suo uso è diffuso soprattutto per la semplicità in cui i
dati sono rappresentati e la sua compatibilità con la maggior parte dei linguaggi di
programmazione.
MVC (Model View Controller): Design pattern architetturale diffuso nello
sviluppo di sistemi software, in particolare nell’ambito della programmazione orientata
agli oggetti, in grado di separare la logica di presentazione dei dati dalla logica di
business, facilitando la manutenzione del prodotto e l’aggiunta di componenti.
PaaS (Platform-as-a-Service): Distribuzione di piattaforme di elaborazione come
servizio. È permesso sviluppare, testare, implementare e gestire le applicazioni
aziendali senza i costi e la complessità associati all’acquisto, la configurazione,
l’ottimizzazione e la gestione dell’hardware e del software di base.
Pagina 76 di 79
Glossario
SaaS (Software-as-a-Service): Modello di distribuzione del software applicativo
dove un produttore di software sviluppa e gestisce un’applicazione web che mette a
disposizione dei propri clienti tramite internet. Il cliente dell’applicazione dunque
non paga per il possesso del software ma per l’utilizzo del software stesso.
Servizi cloud (cloud computing): Insieme di tecnologie che permettono l’archiviazione e l’elaborazione di dati mediante l’uso di risorse hardware e software
distribuite e virtualizzate in rete secondo una tipica architettura client-server. Si
tratta tipicamente di un servizio offerto da un provider al cliente.
SDK (Software Development Kit): In campo informatico si indica con l’acronimo SDK un insieme di strumenti per lo sviluppo e la documentazione di
software.
SOAP (Simple Object Access Protocol): Protocollo per lo scambio di messaggi
tra componenti software, basato secondo il paradigma della programmazione orientata
agli oggetti, utilizzabile in molti protocolli di rete anche se principalmente viene
usato HTTP.
ReST (Representational State Transfer): Architettura software per i sistemi
di ipertesto distribuiti come il World Wide Web che riferisce ad un insieme di principi
di architetture di rete, i quali delineano come le risorse sono definite e indirizzate. Il
termine è spesso usato nel senso di descrivere ogni semplice interfaccia che trasmette
dati su HTTP senza un livello opzionale come SOAP o la gestione della sessione
tramite i cookie.
URI (Uniform Resource Identifier): Stringa che identifica univocamente nel
web una risorsa, che può essere un file di testo, un’immagine, un indirizzo di posta
elettronica, ecc. e le rendono disponibili a vari protocolli di comunicazione come
HTTP o FTP.
URL (Uniform Resource Locator): Si tratta di una specializzazione dell’URI, il
quale identifica una risorsa e fornisce mezzi per agire su di essa oppure per ottenere
una sua rappresentazione, descrivendo il suo meccanismo di accesso primario in una
rete.
W3C (World Wide Web Consortium): Organizzazione non governativa internazionale con lo scopo quello di sviluppare le potenzialità del World Wide Web,
stabilendo standard tecnici inerenti sia i linguaggi di markup che i protocolli di
comunicazione.
Web analytics: Attività di misurazione, raccolta e analisi dei dati tramite internet
con lo scopo di capire e ottimizzare l’uso del web. Non si tratta solo di uno strumento
per la misurazione del traffico web ma di un modo di effettuare ricerche di mercato
con la finalità di migliorare l’efficacia di un sito web.
Pagina 77 di 79
Glossario
Web marketing: Attività di marketing di un’azienda che sfrutta la rete per lo
studio del mercato e lo sviluppo di rapporti commerciali tramite Web, come ad
esempio negozi online.
Web service: Sistema software progettato per supportare l’interoperabilità tra
diversi elaboratori sulla stessa rete, ovvero in un contesto distribuito. L’applicazione
presenta un’interfaccia software che espone all’esterno il servizio associato ai client
che ne desiderano l’utilizzo, mediante lo scambio di dati tramite protocollo HTTP.
Pagina 78 di 79
Bibliografia
Bibliografia
[1] Home page di riferimento per gli strumenti e tecnologie Google:
https://developers.google.com/
[2] Approfondimenti su Google App Engine:
Dan Sanderson, Programming Google App Engine, Ed. O’Reilly
[3] Sito ufficiale di Python:
http://www.python.org/
[4] Manuale di introduzione al linguaggio Python:
Guido van Rossum, An Introduction to Python, Network Theory Ltd, 1 aprile 2003
[5] Documentazione ufficiale di Google App Engine:
https://developers.google.com/appengine/
[6] Documentazione ufficiale di Google Maps API JavaScript v3:
https://developers.google.com/maps/documentation/javascript/
[7] Pagina ufficiale di Eclipse:
http://www.eclipse.org/
[8] Pagina ufficiale di Bitbucket:
https://bitbucket.org
[9] Tutorial per la tecnologia REST:
http://rest.elkstein.org/
Pagina 79 di 79