theses

Università degli Studi Mediterranea di Reggio Calabria
Dipartimento di Ingegneria dell’Informazione, delle Infrastrutture e
dell’Energia Sostenibile
Corso di Laurea in Ingegneria dell’Informazione
Tesi di Laurea
Progettazione e realizzazione, tramite Python, Django e
Bootstrap, di un portale responsive per la gestione di un
centro sportivo: la logica di business
Relatore
Candidato
Prof. Domenico Ursino
Giovanni Quattrocchi
Anno Accademico 2015-2016
Indice
Introduzione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Introduzione al linguaggio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.1 Filosofia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.2 Programmazione di alto e basso livello . . . . . . . . . . . . . . . . . . . .
1.1.3 Cos’è un programma . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1.4 Da Python 2.7 a Python 3.5 . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2 Perchè usare Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.1 L’ambiente di sviluppo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.2 Linguaggi naturali e formali . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.3 Garbage Collection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.2.4 Prestazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.3 Il pattern MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.4 Lo Zen di Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9
9
10
10
11
12
13
14
15
16
17
18
21
Django . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 Caratteristiche generali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1 Funzionalità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2 L’ORM di Django . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3 Espressioni regolari . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.4 Diffusione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 Perché usare un web framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1 Siti ed applicazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2 L’Admin di Django . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 Configurazione di un portale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3.1 Ereditarietà dei template . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23
23
24
25
26
27
27
27
28
30
32
La logica di business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 Il sistema informatico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.1 Funzionalità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2 Livello logico di business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2.1 Usare gli oggetti di business . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
33
33
34
35
36
IV
Indice
3.3 Progettazione multilivello . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Architetture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4 Application Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Vantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Analisi
4.1
4.2
4.3
38
38
39
40
dei requisiti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Descrizione del progetto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Requisiti funzionali e non funzionali . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1 Diagramma dei casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3.2 Dettaglio dei casi d’uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
43
43
44
45
46
46
Progettazione della logica di business . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1 Mappa del sito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Progettazione dei mockup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Progettazione della componente dati . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.1 Progettazione concettuale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.2 Progettazione logica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3.3 Progettazione fisica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.4 Process Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
49
50
51
51
53
55
62
Implementazione della logica di business . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.1 Tecnologie di sviluppo ed interfaccia utente . . . . . . . . . . . . . . . . . . . . . .
6.1.1 Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.2 La pagina index.html . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3 Caratteristiche del portale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1 Login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.2 Area riservata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.3 Tornei . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.4 Prenotazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.4 Manuale di sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
67
67
69
71
74
75
75
76
78
79
Discussione critica in merito al lavoro svolto . . . . . . . . . . . . . . . . . . . . . . . .
7.1 SWOT Analysis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.1 Punti di forza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.2 Punti di debolezza . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.3 Opportunità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.1.4 Minacce . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Confronto con altri sistemi correlati . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.3 Considerazioni in merito all’esperienza maturata . . . . . . . . . . . . . . . . .
85
85
86
87
87
87
87
90
Conclusioni ed uno sguardo al futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Ringraziamenti . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Riferimenti bibliografici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Elenco delle figure
1.1
1.2
1.3
1.4
1.5
1.6
1.7
Il gruppo comico britannico Monty Python . . . . . . . . . . . . . . . . . . . . . . .
Elaborazione per i linguaggi di alto livello . . . . . . . . . . . . . . . . . . . . . . . .
Le principali differenze tra le Versioni 2.x e 3.x di Python . . . . . . . . . .
Il prompt di Python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Ruoli ed attori del pattern MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Aggiornamento dei dati mediante il pattern MVC . . . . . . . . . . . . . . . . .
Selezione di una schermata mediante il pattern MVC . . . . . . . . . . . . . .
10
11
12
15
18
20
20
2.1
2.2
2.3
2.4
Il popolare chitarrista jazz Django Reinhardt . . . . . . . . . . . . . . . . . . . . .
Attori del pattern MTV . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Amministrazione di Django: pannello di login . . . . . . . . . . . . . . . . . . . . .
Ciclo Response - Request di Django . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
24
25
29
31
3.1
3.2
3.3
3.4
3.5
Un generico sistema informatico . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Progettazione della logica di business . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Amministrazione di Django: pannello dei permessi . . . . . . . . . . . . . . . . .
Affinità tra il pattern MVC ed il design pattern a schema three-tier . .
Esempio di Application Server in Java . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
36
37
39
40
4.1
4.2
4.3
4.4
Esempio di layout responsive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
I casi d’uso relativi al sistema (prima parte) . . . . . . . . . . . . . . . . . . . . . .
I casi d’uso relativi al sistema (seconda parte) . . . . . . . . . . . . . . . . . . . . .
I casi d’uso relativi al sistema (terza parte) . . . . . . . . . . . . . . . . . . . . . . .
45
46
47
48
5.1
5.2
5.3
5.4
5.5
5.6
5.7
5.8
5.9
5.10
Mappa gerarchica del sito . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mockup di livello zero relativo alla registrazione . . . . . . . . . . . . . . . . . . .
Mockup di livello due relativo alla registrazione . . . . . . . . . . . . . . . . . . .
Mockup di livello zero relativo alla prenotazione . . . . . . . . . . . . . . . . . . .
Mockup di livello due relativo alla prenotazione . . . . . . . . . . . . . . . . . . .
Mockup di livello zero relativo alla home page . . . . . . . . . . . . . . . . . . . . .
Mockup di livello zero relativo al login . . . . . . . . . . . . . . . . . . . . . . . . . . .
Mockup di livello due relativo alla home page ed al login . . . . . . . . . . .
Lo schema E/R relativo al portale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dizionario delle Entità . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
49
51
52
53
54
55
56
57
58
59
VI
Elenco delle figure
5.11
5.12
5.13
5.14
5.15
5.16
Dizionario delle Relazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Dizionario dei Vincoli . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Process Flow relativo al login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Process Flow relativo alla prenotazione . . . . . . . . . . . . . . . . . . . . . . . . . . .
Process Flow relativo alle prenotazioni in sospeso . . . . . . . . . . . . . . . . . .
Process Flow relativo ad inserimento, eliminazione e modifica di un
campo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
60
61
63
64
65
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
6.9
6.10
6.11
Guido Van Rossum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il logo del Web Framework Django . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Il logo del Framework grafico Bootstrap . . . . . . . . . . . . . . . . . . . . . . . . . .
URL di un sito web realizzato in Django con pattern MVC . . . . . . . . .
Amministrazione di Django: Web App Tornei . . . . . . . . . . . . . . . . . . . . .
Pagina relativa al login . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pagina relativa alla registrazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pagina relativa all’area riservata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Amministrazione di Django: aggiunta di un campo . . . . . . . . . . . . . . . .
Pagina relativa a “La mia Agenda” . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pagina note legali . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
68
69
71
76
77
79
80
81
81
82
83
7.1
7.2
7.3
7.4
7.5
Criteri fondamentali della SWOT Analysis . . . . . . . . . . . . . . . . . . . . . . . .
Home page di Fattore Campo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Home page di Prenotazione Campi Online . . . . . . . . . . . . . . . . . . . . . . . .
Home page di Prenota un Campo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Sviluppatore alle prese con Django e Python . . . . . . . . . . . . . . . . . . . . . .
86
88
89
89
90
66
Elenco dei listati
3.1
6.1
6.2
6.3
6.4
6.5
6.6
6.7
6.8
Implementazione della verifica di una e-mail tramite Django . . . . . . . .
Esempio di implementazione del Design Responsive . . . . . . . . . . . . . . . .
Implementazione della home page (prima parte) . . . . . . . . . . . . . . . . . . .
Implementazione della home page (seconda parte) . . . . . . . . . . . . . . . . .
Parte dell’implementazione del login . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Implementazione dell’area riservata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
L’implementazione della Web App Tornei . . . . . . . . . . . . . . . . . . . . . . . .
Implementazione della prenotazione (prima parte) . . . . . . . . . . . . . . . . .
Implementazione della prenotazione (seconda parte) . . . . . . . . . . . . . . .
37
70
71
73
75
76
77
78
78
All’infinita generosità di mio padre.
All’incondizionato amore di mia madre.
Alla bontà d’animo di mio fratello.
Introduzione
Un portale Web è, al giorno d’oggi, considerato uno strumento di comunicazione
fondamentale e sempre più importante; esso, infatti, rappresenta il mezzo ideale
per sfruttare al meglio le opportunità offerte da Internet, farsi conoscere ed avere
successo.
Gli utenti che accedono al mondo online sono cresciuti del 10% soltanto nell’ultimo anno, cosı̀ come gli utenti dei social media; mentre l’ormai indiscutibile trend
di crescita dei dispositivi mobili è di tipo esponenziale. Gli utenti che utilizzano
il World Wide Web, su una popolazione mondiale di 7,4 miliardi di persone, sono
circa 3,4 miliardi, mentre ben 2,3 miliardi utilizzano anche i social network.
Lo sviluppo di un sito web, quindi, rappresenta un vero e proprio biglietto da
visita; attraverso una grafica accattivante e un’organizzazione intuitiva dei contenuti, esso può apportare un contributo significativo alle scelte degli utenti che lo
visitano, oltre a fornire loro un accesso immediato e semplice ai dati che contiene.
Esso deve essere costantemente aggiornato, completo, accessibile da chiunque
e con le informazioni strutturate in modo tale che siano facilmente rintracciabili e
fruibili.
Questo panorama digitale in continua evoluzione ha stimolato la nascita di nuovi
linguaggi; accanto ai colossi Java e PHP hanno fatto la loro comparsa anche .NET,
Perl, Ruby e Python, tutti adatti per la creazione e la manipolazione di contenuti
e servizi per il Web.
Con una cosı̀ grande varietà di linguaggi a disposizione, è stato decisivo, ai
fini dell’informatizzazione della realtà considerata, valutare attentamente i motivi
secondo i quali scegliere o scartare un linguaggio piuttosto che un altro.
Python è un linguaggio di programmazione dalla sintassi chiara, facile da apprendere, moderno e caratterizzato dalla presenza di un ricco assortimento di funzioni
di base, grazie alle quali, è possibile un approccio semplificato per chiunque si avvicini ad esso. Python presenta qualche somiglianza con Perl; proprio per questo, a
volte, viene classificato tra i linguaggi di scripting; tuttavia, pur essendo molto utile
in questo senso, la sua sintassi essenziale lo rende particolarmente indicato per la
creazione e lo sviluppo di applicazioni molto complesse.
Grazie al suo essere object-oriented, Python permette una programmazione
ben strutturata, mettendo il programmatore nelle condizioni di gestire molto bene progetti di grandi dimensioni; inoltre, è ideale sia per la modellazione di te-
6
Introduzione
mi appartenenti al mondo reale, sia per la realizzazione di modelli astratti da
riprodurre.
Python è un linguaggio molto efficiente; da un lato compila il proprio codice
molto velocemente, e questo permette di raggiungere prestazioni molto vicine a
quelle relative ai linguaggi in codice nativo; dall’altro, implementa un meccanismo
di liberazione automatica della memoria definito Garbage Collection.
Per la scelta dell’oggetto da realizzare nella presente tesi, data la varietà dei
sistemi operativi di tipo mobile, la preferenza è ricaduta su un portale di tipo
responsive, le cui pagine web siano capaci di adattarsi in base al dispositivo che si
sta utilizzando per visualizzarle.
Non esiste un’unica strada per ottenere un sito web di questo tipo; ad esempio,
ci si può avvalere del supporto di un CMS (Content Management System), per la
gestione dei contenuti, o di framework pensati proprio per tale scopo.
Nel nostro caso, infatti, sono stati scelti Django, per l’implementazione del backend, e Bootstrap, per la creazione del front-end, dividendo il portale in due macroaree tematiche; la prima, oggetto della presente tesi, riguardante i meccanismi legati
alla logica di business ed alle implementazioni che rendono possibile il funzionamento del sistema; la seconda, oggetto di un’altro elaborato di tesi tuttora in fase di
realizzazione, legata all’interfaccia utente.
Per i numerosi e validi motivi sopra citati, Python è risultato lo strumento perfetto che si stava cercando, e, grazie all’accostamento con il Web Framework Django,
le sue View che evitano la stesura di codice ripetitivo, i suoi sistemi di espressioni regolari e template ed i suoi plug-in, si è riusciti a testare a fondo, nell’ambito
della realizzazione di un portale complesso come quello da noi implementato, gli
strumenti di cui ci siamo dotati.
Semplicemente sfruttando le numerose librerie messe a disposizione dai framework, si sostiene il programmatore nella realizzazione di vari compiti, sia dal
punto di vista grafico, sia dal punto di vista logico, lasciandogli la totale libertà di
scegliere in che modo implementare le funzionalità.
Utilizzando questo particolare tipo di layout adattativo, inoltre, l’esperienza mobile del portale risulterà particolarmente comoda, diminuendo i tempi di
navigazione.
Questo elaborato di tesi si colloca proprio all’interno di uno scenario applicativo
del genere; esso si pone come obiettivo la creazione, mediante il linguaggio Python
ed i framework Bootstrap e Django, di un portale per la gestione di un centro
sportivo.
Le motivazioni di tale scelta sono di natura gestionale e possono essere ricondotte
alla filosofia dell’aggiornamento e del miglioramento continuo, cosı̀ come vuole la
tecnologia, sempre dinamica, in evoluzione ed in continua corsa contro se stessa.
Per far fronte alle problematiche di sviluppo si è resa necessaria la progettazione
di un portale Web che, oltre a migliorare l’esperienza dell’utente, potesse tener
conto della lunga trafila legata alle modalità attuali di gestione delle prenotazioni
sportive, eliminandola.
Dopo aver effettuato un’analisi attenta delle esigenze dell’utente, finalizzata alla
conoscenza dei suoi reali bisogni, è stata costruita l’alberatura del sito, sviluppando,
dapprima, la Home Page, unica sezione che non necessita di autenticazione, e, solo
successivamente, l’Area Riservata. Per far ciò, si è seguito lo stile emerso dagli
Introduzione
7
strumenti utilizzati, uno su tutti il pattern Model-View-Controller, che ha consentito
di generare delle pagine i cui contenuti rispettino delle regole ben definite, con lo
scopo di migliorare la navigazione e, più in generale, la manutenibilità del codice.
Se dovessimo scegliere una sola caratteristica che rappresenti il valore di Django,
la sua versatilità e la facilità di sviluppo ad esso legata, orienteremmo di certo
la nostra scelta proprio sulla comodissima interfaccia di amministrazione usata e
sulla possibilità di creare una cartella per ciascuna Web App, implementando, cosı̀,
le funzionalità che ogni utente avrà a disposizione all’interno della propria area
riservata. Organizzando il lavoro secondo lo schema suggerito, ovvero utilizzando
una vera e propria composizione di pattern, si distribuisce il codice in modo tale da
avere la sicurezza che, in caso di problemi, l’eventuale intervento rimanga circoscritto
ad un blocco soltanto, lasciando intatti gli altri.
Tra i risultati emersi dall’analisi svolta, un caso particolarmente interessante
è legato alla comprensione dei profili e delle figure che effettueranno l’accesso al
portale, in modo tale che la loro permanenza sul sito possa essere personalizzata
sulla base del ruolo che ricoprono.
I membri dello staff, ad esempio, potranno aggiungere, modificare e rimuovere
campi e tornei, cosa che, chiaramente, ai fini di un corretto andamento del portale,
dovrà essere impedita agli utenti standard; questi, a loro volta, potranno iscriversi
ad uno o più eventi organizzati dagli impianti sportivi, facendo in modo che la
prenotazione venga registrata, in maniera automatica, all’interno della pagina “La
mia Agenda”.
All’interno della presente tesi verranno trattati i processi di analisi, progettazione
ed implementazione delle funzionalità menzionate in precedenza.
La tesi è strutturata come di seguito specificato:
•
•
•
•
•
•
•
•
Nel Capitolo 1 saranno descritti la filosofia, le caratteristiche e le prestazioni di
Python, fornendo i motivi per i quali esso è stato scelto come linguaggio per lo
sviluppo del sistema.
Il Capitolo 2 fornirà una panoramica su Django, il popolare Web Framework
utilizzato; si analizzeranno, inoltre, la sua diffusione ed i vantaggi derivanti dal
suo utilizzo.
Il Capitolo 3 descrive la logica di business, quella logica grazie alla quale si rende
funzionante il core di un sistema informatico. Si effettuerà, inoltre, un focus sugli
oggetti, sulle architetture multilivello e sugli Application Server.
Nel Capitolo 4 si descriveranno le fasi di analisi dei requisiti e di ricerca dei casi
d’uso che il sistema dovrà implementare.
Il Capitolo 5 fornirà una descrizione delle fasi di progettazione della componente
applicativa del portale, suddivisa, come da prassi, nelle sue classiche sottofasi.
Il Capitolo 6 descriverà l’implementazione del sito web oggetto del presente
elaborato, analizzando, nel dettaglio, le tecnologie adottate per lo sviluppo delle
pagine ed illustrando il codice utilizzato.
Nel Capitolo 7 sarà presentata l’analisi SWOT relativa al progetto; successivamente, verrà effettuato un confronto con i sistemi correlati.
Infine, il Capitolo 8 tratterà le conclusioni sul lavoro svolto ed esaminerà alcuni
possibili sviluppi futuri.
1
Python
All’interno di questo capitolo approfondiremo il linguaggio di programmazione Python, le sue prestazioni, la sua filosofia e la sua evoluzione, facendo particolare
attenzione ai molti aspetti positivi ed ai pochi, negativi, che lo caratterizzano.
1.1 Introduzione al linguaggio
Python è un linguaggio di programmazione orientato agli oggetti che fa della dinamicità, della semplicità e della flessibilità i suoi principali obiettivi e punti di forza.
Nasce nei primi anni novanta per mano del ricercatore Guido Van Rossum, che,
lavorando all’interno del National Research Institute for Mathematics and Computer Science di Amsterdam ad un linguaggio di nome ABC, comincia ad ingegnarsi
per migliorarne le prestazioni. Nel 1996 arriva a pubblicare il libro Programming
Python, la cui prefazione riporta:
“Più di sei anni fa, nel dicembre 1989, stavo cercando un progetto di programmazione per hobby che mi avrebbe dovuto tenere occupato nella settimana vicina a Natale. Il mio ufficio sarebbe stato chiuso, ma io avevo un
computer, e non molto di più. Decisi di scrivere un interprete per un nuovo
linguaggio di scripting a cui avrei pensato dopo: un discendente dell’ABC,
che sarebbe dovuto appartenere agli hacker di Unix. Scelsi Python come nome per il progetto, essendo leggermente irriverente, e sono un grande fan di
Monty Python’s (Figura 1.1) Flying Circus”
Qualche anno più tardi, con Python arrivato alla versione 1.6, Van Rossum e il
suo team si trasferiscono, facendo partire il progetto BeOpen PythonLabs, che, nel
2008, darà il via ad una vera e propria rivoluzione grazie al rilascio della versione
3.0 di Python, che rompe la compatibilità con le vecchie versioni 2.x.
10
1 Python
Figura 1.1. Il gruppo comico britannico Monty Python
1.1.1
Filosofia
Python è un linguaggio di programmazione moderno, dalla sintassi semplice e potente, che ne facilita l’apprendimento. È object-oriented, quindi in grado di definire
ed interagire con oggetti software particolarmente indicati sia per la modellazione
degli oggetti del mondo reale o del modello astratto da riprodurre, sia per la manutenzione di progetti di grandi dimensioni, permettendo, cosı̀, una programmazione
ben strutturata.
Le caratteristiche più immediatamente riconoscibili di Python sono le variabili
non tipizzate, l’uso dell’indentazione per la definizione dei blocchi e la presenza
di un ricco assortimento di funzioni di base, che, assieme alle librerie standard
ed alla documentazione disponibile, permettono, come detto prima, un approccio
semplificato per chiunque si avvicini ad esso.
Il controllo del tipo di dato è comunque forte, e viene eseguito a runtime, in
maniera dinamica, con l’ausilio di un garbage collector per la liberazione automatica
della memoria.
Python ha qualche somiglianza con Perl, ma i suoi progettisti hanno scelto la
via di una sintassi più essenziale ed uniforme, con l’unico obiettivo di aumentare la
leggibilità del codice. Viene spesso classificato tra i linguaggi di scripting, ma, pur
essendo molto utile in questo senso, la grande quantità di librerie disponibili e la
facilità di utilizzo lo rendono adatto allo sviluppo di applicazioni molto complesse,
che vanno dai database al web, dal networking alla grafica.
1.1.2
Programmazione di alto e basso livello
Adatto, tra le altre cose, per sviluppare applicazioni distribuite ed effettuare system
testing, Python è spesso paragonato a C, C++, Perl e Java per le sue peculiarità
che lo rendono un linguaggio di alto livello. Esistono, anche, linguaggi di basso
livello, talvolta chiamati linguaggi macchina o assembly, i quali vengono eseguiti
direttamente, senza dover essere prima elaborati.
1.1 Introduzione al linguaggio
11
Chiaramente, il processo di elaborazione impiega del tempo e rappresenta un
piccolo svantaggio, ma, d’altra parte, i vantaggi sono innumerevoli.
In primo luogo è molto più facile programmare in un linguaggio ad alto livello:
questi tipi di programmi sono più veloci da scrivere, più corti e facilmente leggibili,
ed è più probabile che siano corretti. In secondo luogo i linguaggi di alto livello sono
portabili: portabilità significa che essi possono essere eseguiti su tipi di computer diversi con poche, (o addirittura nessuna) modifiche. I programmi scritti in linguaggio
di basso livello possono essere eseguiti solo su un tipo di computer e devono essere
riscritti per poter essere trasportati su un altro sistema.
I vantaggi dei linguaggi di alto livello sono cosı̀ evidenti che quasi tutti i programmi sono ormai scritti in linguaggi di alto livello, lasciando spazio ai linguaggi
di basso livello solo in poche applicazioni specializzate. I programmi di alto livello
vengono trasformati in programmi di basso livello tramite due tipi di elaborazione:
l’interpretazione e la compilazione. Un interprete legge il programma di alto livello
e lo esegue, trasformando ogni riga di istruzioni in un’azione. L’interprete elabora
il programma un po’ alla volta, alternando la lettura delle istruzioni all’esecuzione
dei comandi che queste ultime descrivono (Figura 1.2).
Figura 1.2. Elaborazione per i linguaggi di alto livello
1.1.3
Cos’è un programma
Un programma è una sequenza di istruzioni che specificano come effettuare un’elaborazione. Quest’ultima può essere sia di tipo matematico (per esempio la soluzione
di un sistema di equazioni o il calcolo delle radici di un polinomio) che simbolico (per
esempio la ricerca e sostituzione di un testo in un documento). I dettagli sono diversi per ciascun linguaggio di programmazione, ma un piccolo gruppo di istruzioni
è praticamente comune a tutti. Queste sono:
•
•
•
•
•
Input: ricezione di dati da tastiera, da file o da altro dispositivo.
Output: scrittura di dati su video, su file o trasmissione ad altro dispositivo.
Operazioni : esecuzione di semplici operazioni matematiche, quali l’addizione e
la sottrazione.
Condizioni : controllo di alcune condizioni ed esecuzione della sequenza di
istruzioni appropriata.
Ripetizioni : ripetizione di un’azione specifica, o di una simile, con qualche
variazione.
Che ci si creda o meno, questo è più o meno tutto quello che c’è. Ogni programma
che utilizziamo, per quanto complesso possa sembrare, è costituito da istruzioni che
assomigliano a queste.
12
1 Python
Possiamo affermare che la programmazione altro non è che la suddivisione di un
compito grande e complesso in una serie di sotto-compiti via via più piccoli, finché
questi sono sufficientemente semplici da essere eseguiti da una di queste istruzioni
fondamentali.
1.1.4
Da Python 2.7 a Python 3.5
Python 2.7 è la versione più diffusa di Python per il calcolo scientifico ed ingegneristico. In questo campo predominano i sistemi a 64-bit, in genere con ambienti
Linux o Mac, che, da un lato, permettono di installare grandi quantità di memoria
RAM, dall’altro consentono di realizzare applicazioni facilmente implementabili e
configurabili.
Chi usa Windows, invece, dovrà faticare un po’ di più: la maggior parte del
codice funzionerà bene, ma alcuni aspetti sono specifici del sistema operativo e si
dovrà cercare una soluzione Windows apposita.
Una delle maggiori difficoltà potrebbe essere legata all’installazione dei moduli,
tuttavia esistono soluzioni all-inclusive, come Anaconda, Canopy o Sage, che semplificano la portabilità, eseguendo contemporaneamente sia Python 2 sia Python 3.
Python 2.7 sarà, comunque, utilizzato per molti anni ancora (alcune installazioni
utilizzano ancora la Versione 2.4), la sua data di pensionamento è fissata per il
2020. Il passaggio a Python 3 e versioni successive ha causato tali grattacapi agli
sviluppatori di librerie, che molti hanno tardato a sistemare il proprio codice poiché,
questa volta, non è stata garantita la retro-compatibilità. Tuttavia Python 3 è il
futuro e tutti si stanno adattando. La Figura 1.3 mostra i principali cambiamenti
tra le due Versioni:
Figura 1.3. Le principali differenze tra le Versioni 2.x e 3.x di Python
1.2 Perchè usare Python
13
1.2 Perchè usare Python
Ad oggi esistono numerosi linguaggi di programmazione; ma cosa ci spinge ad usare
Python? Cos’ha di particolare questo linguaggio? Esaminiamo, ora, i suoi punti di
forza ed alcune delle sue applicazioni principali.
È free
Python è completamente gratuito e può essere usato e distribuito senza restrizioni di
copyright. Spesso alla parola free è associato il concetto di software non supportato,
ma non è questo il caso: è sufficiente consultare il sito ufficiale per rendersene conto.
È object-oriented
Python è un linguaggio orientato agli oggetti, supporta nozioni avanzate di polimorfismo, ereditarietà ed operatori di overloading, con una sintassi tutt’altro che
complessa.
È user-friendly
Python è un linguaggio di alto livello con una sintassi dalle regole piuttosto semplici,
ideale per chi si avvicina per la prima volta al mondo dell’informatica, ma anche
per chi ha fatto già esperienza di programmazione con altri linguaggi.
È ricco di librerie
La dotazione standard di Python offre numerose librerie alle quali si aggiungono
moduli di terze parti che crescono continuamente.
Ha performance elevate
Python è un linguaggio molto efficiente; da un lato, compila il proprio codice in
un bytecode molto velocemente permettendo di raggiungere prestazioni vicine ai
linguaggi in codice nativo; dall’altro, implementa molte strutture dati e funzioni
come componente intrinseca del linguaggio. Queste strutture sono dette built-in
types and tools e sono state sviluppate molto accuratamente.
Gestisce la memoria automaticamente
In Python, come in Java, esiste il meccanismo di garbage collection, che permette
di liberare il programmatore dall’ansia di allocazione selvaggia della memoria.
È integrabile con altri linguaggi
Python può essere integrato con altri linguaggi, come, ad esempio, .NET, attraverso
IronPython, o Java, attraverso Jython.
14
1 Python
Come abbiamo visto, la dotazione standard e le librerie di terze parti completano in
maniera eccelsa Python, oltre a farlo crescere in termini di duttilità e funzionalità.
Esso può essere utilizzato per lo sviluppo di interfacce utente (con PyQt o wxPython), per lo sviluppo web (con Django o Web2py), per i database (si interfaccia
con Oracle, SQLite, MySQL, PostgreSQL), per la realizzazione di giochi (con pyGame e pyKyra), per applicazioni scientifiche (SciPy), per grafica 3D (con TkInter,
VPython), e in tanti altri campi. Python risulta un’ottima soluzione anche per molte grandi realtà del mercato informatico come, ad esempio, la NASA, che lo utilizza
per lo sviluppo di alcuni sistemi di controllo, Yahoo!, che lo ha usato per la creazione di alcuni servizi Internet, o ancora Google, che ne ha fatto una componente
sostanziale del suo ecosistema.
1.2.1
L’ambiente di sviluppo
Poichè i sistemi operativi sono molto spesso variegati, è necessario prendere confidenza con l’ambiente di programmazione. Molti computer mettono a disposizione
un ambiente di sviluppo integrato (IDE, Integrated Development Environment), nel
quale scrivere e collaudare i programmi. In altri computer, invece, occorre, innanzitutto, mettere in esecuzione un editor di testo, dove si scrivono le istruzioni in
linguaggio Python, e, successivamente, aprire una finestra di terminale ed eseguire
i comandi che daranno il via.
Per convenzione consolidata, nell’apprendere un nuovo linguaggio di programmazione, si usa un programma che visualizza un semplice saluto, il famosissimo
“Hello, World!”; questo in Python 3 risulta:
print(‘‘Hello, World!’’)
Indipendentemente dall’ambiente di programmazione utilizzato, l’attività inizia
con la scrittura delle istruzioni all’interno della finestra di un editor. Python distingue tra lettere maiuscole e lettere minuscole; di conseguenza è necessario fare
attenzione se non si vuole incorrere in errori banali.
Un programma Python viene eseguito usando l’interprete Python, che legge il
programma e ne esegue le istruzioni. In alcuni ambienti di programmazione l’interprete viene eseguito automaticamente nel momento in cui si seleziona il comando
Run, mentre in altri occorre attivarlo e metterlo in esecuzione in maniera esplicita.
L’attività del programmatore prevede di scrivere programmi, eseguirli e migliorarli: un programma Python può essere memorizzato in un file avente qualunque
nome, a patto che termini con l’estensione *.py; inoltre è consigliabile conoscere
tutte le diramazioni che la cartella in cui scegliamo di salvare il file può contenere,
in modo da organizzare al meglio il lavoro. Alcuni ambienti di programmazione posizionano i programmi in una cartella predefinita di default, a meno che non se ne
specifichi un’altra.
L’interprete di Python è dotato, anche, di una modalità interattiva, che consente
di scrivere le istruzioni una per volta.
La sequenza di caratteri >>> ci indica il punto da cui è possibile scrivere le
nostre istruzioni, e costituisce il prompt: se, ad esempio, abbiamo il comando di
1.2 Perchè usare Python
15
stampa ‘‘Hello, World!’’, l’interprete risponderà eseguendo la funzione di stampa e visualizzando i dati in uscita, seguiti da un nuovo prompt, come mostrato in
Figura 1.4:
Figura 1.4. Il prompt di Python
Questa modalità interattiva si rivela particolarmente utile nella fase iniziale dell’apprendimento, poiché ci consente di fare esperimenti, test e collaudi di singole
istruzioni.
1.2.2
Linguaggi naturali e formali
I linguaggi naturali sono le lingue parlate, ad esempio l’inglese, l’italiano, lo spagnolo. Non sono stati progettati da qualcuno, e, anche se è stato imposto un certo ordine
nel loro sviluppo, si sono evoluti naturalmente. I linguaggi formali sono, invece, linguaggi progettati per specifiche applicazioni. Per fare qualche esempio, la notazione
matematica è un linguaggio formale particolarmente indicato ad esprimere relazioni
tra numeri e simboli, i chimici usano un linguaggio formale per rappresentare la
struttura delle molecole, e cosı̀ via. I linguaggi di programmazione sono linguaggi
formali che sono stati progettati per esprimere elaborazioni.
I linguaggi formali tendono ad essere piuttosto rigidi per quanto riguarda la
sintassi: 3+3=6 è una dichiarazione matematica sintatticamente corretta, mentre
3=/6$ non lo è. H2O è un simbolo chimico sintatticamente corretto contrariamente
a 2Zz.
Le regole sintattiche si possono dividere in due categorie: la prima riguarda
i token, la seconda la struttura. I token sono gli elementi di base del linguaggio
(quali possono essere le parole in letteratura, i numeri in matematica e gli elementi
chimici in chimica). Uno dei problemi con 3=/6$ è che $ non è un token valido in
matematica, e 2Zz non è valido perché nessun elemento chimico è identificato dal
simbolo Zz.
Il secondo tipo di regola riguarda la struttura della dichiarazione, cioè il modo
in cui i token sono disposti.
16
1 Python
La dichiarazione 3=/6$ è strutturalmente non valida perché un segno di frazione
‘‘/’’ non può essere posto immediatamente dopo un segno di uguaglianza ‘‘=’’.
Quando leggiamo una frase in italiano o una dichiarazione in un linguaggio di
programmazione, dobbiamo capire quale sia la struttura della dichiarazione. Questo
processo è chiamato parsing ed in un linguaggio naturale viene realizzato in modo
inconscio, spesso non rendendosi conto della sua intrinseca complessità.
Anche se i linguaggi formali e quelli naturali condividono molte caratteristiche (token, struttura, sintassi e semantica), ci sono, tuttavia, alcune importanti
differenze; queste saranno di seguito esaminate.
Ambiguità
I linguaggi naturali ne sono pieni; il significato viene ottenuto anche grazie ad indizi
ricavati dal contesto. I linguaggi formali sono progettati per essere completamente
non ambigui e ciò significa che ciascuna dichiarazione ha esattamente un significato,
indipendente dal contesto.
Ridondanza
Per evitare l’ambiguità e ridurre le incomprensioni, i linguaggi naturali impiegano
molta ridondanza. I linguaggi formali devono essere meno ridondanti e più concisi
possibile.
Letteralità
I linguaggi naturali fanno uso di paragoni e metafore; anche quando parliamo in
termini astratti intuiamo immediatamente che ciò che sentiamo ha un significato
simbolico. I linguaggi formali, invece, esprimono esattamente ciò che dicono.
1.2.3
Garbage Collection
Inventata nel 1959 da John McCarthy per il linguaggio di programmazione Lisp, la
Garbage Collection (a volte abbreviata con GC), letteralmente raccolta dei rifiuti, è
una modalità automatica di gestione della memoria, mediante la quale un sistema
operativo, o un compilatore e un modulo di runtime, svuotano le porzioni di memoria non più utilizzate dalle applicazioni, esonerando, cosı̀, il programmatore, e
liberandolo dalla necessità di prevedere quando rilasciare le risorse. In altre parole,
il Garbage Collector, altrimenti detto netturbino, annoterà le aree di memoria non
più referenziate, cioè allocate da un processo attivo e le libererà automaticamente.
Questo meccanismo ha condotto ad un notevole progresso nello stile di programmazione dei linguaggi che lo implementano; infatti, non è più necessario richiedere
esplicitamente la liberazione della memoria utilizzata da un oggetto, ma si lascia
che il sistema esegua questa operazione automaticamente, nel momento in cui lo
riterrà più opportuno al fine di migliorare le prestazioni complessive.
Per la gestione della memoria si tiene conto di due principi fondamentali:
• trovare gli oggetti in un programma ai quali non sarà più necessario accedere;
1.2 Perchè usare Python
•
17
recuperare le risorse che sono state utilizzate da questi oggetti.
Tale modalità automatica migliora la stabilità dei programmi, in quanto consente
di evitare quella classe di bug connessi alla necessità di manipolare direttamente, da
parte del programmatore, i puntatori alle varie aree di memoria che contenevano gli
oggetti utilizzati durante l’esecuzione, ma già rilasciati per altri usi. Alcuni linguaggi
di programmazione, come Python, Java e C#, hanno un sistema di GC integrato
direttamente nell’ambiente di esecuzione, mentre per altri linguaggi, come C e C++,
la sua eventuale implementazione è a carico del programmatore.
Molti altri linguaggi utilizzano una combinazione dei due approcci, consentendo
all’utente sia di non eliminare manualmente gli oggetti, sia di farlo, disattivando la
gestione automatica del sistema.
La Garbage Collection presenta, tuttavia, anche alcuni svantaggi:
•
•
•
Consumo eccessivo di risorse: il processo consuma risorse di calcolo, al fine sia
di tenere traccia dell’utilizzo delle varie aree di memoria, sia di poter decidere il
momento e la quantità di memoria da liberare.
Incertezza: il momento in cui viene effettuata la GC non è prevedibile; questa
incertezza può determinare improvvisi blocchi o ritardi nell’esecuzione. Problemi
di questo genere sono inaccettabili in ambienti real-time.
Approccio non deterministico: il momento in cui una data area di memoria viene
rilasciata dipende dal particolare algoritmo implementato, che varia, e non può
essere determinato.
1.2.4
Prestazioni
Se paragonato ai linguaggi compilati statically typed, come ad esempio il C, la velocità di esecuzione di Python non è uno dei suoi punti di forza, specie nel calcolo
matematico. Esiste, però, un’estensione chiamata Psyco, una sorta di compilatore,
che permette di velocizzare in modo notevole alcuni tipi di codice, specialmente
l’implementazione di algoritmi, pur pagandone un prezzo in termini di memoria
utilizzata.
Le performance di Python sono, invece, allineate, o addirittura superiori, ad
altri linguaggi interpretati, quali PHP e Ruby; in alcune condizioni Python può
rivaleggiare anche con Java. Non va, inoltre, dimenticato che Python permette di
aggirare in modo facile l’ostacolo delle performance pure: è, infatti, relativamente
semplice scrivere un’estensione in C o C++ e poi utilizzarla all’interno di Python,
sfruttando, cosı̀, l’elevata velocità di un linguaggio compilato solo nelle parti in cui
effettivamente serve e la potenza e la versatilità di Python per tutto il resto del
software.
Con opportune accortezze e utilizzando solo moduli standard, in alcuni casi,
Python può raggiungere una velocità di esecuzione pari ad un codice equivalente
in C, grazie ad una serie di ottimizzazioni interne della PVM (Parallel Virtual
Machine).
18
1 Python
1.3 Il pattern MVC
Il pattern MVC (Model-View-Controller) è molto famoso ed al contempo complesso,
dal momento che stiamo parlando di una vera e propria composizione di pattern.
Venne introdotto all’interno del mondo software per la costruzione di interfacce
grafiche; oggi deve gran parte della sua fama a Python e Java.
Al momento dello sviluppo di programmi ed applicazioni, non è possibile prevedere con certezza in che modo e con quale tecnologia gli utenti interagiranno.
Appare, quindi, chiaro il bisogno di un’architettura che permetta la separazione
netta tra i componenti software che gestiscono il modo di presentare i dati e i
componenti che gestiscono i dati stessi.
Lo sviluppatore, organizzando il codice secondo lo schema in Figura 1.5, potrà
concentrarsi su un problema specifico ed avere la sicurezza che l’intervento rimanga
circoscritto al blocco di codice di cui si sta occupando, lasciando intatti gli altri.
Se pensiamo, poi, ad un progetto di grandi dimensioni, in cui presumibilmente ogni
parte sarà creata e mantenuta da persone diverse, diventa evidente come la divisione
logica del codice in zone distinte aumenti l’efficienza complessiva.
Figura 1.5. Ruoli ed attori del pattern MVC
Analizziamo adesso, nel dettaglio, le responsabilità dei tre componenti del
pattern MVC.
1.3 Il pattern MVC
19
Model
Il core viene implementato dal Model, che, incapsulando lo stato dell’applicazione,
include i dati e le operazioni che possono essere eseguite su di essi, definendo, di
fatto, le regole di business per l’interazione con l’esterno, esponendo alla View ed
al Controller, rispettivamente, le funzionalità per l’accesso e l’aggiornamento.
Per lo sviluppo del Model, quindi, è consigliato utilizzare le tipiche tecniche
di progettazione object-oriented al fine di ottenere un componente software che
astragga al meglio concetti importati dal mondo reale. Il Model può, inoltre, avere
la responsabilità di notificare ai componenti della View eventuali aggiornamenti
verificatisi in seguito a richieste del Controller, al fine di permettere alle View di
presentare agli occhi degli utenti dati sempre aggiornati.
View
La logica di presentazione dei dati viene gestita solo ed esclusivamente dalla View.
Ciò implica che questa deve, fondamentalmente, gestire la costruzione dell’interfaccia grafica (GUI) che rappresenta il mezzo mediante cui gli utenti interagiranno con
il sistema. Ogni GUI può essere costituita da schermate diverse, ciascuna della quali
può presentare più modi di interagire con i dati dell’applicazione. Le View possono, quindi, richiedere gli aggiornamenti al Model in tempo reale grazie alla notifica
di quest’ultimo; nonostante questa rappresenti la strategia ideale, non è sempre
applicabile. Inoltre la View delega al Controller l’esecuzione dei processi richiesti
dall’utente, dopo averne catturato gli input e le scelte nelle eventuali schermate
presentate in precedenza.
Controller
Questo componente ha la responsabilità di trasformare le interazioni dell’utente della View in azioni eseguite dal Model. Anche se potrebbe sembrare cosı̀, il Controller
non rappresenta un semplice ponte tra View e Model; esso realizza la mappatura tra
input dell’utente e processi eseguiti dal Model e seleziona le schermate della View
richiesta.
Questo tipo di approccio è utile, quindi, per separare i componenti software che
implementano il modello delle funzionalità di business dai componenti che ne
implementano la logica di presentazione e di controllo.
Evidenziamo ora due dei possibili scenari che potrebbero presentarsi durante
l’utilizzo di un’applicazione MVC-based, ovvero l’aggiornamento dei dati (Figura
1.6) e la selezione di una schermata (Figura 1.7).
20
1 Python
Figura 1.6. Aggiornamento dei dati mediante il pattern MVC
Figura 1.7. Selezione di una schermata mediante il pattern MVC
1.4 Lo Zen di Python
21
In Figura 1.6 si evidenzia il complesso scambio di messaggi tra i tre partecipanti al pattern, che, nonostante a prima vista possa sembrare inutile o esagerato,
garantisce pagine sempre aggiornate in tempo reale.
In Figura 1.7 si capisce come la View si occupi solo delle attività di costruzione
e presentazione della schermata all’utente, non decidendo quale essa sia, scelta che
viene delegata al Controller.
Il pattern MVC introduce una notevole complessità all’interno del nostro progetto ed è, sicuramente, di non facile comprensione. Tuttavia, il suo utilizzo si rende
praticamente necessario in tantissime applicazioni moderne, dove le GUI sono insostituibili. Non conviene, quindi, avventurarsi alla scoperta di nuove interazioni tra
logica di business e di presentazione, se una soluzione certa esiste già.
1.4 Lo Zen di Python
Il 3 giugno del 1999, Patrick Phalen mandò un messaggio a Guido van Rossum e
Tim Peters intitolato The Python Way; sostanzialmente, egli suggeriva di scrivere
un documento composto da 15/20 aforismi, che potessero riassumere lo spirito del
linguaggio, una sorta di Zen di Python per gli utenti, da leggere nel momento in
cui le lamentele e le richieste di aiuto fossero diventate un po’ troppe da gestire.
Esattamente 24 ore più tardi ebbe una risposta, un elenco di 19 simpatici aforismi
consegnati alla storia, contenenti tutte le risposte ad ogni possibile problema di
design e di stile che interessava Python.
Ecco i principi guida in lingua originale:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren’t special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one, and preferably only one, obvious way to do it.
Although that way may not be obvious at first, unless you’re Dutch.
Now is better than never.
Although never is often better than right now.
If the implementation is hard to explain, it’s a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea, let’s do more of those!
22
1 Python
Ecco i principi guida tradotti in italiano:
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
Bello è meglio che brutto.
Esplicito è meglio di implicito.
Semplice è meglio che complesso.
Complesso è meglio di complicato.
Lineare è meglio di nidificato.
Sparso è meglio di denso.
La leggibilità conta.
I casi speciali non sono abbastanza speciali per infrangere le regole.
Anche se la praticità batte la purezza.
Gli errori non dovrebbero mai essere ignorati.
A meno che non vengano messi a tacere.
In caso di ambiguità, rifiuta la tentazione di indovinare.
Ci dovrebbe essere un modo ovvio, e preferibilmente uno solo, di fare le cose.
Anche se questo modo potrebbe non essere ovvio da subito, a meno che non
siate olandesi.
Ora è meglio che mai.
Sebbene mai sia spesso meglio che proprio ora.
Se l’implementazione è difficile da spiegare, l’idea è pessima.
Se l’implementazione è facile da spiegare, l’idea può essere buona.
I namespace sono una grandissima idea, usiamoli il più possibile!
2
Django
Questo capitolo sarà un percorso alla scoperta di Django, il valido e popolare
framework scritto in Python, efficace per lo sviluppo di applicazioni Web.
2.1 Caratteristiche generali
Django nasce nell’autunno del 2003, quando un gruppo di programmatori web,
Adrian Holovaty, Simon Willison e Jacob Kaplan-Moss, presso la redazione di un
giornale, decidono di iniziare ad usare Python per le loro applicazioni. Il framework,
quindi, è stato sviluppato in ambiente giornalistico, caratterizzato dalla necessità di
pubblicare notizie con rapidità e di organizzare gli spazi in modo flessibile. Proprio
per questo motivo, da sempre, è orientato allo sviluppo rapido ed elegante secondo il
pattern MVC, a beneficio anche della manutenzione, che diventa più snella. Adrian
Holovaty, uno degli ideatori, è anche un appassionato di musica, in particolare di
gipsy jazz, un genere che è stato reso famoso da un grandissimo chitarrista: Django
Reinhardt (Figura 2.1).
La storia di Reinhardt è avvincente anche per via di un grave incidente che subı̀
a diciotto anni: un incendio distrusse la sua roulotte, rendendo quasi inutilizzabili
le ultime due dita della sua mano sinistra. Trovandosi in una situazione che avrebbe
interrotto la carriera di qualunque altro chitarrista, Django sviluppò, invece, una
tecnica rivoluzionaria che gli permise comunque di suonare divinamente la sua chitarra. Da qui, Adrian Holovaty, ha scelto il nome Django, includendo sia la sua
passione per la musica gipsy, sia la volontà di non mollare mai. Cosı̀ come questo
straordinario musicista riuscı̀ a fare il suo lavoro con il 40% in meno delle dita della
mano sinistra, noi possiamo, grazie a Django, fare il nostro lavoro nel 40% in meno
del tempo.
Nel luglio 2005 Django ottenne la licenza open source; ciò permise la crescita
di una comunità internazionale ancora oggi molto attiva che contribuisce al suo
sviluppo. Fondamentalmente, il framework non è altro che un insieme di complesse librerie scritte in Python. Un sito sviluppato con Django, in definitiva, è un
programma Python che sfrutta tali librerie, applicando meccanismi e convenzioni.
24
2 Django
Per lavorare con Django è necessario conoscere la programmazione strutturata
o object-oriented, ed è bene avere anche una padronanza di tecnologie di sviluppo
web quali HTML e CSS.
Figura 2.1. Il popolare chitarrista jazz Django Reinhardt
2.1.1
Funzionalità
L’orientamento che Django ha nella gestione dei siti di notizie è evidente dal suo
design e dalla sua storia; esso fornisce un certo numero di funzionalità che facilitano
lo sviluppo rapido di applicazioni per la gestione di contenuti web. Un esempio
lampante di questo potrebbe essere rappresentato dal non dover necessariamente
sviluppare in modo autonomo Controller e View per tutto quello che riguarda l’area
di amministrazione di un sito; Django fornisce, infatti, una soluzione integrata che
è inclusa all’interno di un’unica installazione. L’applicazione in questione, oltre a
fornire un’interfaccia grafica per la gestione di utenti, gruppi e permessi, permette
di creare, aggiornare ed eliminare contenuti, tenendo traccia di tutte le operazioni
effettuate.
Django è stato utilizzato e testato per diverso tempo prima di essere distribuito
pubblicamente, perciò propone molte altre funzionalità interessanti, ovvero:
•
•
•
•
•
•
•
astrazione del database relazionale ad oggetti;
possibilità di installare funzionalità attraverso plug-in;
robuste API (Application Programming Interface) per la gestione dei database;
sistema di View generiche che evitano la stesura di codice ripetitivo;
sistema di template basato su tag con ereditarietà;
gestore di URL basati su espressioni regolari;
sistema Middleware per lo sviluppo di funzionalità aggiuntive, ad esempio le
sessioni;
2.1 Caratteristiche generali
•
•
•
•
•
25
supporto per localizzazione, incluse traduzioni dell’interfaccia amministrativa in
molte lingue;
documentazione accessibile dall’interfaccia amministrativa;
sistema di autenticazione;
sistema di gestione degli utenti;
sistema per la creazione e la validazione di form HTML.
Mentre Django è influenzato fortemente dalla filosofia di sviluppo Model-ViewController, i suoi sviluppatori dichiarano pubblicamente che non si sentono in dovere
di seguire un particolare paradigma di sviluppo, preferendo invece semplicemente
“ciò che sembra giusto”. Come risultato, ciò che sarebbe chiamato Controller in
un framework MVC classico è chiamato View in Django, mentre ciò che dovrebbe
essere chiamato View è chiamato Template. Questo dà vita ad un particolare pattern
spin-off chiamato MTV (Model-Template-View Figura 2.2).
Figura 2.2. Attori del pattern MTV
Django supporta in modo completo e multipiattaforma quattro tipi di DBMS:
PostgreSQL, MySQL, SQLite ed Oracle. Microsoft SQL Server può essere usato solo
in ambiente Windows, mentre esiste un nuovo progetto software chiamato DjangoNonRel che supporta DBMS NoSQL, come, per esempio, MongoDB ed il datastore
di Google AppEngine.
2.1.2
L’ORM di Django
Tranne poche eccezioni, quando scriviamo un programma o realizziamo un sito,
dobbiamo occuparci di come e dove salvare i nostri dati. La risposta è semplice:
usiamo un DBMS. Ma subito dopo altre domande sorgono spontanee: che tipo
di DBMS? Come facciamo a scrivere i dati se usiamo le classi? Django cerca di
risolvere questi ed altri problemi con il suo ORM (Object-Relational Mapping), che
viene usato pesantemente nel paradigma di programmazione MTV. In parole povere,
un ORM cerca di costruire un ponte tra due mondi in apparenza inconciliabili: i
database relazionali e la programmazione a oggetti. Attraverso questo ponte gli
oggetti creati con un linguaggio ad alto livello, per esempio Python, vengono salvati
in un DBMS relazionale, per esempio MySQL o Oracle. Effettuando tale percorso nel
26
2 Django
senso inverso, invece, i dati presenti nelle tabelle di un DBMS relazionale diventano
oggetti di un linguaggio di alto livello. L’uso di un ORM, oltre a permettere questa
sorta di trasformazione dei dati, porta con sé altri vantaggi non trascurabili, come
l’astrazione dal DBMS scelto o la possibilità di interrogare i dati usando la sintassi
di un linguaggio di alto livello, piuttosto che quella, certamente meno evoluta, di
SQL (Structured Query Language).
Per capire meglio cos’è un ORM, vediamone un piccolo esempio; immaginiamo
di avere una tabella di un database contenente nome e cognome di alcuni utenti e di
voler estrarre tutti quelli che hanno cognome “Rossi”. Questa sarebbe la richiesta
effettuata con l’ORM di Django:
Utenti.objects.filter(cognome_contains=‘Rossi’)
Il risultato di questa richiesta è una lista di oggetti di tipo Utente; non dobbiamo
preoccuparci di alcuna conversione: abbiamo già a disposizione il tipo di dati di alto
livello che ci interessa quando programmiamo in Python.
La stessa richiesta in SQL nativo sarebbe invece:
SELECT * FROM Utenti WHERE Cognome LIKE ‘%Rossi%’
Ma come riusciremo, adesso, a convertire quello che otteniamo in oggetti da
usare in Python? In ogni caso, l’ORM di Django non risolve soltanto questo tipo
di problemi; si occupa, anche, di tradurre le nostre richieste in SQL corretto per il
DBMS che abbiamo scelto, permettendoci di cambiarlo senza dover fare lunghi e
noiosi adattamenti.
2.1.3
Espressioni regolari
Le RegEx (Regular Expressions), introdotte nel 1950 ma ancora oggi insostituibili, rappresentano oggetti alla base di Django, e quindi del nostro progetto, che ci
aiutano a cercare qualcosa nelle stringhe che usiamo per i nostri programmi ed,
eventualmente, sostituire parti di esse.
Una RegEx può essere, ad esempio, la seguente:
url(r‘^admin/’, include(admin.site.urls))
È proprio utilizzando queste espressioni regolari che Python riesce a far corrispondere URL e View. Esse costituiscono un vero e proprio modello di ricerca, e si
basano su moltissime regole stilistiche, tra cui:
•
•
•
•
•
^, per l’inizio del testo;
$, per la fine del testo;
+, per indicare la ripetizione di un elemento;
( ), per catturare parte del pattern;
/, come carattere di escape.
Questi oggetti cosı̀ antichi ma allo stesso tempo cosı̀ utili e potenti vengono usati
per cercare, individuare e suddividere URL completi o loro parti.
2.2 Perché usare un web framework
2.1.4
27
Diffusione
Negli ultimi anni, tra i framework per lo sviluppo di applicazioni orientate al web,
Django sembra aver fatto breccia nel cuore e nella mente di molti sviluppatori, per
svariate ragioni. Se Python è stato scelto da Google come unico linguaggio per il
suo Google AppEngine e Django resta l’unico framework supportato, un motivo ci
sarà. Qualche volta si trovano pareri discordanti sul processo di sviluppo legato a
questo web framework.
Analizziamo, adesso, i vantaggi che hanno portato Django cosı̀ in alto, e gli
svantaggi che hanno frenato, neanche tanto, la sua popolarità.
•
•
•
•
Installazione: è il primo grande ostacolo che si trova, tutt’altro che semplice, sia
in locale che in remoto.
Documentazione: anche se tutta in lingua inglese, è davvero un’ottima ed ampia
risorsa.
Hosting: trovare uno spazio online che sia Django-ready potrebbe essere proibitivo a causa dei costi.
Performance: Django è eccezionalmente veloce, efficiente ed ottimizzato.
2.2 Perché usare un web framework
Framework, termine in voga e spesso utilizzato a sproposito in informatica, definisce un concetto che, se riportato in ambito quotidiano, potrebbe far pensare ad un
comune tavolo da lavoro, al di sopra del quale troviamo tutti gli attrezzi necessari
per un determinato compito. Non ha uno scopo predefinito, ma fornisce i mezzi per
risolvere problemi in un dato ambito. Nel nostro caso questa definizione è assolutamente azzeccata, perché Django è esattamente questo: un ottimo tavolo da lavoro,
con tanto di strumenti, per costruire siti dinamici e applicazioni web.
Quando si sviluppa qualcosa, si ha sempre bisogno di un insieme di componenti
simili: un sistema per gestire l’autenticazione dell’utente, un pannello di amministrazione, un sistema per caricare i file, e cosı̀ via. Fortunatamente, diverso tempo
fa, un gruppo di colleghi si rese conto che tutti gli sviluppatori incontrano problemi simili di volta in volta, e, proprio partendo da questo, decise di costruire uno
strumento in grado di offrire componenti già pronti per l’uso.
Cosa accade nel momento in cui qualcuno richiede di accedere ad un sito web
scritto in Python e Django? Quando una simile richiesta arriva al server, viene
passata a Django. Esso prova ad interpretarla, considera l’indirizzo della pagina
web e, grazie al cosiddetto URL Resolver, cerca di capire cosa fare. Solo dopo aver
controllato da cima a fondo una serie di schemi e parametri, passa la richiesta alla
View, che farà corrispondere l’URL ad una pagina. Come si può intuire, è all’interno
della View che accadono molte delle cose più interessanti.
2.2.1
Siti ed applicazioni
Django ha una struttura molto ben organizzata: un sito viene memorizzato in una
directory contenente gli script Python di configurazione, ed al suo interno troveremo anche una cartella per ciascuna applicazione del sito stesso. Un website può
28
2 Django
contenere, quindi, più applicazioni, ed ogni applicazione deve far parte di un sito
Django.
La cartella per un nuovo progetto viene creata mediante il comando:
django-admin.py startproject miosito
Le cartelle per le eventuali applicazioni possono essere create lanciando il
comando:
manage.py startapp applicazione1
La struttura appena creata sarà la seguente:
miosito/
__init__.py
settings.py
urls.py
wsgi.py
manage.py
applicazione1
__init__.py
admin.py
models.py
views.py
Tutti i file interni vengono creati in maniera automatica; ciascuno di essi è
importante. I principali file interni sono i seguenti:
•
•
•
•
•
•
•
•
init .py: ci indica che abbiamo a che fare con un package Python;
manage.py: ci permette di interagire con il progetto da riga di comando;
settings.py: contiene i parametri di configurazione;
admin.py: gestisce l’amministrazione del portale;
urls.py: contiene la dichiarazione degli URL gestiti;
wsgi.py: gestisce il protocollo standard per i siti web in Python;
models.py: contiene le definizioni delle classi;
views.py: contiene le definizioni delle View.
2.2.2
L’Admin di Django
Come sarebbe bello disegnare il database e, fatto questo, avere già pronti i form per
inserire tutti i dati via browser. Non disperiamo, con Django questo è possibile!
Se dovessimo scegliere una sola caratteristica che rappresenti il valore di Django,
la sua versatilità e la facilità di sviluppo ad esso legata, orienteremmo di certo la
nostra scelta proprio sulla comodissima interfaccia di amministrazione che si genera
in maniera automatica. Django contiene una serie di applicazioni, già pronte per
l’uso, e una di queste si chiama proprio Admin.
Per usarla è necessario inserire la seguente stringa nel file settings.py:
INSTALLED APPS = (
‘django.contrib.auth’,
‘django.contrib.contenttypes’,
‘django.contrib.sessions’,
‘django.contrib.sites’,
‘django.contrib.admin’,
)
2.2 Perché usare un web framework
29
Sono presenti di default anche le applicazioni Auth e Sites: la prima si occupa
della gestione della sicurezza (utenti, gruppi e permessi), mentre la seconda permette
di differenziare tra loro siti diversi gestiti con una sola installazione.
Dopo aver avviato il nostro web server, vedremo una pagina di login come quella
riportata in Figura 2.3.
Figura 2.3. Amministrazione di Django: pannello di login
Per accedere ad essa, però, sarà necessario creare un superuser, ovvero un utente
speciale che ha il controllo su tutte le aree del sito. La creazione avviene tramite
command-line, digitando:
python manage.py createsuperuser
Effettuando il login con le credenziali che abbiamo appena scelto, avremo di
fronte, finalmente, la struttura della nostra applicazione comprendente gli oggetti
creati, gli attributi, i form da completare e vari button, che ci consentiranno di
modificare, aggiungere o rimuovere qualsiasi elemento. Una delle caratteristiche più
interessanti da evidenziare è legata all’aggiornamento a runtime del server; infatti,
non è necessario interrompere e riavviare il server prima di ogni modifica del codice;
è possibile modificare e salvare il file models.py, aprendolo, per esempio, da una
nuova shell. Django si accorgerà automaticamente dei cambiamenti, ricaricando il
modulo aggiornato.
All’interno del pannello di gestione dell’Admin, come è facile immaginare, è molto naturale coordinare le azioni tra gli elementi; tuttavia se questo dovesse risultare
un po’ più complicato del previsto, è buona norma effettuare, dopo ogni variazione,
un test per verificare che tutto sia andato a buon fine.
30
2 Django
2.3 Configurazione di un portale
Facciamo un passo indietro: prima di installare Django, è consigliabile utilizzare uno
strumento estremamente utile per tenere in ordine il nostro ambiente di sviluppo,
il cosiddetto Virtual Environment. Grazie ad esso riusciremo ad isolare la nostra
configurazione di Python/Django in base ai diversi progetti, in modo che, qualunque
modifica venga effettuata su di un sito, non avrà mai, ed in nessun caso, ripercussioni
su tutti gli altri.
Nella filosofia di Django (Figura 2.4), come già sottolineato, tutte le applicazioni
esistono all’interno di un unico spazio; questo significa che esse ereditano tutte
le impostazioni fondamentali per funzionare al meglio. Quando creiamo un nuovo
progetto, al suo interno vengono generate automaticamente le relative cartelle, che
devono essere modificate in base al nostro obiettivo.
Database
La prima cosa da effettuare consiste nell’impostazione delle coordinate del database,
che è lo stesso per tutto il sito, mentre le tabelle hanno come prefisso il nome
dell’applicazione a cui si riferiscono. Troviamo il blocco di impostazioni relative al
database proprio all’inizio del file di configurazione. Le variabili da configurare sono
le seguenti:
• DATABASE ENGINE: il tipo di database, nel nostro caso SQLite;
• DATABASE NAME: il nome del database contenente i model utilizzati da tutte le
applicazioni gestite dal sito Django;
• DATABASE USER: il nome utente che Django utilizza per accedere al database e
che, per questo, deve avere i privilegi di lettura e scrittura;
• DATABASE PASSWORD: la password, utilizzata per l’autenticazione dell’utente;
• DATABASE HOST: l’indirizzo IP del server, su cui il database server è in ascolto;
• DATABASE PORT: la porta su cui è in ascolto il DBMS (Database Management
System).
Applicazioni
È possibile indicare a Django anche le applicazioni da noi create che esso deve gestire; all’interno del file di configurazione, esattamente come avviene per il database,
troviamo la definizione del parametro INSTALLED APPS, caratterizzato da una tupla
contenente un elemento per ogni applicazione presente.
Ogni elemento è una stringa di questo tipo, avente la notazione di un package
Python:
miosito.applicazione1
Alle applicazioni Django presenti di default dobbiamo aggiungere le nostre applicazioni. Ogni volta che aggiungiamo una nuova applicazione dobbiamo riavviare
Django in modo che esso importi, nel database, i model aggiornati.
2.3 Configurazione di un portale
31
Template
Possiamo configurare Django in modo da utilizzare i template definiti dalla nostra applicazione. Per fare questo cerchiamo, all’interno del file di configurazione
settings.py, la definizione del parametro TEMPLATE DIRS. Tale termine è definito
da una tupla in cui ogni elemento è una stringa contenente il path assoluto di una
cartella che, a sua volta, contiene tutti i template utilizzati da Django.
URL Rewrite
Il file urls.py contiene il mapping tra gli URL e le View: esaminando la configurazione degli URL troviamo la definizione del parametro urlpatterns, al cui interno
esiste una tupla per ogni URL che vogliamo definire. Generalmente, la prima parte
di ogni elemento contiene sempre una RegEx, ovvero un’espressione regolare che
rappresenta un insieme di indirizzi, mentre la seconda contiene la View in notazione Python. L’indicazione dell’indirizzo mediante espressione regolare permette di
riconoscere un insieme di URL con una sola tupla e passare dei valori ai parametri
della View associata.
Figura 2.4. Ciclo Response - Request di Django
32
2 Django
2.3.1
Ereditarietà dei template
Django gestisce il controllo del flusso della costruzione della pagina attraverso i
Tag, in base alle informazioni ricevute dalla View. La sintassi tipica di un tag è la
seguente:
{% tag %} Contenuto {% endtag %}
Alcuni tag generano output, altri sono utilizzati per eseguire cicli e istruzioni
condizionali, ma i più interessanti per la realtà che stiamo esaminando sono block
ed extends; essi definiscono l’ereditarietà tra template, cioè utilizzano una porzione
di codice di un template esistente per estenderne un altro, ridefinendone le sezioni.
Vediamo, adesso, un esempio che mostra i concetti presentati.
Definiamo il template base.html che utilizziamo come contenitore principale,
insieme al file template.html, in cui visualizziamo una particolare View: il secondo
estenderà il primo.
<html>
<head>
<title>{% block title %} Titolo {% endblock %}</title>
</head>
<body>
{% block content %} Contenuto {% endblock %}
</body>
</html>
Osserviamo come si effettua l’override dei blocchi del template base.html:
{% extends ‘‘base.html’’ %}
{% block title %} {{ Titolo }} {% endblock %}
{% block content %}
<h1>{{ Contenuto }}</h1>
{% for item in variabile %}
<h2><a href=‘‘{{ item.get_absolute_url }}’’>{{ item.descrizione }}</a></h2>
{% endfor %}
{% endblock %}
Il tag extends indica il template radice, mentre il tag block definisce un blocco
nel template base, che ha un nome che lo identifica univocamente.
I template devono essere memorizzati in una cartella separata e creata appositamente all’interno del progetto; sarà necessario aggiungere tale directory alla
variabile TEMPLATE DIRS, definita nel file di configurazione.
3
La logica di business
All’interno di questo capitolo analizzeremo il complesso sistema di elaborazione e
presentazione dati legato ad un portale Web, descrivendo, nel dettaglio, la logica di
questa struttura multilivello.
3.1 Il sistema informatico
Il termine sistema informatico o sistema di elaborazione dati indica, genericamente,
un sistema meccanografico, un computer o un insieme di più computer, apparati o
sottosistemi elettronici (server, database, mainframe, supercomputer, switch, router, modem, terminali), tra loro interconnessi in rete, in un’architettura di base
tipica client-server, e preposti ad una o più funzionalità o servizi di elaborazione a
favore degli utenti. Composto da hardware e software con un’architettura che varia
a seconda delle esigenze e della sua progettazione, un sistema informatico, attraverso opportune applicazioni, elabora dati per restituire informazioni utili. Il personal
computer è un esempio di sistema informatico relativamente semplice, la rete Internet è, invece, un esempio di sistema informatico molto più complesso, ampiamente
distribuito.
Un sistema informatico riveste un’importanza strategica all’interno del contesto
in cui si trova; se efficiente, ben progettato e realizzato in prestazioni, affidabilità,
disponibilità e sicurezza, garantisce una migliore gestione delle informazioni con
ricadute positive anche sulla produttività. Una volta realizzato, la gestione del sistema informatico in tutte le sue componenti passa, tipicamente, attraverso un team
di sistemisti o amministratori, mentre agli utenti rimane assegnato l’insieme delle
funzionalità offerte.
Il termine sistema, in informatica, prende significato solo in presenza di interconnessioni fra diversi computer, che, insieme, formano un sistema informatico più
grande (Figura 3.1). Interconnettere computer può essere difficile a causa di incompatibilità presenti sia nell’hardware che nel software installato. A causa di questa
complessità, della conseguente non linearità dei fenomeni coinvolti e dell’interazione che alcuni sistemi necessariamente hanno con input provenienti da decisioni
umane, non risulta ancora formalizzata una teoria informatica intesa come formalizzazione matematica ISU (Ingresso-Stato-Uscita) delle relazioni causa-effetto tra
34
3 La logica di business
gli input e gli output elaborati. Risultano, invece, standardizzati i procedimenti
di realizzazione di singoli sistemi isolati, attraverso metodologie consolidate, come,
ad esempio, il Modello E-R (Entità-Relazione) o il Linguaggio di Modellizzazione
Unificato (UML).
Figura 3.1. Un generico sistema informatico
In generale, un sistema di elaborazione dati deve soddisfare i seguenti requisiti:
•
•
•
•
disponibilità;
affidabilità;
sicurezza;
scalabilità.
3.1.1
Funzionalità
In un sistema informatico, tipicamente, si distinguono i seguenti tre strati logici di
funzionalità, in comunicazione tra loro:
Front-end
Il livello di presentazione ha il compito di offrire i dati all’utente ed inviare le
richieste di questi verso la parte elaborativa del sistema, facendo da interfaccia
uomo-macchina. La sua funzione è molto simile al classico HTML; predisporre la
corretta visualizzazione delle pagine web, in base a ciò che è espresso nel livello
3.2 Livello logico di business
35
funzionale, ovvero quello che elabora i contenuti dinamici da presentare all’utente
finale. La progettazione di questo livello deve essere fatta su misura rispetto alle
funzioni che dovranno essere implementate dal sistema. Il fatto di essere indipendente dal resto consente una sua progettazione che tenga conto di elementi propri
di questo contesto, che sono di natura prettamente grafica. Sarà, altresı̀, semplice
modificare il design, in quanto tale modifica non influenzerà il funzionamento della
logica applicativa sottostante, né tantomeno quella di persistenza.
Business logic layer
Il livello di business è quello che realmente determina la potenzialità del sistema; in
esso è predisposta la logica applicativa affinché determinate funzioni vengano portate a compimento. Il suo utilizzo avviene dal livello di presentazione, al quale deve
restituire delle informazioni consone alla particolare funzione richiesta. In alcuni
casi, la logica applicativa funziona da sé, più spesso ha necessità di utilizzare dei
dati presenti in un database recuperandoli dal livello sottostante, ovvero quello di
persistenza. La progettazione di questo livello è quella, probabilmente, più importante, nel senso che essa rappresenta in maniera definitiva le funzioni del sistema
web, e quindi il loro utilizzo da parte dell’utente finale. La modifica di questo livello non determina cambiamenti nei livelli adiacenti. Importante sarà aderire alle
funzioni che sono state previste e quindi prevedere il ritorno di valori che il livello
di presentazione si aspetta.
Back-end
La logica di accesso dati gestisce le modalità con le quali si interroga il database
e rappresenta in maniera definitiva il modo in cui i dati vengono memorizzati su
un supporto fisico persistente. Non importa se la memorizzazione avviene su un
database, sul file system o seguendo altre logiche, l’importante sarà predisporre
delle funzioni standard utilizzabili dal livello di business. Si tratterà di operazioni
di lettura o scrittura precedute da una forma di autenticazione.
Questo modello, per poter funzionare, deve essere in grado di legare tali livelli
in un’unica applicazione, che riesca, in qualche modo, a far comunicare la presentazione con le funzioni di business, e queste ultime con il livello di persistenza. I
classici server che avevano lo scopo di fornire ai client una serie di pagine web su
loro richiesta si trasformano, ora, in web server, applicazioni predisposte a ricevere
richieste dinamiche, a elaborarne il contenuto e a presentarlo all’utente finale.
3.2 Livello logico di business
Con l’espressione logica di business (Figura 3.2) ci si riferisce all’algoritmica che
gestisce lo scambio di informazioni tra una sorgente dati, generalmente un DBMS, e
l’interfaccia utente, attraverso la logica di presentazione e le elaborazioni intermedie
sui dati estratti. Con tale nome ci si riferisce, quindi, a tutto quel settore applicativo
che rende funzionante un’applicazione, cioè a quello che potrebbe essere, altresı̀,
definito core di elaborazione.
36
3 La logica di business
Figura 3.2. Progettazione della logica di business
In questo contesto, largamente utilizzate sono le cosiddette regole di business,
elementi che dettano i principi secondo i quali le informazioni devono essere visualizzate dagli utenti o memorizzate all’interno del DBMS. Nell’ambito delle applicazioni
web, la business logic viene spesso associata ad architetture software di tipo threetier e viene tipicamente ospitata ed eseguita da un’Application Server su richiesta
del client attraverso il proprio web browser.
Il Livello Logico di Business è uno dei livelli della cosiddetta Multi-tier Architecture (Architettura Multilivello), che si occupa di separare la logica di business
dagli altri moduli, come, ad esempio, il livello di accesso dati (Data Access Layer)
e l’interfaccia utente (Presentation Layer). Al suo interno si possono ulteriormente
partizionare i processi nelle cosiddette entità di business; questi oggetti implementano la sezione Controller del pattern MVC, che non contiene dati, ma metodi che
gestiscono le interazioni tra oggetti.
3.2.1
Usare gli oggetti di business
Un oggetto di business può essere definito come un generico componente che racchiude in sé la logica di funzionamento di una parte di applicazione. Ma perché realizzare
un componente per accedere ai dati quando lo si può fare utilizzando controlli già
pronti? La risposta a questa domanda va ricercata immaginandoci in situazioni e
contesti particolari, in cui la logica di funzionamento di cui abbiamo bisogno non
può essere di tipo standard, ma rielaborata attraverso componenti appositamente
creati per l’occasione. All’interno di questo tipo di approccio, la cosa più importante
che occorre mettere in evidenza è la possibilità di realizzare un’applicazione a più
strati.
Quando si ha a che fare con sistemi di grosse dimensioni, al cui sviluppo partecipano molte figure professionali, è opportuno separare la logica di funzionamento
dall’interfaccia utente. Già in fase di progettazione ci si muove verso il concepimento
3.2 Livello logico di business
37
di un’architettura multi-strato, in cui, una modifica su un componente posizionato ad un certo livello, abbia il minor impatto possibile sui componenti posizionati
all’interno degli altri livelli.
Una delle funzionalità implementate più interessanti da evidenziare, legata ad un
componente che può essere definito business, è, senza dubbio, la verifica dell’indirizzo e-mail. Ogni qualvolta un nuovo utente effettua la registrazione, per prima cosa
viene controllato il form, che deve essere compilato in maniera corretta; se questo
passaggio è verificato, viene mandata una e-mail in maniera totalmente automatica
(Listato 3.1) attraverso i server Gmail verso l’indirizzo inserito dal nuovo iscritto, il
quale dovrà, successivamente, visitare un URL affinché il suo profilo venga attivato
in maniera definitiva (Figura 3.3).
Figura 3.3. Amministrazione di Django: pannello dei permessi
All’interno dell’app Registrazione è stato inserito il seguente codice:
from
from
from
from
django.shortcuts import render
django.contrib.auth.models import User
django.core.mail import send_mail
django.conf import settings
def registrazione (request):
return render (request, ’registrazione.html’, {})
def registrati (request):
nome = request.POST [’nome’]
cognome = request.POST [’cognome’]
username = request.POST [’username’]
email = request.POST [’email’]
password = request.POST [’password’]
try:
user = User.objects.create_user (first_name= nome, last_name=cognome, username=username,
email=email, password=password)
except:
return render (request, ’login_error.html’)
if user is not None:
user.is_active = False
user.save ()
subject = ’Make a Match! E-mail Validation’
message = ’Complimenti! Sei registrato! Clicca sul link per attivare e poter utilizzare il tuo profilo’
from_email = settings.EMAIL_HOST_USER
to_list = [email]
send_mail (subject, message, from_email, to_list, fail_silently=False,)
return render (request, ’sei_registrato.html’)
else:
return render (request, ’login_error.html’)
Listato 3.1. Implementazione della verifica di una e-mail tramite Django
38
3 La logica di business
Per completezza riportiamo anche le coordinate che sono state inserite all’interno
del file di configurazione setting.py, come di seguito specificato:
EMAIL_USE_TLS = True
EMAIL_HOST = ’smtp.gmail.com’
EMAIL_HOST_USER = ’[email protected]’
EMAIL_HOST_PASSWORD = ******
EMAIL_PORT = 587
import os
3.3 Progettazione multilivello
Della progettazione multilivello si discute non soltanto all’interno di contesti legati
al web, ma anche in situazioni che si avvicinano maggiormente alle applicazioni
tradizionali.
Le applicazioni costruite con un approccio basato su un solo livello hanno molti limiti e rendono il lavoro complicato, soprattutto nel momento in cui potrebbe
essere necessario apportare delle modifiche; il codice che dovrebbe occuparsi della
presentazione è correlato al codice che rappresenta le funzioni del sistema (logica
di business) e a quello che rappresenta le funzioni di persistenza dei dati (logica di
persistenza). Emerge forte e chiara, quindi, l’esigenza di dividere logiche concettualmente diverse tra loro, soprattutto in ambito web, che, grazie al suo dinamismo,
sente ancor più questa necessità, in quanto è prassi comune cambiare il look dei siti
web e implementare nuove funzioni.
Sfruttare la progettazione dei sistemi su più livelli concettualmente diversi tra
loro rende il lavoro molto meno difficile e l’implementazione molto celere e meno
soggetta ad errori. La modifica di un livello non influenzerà assolutamente i livelli
intermedi, con un evidente vantaggio rispetto alle applicazioni su un solo livello
logico. L’astrazione a tre livelli è quella più comunemente adottata poiché scinde
nei tre livelli più direttamente demarcabili la progettazione e l’implementazione del
sistema.
3.3.1
Architetture
Rispetto ad un sistema centralizzato, un sistema che si sviluppa su più strati possiede una maggiore complessità di gestione, ma può vantare una maggiore scalabilità,
ovvero la possibilità di estendersi in funzione dell’aumento di terminali, server e
database nei vari strati. Un aspetto rilevante è legato all’alta affidabilità e sicurezza
dovute al fatto che, come già sottolineato, il guasto o la violazione su una macchina
non inficia il funzionamento del restante sistema.
In generale, ciascuno strato logico può essere implementato attraverso architetture fisiche cosiddette a N-tier, centralizzate o distribuite. Tali architetture possono
essere cosı̀ suddivise:
• Architettura 1-tier : le tre funzionalità logiche sono ospitate su una macchina
come sistema centralizzato di tipo mainframe.
3.4 Application Server
•
•
•
39
Architettura 2-tier : le tre funzionalità logiche sono ospitate sue due macchine diverse, quella di presentazione lato utente e le altre due all’interno di un
Application Server.
Architettura 3-tier : le tre funzionalità logiche sono implementate ciascuna su
una macchina o sistema di macchine indipendenti. Una tipica soluzione threetier prevede, per esempio, un PC dedicato all’interfaccia utente grafica, una
workstation per la business logic e un DBMS per la gestione dei dati. Questo
schema generale è piuttosto diffuso e costituisce un’architettura di riferimento
per molte tecnologie moderne. Lo schema three-tier può essere definito un design
pattern, e presenta diverse analogie con il pattern Model View Controller (Figura
3.4), svolgendo un ruolo importante nella progettazione di applicazioni web.
Architettura N-tier : le tre funzionalità logiche sono implementate su più di tre
livelli con architetture molto più distribuite.
Figura 3.4. Affinità tra il pattern MVC ed il design pattern a schema three-tier
3.4 Application Server
Un Application Server (a volte abbreviato con la sigla AS) è una tipologia di server
che fornisce l’infrastruttura e le funzionalità di supporto, sviluppo ed esecuzione
di applicazioni in un contesto distribuito come il nostro. Si tratta di un complesso
di servizi orientati alla realizzazione di applicazioni ad architettura multilivello ed
enterprise, con alto grado di complessità, spesso orientate per il web.
40
3 La logica di business
In altre parole, su un Application Server gira la cosiddetta logica di business in
un’architettura hardware/software di tipo multi-tier; perciò, può essere definito un
middleware, un vero e proprio intermediario tra le diverse applicazioni e componenti
software.
L’application server è composto da moduli realizzati secondo standard ben definiti ed accettati dalla comunità mondiale; un esempio di questi standard è il
protocollo HTTP, normalmente utilizzato per la trasmissione di informazioni sul
web.
Le più importanti componenti normalmente presenti all’interno di un Application Server sono:
• il modulo web, che espone al browser la logica di presentazione delle informazioni
in diretta e stretta interazione con la sottostante logica di business;
• il gestore degli accessi per la sicurezza, che filtra gli utenti basandosi sul loro
grado di permessi;
• il caching, pronto a massimizzare le prestazioni complessive.
Le più famose tecnologie su cui possono basarsi gli application server sono .NET
di Microsoft e Java di Oracle (Figura 3.5); tuttavia, mentre nel secondo caso gli standard Java non sono unicamente frutto della Sun Microsystem, ma sono il risultato
di un rapporto sinergico tra l’azienda americana e la partecipazione libera di sviluppatori in tutto il mondo, la tecnologia .NET è, invece, completamente dipendente
dall’azienda di Bill Gates.
Figura 3.5. Esempio di Application Server in Java
3.4.1
Vantaggi
L’adozione di Application Server offre i seguenti particolari benefici:
3.4 Application Server
•
•
•
•
•
•
•
•
41
Semplificazione delle attività di sviluppo: gli AS creano un ambiente nel quale si
possono utilizzare gli strumenti di sviluppo più diffusi sul mercato, consentendo
di ridurre i tempi, nonchè produrre e distribuire rapidamente le applicazioni.
Supporto di vari linguaggi : a seconda dell’AS utilizzato, le applicazioni possono
essere scritte nel linguaggio preferito dal programmatore.
Riusabilità del codice: è spesso utilizzata la programmazione orientata agli oggetti, grazie alla quale, una volta sviluppata la logica applicativa, quest’ultima
può essere condivisa e riutilizzata.
Alte prestazioni : le caratteristiche architetturali degli AS permettono di erogare
elevati standard, quali il multithreading, il bilanciamento dinamico dei carichi
di lavoro, il caching e il pooling degli oggetti e delle connessioni ai database.
Estendibilità: l’architettura modulare, combinata al supporto dei moduli che
possono essere caricati, consente di estendere facilmente le funzionalità dei
sistemi.
Robustezza: la logica applicativa può essere riconfigurata o rimossa senza interruzioni nell’erogazione dei servizi agli utenti. Queste caratteristiche sono
particolarmente importanti per garantire l’alta disponibilità del sistema.
Gestione delle transazioni : la gestione delle operazioni basate su transazioni
è facilitata, assicurando l’integrità e l’affidabilità dei back-end multipli per le
risorse e i dati.
Sicurezza: gli AS offrono funzioni specifiche di sicurezza end-to-end, necessarie
per l’esecuzione delle applicazioni che richiedono particolari misure di sicurezza
e riservatezza dei dati. Per le comunicazioni tra client e server vengono impiegati
algoritmi standard e ampiamente testati e collaudati sul web, come quelli offerti
dal protocollo SSL.
4
Analisi dei requisiti
Questo capitolo descrive tutte le fasi ed i risultati riguardanti l’analisi dei requisiti
relativi alla realizzazione di un portale per la gestione di un centro sportivo. Saranno
trattate, nel dettaglio, le operazioni che il sistema dovrà svolgere interfacciandosi
con l’utente finale.
4.1 Descrizione del progetto
La realtà che all’interno di questo elaborato si vuole informatizzare ha come obiettivo la creazione di un sistema per la gestione di un centro sportivo. La creazione di
un portale web completo, combinata all’utilizzo di Python e Django, risulta tra gli
strumenti ideali per riuscire nel nostro intento. Lo spunto nasce dall’esperienza; lo
scopo è quello di eliminare qualsivoglia tipologia di difficoltà, lentezza ed aumentare in maniera esponenziale l’efficienza attuale, basata sull’utilizzo di carta e penna,
utilizzate nella grande maggioranza dei casi. Normalmente, l’utente che vuole effettuare una prenotazione, dopo aver scelto il campo da gioco e l’orario di preferenza,
deve verificarne telefonicamente la disponibilità. Come si può intuire, questo modo
di procedere comporta un non immediato riscontro, dal momento che l’impianto
potrebbe risultare già occupato, o il gestore potrebbe non rispondere tempestivamente, come spesso accade. Ciò porterà ad un’ulteriore ricerca e, quindi, un ulteriore
dispendio di tempo. Con questo nuovo sistema, invece, il processo appena descritto sarà facilitato e velocizzato, essendo basato su un servizio online all’interno del
quale sia il gestore (staff ) sia l’utente avranno la possibilità di registrarsi.
Il gestore, effettuata la registrazione, avrà la possibilità di curare la propria pagina inserendo le varie informazioni relative all’impianto, quali contatti, costi, orari,
posizione e indicazioni stradali per raggiungere il campo. Sarà, inoltre, previsto uno
spazio non pubblico dedicato all’inserimento di dati su entrate/uscite, sponsor ed
eventuali costi di manutenzione.
L’utente, per poter usufruire dei servizi erogati dal gestore, dovrà registrarsi al
sistema inserendo i propri dati anagrafici; potrà, in questo modo, effettuare varie
ricerche sui campi che più corrispondono alle proprie esigenze, in base ad orari,
costi, numero di giocatori e posizione geografica. Si avrà, inoltre, la possibilità di
44
4 Analisi dei requisiti
inserire, nella sezione preferiti, i campi scelti con maggiore frequenza e di invitare
un amico ad iscriversi al portale attraverso l’inserimento di un indirizzo e-mail.
Dopo aver effettuato la sua prenotazione, l’utente è tenuto a versare una caparra
minima come garanzia al proprietario dell’impianto, in modo da prevenire prenotazioni fasulle. Il gestore, invece, dovrà essere in grado di accettare o rifiutare la
prenotazione nel minor tempo possibile.
4.2 Requisiti funzionali e non funzionali
In questa sezione si analizzeranno i requisiti funzionali e non funzionali relativi all’applicazione web per la gestione di un centro sportivo. Possiamo definire i requisiti
funzionali come l’insieme delle caratteristiche che il portale dovrà implementare ed
i requisiti non funzionali come l’insieme dei vincoli realizzativi di tipo tecnico che
il sistema dovrà necessariamente rispettare.
Requisiti funzionali
Il portale in esame dovrà garantite le seguenti funzionalità principali:
•
•
•
•
•
•
•
•
gestione dell’autenticazione dell’utente o del gestore, con relative credenziali;
ricerca, da parte dell’utente, del campo più adatto secondo le proprie esigenze;
caricamento, da parte del gestore, di più campi relativi alla stessa struttura;
prenotazione o disdetta, nei tempi indicati, di un campo;
notifica dell’avvenuta richiesta di prenotazione;
annullamento automatico delle prenotazioni contemporanee;
creazione, da parte del gestore, di tornei all’interno della propria struttura;
creazione, da parte dell’utente, di una squadra.
Basandosi su queste funzionalità, sarà necessario permettere la modifica e l’eventuale rimozione della propria area riservata o di porzioni di dati contenuti in
essa, la modifica o la rimozione di prenotazioni, tornei e squadre (attività CUD);
mentre, per effettuare l’accesso, tutte le figure dovranno essere in possesso delle
credenziali formate dalla combinazione di username e password.
L’amministratore, con pieni privilegi di superuser, sarà l’unico ad avere la
possibilità di effettuare questo tipo di attività su ogni elemento presente nel portale.
Requisiti non funzionali
Per quanto riguarda i requisiti non funzionali, il portale dovrà essere sviluppato con
un design di tipo responsive (Figura 4.1), in maniera tale che le pagine visualizzate
si adattino a runtime alle dimensioni dello schermo o della finestra all’interno della
quale sono visualizzate.
Il portale dovrà avere la massima compatibilità con il maggior numero possibile
di browser, utilizzare le API dei servizi Google Maps e Mail, in modo tale da visualizzare l’esatto luogo in cui si trovano le strutture precaricate dai gestori, ed essere
in grado di inviare e-mail in maniera autonoma.
4.3 Casi d’uso
45
Figura 4.1. Esempio di layout responsive
Gli indirizzi di posta elettronica e gli username associati agli utenti dovranno essere unici all’interno del database, mentre le password dovranno avere una
lunghezza compresa tra 8 e 20 caratteri.
Per quanto riguarda gli aspetti tecnologici, invece, si userà Bootstrap per gestire
il layout, la grafica e tutto quello che riguarda il design del sito, mentre il linguaggio
scelto per realizzare le pagine è Python, combinato con la potenza, l’efficacia e la
versatilità di un Web Framework come Django. Il DBMS scelto, per ragioni di costi
e compatibilità, è SQLite.
4.3 Casi d’uso
La fase di analisi dei requisiti che un portale come quello in esame deve possedere
si porta a termine con la creazione dei casi d’uso. Essi rappresentano una sequenza
di azioni che il sistema si può ritrovare ad eseguire grazie all’interazione con attori
esterni. I casi d’uso emulano il comportamento del sistema quando un attore invia
ad esso un particolare input.
Le attività che vengono descritte hanno lo scopo principale di derivare diagrammi dettagliati del sistema in fase di sviluppo. La progettazione di un caso d’uso
stabilisce precisamente come la collaborazione tra classi permette di raggiungere gli
obiettivi posti alla base del sistema.
Attori
Un attore identifica il ruolo che un’entità esterna assume quando interagisce direttamente con il sistema; in generale, un attore può rappresentare un utente, un altro
sistema o un’entità astratta.
Gli attori che interagiranno con il nostro portale Web saranno i seguenti:
•
Utente registrato: utente con username e password che può accedere alle funzionalità implementate;
46
4 Analisi dei requisiti
• Utente non registrato: utente che non può accedere alle funzionalità implementate, ma solo a poche ed eventuali pagine statiche;
• Amministratore: utente con permessi superiori a tutti gli altri utenti all’interno
del sistema;
• Tempo: attore che interviene nel sistema per attività programmate, in modo
sincrono.
4.3.1
Diagramma dei casi d’uso
Il diagramma dei casi d’uso è un diagramma dedicato alla descrizione delle funzioni o
dei servizi offerti da un sistema. Dopo aver individuato gli attori principali, nel caso
della realtà presa in esame, è necessario che l’amministratore o l’utente registrato
interagiscano con il sistema per attivare uno dei casi d’uso esaminati.
Per quanto riguarda, invece, le funzionalità sopra descritte, si ottengono i
diagrammi dei casi d’uso riportati nelle Figure 4.2, 4.3 e 4.4:
Figura 4.2. I casi d’uso relativi al sistema (prima parte)
4.3.2
Dettaglio dei casi d’uso
All’interno di questa fase di analisi appare necessario fornire una breve descrizione,
in linguaggio naturale, dei seguenti e più importanti casi d’uso considerati:
• Login: permette all’utente registrato di accedere alla propria area riservata per
utilizzare funzionalità altrimenti inaccessibili.
• InvitaAmici : permette all’utente registrato di inserire un indirizzo e-mail ed
invitare un amico.
• GestisciManutenzione: permette all’amministratore di verificare le tempistiche
di manutenzione delle strutture.
4.3 Casi d’uso
47
Figura 4.3. I casi d’uso relativi al sistema (seconda parte)
•
•
•
•
•
•
•
•
GestisciBackup: permette all’amministratore di effettuare il backup dei dati in
casi di malfunzionamento.
InserisciPrenotazione: permette all’utente registrato di inserire una prenotazione ed inviarla al gestore della struttura.
ModificaPrenotazione: permette all’amministratore registrato di modificare una
prenotazione inserita.
AnnullaPrenotazione: permette all’amministratore di eliminare una prenotazione inserita dall’utente.
InserisciTorneo: permette all’amministratore di creare un nuovo torneo presso i
propri impianti.
InserisciCampo: permette all’amministratore di inserire un nuovo campo.
InserisciSquadra: permette all’utente registrato di creare un team.
RifiutaPrenotazione: permette all’amministratore di annullare una prenotazione
in sospeso.
48
4 Analisi dei requisiti
Figura 4.4. I casi d’uso relativi al sistema (terza parte)
5
Progettazione della logica di business
All’interno di questo capitolo faremo un focus sulla componente dati relativa ad un
portale adibito alla gestione di un centro sportivo. Analizzeremo, nel dettaglio, la
mappa gerarchica del sito, i mockup e le tre fasi di progettazione svolte: concettuale,
logica e fisica.
5.1 Mappa del sito
La cosiddetta Mappa di un sito web altro non è che lo strumento grazie al quale la
struttura del nostro portale diviene semplice ed evidente, già a cominciare dal primo
impatto visivo; essa ha come scopo ultimo la rappresentazione e l’organizzazione dei
contenuti in maniera quanto più intuitiva possibile.
Esistono varie tipologie differenti di mappe, tuttavia, quella maggiormente utilizzata e che abbiamo deciso di scegliere, è definita gerarchica. La mappa relativa al
nostro sistema è rappresentata dalla seguente Figura 5.1.
Figura 5.1. Mappa gerarchica del sito
Trattandosi di progettazione di programmi, questa fase di informatizzazione di
un sistema non può non tenere in forte considerazione le metodologie e gli strumenti tipici dell’Ingegneria del Software. Utilizziamo come meta-modello UML poichè
supporta in modo estremamente preciso e rigoroso sia la progettazione orientata
50
5 Progettazione della logica di business
agli oggetti che la progettazione basata sui componenti, che rappresentano le tecniche di programmazione di gran lunga più utilizzate attualmente nel contesto della
produzione del software.
5.2 Progettazione dei mockup
Il secondo strumento che utilizziamo per la progettazione della logica di business è
quello dei mockup. Con questo termine si intende, comunemente, la riproduzione di
un oggetto originale ad uso didattico, dimostrativo, scenografico o di comunicazione
visiva. In genere, si realizza un mockup quando è necessario disporre di una copia
verosimile dell’oggetto, che attragga l’attenzione e che sia in grado di rappresentare
un progetto completo, oppure una sua parte.
In ambito informatico, il significato di tale termine non si discosta molto; infatti,
un mockup è la rappresentazione grafica, pulita e stilizzata, delle interfacce di un
sistema informativo. Solitamente, questo tipo di modello visivo viene sottoposto al
cliente, prima di passare alla realizzazione del template vero e proprio, per riuscire a
far capire la strategia di comunicazione della realtà e per mostrargli la disposizione
ed il layout dei principali elementi.
Nel caso della gestione del centro sportivo, sono stati creati quattro mockup
relativi alle operazioni più utilizzate, che analizzeremo di seguito.
Registrazione
Il portale realizzato non include, in alcun modo, la possibilità di essere utilizzato
nelle sue funzioni logiche, se non passando attraverso la propria area riservata;
di conseguenza sarà necessario registrarsi (Figure 5.2 e 5.3) per poter utilizzare
qualsivoglia funzionalità.
Prenotazione
La principale funzionalità della realtà che si sta informatizzando è, chiaramente, la
possibilità di effettuare la ricerca di una struttura ed, una volta trovata, di prenotarla (Figure 5.4 e 5.5). Sarà possibile conoscere l’esatta ubicazione di quest’ultima
grazie al pannello delle mappe di Google.
Home Page e Login
Nelle Figure 5.6 e 5.7 viene illustrata la home page del nuovo portale; come si può
dedurre, essa prevede quattro sezioni principali ben separate l’una dall’altra, ed
include la possibilità di effettuare velocemente il login (Figura 5.8). Quest’ultimo
è disponibile solo ed unicamente se l’utente ha precedentemente provveduto alla
registrazione; cosı̀ facendo, egli potrà accedere alla propria area riservata e utilizzare
una serie di funzionalità altrimenti inaccessibili.
Sono presenti ulteriori URL che rimandano ad altri contenuti del sito web.
L’impatto visivo che questo strumento desta, è evidente; rimane un primo approccio ideale con chiunque desideri vedere stilizzata la struttura del proprio sito o
della propria app.
5.3 Progettazione della componente dati
51
Figura 5.2. Mockup di livello zero relativo alla registrazione
5.3 Progettazione della componente dati
La progettazione della componente dati si occupa dell’organizzazione di tutte le
entità che compongono la realtà considerata.
Questa parte del processo di informatizzazione si suddivide in tre fasi, che
saranno esaminate di seguito.
5.3.1
Progettazione concettuale
La prima fase è definita progettazione concettuale; essa rappresenta le specifiche
informali, ovvero indipendenti dai criteri di rappresentazione utilizzati nei sistemi
di gestione delle basi di dati. Sarà questa la fase in cui rappresenteremo il contenuto
informativo del DBMS, senza preoccuparci nè dell’efficienza nè delle modalità di
implementazione.
Nella progettazione concettuale è opportuno seguire le linee guida di seguito
specificate:
•
•
•
•
•
•
scegliere il corretto livello di astrazione;
standardizzare la struttura delle frasi;
unificare i termini evitando i sinonimi;
rendere esplicito il contesto di riferimento;
evitare frasi contorte;
costruire un glossario dei termini.
52
5 Progettazione della logica di business
Figura 5.3. Mockup di livello due relativo alla registrazione
Le principali informazioni per l’acquisizione delle specifiche riguardo la fase concettuale possono essere ricavate sia da eventuali precedenti versioni del sistema, sia
attraverso interviste, questionari e workshop con gli utenti finali, da affrontare con
l’utilizzo di un linguaggio naturale e poco tecnico.
Un primo strumento da utilizzare è il diagramma Entità/Relazione, grazie al
quale riusciremo ad esprimere la realtà analizzata tenendo conto della maggior parte
dei fattori possibili.
Il diagramma Entità-Relazione
Attraverso questo strumento, il cui output è riportato in Figura 5.9, è possibile
esprimere la nostra realtà di interesse mediante un insieme di concetti e relazioni
fra concetti.
I Dizionari
I concetti rappresentati all’interno di uno schema E/R possono essere descritti in
maniera ancor più approfondita facendo uso del cosiddetto Dizionario dei Dati ;
esso si divide, tipicamente, in Dizionario delle Entità (Figura 5.10) e Dizionario
delle Relazioni (Figura 5.11).
Per completare la fase di progettazione concettuale però, non basterà considerare
Entità e Relazioni; sarà necessario determinare anche quali saranno i Vincoli di
Integrità fondamentali (Figura 5.12) che dovranno essere soddisfatti.
5.3 Progettazione della componente dati
53
Figura 5.4. Mockup di livello zero relativo alla prenotazione
Glossario dei termini
Al fine di evitare ambiguità è opportuno definire un glossario al quale fare riferimento per i termini maggiormente utilizzati nella progettazione.
•
•
•
•
•
Prenotare: selezionare un campo per un determinato intervallo di tempo in modo
da garantirsi la pratica dello sport in maniera esclusiva.
Campo: Luogo fisico in cui si disputano gli incontri; utilizzato, a volte, come
sinonimo di impianto.
Manutenzione: prendersi cura delle strutture sportive controllandone le condizioni e segnalando eventuali danni.
Entrate/Uscite: rendiconto dei guadagni e delle spese relative alla manutenzione
e all’utilizzo delle strutture proprietarie.
Caparra: quota di denaro versata al gestore per evitare prenotazioni fasulle
all’interno del portale.
5.3.2
Progettazione logica
La seconda fase relativa alla creazione della componente dati è la progettazione logica, che si pone come obiettivo la definizione di uno schema capace di rappresentare
in modo fedele ed efficiente le informazioni contenute nel modello concettuale.
54
5 Progettazione della logica di business
Figura 5.5. Mockup di livello due relativo alla prenotazione
La ristrutturazione dello schema E/R
Innanzitutto, è necessario considerare l’idea di una ristrutturazione che riguardi il
nostro schema E/R, per evitare del tutto generalizzazioni o attributi multivalore.
In generale, la fase di ristrutturazione prevede una serie di passi da eseguire:
•
•
•
•
•
analisi delle ridondanze;
eliminazione delle generalizzazioni;
accorpamento di entità e associazioni;
eliminazione degli attributi composti o multivalore;
scelta degli identificatori primari.
Nel nostro caso, tale operazione appare non necessaria; di conseguenza, possiamo
procedere direttamente verso la traduzione dello schema concettuale ristrutturato
in uno schema logico.
Lo schema relazionale
Procedendo alla traduzione dello schema E/R di Figura 5.9 ed applicando le regole
standard, si ottiene il seguente schema relazionale:
• GESTORE (CodiceFiscaleG, Nome, Cognome, Cellulare, E-mail, DataDiNascita)
• CAMPO (CodiceC, Indirizzo, Tipo, CodiceFiscaleG)
• DITTA (NomeD, CostoManutenzione)
5.3 Progettazione della componente dati
55
Figura 5.6. Mockup di livello zero relativo alla home page
•
•
•
•
•
•
•
•
•
FA MANUTENZIONE (CodiceC, NomeD)
SPONSOR (NomeS, Donazione)
TORNEO (CodiceT, Nome, Campo, NumMaxSqu, CodiceFiscaleG)
PUBBLICIZZA (CodiceFiscaleG, NomeS)
PRENOTA (CodiceFiscaleU, CodiceC, Data, illuminazione, FasciaOraria)
UTENTE (CodiceFiscaleU, Nome, Cognome, Cellulare, E-mail, DataDiNascita)
SQUADRA (NomeSqu, NumGioc)
CREA (CodiceFiscaleU, NomeSqu)
PARTECIPA (CodiceT, NomeSqu)
5.3.3
Progettazione fisica
L’ultima fase della progettazione della componente dati di un sistema consiste nella
progettazione fisica. Prima di cominciare con questa attività, occorre scegliere un
opportuno DBMS che implementi il modello dei dati dello schema logico. Questa
fase comprende tutti quegli strumenti che avvicinano il programmatore al modo di
pensare dell’utente finale.
La progettazione fisica consta delle seguenti tre attività:
•
•
Selezione delle strutture di memorizzazione delle tabelle e delle strutture ausiliarie di accesso ai dati (indici); queste ultime servono per rendere più efficiente
l’accesso alle tabelle usate di frequente. Le strutture di memorizzazione e di
accesso devono essere scelte tra quelle messe a disposizione dal DBMS scelto.
Traduzione dello schema logico in uno schema fisico, contenente le definizioni
delle tabelle, dei relativi vincoli di integrità e delle viste espresse in SQL.
56
5 Progettazione della logica di business
Figura 5.7. Mockup di livello zero relativo al login
• Implementazione delle transazioni in SQL.
Terminato ciò, la base di dati è stata completamente progettata e si passa alla
sua realizzazione, cioè alla immissione effettiva delle tabelle e dei corrispettivi dati
nel DBMS prescelto.
Scelta degli indici
Un indice è una struttura realizzata per migliorare i tempi di ricerca dei dati. Se una
tabella non ha indici, ogni ricerca obbliga il sistema a leggere tutti i dati presenti in
essa; l’indice consente, invece, di ridurre l’insieme dei dati da leggere per completare
la ricerca in un intervallo minore di tempo.
Generalmente un indice non è strettamente necessario; esso, tuttavia, ha un
impatto significativo sulle performance di sistema, che possono essere migliorate
anche fino all’80% su operazioni di lettura (Read ). Gli indici, hanno, però, anche
degli effetti negativi; essi, infatti, rendono lente le operazioni di inserimento (Create)
e di modifica (Update), poichè aumentano l’uso della memoria di massa.
Gli indici che vengono definiti primari non solo garantiscono l’accesso in base
alla chiave, ma facilitano il raggiungimento delle locazioni fisiche, poichè contengono
direttamente i dati. Gli indici che, invece, sono definiti secondari hanno lo scopo di
favorire gli accessi ai dati senza contenere i dati stessi; essi vengono, generalmente,
definiti su attributi che possono avere valori ripetuti.
Per il database sul quale sono memorizzati i dati del portale relativo alla gestione
del centro sportivo, oltre agli indici primari, si sono rivelati molto utili i seguenti
indici secondari:
5.3 Progettazione della componente dati
57
Figura 5.8. Mockup di livello due relativo alla home page ed al login
•
•
CAMPO.Nome, utilizzato per velocizzare la ricerca di un campo;
PRENOTA.Data, utilizzato per velocizzare la prenotazione di un campo o un
torneo.
Dimensionamento degli attributi
Di seguito sono riportate le tipologie di variabili degli attributi di ogni tabella, e le
relative dimensioni totali.
GESTORE
•
•
•
•
•
•
CodiceFiscaleG: VARCHAR(16);
Nome: VARCHAR(30);
Cognome: VARCHAR(30);
Cellulare: VARCHAR(10);
E-mail: VARCHAR(50);
DataDiNascita: DATE;
Totale: 146 byte
CAMPO
•
•
CodiceC: VARCHAR(50);
Indirizzo: VARCHAR(200);
58
5 Progettazione della logica di business
Figura 5.9. Lo schema E/R relativo al portale
• Tipo: VARCHAR(30);
• CodiceFiscaleG: VARCHAR(16);
Totale: 296 byte
DITTA
• Nome: VARCHAR(50);
• CostoManutenzione: DOUBLE;
Totale: 60 byte
FA MANUTENZIONE
• CodiceC: VARCHAR(50);
• NomeD: VARCHAR(50);
Totale: 100 byte
SPONSOR
• NomeS: VARCHAR(50);
• Donazione: DOUBLE;
Totale: 60 byte
PUBBLICIZZA
• CodiceFiscaleG: VARCHAR(16);
5.3 Progettazione della componente dati
Figura 5.10. Dizionario delle Entità
•
NomeS: VARCHAR(50);
Totale: 66 byte
TORNEO
•
•
•
•
•
CodiceT: VARCHAR(50);
Nome: VARCHAR(30);
Campo: VARCHAR(40);
NumMaxSqu: INT;
CodiceFiscaleG: VARCHAR(16);
Totale: 162 byte
SQUADRA
•
•
NomeSqu: VARCHAR(30);
NumGioc: INT;
Totale: 40 byte
UTENTE
•
•
•
CodicefiscaleU: VARCHAR(16);
Nome: VARCHAR(30);
Cognome: VARCHAR(30);
59
60
5 Progettazione della logica di business
Figura 5.11. Dizionario delle Relazioni
• Cellulare: VARCHAR(10);
• E-mail: VARCHAR(50);
• DataDiNascita: DATE;
Totale: 146 byte
PRENOTA
•
•
•
•
•
CodicefiscaleU: VARCHAR(16);
CodiceC: VARCHAR(50);
Data: DATE;
Illuminazione: VARCHAR(40);
fasciaOraria: VARCHAR(20);
Totale: 136 byte
CREA
• CodiceFiscaleU: VARCHAR(16);
• NomeSqu: VARCHAR(30);
Totale: 46 byte
PARTECIPA
• CodiceT: VARCHAR(50);
5.3 Progettazione della componente dati
61
Figura 5.12. Dizionario dei Vincoli
•
NomeSqu: VARCHAR(30);
Totale: 80 byte
Stima delle dimensioni richieste
La stima dell’occupazione di spazio su disco è un passaggio necessario per definire la
quantità di spazio necessaria per il database. Essa è indispensabile al fine di stabilire
se l’hardware utilizzato per memorizzare il database sia sufficiente o meno. Tale
valutazione è fortemente dipendente dal DBMS prescelto, nonchè dalla piattaforma
hardware e software a disposizione.
In generale, essa è basata sulla dimensione di ciascuna tupla e sul numero di
tuple della relazione; quest’ultimo valore potrebbe essere posto pari al caso massimo
previsto; in alternativa, si potrebbe stimare in che modo crescerà la relazione e
stimare l’occupazione del disco tenendo conto di tale fattore di crescita. In questo
modo, chiaramente, viene individuata la massima occupazione di spazio (Upper
Bound ) impegnato, sul disco, dal database.
Supponiamo di prevedere, per il nostro sistema, una vita di 10 anni e stimiamo
che, durante questo periodo, si iscriveranno circa 5000 tra gestori ed utenti, dei
quali non più del 10% deciderà di rimuovere il proprio account dal portale.
Gli utenti considerati inseriranno, verosimilmente, 12 prenotazioni ciascuno
all’anno, per un totale complessivo di circa 6000 prenotazioni. Queste ultime
diventeranno 60000 considerando l’intero periodo preso in esame.
Si ipotizza, inoltre, che dei 5000 utenti totali, solo 50 siano i gestori che amministrano gli impianti sportivi; essi potranno inserire sia i campi che gestiscono, sia
i tornei a cui gli utenti potranno iscriversi. Si suppone che ogni gestore organizzi
62
5 Progettazione della logica di business
un torneo all’anno, per un totale di 500 tornei in 10 anni, ai quali, mediamente,
parteciperanno circa 12 squadre. Gli stessi membri dello staff potranno, poi, inserire i propri campi, che si stima siano 2 per ogni impianto analizzato, ottenendo
complessivamente 1000 campi memorizzati in 10 anni.
Detto ciò, si terrà tuttavia conto, per la valutazione dell’occupazione di spazio,
del fatto che non tutte le prenotazioni e le iscrizioni rimarranno all’interno del
sistema per l’intero periodo preso in esame.
Inoltre, ogni impianto stipulerà contratti di tipo biennale con le ditte di manutenzione e sponsorizzazione presenti al suo interno. Considerando, nel caso peggiore,
che ogni qualvolta ci sia la possibilità di farlo, ogni gestore decida di cambiare ditta,
al più se ne dovranno registrare 500.
Per quanto riguarda, invece, i file, tenuto conto delle cifre riportate, prendendo
in considerazione il caso peggiore, ovvero immaginando che gli utenti, ogniqualvolta abbiano la possibilità di caricare un’immagine, lo facciano, saranno presenti
contemporaneamente circa 300 file, ciascuno dei quali potrà avere una dimensione
massima di 3 MB.
Pertanto, tenuto conto delle stime riportate e dell’occupazione che caratterizza
le tuple di ciascuna tabella (circa 20 MB), aggiungendo un ulteriore margine del
25% sul risultato finale, lo spazio richiesto sul disco per le funzioni descritte sarà di
circa 5 GB.
5.4 Process Flow
Per rappresentare in modo chiaro la struttura dei casi d’uso si è deciso di utilizzare
i flow chart, molto utili per descrivere in maniera semplice ed intuitiva le varie
operazioni e decisioni che sono state previste ed implementate.
Di seguito vengono presentati i flow chart dei casi d’uso più significativi.
Login
All’interno dello scenario di autenticazione, un utente registrato, in possesso di
username e password, inserisce le proprie credenziali nel form predisposto.
Queste ultime saranno convalidate attraverso il confronto con una tabella UTENTI
presente all’interno del DBMS, e, solo nel caso in cui siano corrette, si procederà
verso l’area riservata (Figura 5.13).
5.4 Process Flow
63
Figura 5.13. Process Flow relativo al login
Effettua prenotazione
All’interno dello scenario relativo alla prenotazione, in Figura 5.14, che si presenterà
all’utente solo dopo la ricerca e la scelta del campo (ammesso che quest’ultimo
sia registrato all’interno del sito), sarà fondamentale valutare se, in quel preciso
intervallo di tempo, la risorsa risulti libera o meno.
In entrambi i casi si arriverà ad una conclusione dell’operazione.
64
5 Progettazione della logica di business
Figura 5.14. Process Flow relativo alla prenotazione
Prenotazione in sospeso
All’interno dello scenario di ricerca, mostrato in Figura 5.15, un membro dello staff
è in grado di controllare se, all’interno del proprio impianto, esistano prenotazioni
pendenti.
Nel caso in cui ci siano richieste ancora in sospeso, esse possono essere accettate
o rifiutate.
5.4 Process Flow
65
Figura 5.15. Process Flow relativo alle prenotazioni in sospeso
Campi
Per quanto riguarda lo scenario di inserimento di un nuovo campo (Figura 5.16), è
possibile che l’impianto in questione sia già stato registrato all’interno del sistema;
se cosı̀ non fosse, sarà possibile aggiungerlo; in caso contrario, si visualizzerà un
messaggio di errore.
Se un membro dello staff volesse, invece, eliminare o modificare i dati relativi
ad un campo già inserito, dopo aver effettuato l’autenticazione, non dovrà far altro
che accedere alla propria area riservata e salvare i cambiamenti.
66
5 Progettazione della logica di business
Figura 5.16. Process Flow relativo ad inserimento, eliminazione e modifica di un campo
6
Implementazione della logica di business
Questo capitolo descrive le fasi di implementazione relative al portale oggetto della
presente tesi. Inizialmente, si presenteranno gli strumenti utilizzati definendo, cosı̀,
una panoramica generale; successivamente, si passerà alla descrizione, con annesso
il corrispettivo codice, di alcune delle più importanti funzionalità del sistema.
6.1 Tecnologie di sviluppo ed interfaccia utente
Tra le tecnologie utilizzate per lo sviluppo del portale per la gestione di un centro
sportivo figurano il linguaggio di programmazione orientato agli oggetti Python,
combinato con la potenza, l’efficacia e la versatilità del Web Framework Django. Il
layout delle pagine è stato sviluppato utilizzando HTML5 e CSS3; per lo sviluppo
del front-end, invece, si è utilizzato il Framework Bootstrap.
Python, nato per mano del ricercatore Guido Van Rossum (Figura 6.1) nei
primi anni novanta, come già ampiamente sottolineato, è un linguaggio moderno e
dalla sintassi semplice, che ne facilita l’apprendimento. Le sue caratteristiche più
facilmente riconoscibili sono le variabili non tipizzate, l’uso dell’indentazione per la
definizione dei blocchi e la presenza di un già ricco assortimento di funzioni di base.
Al momento, l’ultima versione di Python disponibile è la 3.5.2, rilasciata il 26
Giugno 2016.
68
6 Implementazione della logica di business
Figura 6.1. Guido Van Rossum
Django (Figura 6.2), nato nell’autunno 2003 da un gruppo di programmatori in
ambito giornalistico, è uno strumento molto vasto e potente che ci permette, innanzitutto, di evitare la progettazione e l’implementazione della componente Controller
e View per tutto quello che riguarda l’area di amministrazione, ma anche di rendere
più snelle, piacevoli e robuste la stesura e la manutenzione del codice.
Al momento, l’ultima versione di Django disponibile è la 1.10.3, rilasciata l’1
Novembre 2016.
Oltre a questi strumenti prettamente tecnici ed utilizzati offline, per l’informatizzazione della realtà in esame sono stati utilizzati anche i servizi GitHub e
PythonAnywhere.
GitHub, fondato nel 2008 con il nome di “Logical Awesome”, è un servizio di hosting per progetti software. Il sito ha, attualmente, funzionalità molto simili a quelle
di un social network (feeds, follower), ed è una piazza virtuale per la cooperazione
ed il confronto, utilizzata da sviluppatori di tutto il mondo.
PythonAnywhere è un ambiente di sviluppo e servizio hosting online, basato sul
linguaggio di programmazione Python. Esso prevede una shell ed un editor di testo
piuttosto evoluti, realizzati interamente con codice HTML, attraverso i quali l’utente può creare, modificare ed eseguire i propri script. I file vengono memorizzati
in un’area di storage di dimensioni variabili, a seconda del profilo dell’account. Se
lo spazio non dovesse bastare, o se si volesse un’integrazione più fluida con il file
system del proprio PC, PythonAnywhere consente di utilizzare un account Dropbox rendendo accessibile dalla dashboard la propria cartella condivisa sul popolare
servizio di storage.
6.1 Tecnologie di sviluppo ed interfaccia utente
69
Figura 6.2. Il logo del Web Framework Django
Esiste la possibilità di scegliere con quale versione di Python lavorare; è disponibile, altresı̀, un wizard attraverso il quale preconfigurare un’applicazione
Django.
6.1.1
Bootstrap
In questi ultimi anni le modalità di intendere e creare il web sono totalmente cambiate. Prima, la maggior parte dei siti web veniva creata ad hoc; ciò vuol dire che
tutto il codice HTML, CSS e JavaScript veniva generato su misura, per le esigenze specifiche del nuovo progetto. Il successo del Web 2.0 sta proprio nel fatto che
nuove tipologie di sviluppo sono state portate alla luce, ed attraverso framework,
librerie e sistemi di gestione automatizzati, si è trovato un ottimo compromesso con
il passato.
Bootstrap nasce nel 2011 come soluzione interna per cercare di ridurre le incoerenze dello sviluppo legato al social network Twitter. Esso è molto più leggero di
alcuni concorrenti, a tal punto da poter essere definito un set di librerie.
Bootstrap (Figura 6.3) supporta le più recenti versioni dei seguenti browser:
•
•
•
•
•
Chrome;
Safari;
Firefox;
Edge;
Opera.
Esso consiste in una serie di elementi e funzioni per il web-design, personalizzabili e raccolti in un unico strumento, che include, essenzialmente, HTML, CSS e
JavaScript. Quando si progetta un sito web con Bootstrap, chiaramente, sono gli
sviluppatori a scegliere quali elementi utilizzare, avendo la certezza che essi non
vadano in conflitto tra loro; inoltre, basterà includere all’interno del progetto un
asset, tra i tanti messi a disposizione, per avere tra le mani un discreto numero di
stili e funzionalità.
La struttura di Bootstrap è realizzata in modo tale che il risultato finale creato sia responsive, ovvero si adatti alle dimensioni e alle finestre degli schermi su
70
6 Implementazione della logica di business
cui è visualizzata. Dopo aver impostato la struttura di base, si potrà iniziare a
personalizzare gli elementi, eventualmente aggiungendo funzionalità dinamiche.
Nel contesto della realtà esaminata è stata utilizzata proprio una logica di questo tipo, capace di sfruttare le potenzialità del Design Reattivo. In particolare, se
analizziamo il codice del file style.css, una cui minima parte è riportata nel Listato 6.1, possiamo notare la presenza di numerosissimi blocchi separati dai cosiddetti
punti di rottura (Break-Point), i quali determinano una nuova disposizione alternativa delle sezioni all’interno del portale. Vengono definite più versioni sia per tablet
e smartphone, sia per i dispositivi desktop, che varieranno in base alle risoluzioni
degli schermi.
/*--responsive design--*/
@media (max-width:1366px){
.lb-album li > a span {
line-height:14em; }
.field_content {
top: 17em;
left: 8em; }
.field_content h1 {
font-size: 2.6em; }
}
@media (max-width:1280px){
.lb-album li > a span {
line-height:13em; }
.field_content h1 {
font-size: 2.5em; }
.field_content {
top: 16em;
left: 5em; }
}
@media (max-width:1024px){
.lb-album li > a span {
line-height:13em; }
.header_top_right {
width: 27%; }
ul.content-home li .item-html h3 {
font-size:50px;
line-height:30px;
} [. . .]
@media (max-width:930px){
.header_top_right {
width: 35%; }
.cart-items {
width: 100%;
margin-right: 0; }
ul.content-home li .item-html h3 {
font-size: 30px;
line-height:10px;
} [. . .]
@media (max-width:768px){
.logo{
float:none; }
.logo h1 {
font-size: 7em;
font-weight: bold; }
.middle_content h2 {
font-size: 50px;
} [. . .]
@media (max-width:640px){
.field_content h1 {
font-size: 1.3em; }
.delivery span {
float: none; }
.account-in {
padding: 3em 0;
} [. . .]
@media (max-width:480px){
.header_arrow {
margin-top:6em; }
.middle_content h2 {
font-size: 45px; }
ul.content-home {
padding: 3em 0;
} [. . .]
@media (max-width:414px){
i.user {
margin: 6px 5px 0 5px; }
.dropdown {
width: 50px;
padding: 8px 10px 5px; }
.lang_list {
width: 33%; }
@media (max-width:375px){
6.2 La pagina index.html
.banner {
min-height:200px;
padding-top:1em; }
.header_top_left {
float: none;
margin: 0; }
.header_top_right {
width: 100%;
float: none;
margin: 10px 0 0 0;
} [. . .]
71
Listato 6.1. Esempio di implementazione del Design Responsive
È consigliabile scegliere di utilizzare questo framework grafico nel momento in cui
si è in procinto di mettere in piedi un nuovo progetto, poichè risulta particolarmente
difficoltoso adattare un sito già esistente a questa tecnologia. Al momento, l’ultima
versione di Bootstap disponibile è la 4.0.0, rilasciata il 5 Ottobre 2016.
Figura 6.3. Il logo del Framework grafico Bootstrap
6.2 La pagina index.html
Una tra le tante pagine interessanti di cui è necessario approfondire la realizzazione
è la home page. Essa è la prima che viene visitata dall’utente e rappresenta, di
conseguenza, anche la struttura cardine di tutte le altre pagine del portale. Proprio
per questo motivo verranno analizzate parti di codice (Listato 6.2) che risultano
importanti nella sua implementazione.
Il codice relativo alla pagina index.html, appare come di seguito specificato:
{% extends ’header.html’ %}
{% block content %}
{% load staticfiles %}
<div class="main">
<div class="container">
<ul class="content-home">
<div class="middle_content">
<div class="container">
<h2>Benvenuto</h2>
<p>Make a Match! Scegli il tuo profilo e potrai subito prendere parte al divertimento!</p>
</div></div>
<li class="col-sm-4">
<a href="http://johnfoureyes.pythonanywhere.com/admin/" class="item-link">
72
6 Implementazione della logica di business
<div class="bannerBox">
<img src="{% static ’admin/images/field.jpg’ %}" class="item-img" width="100%" height="100%">
<div class="item-html">
<h3>Campo</h3>
<button>Aggiungi</button>
</div></div></a>
</li>
<li class="col-sm-4">
<a href="single.html" class="item-link" title="">
<div class="bannerBox">
<img src="{% static ’admin/images/rove.png’ %}" class="item-img" width="100%" height="100%">
<div class="item-html">
<h3>Match</h3>
<button>Prenota</button>
</div></div></a>
</li>
<li class="col-sm-4">
<a href="http://johnfoureyes.pythonanywhere.com/Tornei/Tornei" class="item-link" title="">
<div class="bannerBox">
<img src="{% static ’admin/images/team.jpg’ %}" class="item-img" width="100%" height="100%">
<div class="item-html">
<h3>Tornei</h3>
<button>Visualizza</button>
</div></div></a>
</li>
</ul>
</div>
<div class="content_middle_bottom">
<div class="header-left" id="home">
<section>
<ul class="lb-album" >
<li>
<a href="#image-1">
<img src="{% static ’admin/images/g1.jpg’ %}" class="img-responsive" alt="image01"/>
<span>Soccer</span></a>
<div class="lb-overlay" id="image-1">
<a href="#page" class="lb-close">x Close</a>
<img src="{% static ’admin/images/g1.jpg’ %}" class="img-responsive"/>
<div>
<h3>Soccer<span>/point/</span></h3><p>Praticato in tutto il mondo</p>
</div></div></li>
<li>
<a href="#image-2">
<img src="{% static ’admin/images/g2.jpg’ %}" class="img-responsive"/>
<span>Port de bras</span></a>
<div class="lb-overlay" id="image-2">
<img src="{% static ’admin/images/g2.jpg’ %}" class="img-responsive"/>
<div>
<h3>port de bras <span>/?p^
or d? ’brä/</span></h3>
<p>An exercise designed to develop graceful movement and disposition of the arms</p>
</div>
<a href="#page" class="lb-close">x Close</a></div></li>
<li>
<a href="#image-3">
<img src="{% static ’admin/images/g3.jpg’ %}" class="img-responsive" alt="image03"/>
<span>Plié</span></a>
<div class="lb-overlay" id="image-3">
<img src="{% static ’admin/images/g3.jpg’ %}" class="img-responsive" alt="image03"/>
<div>
<h3>pli·é <span>/ple’a/</span></h3>
<p>A movement in which a dancer bends the knees and straightens them again</p>
</div>
<a href="#page" class="lb-close">x Close</a>
</div></li>
<li>
<a href="#image-4">
<img src="{% static ’admin/images/g4.jpg’ %}" class="img-responsive" alt="image04"/>
<span>Adagio</span></a>
<div class="lb-overlay" id="image-4">
<img src="{% static ’admin/images/g4.jpg’ %}" class="img-responsive" alt="image04"/>
<div>
<h3>a·da·gio <span>/?’däjo/</span></h3>
<p>A movement or composition marked to be played adagio</p>
</div>
<a href="#page" class="lb-close">x Close</a>
</div></li>
<li>
<a href="#image-5">
<img src="{% static ’admin/images/g5.jpg’ %}" class="img-responsive" alt="image05"/>
<span>Frappé</span></a>
<div class="lb-overlay" id="image-5">
<img src="{% static ’admin/images/g5.jpg’ %}" class="img-responsive" alt="image05"/>
<div>
<h3>frap·pé<span>/fra’pa/</span></h3>
<p>Involving a beating action of the toe of one foot</p>
</div>
<a href="#page" class="lb-close">x Close</a>
</div></li>
<li>
<a href="#image-6">
<img src="{% static ’admin/images/g6.jpg’ %}" class="img-responsive" alt="image06"/>
<span>Glissade</span></a>
<div class="lb-overlay" id="image-6">
<img src="{% static ’admin/images/g6.jpg’ %}" class="img-responsive" alt="image06"/>
6.2 La pagina index.html
73
<div>
<h3>glis·sade <span>/gli’säd/</span></h3>
<p>One leg is brushed outward from the body, which then takes the weight</p>
</div>
<a href="#page" class="lb-close">x Close</a>
</div></li>
<li>
<a href="#image-7">
<img src="{% static ’admin/images/g7.jpg’ %}" class="img-responsive" alt="image07"/>
<span>Jeté</span></a>
<div class="lb-overlay" id="image-7">
<img src="{% static ’admin/images/g7.jpg’ %}" class="img-responsive" alt="image07"/>
<div>
<h3>je·té <span>/zh?-’ta/</span></h3>
<p>A springing jump made from one foot to the other in any direction</p>
</div>
<a href="#page" class="lb-close">x Close</a>
</div></li>
<li>
<a href="#image-8">
<img src="{% static ’admin/images/g8.jpg’ %}" class="img-responsive" alt="image08"/>
<span>Piqué</span></a>
<div class="lb-overlay" id="image-8">
<img src="{% static ’admin/images/g8.jpg’ %}" class="img-responsive" alt="image08"/>
<div>
<h3>pi·qué <span>/pe’ka/</span></h3>
<p>Strongly pointed toe of the lifted and extended leg sharply lowers</p>
</div>
<a href="#page" class="lb-close">x Close</a>
</div></li></ul>
</section>
</div>
</div>
</div>
{% endblock content %}
Listato 6.2. Implementazione della home page (prima parte)
Come si può notare, all’interno della pagina analizzata, non compaiono le sezioni
header e footer, che sono state semplicemente richiamate al suo interno. Questa
scelta comporta un miglioramento della manutenzione e della velocità di sviluppo,
dovute al fatto che, nel caso in cui qualcosa dovesse essere modificata, basterà
ritoccare un singolo file che, a cascata, modificherà tutte le pagine che lo richiamano,
piuttosto che correggere tutto singolarmente.
Per completezza riportiamo anche la porzione di codice (Listato 6.3) inserita all’interno del file richiamato, proprio secondo il metodo dell’ereditarietà dei
template.
<!DOCTYPE HTML>
<html>
<head>
<title>Make a Match! Registrati al nostro sito web per la migliore esperienza di gioco. Join us!</title>
<meta name="viewport" content="width=device-width, initial-scale=1">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="keywords" content="Make a Match! Bootstrap Web Templates" />
{% load staticfiles %}
<script type="application/x-javascript"> addEventListener("load", function()
{ setTimeout(hideURLbar, 0); }, false); function hideURLbar(){ window.scrollTo(0,1); } </script>
<link href="{% static ’admin/css/bootstrap.css’ %}" rel=’stylesheet’ type=’text/css’ />
<!-- jQuery (Bootstrap’s JavaScript plugins) -->
<!-- Theme files -->
<link href="{% static ’admin/css/style.css’ %}" rel=’stylesheet’ type=’text/css’ />
<!-- Theme files -->
<!-- Font online -->
<link href=’//fonts.googleapis.com/css?family=PT+Sans+Narrow:400,700’ rel=’stylesheet’ type=’text/css’>
<link href=’//fonts.googleapis.com/css?family=Dorsa’ rel=’stylesheet’ type=’text/css’>
<script type="text/javascript" src="{% static ’admin/js/jquery-1.11.1.min.js’ %}"></script>
<!-- Start menu -->
<link href="{% static ’admin/css/megamenu.css’ %}" rel="stylesheet" type="text/css" media="all" />
<script type="text/javascript" src="{% static ’admin/js/megamenu.js’ %}"></script>
<script>$(document).ready(function(){$(".megamenu").megamenu();});</script>
<script src="{% static ’admin/js/jquery.easydropdown.js’ %}"></script>
<script src="{% static ’admin/js/simpleCart.min.js’ %}"> </script>
</head>
<body>
<div class="men_banner">
<div class="container">
<div class="header_top">
<div class="header_top_left">
<div class="header_top_right">
74
6 Implementazione della logica di business
<ul class="header_user_info">
{% if user.is_authenticated %}
<li class="user_desc">Benvenuto, {{ user.username }}</li>
<a class="login" href="http://johnfoureyes.pythonanywhere.com/loggati/do_logout">
<li style="margin-left:30px" class="user_desc">Logout</li>
</a>
{% else %}
<a class="login" href="http://johnfoureyes.pythonanywhere.com/loggati/pagina_login">
<li class="user_desc">Login</li>
</a>
{% endif %}
</ul>
<!----search-scripts---->
<script src="{% static ’admin/js/classie1.js’ %}"></script>
<script src="{% static ’admin/js/uisearch.js’ %}"></script>
<script>new UISearch( document.getElementById( ’sb-search’ ) );</script>
<!----//search-scripts---->
</div>
</div>
<div class="header_bottom">
<div class="logo">
<h1><a href="http://johnfoureyes.pythonanywhere.com/">
<span class="m_1"></span>Make a Match</a></h1>
</div>
<div class="menu">
<ul class="megamenu skyblue">
<li class="active grid"><a class="color3" href="http://johnfoureyes.pythonanywhere.com/">
HOME</a></li>
{% if user.is_authenticated %}
<li class="active grid"><a class="color3" href="http://johnfoureyes.pythonanywhere.com/
loggati/area_riservata">AREA RISERVATA</a></li>
{% else %}
<li class="active grid"><a class="color3" href="http://johnfoureyes.pythonanywhere.com/
registrazione/registrazione">REGISTRATI</a></li>
{% endif %}
</ul>
</div>
</div>
</div>
</div>
</div>
{% block content %}
{% endblock %}
<div class="footer">
<div class="container">
<div class="cssmenu">
<ul>
<li><a href="#">CHI SIAMO</a></li>
<li><a href="https://johnfoureyes.pythonanywhere.com/note_legali">NOTE LEGALI</a></li>
<li><a href="#">CONTATTACI</a></li>
</ul>
</div>
<ul class="social">
<li><a href=""> <i class="instagram"> </i> </a></li>
<li><a href=""><i class="fb"> </i> </a></li>
<li><a href=""><i class="tw"> </i> </a></li>
</ul>
<div class="clearfix"></div>
</div>
</div>
</body>
</html>
Listato 6.3. Implementazione della home page (seconda parte)
6.3 Caratteristiche del portale
Le componenti principali presenti all’interno del sistema sono state implementate
attraverso strumenti quali JavaScript, Python e CSS3; tuttavia, un decisivo aiuto
è arrivato, senza ombra di dubbio, dalle librerie Django. Esse riescono a coprire
ben oltre la maggior parte delle esigenze di sviluppo di un portale di questo tipo,
ignorando i dettagli implementativi della piattaforma utilizzata.
Grazie al supporto di un tale Web Framework si riesce ad evitare la creazione
di molte delle strutture che, solitamente, si dovrebbero implementare a mano, e che
sono, invece, già pronte per l’uso.
6.3 Caratteristiche del portale
6.3.1
75
Login
Questa sezione del portale è stata trattata con un occhio di riguardo; inoltre, grazie
a Django, non è venuto a mancare nessuno degli strumenti di cui si è sentita la
necessità. Grazie al metodo is authenticated, infatti, si è resa inutile, o perlomeno
già predisposta, l’implementazione di alcuni costrutti logici che, di norma, devono
essere inseriti manualmente.
Il login, ma non solo, è stato gestito attraverso la creazione di una Web App in
Django, per la quale, nel Listato 6.4 vediamo il contenuto del file views.py.
from django.shortcuts import render
from django.contrib.auth import authenticate, login, logout
def pagina_login(request):
return render(request, ’loggati.html’, {})
def loggati(request):
username = request.POST[’username’]
password = request.POST[’password’]
user = authenticate(username=username, password=password)
if user is not None:
login(request, user)
return render(request, ’buonfine.html’)
else:
return render(request, ’login_error.html’)
def do_logout(request):
logout(request)
return render(request, ’index.html’)
def area_riservata(request):
username = request.POST[’username’]
password = request.POST[’password’]
user = authenticate(username=username, password=password)
if request.user.is_authenticated:
return render(request, ’area_riservata.html’)
else:
return render(request, ’login_error.html’)
Listato 6.4. Parte dell’implementazione del login
Di seguito, invece, viene mostrato il semplice script di Django grazie al quale
riusciamo ad effettuare il logout e, a terminare la sessione in corso.
def do_logout(request):
logout(request)
return render(request, ’index.html’)
6.3.2
urlpatterns = [
url(r’^do_logout’, views.do_logout, name=’do_logout’),
]
Area riservata
Il sito web creato non permette di accedere alle funzionalità logiche implementate
senza effettuare l’autenticazione; proprio per questo motivo, alcune pagine o porzioni
di codice sono state oscurate per verificare, prima di tutto, tale passaggio.
Attraverso l’utilizzo di Django e delle variabili di sessione, quindi, si riesce a
risalire al nome dell’utente che sta utilizzando il portale e che ha terminato la fase
di autenticazione, reindirizzandolo alla sua area riservata (Listato 6.5), la quale
riporterà, oltre a tutte le funzioni classiche, anche il suo username.
In questo caso, come, in seguito, in tutte le altre pagine, è stato utilizzato il
metodo dell’ereditarietà dei template.
76
6 Implementazione della logica di business
{% extends ’header.html’ %}
{% block content %}
{% load staticfiles %}
<div class="men">
<div class="container">
<div class="grid_1">
<img src="{% static ’admin/images/spunta.bmp’ %}"/>
<br><br><br>
<p><h1>Ciao, {{ user.username }}! <p></p>Ecco la tua area riservata</h1>
<p>Benvenuto!</p>
<div class="container">
<div class="col-md-4 sidebar_men">
<h3>Azioni</h3>
<ul class="product-categories color">
<li class="cat-item cat-item-42"><a href="#">Prenota un campo</a></li>
<li class="cat-item cat-item-63"><a href="http://johnfoureyes.pythonanywhere.com/
Tornei/Tornei">Visualizza Tornei</a></li>
<li class="cat-item cat-item-63"><a href="http://johnfoureyes.pythonanywhere.com/
agenda">La mia Agenda</a></li>
<li class="cat-item cat-item-63"><a href="http://johnfoureyes.pythonanywhere.com/
Campi/Campi">Visualizza Campi</a></li>
<li class="cat-item cat-item-63"><a href="http://johnfoureyes.pythonanywhere.com/
loggati/do_logout">Logout</a></li>
</ul>
</div>
</div>
</div>
{% endblock content %}
Listato 6.5. Implementazione dell’area riservata
All’interno di questa porzione di codice, ma non solo, sono presenti i richiami
al pattern MVC, sia per quanto concerne la definizione del Model sia per quanto
riguarda le View. Questo si può riscontrare in qualsiasi pagina del portale, che, se
correttamente visualizzata, non conterrà mai la sua estensione (Figura 6.4).
Figura 6.4. URL di un sito web realizzato in Django con pattern MVC
Per completezza riportiamo, anche, la porzione di codice inserita all’interno dei
file urls.py:
from django.conf.urls import url
from . import views
6.3.3
urlpatterns = [
url(r’^area_riservata’, views.area_riservata, name=’area_riservata’)
]
Tornei
All’interno dello scenario informatizzato, l’amministratore può creare degli eventi,
ad esempio dei tornei (Figura 6.5), ai quali gli utenti iscritti possono prendere parte. Sono stati definiti alcuni attributi quali Nome, Campo, Numero delle squadre e
Data dell’evento; queste variabili vengono, poi, richiamate e visualizzate all’interno di uno spazio apposito nell’ambito dell’area riservata.
6.3 Caratteristiche del portale
77
Grazie allo stesso principio possono essere utilizzate altre funzioni che, ad
esempio, permettono di eliminare o di modificare un evento simile.
Figura 6.5. Amministrazione di Django: Web App Tornei
Di seguito l’implementazione della Web App relativa ai tornei (Listato 6.6).
from
from
from
from
from
from
from
from
from
django.contrib import admin
.models import Tornei
django.apps import AppConfig
django.conf.urls import url
. import views
django.shortcuts import render
django.utils import timezone
django.db import models
django.utils import timezone
admin.site.register(Tornei)
class TorneiConfig(AppConfig):
name = ’Tornei’
urlpatterns = [
url(r’^Tornei’, views.lista_tornei, name=’lista_tornei’),
]
def lista_tornei(request):
if request.user.is_authenticated:
tornei = Tornei.objects.filter(published_date__lte=timezone.now()).order_by(’published_date’)
return render(request, ’lista_tornei.html’, {’tornei’: tornei})
else:
return render(request, ’login_error.html’, {})
class Tornei(models.Model):
author = models.ForeignKey(’auth.User’)
nome = models.CharField(max_length=100)
campo = models.CharField(max_length=100)
num_squad = models.IntegerField()
created_date = models.DateTimeField(
default=timezone.now)
published_date = models.DateTimeField(
blank=True, null=True)
def publish(self):
self.published_date = timezone.now()
self.save()
def __str__(self):
return self.nome
Listato 6.6. L’implementazione della Web App Tornei
Per quanto concerne la funzione di aggiunta del campo e la relativa Web App,
si è deciso di procedere con le stesse modalità appena trattate.
78
6 Implementazione della logica di business
6.3.4
Prenotazioni
Anche questa importante sezione del progetto relativa alla realtà informatizzata è
stata implementata utilizzando i modelli e le risorse messe a disposizione da Django.
Nel dettaglio, dal punto di vista tecnico, si è inserito all’interno della pagina
ListaTornei.html una sezione hidden, grazie alla quale si riesce a portare le variabili NomeTorneo, CampoTorneo ed Utente all’interno di una View e ad utilizzarle
reindirizzandole all’interno dell’area riservata, cosı̀ come previsto dal pattern MVC.
Nel Listato 6.7 viene mostrata una porzione di codice utilizzata per implementare questa funzionalità.
{% extends ’header.html’ %}
{% block content %}
{% load staticfiles %}
<div class="men">
<div class="container">
<div class="grid_1">
<img src="{% static ’admin/images/sportivo.jpg’ %}"/>
<br><br><br>
<p><h1>TORNEI</h1>
<p>Enjoy!</p>
<br><br>
{% for torneo in tornei %}
<div class="container">
<div class="col-md-4 sidebar_men">
<ul class="product-categories color">
<li class="cat-item cat-item-60"><h4>{{ torneo.nome }}</h4></li>
<li class="cat-item cat-item-63"><p>Luogo dell’evento: </p>{{ torneo.campo }}</li>
<li class="cat-item cat-item-63"><p>Data: </p>{{ torneo.created_date }}</li>
<li class="cat-item cat-item-42"><p>Pubblicato il </p>{{ torneo.published_date }}</li>
<div class="account-in">
<div class="col-md-7 account-top">
<form name = "form" action = "/Tornei/iscrivi_tornei"
method = "POST" ><input type="submit" value="Iscriviti">
{% csrf_token %}
<input type="hidden" value={{ torneo.nome }} name="nome_torneo">
<input type="hidden" value={{ torneo.campo }} name="campo_torneo">
<input type="hidden" value={{ user.username }} name="username">
</form>
</div>
</ul><br></div></div>
{% endfor %}
</div>
</div>
</div>
{% endblock content %}
Listato 6.7. Implementazione della prenotazione (prima parte)
Per completezza riportiamo, anche, la porzione di codice (Listato 6.8) inserita
all’interno del file agenda.html, grazie al quale vengono visualizzate le prenotazioni
e le iscrizioni, all’interno di una tabella dinamica.
{% extends ’header.html’ %}
{% block content %}
{% load staticfiles %}
<div class="men">
<div class="container">
<div class="grid_1">
<img src="{% static ’admin/images/lock.png’ %}"/>
<br><br><br>
<p><h1>LE TUE PRENOTAZIONI</h1>
<p>Enjoy!</p>
<br><br>
{% for torneo_iscritto in tornei_iscritti %}:
<div class="container">
<div class="col-md-4 sidebar_men">
<ul class="product-categories color">
<li class="cat-item cat-item-60"><h4>{{ torneo_iscritto.nome_torneo }}</h4></li>
<li class="cat-item cat-item-63"><p>Presso: </p>{{ torneo_iscritto.campo_torneo }}</li>
</ul><br></div></div>
6.4 Manuale di sistema
79
{% endfor %}
</div>
</div>
</div>
{% endblock content %}
Listato 6.8. Implementazione della prenotazione (seconda parte)
6.4 Manuale di sistema
Questa sezione illustra, per grandi linee, il funzionamento del sistema. In particolare,
saranno presentate alcune schermate del portale, e, per ciascuna di esse, verrà fornita
una spiegazione del loro funzionamento.
Login
Nel caso rappresentato in Figura 6.6, analizziamo la prima pagina che viene vista
da un utente qualsiasi che si colleghi al portale. Essa permette di effettuare il login
al sistema; infatti, l’utente può visualizzare i dati presenti nel portale solo qualora
egli si sia autenticato.
Requisito fondamentale per l’accesso è la registrazione.
Figura 6.6. Pagina relativa al login
80
6 Implementazione della logica di business
Registrazione
In Figura 6.7 analizziamo la pagina di registrazione al portale, accessibile tramite
un link presente all’interno della home page. Grazie ad essa è possibile completare
il form predisposto per accedere alle ulteriori sezioni.
L’amministratore, attraverso Django, potrà effettuare le seguenti scelte:
•
•
•
•
attivare o disattivare l’accesso all’area riservata;
far sı̀ che il nuovo utente entri a far parte dello staff ;
far sı̀ che il nuovo utente diventi un suo pari;
modificare o eliminare il profilo in questione.
Figura 6.7. Pagina relativa alla registrazione
Area Riservata
La Figura 6.8 presenta, sia all’interno dell’header sia nella stringa di benvenuto,
una variabile istanziata dal sistema, costituita dal nome dell’utente corrente già
autenticato.
Allo stesso modo, grazie ai metodi messi a disposizione da Django, è possibile
effettuare il logout.
6.4 Manuale di sistema
81
Figura 6.8. Pagina relativa all’area riservata
Prenotazione
Una volta che l’utente finale, dopo aver effettuato l’accesso, si troverà nella sua area
riservata, potrà decidere, nel caso sia un componente dello staff e quindi un gestore,
di creare un nuovo campo o un torneo a cui ci si potrà iscrivere (Figura 6.9); nel
caso in cui egli sia un semplice utilizzatore, invece, sarà in grado di effettuare una
prenotazione che comparirà nella sezione La mia agenda (Figura 6.10).
Figura 6.9. Amministrazione di Django: aggiunta di un campo
82
6 Implementazione della logica di business
Figura 6.10. Pagina relativa a “La mia Agenda”
Note Legali
Sono state inserite, anche, alcune pagine statiche (Figura 6.11), che, pur non avendo
alcun tipo di azione o meccanismo logico alle spalle, si sono rivelate utili, in una
prima fase, ai fini dello studio del responsive design e di Bootstrap.
6.4 Manuale di sistema
Figura 6.11. Pagina note legali
83
7
Discussione critica in merito al lavoro
svolto
All’interno di questo capitolo verrà effettuata l’analisi del sistema attraverso la
tecnica SWOT; nello specifico saranno descritti punti di forza, debolezze, criticità
ed ulteriori opportunità di sviluppo. Successivamente, si presenteranno analogie e
differenze nate dal confronto con sistemi correlati.
7.1 SWOT Analysis
L’analisi SWOT (Strenghts, Weakness, Opportunity and Treaths) è una delle tecniche di indagine più diffuse in quest’ambito e costituisce un supporto per la definizione di strategie d’azione in contesti caratterizzati da forte competitività. Tale
tecnica è attribuita ad Albert Humphrey, che, tra il 1960 ed il 1970, ha guidato un
progetto di ricerca all’Università di Stanford, anche se, in un paper pubblicato nel
2005, egli stesso evidenziava il fatto di non essere il creatore della SWOT Analysis,
attribuendo, piuttosto, tale merito alla sua università ed al MIT di Boston.
L’analisi SWOT (Figura 7.1) è uno strumento di pianificazione strategica tipicamente usato per valutare i punti di forza (Strengths), i punti di debolezza (Weaknesses), le opportunità (Opportunities) e le minacce (Threats) di un progetto, ma,
in generale, può essere utilizzato anche in ogni altra situazione in cui un’organizzazione o un individuo debba prendere una decisione per il raggiungimento di un
determinato obiettivo.
L’analisi può riguardare l’ambiente interno o esterno; l’analisi interna fa riferimento a tutti i fattori strettamente legati al progetto; al contrario, l’analisi esterna
permette di tener conto di fattori indipendenti dal prodotto e che possono essere a
suo vantaggio o svantaggio, dando luogo ad opportunità di maggiore sviluppo o a
rischi generati da particolari condizioni del contesto in cui si opera.
Per effettuare l’analisi SWOT di un progetto, è necessario, dunque, definire i
quattro parametri sui quali tale analisi si basa, ovvero:
•
•
Strength: sono gli elementi da potenziare e su cui puntare; rappresentano gli
argomenti principali da comunicare.
Weaknesses: raffigurano un vincolo ed un freno al conseguimento dell’obiettivo
del progetto; devono essere migliorati, neutralizzati o ridimensionati.
86
7 Discussione critica in merito al lavoro svolto
• Opportunities: sono i vantaggi che possono venire dall’ambiente esterno come, ad
esempio, normative favorevoli, cambiamenti socio-economici, sviluppo di nuove
tecnologie. Vanno colte al momento giusto per poterle trasformare in punti di
forza; se, invece, venissero trascurate, rischierebbero di trasformarsi in punti di
debolezza.
• Threats: sono fattori o eventi che possono ostacolare e frenare gli obiettivi auspicati di un progetto. Derivano da punti di debolezza, opportunità lasciate andare
ed eventuali punti di forza non utilizzati in modo opportuno.
Figura 7.1. Criteri fondamentali della SWOT Analysis
Di seguito viene riportata l’analisi SWOT dettagliata relativa al sistema oggetto
della presente tesi.
7.1.1
Punti di forza
Come già ampiamente dimostrato, il mondo del Web 2.0 gode di un supporto tale da
consentire la fruizione di un insieme esteso di framework e di librerie attraverso cui
procedere con lo sviluppo. I punti di forza del progetto sono, certamente, da ritrovarsi nel linguaggio di programmazione, Python, e dei validissimi framework Django
e Bootstrap, usati per la sua realizzazione. Grazie al suo essere object-oriented, alla
sua semplicità e flessibilità, Python ha permesso di realizzare velocemente, ed in
modo facilmente leggibile, lo sviluppo di un sistema con modalità ben strutturate.
La scelta di informatizzare la realtà in esame anche tramite il framework Bootstrap non è stata casuale; la chiarezza, la quantità di documentazione e la compatibilità con le piattaforme più diffuse sono stati motivi determinanti nella scelta di
questo, piuttosto che di qualsiasi altro strumento. Considerando la crescita esponenziale dei dispositivi mobili, inoltre, la necessità di rendere un portale web di nuova
generazione compatibile con la maggior parte di essi, è essenziale.
7.2 Confronto con altri sistemi correlati
7.1.2
87
Punti di debolezza
Sicuramente, l’utilizzo di Django ha apportato numerosi vantaggi all’implementazione del sito web; paradossalmente, però, esso potrebbe anche mostrare un risvolto
della medaglia, generando alcuni punti di debolezza. Se la presenza di librerie è
uno dei principali vantaggi di Django, la sua installazione non proprio intuitiva ed
i costi per un sistema che sia pronto e totalmente compatibile, potrebbero essere
proibitivi.
Infine, l’ultimo svantaggio riscontrato è legato a Bootstrap; se è vero che questo
framework grafico dalle potenzialità incredibili permette di adattare automaticamente il contenuto delle pagine per facilitare la costruzione di un portale responsive,
è altrettanto vero che, talvolta, tende ad alterare l’adattamento di alcune sezioni di
esso, non posizionando i contenuti con la precisione che si desidererebbe.
7.1.3
Opportunità
Una tra le più grandi opportunità, che questo tipo di realtà informatizzata permette,
può essere quella di generalizzare e portare l’idea legata alla gestione del centro
sportivo anche al di fuori di questo contesto.
Sarebbe, inoltre, possibile tentare di sfruttare la crescente richiesta di dispositivi
mobili per sviluppare un’applicazione che sincronizzi, su di un account e-mail, la
prenotazione portata a termine con successo, e che riesca a far rilasciare un feedback
relativo all’esperienza di gioco avuta, in modo che ogni impianto abbia una votazione
media calcolata secondo un algoritmo creato appositamente.
7.1.4
Minacce
Una delle minacce che potrebbe, forse, gravare sul progetto sta nell’utilizzo di un tema sviluppato esternamente; tale tema risulterà, quindi, soggetto al suo sviluppatore
in termini di aggiornamenti.
Un eventuale rischio, a livello sociale, potrebbe essere quello di incontrare, una
volta portata a termine con successo una prenotazione, un utente estraneo ed incompatibile con le proprie preferenze, per cui si andrebbe incontro a dei pericoli
simili a quelli di un social network.
7.2 Confronto con altri sistemi correlati
Analizzeremo, ora, alcuni sistemi correlati al mondo dei centri sportivi presenti in
rete, riassumendo sia le funzioni logiche implementate, sia i contenuti. In particolare,
approfondiremo tre portali italiani, ciascuno dei quali sarà brevemente presentato;
successivamente, saranno discusse eventuali analogie e differenze.
Il primo sistema di prenotazioni scelto è raggiungibile all’indirizzo jungoal.it
(Figura 7.2); si tratta di un sito web con design responsive all’interno del quale,
come nel caso da noi gestito, è presente la possibilità di registrarsi per entrare a
far parte del team. Navigando tra le pagine, è possibile scorrere, senza bisogno di
88
7 Discussione critica in merito al lavoro svolto
autenticarsi, l’elenco dei centri sportivi aderenti, l’elenco degli sport e la presenza
degli impianti sul territorio.
Figura 7.2. Home page di Fattore Campo
Il secondo sistema di prenotazioni considerato è raggiungibile all’indirizzo
prenotazionecampionline.it (Figura 7.3). Si tratta di un sito web che non prevede un design di tipo responsive; di conseguenza, la sua navigazione su dispositivi
mobili risulta alquanto difficoltosa, anche per la scarsa attenzione nello sviluppo del
front-end, che non appare particolarmente accattivante.
Esso non prevede una sezione per l’autenticazione nè, tantomeno, un’area riservata dentro la quale visualizzare le proprie iscrizioni. Per prima cosa è necessario
filtrare le strutture per provincia, in modo tale da visualizzare quelle più vicine
alla zona in cui si vuole disputare il match; successivamente, una volta scelto il
campo più adeguato alle proprie esigenze, si dovrà compilare un form da inviare
direttamente presso l’indirizzo e-mail del gestore dell’impianto scelto.
7.2 Confronto con altri sistemi correlati
89
Figura 7.3. Home page di Prenotazione Campi Online
Il terzo ed ultimo sistema di prenotazioni scelto è raggiungibile all’indirizzo
prenotauncampo.it (Figura 7.4). Anche questo sito web presenta un design responsive, oltre alla possibilità di scaricare un’applicazione mobile per dispositivi
Android ed iOS. In questo portale, l’unica sezione accessibile senza l’autenticazione, come nel caso da noi gestito, è la home page; è presente, inoltre, una ricerca di
tipo avanzato che fa scegliere all’utente tra vari tipi di impianti, filtrando per città,
indirizzi, date ed orari.
Figura 7.4. Home page di Prenota un Campo
In conclusione, è possibile affermare che il portale responsive adibito alla gestione
di un centro sportivo da noi creato possiede una buona parte delle funzionalità
90
7 Discussione critica in merito al lavoro svolto
che si possono riscontrare nei sistemi correlati; dunque, permette all’utente finale
un’esperienza d’uso piuttosto completa.
7.3 Considerazioni in merito all’esperienza maturata
Le nozioni apprese durante lo sviluppo, tramite Python e Django (Figura 7.5), di
un portale per la gestione di un centro sportivo, sono state davvero numerose.
Una tra tutte riguarda l’importanza dello sviluppo utilizzando i pattern e le
Web App, ovvero la creazione di componenti software indipendenti tra loro che si
richiamano a vicenda, se necessario, per l’esecuzione di compiti specifici. In generale, un approccio di questo tipo garantisce, senza ombra di dubbio, un alto livello
di manutenibilità del codice, considerando che, anche nel caso in cui si volessero
effettuare delle modifiche o apportare delle migliorie, non sarà necessario andare
troppo in profondità o riprendere più sezioni di codice di quelle necessarie.
Figura 7.5. Sviluppatore alle prese con Django e Python
Non è da sottovalutare, in questo contesto, l’importanza della coppia di framework utilizzati, ovvero Bootstrap e Django, grazie ai quali si riesce a portare a
termine gli obiettivi prefissati più velocemente e con meno complicazioni rispetto al
solito. Questo succede, anche, per l’importanza delle moltissime librerie presenti al
loro interno, che, se utilizzate a dovere, riescono ad agevolare il lavoro di sviluppo ed
7.3 Considerazioni in merito all’esperienza maturata
91
implementazione, fornendo componenti pronte per l’uso senza il bisogno di pensare
di costruirle partendo da zero.
Un ulteriore elemento appreso durante lo sviluppo del software in oggetto è quello di riuscire a trovare un compromesso tra le varie versioni di strumenti disponibili;
utilizzare sempre l’ultima versione di un linguaggio, ad esempio, preferendola a quelle più datate, può essere una scelta sbagliata poiché, cosı̀ facendo, non si garantisce
la compatibilità con il più alto numero possibile di sistemi esterni.
In conclusione, da tutte le difficoltà affrontate e superate, è emerso che non
esiste sempre una soluzione univoca per qualsiasi esigenza; è necessario cercare di
ottenere i risultati migliori dagli strumenti che si stanno utilizzando, senza tentare
di forzarne l’espressività verso una direzione prestabilita.
8
Conclusioni ed uno sguardo al futuro
All’interno del presente elaborato sono state illustrate le fasi di analisi, progettazione
ed implementazione di un portale responsive per la gestione di un centro sportivo.
Per quanto riguarda il front-end, esso è stato realizzato utilizzando il framework
open source Bootstrap, che, come ampiamente sottolineato, è risultato fondamentale
per la realizzazione della componente grafica. Per quanto concerne, invece, il backend, la scelta per la realizzazione del nuovo sito web è ricaduta sulla coppia Python
e Django.
I primi capitoli della presente tesi sono integralmente dedicati alla descrizione
delle caratteristiche del linguaggio e del Web Framework utilizzati; successivamente, vengono espressi i risultati derivanti dall’analisi dei requisiti e dalla progettazione della logica di business, ovvero quella logica che riesce a rendere funzionale ed
operativa l’elaborazione dati di un sistema.
Individuati i tool da utilizzare per l’implementazione ed analizzati tutti i requisiti, ci si è occupati sia della progettazione della componente applicativa, sia di
quella della componente dati, suddivisa, come da prassi, nelle tre fasi di progettazione concettuale, logica e fisica. Per quest’ultima, in particolare, si è tenuto conto
del fatto che la realizzazione della base di dati sarebbe stata effettuata utilizzando
il DBMS SQLite. Come accennato pocanzi, dopo aver progettato la base di dati, è
stata elaborata la componente applicativa attraverso la realizzazione della mappa
gerarchica, dei mockup e, per concludere, dei process flow dei più importanti casi
d’uso implementati.
Alla fase di progettazione ha fatto seguito, come già accennato, l’implementazione del sistema, realizzata, in particolare, attraverso il pattern MVC ed utilizzando
il linguaggio di sviluppo orientato agli oggetti Python, totalmente integrato con le
funzionalità che Django ha da offrire. La descrizione dettagliata del codice implementato, seguita da una forma breve di manuale utente, viene proposta all’interno
degli ultimi capitoli della presente tesi.
Terminata la descrizione delle attività di implementazione del sistema, è stata
presentata l’analisi SWOT, che riassume i punti di forza, di debolezza, le prospettive
e le minacce collegate al portale. È stata, inoltre, definita una serie di best pratice
e lezioni apprese, emerse durante la fase di progettazione ed implementazione, che
risulteranno utili nella realizzazione di progetti futuri.
94
8 Conclusioni ed uno sguardo al futuro
L’ultima sezione affrontata riguarda il confronto del progetto realizzato con altri
sistemi simili presenti in rete; si è riusciti ad affermare, senza riserve, che il risultato
finale dell’informatizzazione della realtà in questione, permette, all’utente, un’esperienza d’uso piuttosto completa. Tuttavia, è opportuno evidenziare che queste sono
solo alcune delle funzionalità e delle aree che compongono il sito, le altre sono attualmente in fase di realizzazione e rappresentano l’oggetto di un altro elaborato di
tesi.
Per quanto riguarda il futuro del portale, una delle caratteristiche che andrebbero probabilmente implementate è la connessione con i principali social network, in
modo da poter effettuare l’autenticazione attraverso l’utilizzo di Facebook, Twitter
o Google+. Inoltre, dovrebbe essere data agli utenti la possibilità di condividere
una prenotazione portata a termine; cosı̀ facendo, anche le possibilità di espansione
del sito web sul territorio nazionale, e non, crescerebbero in maniera esponenziale.
Si potrebbe aggiungere, all’interno dell’area riservata dell’utente, la possibilità
di rilasciare un feedback relativo all’esperienza di gioco avuta all’interno di una
struttura, in modo tale che ogni impianto abbia una votazione media calcolata
secondo un algoritmo creato ad hoc.
Un’altra idea particolarmente interessante, nel caso in cui si voglia ulteriormente
estendere le funzionalità del portale Web, potrebbe essere quella di introdurre dei
bonus fedeltà, in modo tale che gli utenti siano sempre più spinti a prenotare un
campo utilizzando la propria connessione a Internet. Per ogni prenotazione potrebbero essere assegnati dei crediti, da utilizzare all’interno del portale stesso o come
moneta virtuale all’interno dell’impianto.
Ed ancora, si potrebbe implementare la funzionalità Cerca un avversario, grazie
alla quale, qualunque utente finale possa candidarsi a giocare una partita pur non
avendo una squadra al completo, affidandosi al sistema per la ricerca degli avversari
sulla base di opportuni filtri specificati dall’utente stesso.
In ultimo, ma non per importanza, si dovrebbe, probabilmente, progettare un’applicazione per i dispositivi mobili più diffusi, Android ed iOS su tutti, creando un
sistema di sincronizzazione con le mappe ed il calendario, in modo tale da raggiungere con più facilità la struttura scelta e registrare la prenotazione tra i propri
impegni personali.
Ringraziamenti
Troppe volte mi è capitato di sentire che, probabilmente, i ringraziamenti sono la
parte della tesi più difficile da comporre.
In questo caso, ahimè, mi sento in dovere di dissentire. A mio avviso, infatti, non
c’è cosa più semplice che ringraziare di cuore le persone che mi hanno supportato
e sopportato durante questo cammino. I tanti volti incontrati lungo la strada sono
stati veicolo di un gusto nuovo per lo studio; si son presi carico dei miei timori,
dubbi ed insicurezze, hanno riso e pianto con me, rasserenandomi e tirandomi sù di
morale, anche quando la salita si presentava molto ripida.
Ringrazio mio padre, mia madre e mio fratello, che non hanno mai smesso di
credere in me, sacrificandosi e regalandomi i momenti più belli della mia vita.
Ringrazio Chiara, mio unico grande amore, per essere stata al mio fianco anche
quando pensavo di non farcela e, senza la quale, probabilmente, non sarei giunto
sin qui.
Ringrazio il prof. Ursino, per l’incredibile disponibilità dimostrata, per essere
stato paziente e discreto nell’indirizzarmi al meglio.
Ringrazio Giorgio, Dave e Budino, amici veri e sempre pronti ad alleggerire le
mie giornate.
Ringrazio Don Pietro, il cui sguardo arriva sempre più lontano di quello altrui.
Ringrazio mio nonno Giò, per avermi insegnato l’umiltà e l’arte della vita; mia
nonna Tota, per avermi fatto capire che essere è più importante che apparire;
mio nonno Paolo e mia nonna Maria, dall’altra parte della strada, “la vita può
allontanarci, l’amore continuerà”.
Ringrazio Frank e Peppe Z, che mi sono venuti incontro quando molti altri
sembravano non accorgersi delle mie difficoltà.
Ringrazio Cicciriti, Sam, Pietro, Claudia e Andrea, compagni di risate e di
avventura.
Ringrazio Paola, Santina, Marianna e Peppe, che, anche se fisicamente lontani,
non hanno mai fatto sentire la loro mancanza.
Ringrazio Mimmo Crea e Nino Ficara, per i loro preziosi consigli.
Ringrazio Peppino, Alessia, Andrea, Anna, Bi, Pucci, Valentina, Peppe Tripodi,
Peppe Cuore, Marco, Pablito, Oscar, Bono, Demetrio, Gabri e tutti gli altri amici
che mi vogliono bene.
Ed, infine, ringrazio Dio per avermi preferito e donato tutti voi.
O Maria, Madre di Dio,
conservami un cuore di fanciullo,
puro e limpido come acqua di sorgente.
Ottienimi un cuore semplice,
che non assapori la tristezza;
un cuore grande nel donarsi
e tenero nella compassione;
un cuore fedele e generoso
che non dimentichi nessun beneficio
e non serbi rancore per il male.
Forma in me un cuore dolce e umile,
un cuore grande ed indomabile
che nessuna ingratitudine possa chiudere
e nessuna indifferenza possa stancare;
un cuore tormentato dalla gloria di Gesù Cristo,
ferito dal Suo amore con una piaga
che non rimargini se non in Cielo. Amen.
Riferimenti bibliografici
1. Tutorial Python. http://www.python.it/doc/Easytut/easytut-it/contents.html,
2002.
2. The Zen of Python. https://www.python.org/dev/peps/pep-0020/, 2004.
3. Motivi Per Cui Django Stenta A Diffondersi. http://www.davidesalerno.net/2008/
04/motivi-per-cui-django-stenta-a-diffondersi/, 2008.
4. Il pattern MVC. http://www.html.it/pag/18299/il-pattern-mvc/, 2009.
5. Il tutorial di Django. https://tutorial.djangogirls.org/it/, 2012.
6. PythonAnywhere: un ambiente Python nel proprio browser. http://blog.html.it/
10/05/2012/pythonanywhere-un-ambiente-python-nel-proprio-browser/, 2012.
7. Model View Controller Pattern. http://www.claudiodesio.com/ooa&d/mvc.htm,
2014.
8. Focus su Python e Django. http://www.devinterface.com/it/blog/focus-supython-e-django, 2015.
9. Lezione su Django. http://www.w3ii.com/it/django/default.html, 2015.
10. What really is the business logic? http://softwareengineering.stackexchange.
com/questions/234251/what-really-is-the-business-logic, 2015.
11. Django Official. https://www.djangoproject.com/, 2016.
12. GitHub Official. https://github.com/, 2016.
13. Guida Django. http://www.html.it/guide/guida-django-10/, 2016.
14. Learn to code and to Build real projects. https://www.codingforentrepreneurs.
com/, 2016.
15. Python Official. https://www.python.org/, 2016.
16. M. Beri. Sviluppare applicazioni web con Django. Apogeo, 2009.
17. M. Bigatti. UML e design pattern. Notazioni grafiche e soluzioni per la progettazione.
Hoepli, 2006.
18. J. Elman and M. Lavin. Lightweight Django: Using REST, WebSockets, and Backbone.
O’Reilly Media, 2014.
19. J. E. Forcier, P. Bissex, and W. J. Chun. Python Web Development with Django.
Addison-Wesley Professional, 2008.
20. G. Gigliotti. HTML5 e CSS3. Apogeo, 2010.
21. A. R. Greenfeld. Two Scoops of Django: Best Practices for Django 1.8. Lightning
Source Inc, 2015.
22. S. Hay. Responsive design: Progettare siti web per i dispositivi mobili. Pearson, 2014.
23. C. S. Horstmann, R. D. Necaise, and M. Dalpasso. Concetti di informatica e
fondamenti di Python. Apogeo, 2014.
24. S. Jaiswal. Learning Django Web Development. Packt Publishing, 2015.
25. A. Mele. Django by Example. Packt Publishing, 2015.
100
Riferimenti bibliografici
26. D. Moore, R. Budd, and W. Wright. Professional Python Frameworks: Web 2.0
Programming with Django. Wrox, 2007.
27. A. Pinkham. Django Unleashed. Sams Publishing, 2015.
28. A. Ravindran. Django Design Patterns and Best Practices. Packt Publishing, 2015.
29. Z. A. Shaw. Learn Python the Hard Way: A Very Simple Introduction to the Terrifyingly Beautiful World of Computers and Code. Addison Wesley Longman Inc,
2013.
30. I. Sommervilles. Ingegneria del software. Pearson, 2007.