theses
Transcript
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.