Università degli Studi di Padova
Dipartimento di Matematica
Corso di Laurea in Informatica
Applicazione per la gestione di liste integrata con Facebook
Tesi di Laurea
Relatrice
Prof.ssa Ombretta Gaggi
Laureando Marco Michielotto
Anno Accademico: 2014-2015
Sommario
Il presente documento descrive il dettaglio dello stage formativo intrapreso dal lau- reando Marco Michielotto presso l’azienda Noonic s.r.l., della durata di 320 ore. Lo Stage aveva come obiettivo lo sviluppo di un applicativo Web per la gestione e la com- pilazione di liste di elementi generici in una sorta di minigioco integrato con il social network Facebook.
Si andranno dunque a riassumere le attività svolte durante lo stage, con particolare attenzione agli strumenti e alle tecnologie utilizzate.
iii
Ringraziamenti
Vorrei innanzitutto ringraziare la professoressa Ombretta Gaggi, relatrice della mia te- si, per la disponibilità e l’aiuto offertomi.
Ringrazio inoltre tutto il team di Noonic s.r.l. ed in particolare il tutor aziendale Sebastiano Favaro, per avermi accolto nel loro ufficio ed avermi sempre fatto sentire come a casa e parte integrante del gruppo.
Desidero poi ringraziare i miei genitori e mio fratello per avermi sostenuto ed aiu- tato in questi intensi anni di studio, senza i quali non sarei mai giunto fin qui.
Un sentito ringraziamento va a tutti i miei amici e compagni di università per i bel- lissimi momenti passati assieme, per essermi stati vicini e avermi sopportato durante questi anni di studi.
Padova, Ottobre 2015 Marco Michielotto
v
Indice
1 Introduzione 1
1.1 L’azienda . . . 1
1.2 Proposta di stage . . . 1
2 Pianificazione 3 3 Analisi dei Requisiti 5 3.1 Casi d’uso . . . 5
3.1.1 Caso d’uso UC 1.3: Gestione liste . . . 7
3.1.2 Caso d’uso UC 1.3.1: Creazione nuova lista. . . 8
3.1.3 Caso d’uso UC 1.5: Compilazione nuova lista. . . 9
3.1.4 Caso d’uso UC 1.5.4: Visualizzazione risultato sintetico . . . 10
3.2 Elenco dei requisiti . . . 11
3.2.1 Requisiti Funzionali. . . 11
3.2.2 Requisiti qualitativi. . . 13
3.2.3 Requisiti dichiarativi . . . 14
3.3 Resoconto . . . 14
4 Progettazione 15 4.1 Dominio applicativo . . . 15
4.2 Architettura generale . . . 17
4.3 Progettazione del Model . . . 18
4.3.1 Progettazione del Database . . . 19
4.4 Progettazione del Controller . . . 21
4.4.1 Routing . . . 21
4.4.2 Architettura del Controller . . . 21
4.4.3 FacebookSDK . . . 23
4.4.4 Middleware . . . 23
4.5 Progettazione delle View . . . 24
4.6 Diagrammi delle attività . . . 26
4.6.1 Attività principale . . . 26
4.6.2 Compilazione di una lista . . . 28
4.6.3 Gestione liste . . . 30
4.6.4 Gestione risultati liste . . . 31 vii
5 Implementazione e testing 33
5.1 Strumenti . . . 33
5.2 Implementazione del backend . . . 33
5.2.1 Autenticazione con Facebook . . . 33
5.2.2 Model . . . 35
5.2.3 Controller . . . 35
5.3 Implementazione dell’interfaccia . . . 38
5.3.1 Autenticazione . . . 40
5.3.2 Homepage . . . 42
5.3.3 Compilazione Lista . . . 43
5.3.4 Creazione e gestione delle liste . . . 45
5.4 Metriche di progettazione e codifica . . . 48
5.5 Verifica e Validazione . . . 48
5.5.1 Test di verifica . . . 48
5.5.2 Test di validazione . . . 49
6 Conclusioni 51 6.1 Obiettivi raggiunti . . . 51
6.2 Conoscenze acquisite . . . 51
A Design Pattern utilizzati 53 A.1 Model-View-Controller . . . 53
A.2 Facade . . . 54
Glossario 55
Bibliografia 61
Capitolo 1
Introduzione
1.1 L’azienda
Noonic s.r.l. è una web agency e digital factory, fondata da tre giovani ragazzi nel 2012, che opera in Italia e in India. La sede legale si trova a Milano, l’ufficio operativo a Padova e una sede di sviluppo a Trivandrum.
L’azienda si occupa di sviluppo di applicativi web e recentemente anche di applica- zioni per smartphone, garandendo al cliente anche soluzioni di web marketing per il raggiungimento degli obiettivi di business e comunicazione dell’azienda.
Figura 1.1: logo dell’azienda
1.2 Proposta di stage
Il progetto proposto dall’azienda riprende un’idea già sviluppata alcuni anni fa, che riscontrò molto successo in Italia (più di 10 milioni di utilizzi). Consiste nel realizzare un applicativo web, all’interno del quale l’utente si sottopone alla compilazione di alcu- ne liste di elementi, dalle quali può scegliere gli elementi di proprio interesse (secondo il tema per cui è stata creata la stessa lista).
Ad esempio potrà esserci una lista di sport dalla quale l’utente potrà scegliere quali ha praticato, oppure una lista di libri dove selezionare quelli letti e l’applicazione darà la possibilità di condividere il risultato con gli amici. L’idea è dunque quella di un mini gioco sociale all’interno del quale gli utenti condividono aspetti della loro vita
1
semplicemente selezionando elementi da liste pre-create da altri utenti, rendendo così minimo lo sforzo da parte del giocatore.
L’applicazione è integrata con il social network Facebook, sfruttando il sistema Canvas Frame.
All’utente, dopo la compilazione di una lista viene presentato un risultato aggregato contenente solo il numero di elementi selezionati come ad esempio: "Hai selezionato 15 sport su 63". Il risultato ottenuto potrà essere condiviso su Facebook invogliando così gli amici dell’utente a vedere nel dettaglio quanto selezionato dall’utente e l’amico stesso verrà invitato ad effettuare il questionario.
La Web App prevede sia la funzionalità di compilazione delle liste, sia la possibilità, da parte di qualsiasi utente, di crearne; questo rende meno gravoso il popolamento della piattaforma agli sviluppatori della stessa. Infine dalla pagina di gestione del- le liste create, l’utente può controllare quante volte è stata compilata ciascuna lista, indicandone il livello di popolarità. Lo scopo principale era quello di sviluppare nuo- vamente questo applicativo, sfruttando le nuove tecnologie disponibili, da immettere sul mercato indiano, nel quale l’azienda è molto presente.
L’applicazione è sviluppata in lingua inglese poiché una delle lingua ufficiali dell’in- dia.
Capitolo 2
Pianificazione
Prima dell’inizio dello stage è stato redatto un piano di lavoro, proposto dall’azianda, a cadenza settimanale che è stato ampiamente rispettato.
• Prima settimana: Fase di studio delle tecnologie coinvolte: API di Facebook, Laravel, PHP, HTML, CSS, Javascript, MySQL;
• Seconda settimana: Fase di studio parziale, inizio della fase di analisi, colle- zione dei requisiti ed inizio della stesura di un documento di analisi dei requisiti;
• Terza Settimana: Fine della fase di analisi ed inizio della fase di realizzazione della specifica tecnica;
• Quarta Settimana: Sviluppo del prodotto;
• Quinta Settimana: Sviluppo del prodotto, fino al rilascio di una versione alpha;
• Sesta Settimana: Fine dello sviluppo ed inizio della fase di test funzionali, rilascio di una versione beta;
• Settima Settimana: Validazione ulteriore parte dell’azienda con relative corre- zioni, e messa online del progetto. (circa una versione di RC);
• Ottava Settimana: Correzioni a seguito di bug presentati dagli utilizzatori, monitoraggio dell’utilizzo, miglioramenti a seguito della messa online, ulteriori potenziali sviluppi.
3
Capitolo 3
Analisi dei Requisiti
In questo capitolo viene documentata l’attività di analisi dei requisiti del progetto proposto.
3.1 Casi d’uso
Per favorire l’attività di estrazione dei requisiti, a seguito di una riunione con il tutor interno, sono stati redatti dei casi d’uso, dai quali è stato possibile estrarre un numero consistente di requisiti. Per ogni caso d’uso è stato redatto il rispettivo diagramma seguendo le specifiche UML 2.0, accompagnato con una descrizione testuale, secondo lo schema seguente:
UC: Il nome del caso d’uso con un codice identificativo gerarchico;
• Attori Principali: Gli attori coinvolti;
• Precondizioni: La precondizione del caso d’uso;
• Descrizione: La descrizione del caso d’uso;
• Post-condizioni: La Post-condizione del caso d’uso;
• Scenario Alternativo: L’eventuale caso d’uso alternativo.
Caso d’uso UC 1: Visione ad alto livello
• Attori: utente, nuovo utente;
• Precondizione: l’utente è autenticato su Facebook;
• Descrizione: Al momento dell’apertura dell’app l’utente di Facebook ha la pos- sibilità, in stile gioco, di compilare delle liste tra quelle proposte e di gestire la creazione di nuove liste da sottoporre ad altri utenti. Inoltre nel caso l’utente provenga da un link della bacheca di Facebook ha la possibilità di visualizzare i risultati della persona che ha condiviso il risultato. Infine se l’utente ha già utilizzato l’app e dunque ha già compilato almeno una lista, potrà visualizzarne i risultati ottenuti;
5
Figura 3.1: Caso d’uso UC1: Visione ad alto livello
• Post-condizione: l’utente ha selezionato l’operazione da eseguire;
• Scenario alternativo: se l’utente richiede la visualizzazione dei risultati di un amico riguardo una lista che lui stesso non ha ancora compilato, viene esortato a sottoporsi ad essa tramite un messaggio di notifica.
3.1. CASI D’USO 7
3.1.1 Caso d’uso UC 1.3: Gestione liste
Figura 3.2: Caso d’uso UC 1.3: Gestione liste
• Attori: utente, nuovo utente;
• Precondizione: l’utente è autenticato su Facebook;
• Descrizione: Il nuovo utente può solamente iniziare la procedura per crearne una nuova; mentre un utente che ha già utilizzato l’app potrà, se presente, modificare una lista già creata;
• Post-condizione: l’utente procede con la compilazione, modifica o ripresa della creazione di una lista;
• Scenario alternativo: se l’utente aveva lasciato in sospeso la creazione di una lista, avrà la possibilità di riprenderla.
3.1.2 Caso d’uso UC 1.3.1: Creazione nuova lista
Figura 3.3: Caso d’uso UC 1.3.1: Creazione nuova lista
• Attori: utente;
• Precondizione: l’utente sta creando una nuova lista da poter sottoporre ad altri utenti di Facebook;
• Descrizione: l’utente durante la procedura di creazione di una nuova lista ha la possibilità di inserire ordinatamente un titolo, un’immagine, una descrizione e infine gli elementi testuali che dovrà contenere;
• Post-condizione: la lista è stata creata correttamente.
3.1. CASI D’USO 9
3.1.3 Caso d’uso UC 1.5: Compilazione nuova lista
Figura 3.4: Caso d’uso UC 1.5: Compilazione nuova lista
• Attori: utente;
• Precondizione: l’utente vuole sottoporsi alla compilazione di una lista;
• Descrizione: l’utente procede con la compilazione della lista selezionando gli elementi che ritiene di suo interesse (secondo il titolo e la descrizione della lista) e può sosparsi tra gruppi di elementi per favorirne la leggibilità. Infine l’utente può concludere la compilazione e vedrà visualizzato un risultato riassuntivo che potrà condividere nella bacheca di Facebook;
• Postcondizione: l’utente ha compilato la lista desiderata.
3.1.4 Caso d’uso UC 1.5.4: Visualizzazione risultato sintetico
Figura 3.5: Caso d’uso UC 1.5.4: Visualizzazione risultato sintetico
• Attori: utente;
• Precondizione: l’utente ha concluso la compilazione di una lista;
• Descrizione: viene data la possibilità all’utente di rivedere gli elementi che ha selezionato nella lista appena compilata, di sceglierne un’altra tra quelle proposte dall’applicazione a quale sottoporsi o di visualizzare i risultati che hanno ottenuto i suoi amici che si sono sottoposti alla medesima lista. Infine è possibile pubblicare i risultati ottenuti sulla propria bacheca di Facebook;
• Postcondizione: l’utente ha selezionato l’operazione da eseguire.
3.2. ELENCO DEI REQUISITI 11
3.2 Elenco dei requisiti
A seguito della stesura dei casi d’uso è stato possibile redigere la seguente lista di re- quisiti. Ogni requisito deve essere classificato nella seguente maniera:
R[rilevanza][tipo][codice]
dove:
• rilevanza può assumere i seguenti valori:
– 0. obbligatorio;
– 1. desiderabile;
– 2. facoltativo.
Tale attributo dovrà essere rappresentato per mezzo del numero corrispondente.
• tipo può assumere i seguenti valori:
– F. funzionale;
– Q. qualitativo;
– D. dichiarativo.
Tale attributo dovrà essere rappresentato dalla lettera corrispondente.
• codice è univoco e identificativo del singolo requisito. Il codice viene inoltre usato per creare una gerarchia tra requisiti. Dato il requisito “A” questo sarà soddisfatto se e solo se tutti i suoi sotto-requisiti obbligatori saranno soddisfatti.
Si elencano sotto tutti i requisiti individuati, suddivisi per tipologia.
3.2.1 Requisiti Funzionali
Requisito Rilevanza Descrizione
R0F1 Obbligatorio L’applicazione web deve presentare in ho- mepage un elenco di liste, rappresentate da un’immagine ed un titolo, a cui l’utente può sottoporsi.
R0F1.1 Obbligatorio L’elenco delle liste deve essere un sottoinsie- me di quelle presenti nel sistema, scelte tra le più popolari o nuove, ma comunque non ancora utilizzate dall’utente.
R2F1.2 Opzionale La logica di visualizzazione delle liste in ho- mepage può essere cambiata dal pannello configurazione.
R0F2 Obbligatorio L’utente quando si sottopone ad una lista composta da n elementi, ha la possibilità di sceglierne un numero che va da zero a n.
Continua nella pagina successiva.
Continua dalla pagina precedente.
Requisito Rilevanza Descrizione
R0F2.1 Obbligatorio Ogni lista contiene un numero di elementi va- riabile, ma limitato ad un massimo di 100.
R0F2.2 Obbligatorio Le liste sono presentate all’utente per pa- gine con 10 elementi ciascuna per garantire l’accessibilità.
R0F2.2.1 Obbligatorio Il numero di elementi per pagine è modifi- cabile tramite variabile di configurazione di Laravel.
R0F2.3 Obbligatorio Ogni lista è composta, oltre che da un insie- me di elementi, da un titolo ed un’immagine.
R0F2.4 Obbligatorio Quando l’utente termina la compilazione di una lista verrà visualizzato un risultato aggregato.
R0F2.5 Obbligatorio Quando l’utente termina la compilazione di una lista potrà visualizzare i risultati aggre- gati e dettagliati degli amici Facebook che hanno compilato la stessa.
R0F3 Obbligatorio L’utente può visualizzare i risultati dettaglia- ti di utenti Facebook solamente se ha già compilato la lista corrispondente.
R0F3.1 Obbligatorio Nel caso l’utente cercasse di visualizzare i ri- sultati di un utente Facebook circa una lista che non ha ancora compilato, una notifica lo esorterà a sottoporsi a quest’ultima.
R0F4 Obbligatorio Gli utenti dell’applicazione possono gestire la creazione di nuove liste da pubblicare e sottoporre ad altri utenti.
R0F4.1 Obbligatorio L’utente può creare nuove liste inserendo un titolo, un’immagine e una lista di elementi.
R0P4.1.1 Obbligatorio Le pagine di creazione delle liste sono in real- tà un’unica pagina dinamica gestita tramite Javascript per ridurre il carico lato server.
R2F4.1.2 Opzionale L’inserimento delle immagini è gestito con una ricerca in Google immagini.
R1F4.2 Desiderabile L’utente ha la possibilità di modificare una lista creata, ma la modifica non altererà in alcun modo i risultati degli utenti che l’hanno già compilata.
Continua nella pagina successiva.
3.2. ELENCO DEI REQUISITI 13
Continua dalla pagina precedente.
Requisito Rilevanza Descrizione
R1F4.3 Desiderabile L’utente può abbandonare e riprendere la creazione di una nuova lista.
R0F4.4 Obbligatorio La funzionalità di gestione della liste è ac- cessibile da ogni pagina dell’applicazione.
R0F5 Obbligatorio L’utente ha la possibilità di conoscere i ri- sultati dettagliati, e quindi quali elementi ha selezionato, di tutte le liste che ha compilato.
R0F5.1 Obbligatorio Assieme ai risultati è possibile visualizzare le statistiche di tutti gli utenti in percentuale per ogni elemento suddivise per sesso.
R0F6 Obbligatorio L’applicazione deve tracciare tutti i dati che Facebook, di base, mette a disposizione quando l’utente accetta di utilizzare l’App, in particolare l’età (o un suo range), l’indirizzo e-mail, il sesso e in più la lista degli amici.
R0F7 Obbligatorio Il sistema deve tenere traccia del numero di utenti che si sono sottoposti ad ogni lista.
R0F8 Obbligatorio L’utente può condividere il risultato ottenu- to dalla compilazione della lista sulla propria bacheca di Facebook.
R0F8.1 Obbligatorio Il post in bacheca deve contenere l’immagine, il risultato della lista e un link per visualiz- zarne il risultato all’interno dell’applicazione.
R1F9 Desiderabile Gli utenti con permessi di amministrazione possono visualizzare la lista di tutti i test ordinata per utilizzo.
R1F9.1 Desiderabile Per ogni lista sono disponibili le statistiche del tasso di abbandono e la lista di utenti che l’hanno compilata.
R2D14 Opzionale Il sistema prevede un pannello di configu- razione accessibile al di fuori di Facebook tramite autenticazione.
Tabella 3.1: Tabella requisiti funzionali
3.2.2 Requisiti qualitativi
Nessun requisito qualitativo è stato individuato.
3.2.3 Requisiti dichiarativi
Requisito Rilevanza Descrizione
R0D10 Obbligatorio L’applicazione sarà in lingua inglese.
R0D11 Obbligatorio L’applicazione deve essere integrata in Face- book, quindi sfruttare le API che il social net- work mette a disposizione e sarà visualizzata all’interno del Canvas Frame di Facebook.
R0D12 Obbligatorio La parte server side dell’applicazione deve essere sviluppata utilizzando il framework Laravel 5.0 ed il linguaggio PHP 5.4.
R0D13 Obbligatorio L’interfaccia web deve utilizzare le tecnologie HTML5, CSS3 e Javascript.
Tabella 3.2: Tabella requisiti dichiarativi
3.3 Resoconto
In totale sono stati individuati 32 requisiti suddivisi tra tipologia e rilevanza nel modo seguente:
Figura 3.6: suddivisione requisiti per tipologia Figura 3.7: suddivisione requisiti per rilevanza
Capitolo 4
Progettazione
Il capitolo presenta le tecnologie utilizzate per lo sviluppo dell’applicazione ed il riepi- logo della progettazione dell’architettura generale.
4.1 Dominio applicativo
In questa sezione vengono presentate le tecnologie utilizzate per lo sviluppo dell’ap- plicazione. Il linguaggio utilizzato per il progetto è PHP, in particolare la versione 5.5, ampiamente utilizzato durante il corso di studi, anche se mai utilizzato nella programmazione ad oggetti, era abbastanza conosciuto.
Framework Laravel
L’applicazione è stata sviluppata utilizzando Laravel versione 5.0, un framework svi- luppato in linguaggio PHP. L’utilizzo di questo framework è stato consigliato da parte dell’azienda e ben si adattava alla natura del progetto proposto di applicazione web ad elevata dinamicità.
Lo strumento era totalmente sconosciuto, ma lo studente aveva già avuto modo di lavorare con un framework PHP durante il corso di Ingegneria del Software, dunque lo studio è stato meno impegnativo.
Figura 4.1: Design pattern MVC
15
MySQL
Per la gestione dei dati consistenti dell’applicazione il proponente ha imposto l’utilizzo di un database di tipo MySQL che si interfaccia con il modulo Eloquent ORM di Laravel. La tecnologia era già ben conosciuta da parte dello studente, grazie a quanto appreso durante il corso di studi.
Figura 4.2: logo MySQL
Facebook API
L’integrazione dell’applicazione avviene tramite le API ufficiali di Facebook, le quali, essendo mal documentate, hanno costretto la perdita di alcune ore di studio aggiuntive, per testare e capire al meglio il loro funzionamento.
Figura 4.3: logo facebook API
Bootstrap
Prima di progettare l’interfaccia grafica dell’applicazione è stato necessario decidere, dopo aver scartato l’idea di scrivere a mano tutto il codice CSS, quale framework utilizzare per velocizzare l’attività di sviluppo del front-end. Come consigliato anche dalla comunity di Laravel, l’attenzione è ricaduta sul framework Bootstrap, il quale ha facilitato la creazione di un interfaccia responsive e accessibile. Per il progetto è stata utilizzata la versione 3 del suddetto framework, l’ultima disponibile al momento dello scelta.
4.2. ARCHITETTURA GENERALE 17
Figura 4.4: logo Bootstrap
Javascript
Linguaggio già ben noto grazie al corso di studi, Javascript è stato utilizzato in particolare per alleggerire il carico del server nella paginazione e nella compilazione dei form, sfruttando la tecnologia Ajax e le librerie JQuery.
Figura 4.5: logo Javascript Figura 4.6: logo Ajax Figura 4.7: logo jQuery
4.2 Architettura generale
Nel progettare l’architettura software si è seguito un approccio di tipo top-down, de- scrivendo in un primo momento le componenti ad un alto livello di astrazione, per poi scendere nel dettaglio. Il framework Laravel possiede una propria architettura strut- turata secondo il design pattern MVC e questo a forzato l’utilizzo dello stesso anche nella modellazione dell’architettura dell’applicazione. Le principali conponenti ad alto livello sono:
• Model: contenente le classi che rappresentano rispettivamente le tabelle all’in- terno del database, mappate dalle librerie di Eloquent ORM;
• View: insieme di file contenenti codice HTML e Template Blade che rappre- sentano le pagine visualizzate all’utente;
• Controller: classi contenenti la logica dell’applicazione.
4.3 Progettazione del Model
Per la progettazione del Model si sono identificate le entità che contenessero i dati dell’applicazione nelle seguenti:
• FacebookUser: che rappresenta il singolo utente registrato all’interno del social network Facebook che utilizza l’applicazione;
• List: entità rappresentate la lista compilabile dagli utenti che contiene una serie di elementi selezionabili;
• ListElement: elemento di una lista;
• FacebbokUserList: rappresenta il risultato ottenuto da un utente dopo aver compilato una lista.
• Gui: modulo contenente le configurazioni riguardanti la grafica dell’applicazione, come ad esempio il numero di elementi per pagina durante la fruizione di una lista.
La componente FacebookUserList del Model, come si potrebbe pensare, sembrereb- be non aggiungere nulla in più rispetto ad una relazione molti a molti fra FacebookUser e ListElement. Ma come espressamente richiesto dal proponente dell’azienda, si vuole mantenere il risultato, ottenuto dalla compilazione di una lista, salvato nel database senza doverlo ogni volta calcolare per questioni di efficienza.
Dunque a discapito di una buona architettura si è scelto di aggiungere una classe in più al Model, contenete queste informazioni.
In figura4.8 sono rappresentate le componenti del Model e le rispettive relazioni.
Figura 4.8: Diagramma dell’architettura del model in Eloquent ORM
4.3. PROGETTAZIONE DEL MODEL 19
4.3.1 Progettazione del Database
Viene ora presentata la struttura del database che mantiene la persistenza dei dati dell’applicazione. Ogni componente del Model è stata tradotta in una tabella all’interno del database e le relazioni molti a molti ( in questo caso una soltatnto) sono state implementate aggiungendo una tabella ulteriore contenente le chiavi primarie delle due tabelle facenti parte della relazione.
Il database è stato creato con lo Schema Builder di Laravel, che fornisce un mo- do molto comodo di creare, modificare ed eliminare le tabelle del proprio database, indipendentemente dal sistema usato. Laravel inoltre mette a disposizione una sorta di version control del database detto Migration. Esso, tramite comandi da terminale, permette di avviare delle procedure definite utilizzando lo Schema Builder, per creare o modificare il database molto agevolmente.
Si riporta un esempio di migration, utilizzata per la creazione della tabella FacebookUser, dove si può vedere come con la sola invocazione di due metodi statici della classe Schema, è possibile creare le tabelle all’interno del database, indipendentemente dalla tecnologia utilizzata.
1 class CreateFacebookUsersTable extends Migration {
2 /* *
3 * Run the m i g r a t i o n s .
4 *
5 * @ r e t u r n v o i d
6 */
7 public function up ()
8 {
9 Schema :: create (' facebook_users ', function( Blueprint $ table)
10 {
11 $table-> increments ('id ');
12 $table-> bigInteger (' facebook_id ') -> unsigned () -> unique ();
13 $table-> string ('name ');
14 $table-> string (' first_name ');
15 $table-> string ('link ');
16 $table-> string ('locale ');
17 $table-> string ('email ');
18 $table-> string ('gender ');
19 $table-> integer ('admin ') ->default(0);
20 $table-> boolean (' has_created ');
21 $table-> timestamps ();
22 });
23 }
24
25 /* *
26 * R e v e r s e the m i g r a t i o n s .
27 *
28 * @ r e t u r n v o i d
29 */
30 public function down ()
31 {
32 Schema :: drop (' facebook_users ');
33 }
34 }
Codice 4.1: classe migration per la creazione della tabella facebook_users
Di seguito viene mostrato lo schema del database così ottenuto.
Figura 4.9: Diagramma dell’architettura del database
4.4. PROGETTAZIONE DEL CONTROLLER 21
4.4 Progettazione del Controller
Dopo aver definito le componenti del Model si è potuto procedere con la definizione dell’architettura del controller.
4.4.1 Routing
In Laravel le richieste HTTP che provengono dall’esterno, vengono gestite e instradate attraverso un sistema di routing. Esso permette di rispondere alle richieste esterne dell’utente con la pagina WEB corretta. Consente infatti di definire il comportamen- to dell’applicazione che si sta sviluppando, semplicemente associando una URI (cioè un indirizzo Web, un file, un servizio, ecc.) ad una determinata funzione o Closure, all’interno della quale lo sviluppatore inserisce l’azione corrisponde.
Un esempio di route in Laravel che visualizza la stringa “Hello world” alla richiesta dell’utente della URL base del sito:
1 Route :: get ('/', function() 2 {
3 return 'Hello ␣ World ';
4 });
Codice 4.2: esempio di route
Una possibilità è quella di inserire tutta la logica dell’applicazione all’interno del file route.php (contente le rotte) oppure di suddividerla utilizzando i controller. Essi sono delle classi messe a disposizione dal framework, per strutturare al meglio il compor- tamento del sito e, in caso di applicazione molto elaborata, permettere di creare una buona architettura della logica.
Nell’applicazione sviluppata è stato gestito a livello di routing solamente l’instrada- mento delle richieste ai vari controller, che si occuperanno di gestire il comportamento generale del sito. Questo ha permesso progettare una gerarchia di classi controller in modo da suddividere la logica del sito per macro-funzionalità e rendere il codice più mantenibile.
4.4.2 Architettura del Controller
Nella progettazione dell’architettura del controller si è cercato di creare un compo- nente per ogni funzionalità offerta dall’applicazione. Innanzi tutto una super classe MainController, che eredita dalla classe Controller di Laravel, contiene il controllo dell’autenticazione con il social network Facebook; da essa ereditano le seguenti classi:
• HomeController: si occupa della gestione della homepage e della visualizzazione della pagina dei risultati ottenuti da un amico dell’utente (cioè la pagina che verrà visualizzata nel momento in cui un utente clicca su un link all’interno della propria bacheca);
• ListCreationController: contiene le funzioni che permettono la creazione di nuove liste e la loro gestione (modifica e cancellazione);
• ListDrwaingUpController: controller che si occupa della compilazione delle liste da parte degli utenti e della visualizzazione del risultato prima della condivisione in bacheca.
Si riporta la gerarchia appena esposta:
Figura 4.10: Diagramma dell’architettura del Controller
4.4. PROGETTAZIONE DEL CONTROLLER 23
4.4.3 FacebookSDK
L’applicazione web sviluppata doveva essere inserita all’interno del Canvas Frame di Facebook e dunque necessitava di interfacciarsi con esso attraverso le API che espone.
Il problema nasce da come queste API cambino anche a distanza di pochi mesi. Per questo si è pensato di creare una classe FacadeFacebookSDK che, sfruttando il Design Pattern Facade, esponesse all’applicazione alcuni metodi necessari al suo funziona- mento, nascondendo al suo interno le chiamate ai metodi effettivi delle Facebook API.
E stato garantito così un basso accoppiamento e un codice più pulito.
4.4.4 Middleware
Una novità introdotta in Laravel dalla versione 5.0 sono i middleware, un meccanismo creato per il filtraggio delle richieste HTTP. Ad esempio vengono utilizzati per il con- trollo dell’autenticazione dell’utente che, in caso non fosse correttamente autenticato, verrebbe reindirizzato alla pagina di login. Questo meccanismo permette di eseguire questo controllo alla richiesta di ogni pagina prima ancora di eseguire la corrispondente funzione del controller e quindi di non eseguire il controllo direttamente nel codice di quest’ultimo.
Nel caso specifico dell’applicazione è stato creato un middleware FacebookCheck che controlla la corretta autenticazione dell’utente all’interno del social network. Facebook- Check in caso di errore reindirizzerà l’utente all’interno del Canvas Frame di Facebook.
Infatti poiché l’applicazione è stata pensata per funzionare solamente all’interno del Canvas Frame di Facebook, la mancata autenticazione indicherà una situazione di errore o di accesso esterno dall’esterno del social network.
1 class AgeMiddleware {
2 public function handle ($ request, Closure $ next)
3 {
4 if ($ request-> input ('age ') < 20)
5 {
6 return redirect ('home ');
7 }
8 return $ next($ request);
9 }
10 } 11
12 class MainController extends Controller { 13
14 /* *
15 * M a i n C o n t r o l l e r i n s t a n c e .
16 */
17 public function __construct ()
18 {
19 $this-> middleware (' ageMiddleware ');
20 }
21 }
Codice 4.3: esempio di Middleware
Nell’esempio si può vedere come nella prima classe viene definito un middleware, che nel caso in cui il parametro “age” fosse inferiore a 20, reindirizza la richiesta alla pagina “home”, altrimenti permette alla richiesta di proseguire. Per associare questo
middleware al controller MainController basta richiamare all’interno del costruttore di quest’ultimo il metodo middleware passando come unico parametro il nome del middleware appena creato.
4.5 Progettazione delle View
Per la creazione delle viste, Laravel include out of the box Blade. Esso è un template engine molto semplice ma anche molto potente, che permette la creazione di template che ne estendono altri, così da rendere il codice più pulito, mantenibile e riutilizzabile.
Nonostante le sue svariate funzionalità, Blade non impedisce l’utilizzo di PHP vero e proprio nel codice. Tutte le view vengono compilate e messe in cache per poi essere ri-compilate in caso di modifiche, il che garantisce un overhead di Blade praticamen- te prossimo allo zero. Tutti i file per essere riconosciuti da Blade devono avere un estensione del tipo file.blade.php.
Nella figura4.11 è possibile vedere la struttura dell’architettura generale delle view.
Package layout
Questo package raggruppa tutti i template responsabili dell’aspetto grafico, comuni a tutte o più di una pagina del sito:
• main_layout.blade: file contenete la struttura base delle pagine dell’applicati- vo come l’inclusione dei fogli di stile, script Javascript ed il layout della barra superiore;
• top_bar.blade: template contenente il codice per la grafica della top bar del sito;
• friend_layout.blade: questo file viene utilizzato da results.blade per visua- lizzare, sotto ai risultati dell’utente della lista appena compilata, gli esiti della stessa di alcuni amici dell’utente stesso;
• other_lists.blade: come per il precedente template, viene utilizzato da results.blade per proporre all’utente altre liste a cui sottoporsi;
• footer.blade: file contenente il layout della barra inferiore di ogni pagina.
Package list_drawing_up_views
In questo package sono racchiusi i template delle pagine riguardanti la compilazione di una lista, cioè dunque l’atto dell’utente di selezione degli elementi in essa contenuti e la conseguente visualizzazione del risultato ottenuto:
• drawing_up.blade: template della pagina di selezione degli elementi di una determinata lista;
• results.blade: pagina di visualizzazione del risultato aggregato dopo la com- pilazione di una lista (viene utilizzato questo template anche per visualizzare il risultato di un amico);
4.5. PROGETTAZIONE DELLE VIEW 25
Figura 4.11: Diagramma dell’architettura delle View
• details.blade: pagina che mostra in dettaglio gli elementi che l’utente ha selezionato (viene utilizzato questo template anche per visualizzare il risultato dettagliata di un amico);
• all_list _results.blade: template per mostrare tutte le liste a cui l’utente si è sottoposto e il relativo risultato.
Package list_creation_views
La grafica della funzionalità di creazione e gestione delle liste è contenuta in questo package così strutturato:
• manage.blade: template della pagina di gestione delle liste, e dunque di visualiz- zazione dell’elenco delle liste, create dall’utente autenticato, con le relative stati- stiche (nel caso di un utente con privilegi di amministratore, verranno visualizzate tutte le liste presenti nella piattaforma).
• create.blade: pagina che offre all’utente una procedura di creazione di una nuova lista;
• update.blade: permette all’utente autenticato la modifica di una lista creata dallo stesso;
• show.blade: visualizza un’anteprima della lista selezionata;
• show_items.blade: pagina di visualizzazione degli elementi che compongono la lista che l’utente sta visualizzando.
Infine, al di fuori dei package appena elencati, vi sono due classi template: una index.blade che si occupa della visualizzazione della homepage dell’applicazione web, visualizzando un insieme di liste da proporre all’utente, secondo una logica selezionabile nella configurazione; la seconda facebook_authentication.blade contiene uno script Javascript, responsabile della comparsa del pop-up di Facebook, con il quale l’utente accetta l’invio delle proprie informazioni all’applicazione.
4.6 Diagrammi delle attività
I diagrammi delle attività illustrati di seguito, descrivono le interazioni tra l’utente ed l’applicazione. Essi sono stati definiti durante le attività di progettazione dell’archi- tettura, per mostrare che il prodotto integrasse tutte le funzionalità richieste.
4.6.1 Attività principale
Una volta aperta l’applicazione l’utente visualizza l’homepage dalla quale ha la possi- bilità di:
• scegliere una lista e iniziare di conseguenza la sua compilazione;
• visualizzare tutti i propri risultati ottenuti da precedenti compilazioni;
4.6. DIAGRAMMI DELLE ATTIVITÀ 27
Figura 4.12: Diagramma delle attività - Attività principale
• gestire le proprie liste;
• tornare alla homepage mentre sta visualizzando altre pagine.
4.6.2 Compilazione di una lista
Figura 4.13: Diagramma delle attività - Compilazione di una lista
Dopo che l’utente ha scelto di compilare una lista e cioè scegliere quali elementi selezionare all’interno di essa può:
• visualizzare gli elementi in gruppi di 10 e selezionarne alcuni, tutti o nessuno;
4.6. DIAGRAMMI DELLE ATTIVITÀ 29
• visualizzare il risultato sintetico (del tipo “Hai selezionato x elementi su y”) al termine della compilazione;
• decidere ora se:
– selezionare un’altra lista a cui sottoporsi;
– condividere il risultato con un amico;
– visualizzare i propri risultati in maniera dettagliata (cioè quali elementi ha appena selezionato);
– visualizzare il risultato aggregato e dettagliato di un amico che ha compilato la medesima lista.
4.6.3 Gestione liste
Figura 4.14: Diagramma delle attività - Gestione liste
Una volta entrato nella gestione delle proprie liste, l’utente può:
• selezionare una lista e modificarla o, nel caso non avesse concluso la creazione della stessa, riprendere l’operazione da dove aveva abbandonato;
• creare una nuova lista da pubblicare nella piattaforma.
4.6. DIAGRAMMI DELLE ATTIVITÀ 31
4.6.4 Gestione risultati liste
Figura 4.15: Diagramma delle attività - Gestione risultati liste
Nella visualizzazione dei risultati di tutte le liste l’utente ha la possibilità di selezio- nare una determinata lista, ovviamente tra quelle che ha già compilato, e visualizzarne prima il risultato sintetico e successivamente quello dettagliato.
Capitolo 5
Implementazione e testing
In questo capitolo vengono descritte le attività di codifica dell’applicazione, a seguito della terminazione della progettazione architetturale.
5.1 Strumenti
Per implementare questa applicazione web, era necessario scegliere quale IDE utilizzare tra i tanti esistenti. In passato lo studente aveva utilizzato ad esempio NetBeans, poiché uno degli IDE più completi tra quelli free, ma non era stato abbastanza soddisfacente.
L’attenzione è dunque ricaduta su PHPStorm, come consigliato dalla comunity di Laravel, strumento questo specifico per i linguaggi PHP, HTML e Javascript. Consente l’analisi del codice al volo, la prevenzioni degli errori, l’auto-completamento e dispone di molte altre funzionalità interessanti. Unico punto a sfavore è che si tratta di un software a pagamento, ma per fortuna è possibile ottenere una licenza free limitata per gli studenti.
La versione utilizzata durante lo stage è PHPStorm 8.0.3.
Figura 5.1: logo di PHPStorm
5.2 Implementazione del backend
A seguito della progettazione si è passati all’implementazione vera e propria del bac- kend, iniziando dall’integrazione con Facebook.
5.2.1 Autenticazione con Facebook
Il Canvas Frame di Facebook altro non è che un iframe all’interno del quale viene visualizzata la propria applicazione. Esso però non si limita ad aprire la homepage del sito, ma invia una richiesta HTTP POST contenente la Signed Request. Essa, senza
33
entrare troppo nel dettaglio, consiste in una stringa, nella quale sono codificate una serie di informazioni per identificare l’utente attualmente autenticato, e un token che identifica la sessione all’interno del browser. Sfruttando però le librerie PHP SDK non è necessario conoscere in dettaglio il funzionamento della Signed Request, poichè queste librerie mettono a disposizione già dei metodi per dialogare con Facebook.
Si riporta un esempio di funzione per la creazione della sessione sfruttando la Signed Request inviata dal Canvas Frame:
1 public static function createFacebookSessionFromCanvas () { 2 $ helper = new FacebookCanvasLoginHelper ();
3 try {
4 $ facebookSession = $ helper-> getSession ();
5 } catch ( FacebookRequestException $ex) { 6 // W h e n F a c e b o o k r e t u r n s an e r r o r 7 echo $ex-> getMessage ();
8 return false ;
9 } catch (\ Exception $ex) {
10 // W h e n v a l i d a t i o n f a i l s or o t h e r l o c a l i s s u e s 11 echo $ex-> getMessage ();
12 return false ;
13 }
14 if(isset($ facebookSession)) {
15 // u s e r is l o g g e d in
16 }
17 // F a c e b o o k S e s s i o n is not v a l i d 18 return false ;
19 }
Codice 5.1: funzione di recupero sessione dal Canvas
Questa funzione restituisce un oggetto Facebook Session, necessario poi per richieste al social network, come ad esempio ottenere il profilo dell’utente o la lista dei suoi amici. In caso di errore vengono sollevate delle eccezioni.
L’estratto di codice seguente invece, a partire dall’oggetto sessione ottenuto dalla funzione soprastante, invia una richiesta al social network restituendo le informazioni dell’utente autenticato:
1 if(isset($ facebookSession)) {
2 $ requestU = new FacebookRequest (
3 $ facebookSession,
4 'GET ',
5 '/me '
6 );
7 try {
8 $ response = $ requestU-> execute ();
9 } catch ( FacebookAuthorizationException $ex) {
10 Self ::$ fb_Session = null ;
11 echo $ex-> getMessage ();
12 return null ;
13 }
14 $ userInfo = $ response-> getGraphObject ();
15 return $ userInfo;
16 }
17 else
18 return null ;
Codice 5.2: estratto richiesta informazioni utente da Facebook
5.2. IMPLEMENTAZIONE DEL BACKEND 35
Queste sono solo alcuni esempi di funzioni che sono state utilizzate per creare la clas- se FacaceFacebookSDK, la quale espone una interfaccia al resto dell’applicazione che permette di:
• creare la sessione Facebook a partire dalla Signed Request;
• controllare che la sessione sia ancora valida, che per questioni di sicurezza ha una durata limitata);
• ottenere le informazioni le informazioni dell’utente restituendo un oggetto FacebookUser, proprietario dell’applicazione;
• ottenere la lista degli amici dell’utente;
All’atto pratico ogni qual volta una pagina viene richiesta, il middleware
CheckFBAuthentication sfrutta i metodi esposti da FacaceFacebookSDK, per con- trollare che l’autenticazione sia andata a buon fine e permette alla richiesta di essere soddisfatta dal controller competente.
5.2.2 Model
Ogni model precedentemente progettato, per funzionare in Laravel, non necessita di al- cun metodo al suo interno. Infatti Eloquent ORM rende disponibili moltissime funzioni per operare con i dati contenuti nel database, dove ogni riga della tabella è rappresenta- ta da un oggetto e ogni colonna da un attributo. È possibile per esempio con il metodo all applicato sul model, ottenere una lista di oggetti che rappresentano i dati conte- nuti nella tabella. Eloquent ORM permette però di definire dei Query Scope statici o dinamici, per definire dei set comuni di condizioni, da poter riutilizzare successivamen- te nell’applicazione. Ad esempio, per recuperare i risultati di una specifica lista degli amici dell’utente autenticato, è stato definito il seguente Quesry Scope dinamico che, data in input la lista degli ID degli amici e l’ID di una lista, restituisce una tabella che associa utente amico e risultato.
1 public function scopeFriendResults ($query, $ friends, $ list_id) { 2 return $query-> whereIn (' facebook_id ', $ friends)
3 ->join (' facebook_user_lists ', 'user_id ', '=', 'id ') 4 ->where ('list_id ', '=', $ list_id)
5 -> orderBy ('result ', 'desc ');
6 }
Codice 5.3: query scope per ottenere i sisultati degli amici di una lista specifica Queste, insieme ad altre funzioni molto più banali, come per esempio controllare se l’utente è amministratore o una lista è stata pubblicata, hanno permesso poi una più agevole implementazione dei controller, evitando di inserire query all’interno di essi.
5.2.3 Controller
Il passo successivo allo sviluppo del model, è stata l’implementazione della gerarchia dei controller precedentemente progettata. Ogni controller è stato reso accessibile creando tre differenti rotte:
• /list_creation: per accedere alle pagine di creazione delle liste;
• /drawing_up: per accedere alle funzionalità di fruizione delle liste nell’applica- zione web;
• /: rootpath per la homepage e le pagine dei risultati degli amici.
Dopodiché per ognuno dei controller, osservabili in figura 4.10, sono state codificate le funzioni per rispondere alle possibili richieste provenienti dall’utente, attraverso l’inter- faccia grafica. In particolare in MainController, troviamo, all’interno del costruttore della classe, l’associazione al middleware FacebookCheck in modo che venga ereditato da tutta la gerarchia di classi sottostante.
Ogni funzione implementata all’interno di un controller in Laravel deve avere la seguente forma:
1 /* *
2 * R e s p o n d s to r e q u e s t s to GET / s h o w /1
3 */
4 public function getShow ($id)
5 {
6 //
7 }
Codice 5.4: esempio di funzione di un controller
La funzione getShow() dell’esempio, viene eseguita quando l’applicazione riceve una richiesta HTTP GET sulla URL /show, mentre la stessa funzione con parametri, ri- spenderà alla medesima richiesta, arricchita dallo stesso numero di parametri separati da uno “/”; Nell’esempio soprastante è presente un solo parametro id.
Si riporta ora una delle funzioni implementata all’interno del controller ListCreationController:
1 /* *
2 * D i s p l a y the s p e c i f i e d l i s t .
3 *
4 * @ p a r a m int $id 5 * @ r e t u r n R e s p o n s e 6 */
7 public function anyShow ($id) {
8 $ user = $this-> facadeFB -> getUser ();
9 $list = List:: find ($id);
10 $ elements = $list->elements() ->get ();
11 return view (" list_creation_views . show ", ['user ' => $user, 'list '
=> $list, 'elements ' => $ elements]);
12 }
Codice 5.5: funzione per visualizzare una specifica lista
Nel codice sopra, la funzione anyShow($id) permette di far visualizzare la lista con numero identificativo (ID) specificato nella URL. Viene innanzitutto recuperato l’u- tente autenticato attraverso la FacadeFacebookSDK (ogni controller ne possiede un puntatore), viene poi recuperata la lista dal database, corrispondente all’ID specificato e successivamente recuperati anche tutti i suoi elementi, con il metodo elements() (implementato nel model List). Nell’ultima istruzione il metodo view (un cosiddet- to helper di Laravel) crea la vista show, del package list_creation_views, con gli opportuni parametri, che specificano l’utente, la lista e gli elementi da visualizzare.
5.2. IMPLEMENTAZIONE DEL BACKEND 37
Ajax
Per garantire un’esperienza migliore all’utente nella fruizione dell’applicazione web, sono state implementate alcune azioni di gestione delle liste, come ad esempio la can- cellazione, fruttando Ajax. In Laravel l’utilizzo di Ajax è molto immediato, infatti la firma delle funzioni in un controller non cambia, sarà il framework ad occuparsi di tutto; unica differenza sta nel tipo di risposta data dalla funzione, che dovrà essere in formato json invece di produrre una nuova pagina web.
1 /* *
2 * A j a x f u n c t i o n e x a m p l e
3 *
4 * @ p a r a m int $id 5 * @ r e t u r n R e s p o n s e 6 */
7 public function ajaxRequest ($id) { 8
9 // do s o m e t h i n g
10
11 return responce () ->json (['state ' => 'success ']);
12 }
Codice 5.6: funzione per visualizzare una specifica lista
Nel caso Javascript non funzionasse a dovere o fosse disattivato, renderebbe impos- sibile eseguire le operazioni di gestione delle liste, rese disponibili tramite Ajax. Si è dunque prevista nell’interfaccia Web e nei controller, la gestione delle sopracitate funzionalità anche attraverso classiche richieste HTTP, permettendo così un degrado elegante senza compromettere accessibilità e usabilità dell’applicazione.
5.3 Implementazione dell’interfaccia
La realizzazione delle interfacce dell’applicazione è avvenuta utilizzando Blade, il tem- plate engine di Laravel. Il linguaggio utilizzato per la codifica delle pagine è HTML 5, supportato graficamente da una Bootstrap 3 e con fogli di stile scritti nello standard CSS3.
Blade
La creazione di template in Blade è molto semplice e sfrutta una serie di keywords messe a disposizione dal template engine. Un esempio di template base è il seguente:
1 <!-- file resources / views / layouts / master . blade . php -->
2 <html >
3 <head >
4 <title > App Name - @yield ('title ') </title >
5 </head >
6 <body >
7 @section ('sidebar ')
8 Master sidebar .
9 @endsection
10
11 <div class=" container ">
12 @yield ('content ')
13 </div >
14 </body >
15 </html >
Codice 5.7: esempio di template base in Blame
In questo modo è possibile definire l’intelaiatura base della pagine, la quale è facil- mente estendibile per creare poi vere e proprie pagine, che dovranno solamente definire il loro contenuto specifico. La keyword @section definisce una sezione con dei conte- nuti specifici che potrà essere estesa o ridefinita, mentre la keyword @yield funge da segnaposto per contenuti che verranno aggiunti successivamente (da pagine derivanti da questa “base”).
Una possibile estensione del template base ad esempio può essere la seguente:
1 @extends ('layouts . master ') 2
3 @section ('sidebar ')
4 @parent
5 <p> appended to the master sidebar </p>
6 @stop 7
8 @section ('content ') 9 <p> Page content .</p>
10 @stop
Codice 5.8: possibile estensione del template base
Nell’esempio viene esteso il template prima indicato, al quale viene aggiunto del contenuto alla sezione sidebar e definito il corpo della pagina finale.
5.3. IMPLEMENTAZIONE DELL’INTERFACCIA 39
Javascript
Per lo sviluppo dell’applicativo è stato necessario un cospicuo utilizzo di script Java- sript sviluppati appositamente, in particolare per rendere la paginazione client-side.
Inizialmente si sono cercate delle soluzioni prefabbricate, ma esse non rispondevano a pieno alle esigenze richieste. Perciò si è deciso di sviluppare un plugin autonomamente chiamato pagination.js.
Per implementare questo plugin si è scelto di sfruttare la tecnica dei prototipi per mantenere il codice più pulito.
In Javascript ciascuna classe presenta al suo interno una proprietà, chiamata appun- to prototype, che presenta un “meta oggetto”. Qualsiasi oggetto facente capo a questa classe, sarà istanziato esattamente come una copia di questo prototipo. Modificando questa meta classe, sarà possibile influenzare direttamente tutti i precedenti oggetti creati a partire da questa classe, anche a runtime.
Dunque è possibile definire una classe con il solo costruttore che imposta gli attributi della classe, e successivamente aggiungere al prototipo i metodi della stessa, rendendo più leggibile e mantenibile il codice.
Si presenta ora un estratto dallo script pagination.js:
1 function Pagination ( perPage , form_control , back_action , validation_func ) { 2 this . itemPerPage = perPage ;
3 this . form_control = form_control ; 4 this . back_action = back_action ;
5 this . validation_func = validation_func ; 6 }
7
8 Pagination . prototype . _showPage = function (i) { 9 this . items . hide ();
10 this . items . removeClass ('hidden ');
11 var startIndex = 0;
12 var endIndex = 0;
13 if ( this . activePage == 1) {
14 startIndex = 0;
15 endIndex = this . itemPerPage ;
16 }
17 else {
18 startIndex = this . itemPerPage * ( this . activePage - 1);
19 endIndex = this . itemPerPage * ( this . activePage );
20 }
21 var showItems = this . items . slice ( startIndex , endIndex );
22 showItems . fadeIn ();
23 };
24 [...]
Codice 5.9: estratto di pagination.js
Nel codice sopra troviamo il costruttore della classe Pagination che riceve come attributi: il numero di elementi per ogni pagina, un boleano che indica se attivare la funzionalità di form, la funzione da eseguire con il pulsante back e la funzione di validazione dei dati nel caso si tratti di un form. Questo script di paginazione infatti permette di paginare semplici liste di elementi o anche dei form, entrambe funzionalità ricercate per la realizzazione dell’applicazione.
Sotto il costruttore troviamo come, grazie al prototype, è possibile aggiungere il metodo showPage (in questo caso metodo privato) alla classe Pagination.
L’utilizzo del suddetto plugin è molto semplice, basta istanziare un nuovo oggetto Pagination passando al costruttore le configurazioni desiderate e utilizzare i metodi createNav() e activatePage(); rispettivamente per creare il menù di paginazione e attivare la prima pagina. Unici vincoli sono la presenza, nella pagina da paginare, di un div con attributo id=item-container contenente gli elementi da paginare e un ul con id=pagination che conterrà il menù creato dal plugin.
1 function goBack () {
2 $('#list - info ').toggleClass('hidden ', 'true ');
3 $('#item - list ').toggleClass('hidden ', 'false ');
4 } 5
6 var pag = new Pagination ( du_item_per_page , 1, goBack );
7 pag . createNav ();
8 pag . activatePage (1);
Codice 5.10: utilizzo di pagination in drawing_up.js
5.3.1 Autenticazione
Non appena un nuovo utente tenti di utilizzare l’applicazione verrà mostrato il pop- up in figura 5.2, con il quale si acconsente l’invio delle proprie informazioni ad essa.
In particolare verrà richiesto l’accesso al profilo pubblico, all’indirizzo email e alla lista degli amici. L’utente può eventualmente negare l’accesso a queste due ultime, compromettendo però la fruizione alla funzionalità di vedere i risultati degli amici che hanno compilato le sue stesse liste.
5.3. IMPLEMENTAZIONE DELL’INTERFACCIA 41
Figura 5.2: pop-up di richiesta permessi Facebbok
5.3.2 Homepage
L’homepage propone all’utente un elenco delle liste più popolari e alcune nuove, scelte casualmente tra le liste appena create, per dare visibilità anche ad esse. Ogni pagina dell’applicazione è costituita da una barra superiore, un titolo e il contenuto della pa- gina. La barra superiore contiene a sua volta le breadcrumb, che permettono all’utente di orientarsi all’interno del sito, un pulsante per entrare nell’area risultati e un pulsante per la creazione di nuove liste. Quest’ultimo pulsante è stato creato appositamente di un colore vivace, per attirare l’attenzione e invogliare l’utente a inserire una propria lista all’interno del sistema. Dal momento in cui l’utente avesse già creato almeno una lista, il pulsante permetterà di accedere alla gestione delle liste create.
Figura 5.3: homepage
5.3. IMPLEMENTAZIONE DELL’INTERFACCIA 43
5.3.3 Compilazione Lista
La compilazione di una lista, si presenta inizialmente mostrando l’immagine ed una breve descrizione associata; mentre, dopo la pressione del pulsante Start, come una lista di elementi che l’utente può selezionare. Terminata la selezione l’utente verrà indirizzato in una pagina, che riepilogherà il risultato ottenuto e ne permetterà la con- divisione sulla propria bacheca. In quest’ultima pagina, nella parte inferiore, l’utente potrà vedere i risultati ottenuti dai propri amici in quella stessa lista ed eventualmente, cliccandoci, visualizzarne i dettagli (cioè quali elementi ha effettivamente scelto della lista).
Figura 5.4: pagina di compilazione di una lista
Figura 5.5: pagina di compilazione di una lista - selezione elementi
5.3. IMPLEMENTAZIONE DELL’INTERFACCIA 45
5.3.4 Creazione e gestione delle liste Creazione di liste
Per quanto concerne la funzionalità di creazione, è stato implementato una sorta di wizard che guida l’utente nel formare una nuova lista. L’utente dovrà inizialmente inserire:
• un titolo [obbligatorio];
• un’immagine [obbligatoria];
• scegliere la lingua;
• un nome dell’elemento singolo [obbligatorio] (es. città, libro, film...);
• una breve descrizione.
Successivamente l’utente dovrà inserire gli elementi costituenti la lista, per un massimo di 6 per pagina; in altre parole dopo averne inseriti 6, premendo il tasto next, se ne potranno inserire altri 6 e così via. (N.B.: per ogni pagina è possibile lasciare gli ultimi elementi vuoti se l’utente volesse inserire un numero di voci non divisibili per 6).
Come è evidente in figura5.6, se l’utente dovesse non completare tutti i campi obbli- gatori o inserire informazioni errate (es. immagine troppo grande, titolo troppo lungo, ecc.), dei controlli, prima sfruttando Javascript e poi lato server, faranno comparire dei messaggi di errore notificando l’utente di controllare quanto inserito.
Figura 5.6: pagina di creazione di una liste
5.3. IMPLEMENTAZIONE DELL’INTERFACCIA 47
Gestione delle liste
La pagina di gestione delle liste create sarà accessibile dall’utente autenticato, solamen- te se possieda almeno una propria lista. Essa presenta una tabella in cui sono elencati i titoli, il numero di fruizioni ed alcune azioni applicabili a tutte le liste possedute. Da questa pagine è altresì possibile creare una nuova lista.
Le azioni disponibili sono la visione, l’eliminazione, la modifica e la pubblicazione;
queste ultime sono applicabili solamente a liste in stato di bozza e non ancora rese pubbliche.
Figura 5.7: pagina di gestione delle liste create
5.4 Metriche di progettazione e codifica
Per garantire un prodotto di qualità sono state definite alcune metriche con le quali è stato valutato il software. Vengono ora riportate tali metriche.
Complessità Ciclomatica
La complessità ciclomatica rappresenta il numero di cammini linearmente indi- pendenti attraverso una sezione di codice. Alti valori di complessità ciclomati- ca implicano una ridotta manutenibilità del codice. Valori bassi di complessità potrebbero determinare scarsa efficienza dei metodi.
• intervallo accettato: 1-15;
• intervallo ottimale: 1-10.
Copertura del codice
Percentuale di istruzioni che sono eseguite durante i test. Al crescere della per- centuale di istruzioni coperte dai test eseguiti aumenta la probabilità che le componenti testate abbiano una ridotta quantità di errori.
• intervallo accettato: 50%-100%;
• intervallo ottimale: 70%-100%.
Linee di codice Al fine di incapsulare al meglio il codice agevolarne la leggibilità, è necessario che i metodi non superino una certa lunghezza in termini di linee di codice.
• massimo accettato: 30;
• valore ottimale: 20.
Linee di codice per linee di commento
Rapporto tra linee di codice e linee di commento. Utile per la leggibilità del codice e successiva manutenzione.
• min accettato: maggiore di 25%.
5.5 Verifica e Validazione
5.5.1 Test di verifica
Durante le attività di codifica sono stati eseguiti numerosi test con lo scopo di ga- rantire la correttezza del codice ed un comportamento dell’applicazione conforme alle aspettative. Gli strumenti utilizzati per questi test sono:
• PHPUnit per l’esecuzione dei test di unità;
• Plugins di PHPStrom: per l’analisi statica del codice;
• Developers tools (Chrome): per il testing degli script Javascript;
5.5. VERIFICA E VALIDAZIONE 49
A seguito dei test si sono ottenute le seguenti misurazioni delle metriche sopra definite:
Complessità Ciclomatica mesito: 5.
Copertura del codice esito: 87%.
Linee di codice
In media i metodi rientrano nei valori ottimali, solamente alcuni superano legger- mente questi valori.
Linee di codice per linee di commento esito: 26%.
Nota: Grazie anche alle funzionalità offerte da PHPStorm, che permette il con- trollo della documentazione del codice, è stata prodotta una buona documenta- zione del prodotto.
Tutti i valori ottenuti sono stati ritenuti soddisfacenti.
5.5.2 Test di validazione
Al termine dello sviluppo dell’applicazione, si è testato quali funzionalità richieste dal proponente il prodotto riuscisse a soddisfare. Il resoconto di tale attività risulta essere il seguente:
• Requisiti obbligatori soddisfatti: 100%;
• Requisiti desiderabili soddisfatti: 33%;
• Requisiti opzionali soddisfatti: 0%.
I requisiti obbligatori estrapolati dall’analisi dei requisiti sono stati completamente implementati e soddisfatti, a discapito però di alcune funzionalità richieste opzional- mente. Queste ultime non erano ritenute di vitale importanza dal proponente, che ha specificamente espresso di concentrasi sui requisiti obbligatori, sviluppandoli nella maniera più accurata possibile.
L’applicazione risulta infatti pienamente funzionante e, con il nome di Social Check, è stata pubblicata online, come applicazione di Facebook, durante gli ultimi giorni di stage presso l’azienda.
Figura 5.8: logo Social Check
