Università degli Studi di Padova Facoltà di Scienze MM.FF.NN. Dipartimento di Matematica pura e applicata Corso di Laurea Triennale in Informatica
Refactoring del software gestionale web-based Infostudenti
Relatore: Ch.mo Professor Paolo Baldan Laureando: Nicola Beghin, matr. 561540 A.A. 2009/2010
Indice
1 Introduzione 7
1.1 Obiettivi ...... 7
1.2 Problematiche ...... 8
2 Analisi dei requisiti 11
2.1 Requisiti di prodotto ...... 11
2.1.1 Segreteria ...... 12
2.1.2 Secondo livello ...... 12
2.1.3 Terzo livello ...... 12
2.1.4 Direttore ...... 13
2.1.5 Docenti ...... 13
2.1.6 Studenti ...... 13
2.1.7 Utenti esterni ...... 13
2.1.8 Amministratore ...... 14
2.1.9 Funzionalità condivise tra gli utenti autenticati ...... 14
2.2 Requisiti di processo ...... 14
2.3 Consuntivo finale ...... 15
3 Specifica tecnica 17
3.1 Architettura MVC ...... 17
3.1.1 Layer MVC implementati in CakePHP ...... 20
3.2 Web application (client-server) ...... 22
3.3 AJAX ...... 23
3 INDICE INDICE
3.4 ORM ...... 25
3.5 Infostudenti ...... 26
3.5.1 Piani di studio ...... 27
3.5.2 Piani di studio consigliati ...... 29
3.5.3 Esami ...... 30
3.5.4 Creazione nuovi utenti ...... 31
3.5.5 Crediti insegnamenti ...... 32
3.5.6 Crediti riga di piano di studi tipo C ...... 33
3.5.7 Crediti riga di piano di studi tipo D ...... 34
4 Definizione di prodotto 37
4.1 Database ...... 37
4.1.1 Modellazione concettuale ...... 37
4.1.2 Specifiche di modellazione relazionale ...... 37
4.1.3 Convenzioni di database del framework CakePHP ...... 42
4.2 Classi Model ...... 45
4.2.1 Application ...... 47
4.2.2 Check ...... 47
4.2.3 Classroom ...... 48
4.2.4 Course ...... 48
4.2.5 CoursesTeaching ...... 48
4.2.6 Exam ...... 48
4.2.7 Examstatus ...... 49
4.2.8 Genre ...... 49
4.2.9 Grant ...... 49
4.2.10 Instrument ...... 49
4.2.11 Log ...... 49
4.2.12 Page ...... 49
4.2.13 Plan ...... 50
4.2.14 Planstatus ...... 50
4.2.15 Preiscription ...... 50
4 INDICE INDICE
4.2.16 Presence ...... 51
4.2.17 Qualification ...... 51
4.2.18 Requirement ...... 51
4.2.19 Role ...... 51
4.2.20 Student ...... 52
4.2.21 Studentstatus ...... 54
4.2.22 Tax ...... 54
4.2.23 Teacher ...... 54
4.2.24 Teaching ...... 54
4.2.25 Teachingstatus ...... 55
4.2.26 TipoCPlan ...... 55
4.2.27 TipoCType ...... 55
4.2.28 TipoDElement ...... 55
4.2.29 TipoDPlan ...... 55
4.2.30 TipoDType ...... 56
4.2.31 TipoDTypology ...... 56
4.2.32 Tipology ...... 56
4.2.33 User ...... 56
4.2.34 Years ...... 57
4.2.35 Classi Behavior ...... 57
4.3 Classi Controller ...... 58
4.3.1 Classi Component ...... 58
4.4 Classi View ...... 60
4.4.1 Helper ...... 60
5 Strumenti utilizzati 63
5.1 PHP Framework ...... 63
5.1.1 Caratteristiche valutate per la scelta ...... 64
5.1.2 CakePHP (v. 1.2.5) ...... 66
5.1.3 Zend Framework (v. 1.9.6) ...... 67
5.1.4 CodeIgniter (v. 1.7.2) ...... 68
5 INDICE INDICE
5.1.5 Ulteriori framework ...... 68
5.2 Database ...... 69
5.2.1 Transazioni ...... 69
5.2.2 ACID ...... 70
5.2.3 Database abstraction layer ...... 71
5.2.4 Comparazione motori di storage MySQL ...... 71
5.2.5 Migrazione dati ...... 73
5.3 Javascript framework ...... 74
5.3.1 Benefici derivanti dall’utilizzo di un framework Javascript ...... 74
5.3.2 jQuery (v. 1.3.2) ...... 75
5.3.3 Prototype (v. 1.6.1) ...... 76
5.3.4 Comparazione performance ...... 76
5.4 Scambio dati asincrono ...... 78
5.4.1 AJAX ed XML ...... 78
5.4.2 AJAJ: AJAX e JSON ...... 78
5.4.3 AJAH: AJAX ed HTML ...... 79
5.5 CSS ...... 80
5.5.1 Blueprint CSS framework (v. 0.9.1) ...... 80
5.5.2 Stampa ...... 81
5.5.3 Validazione W3C ...... 81
5.6 Librerie di esportazione ...... 81
5.6.1 TCPDF (v. 4.8.16) ...... 81
5.6.2 RTF (v. 0.3.0) ...... 81
5.7 Piattaforma di sviluppo ...... 82
5.8 Versionamento ...... 82
5.8.1 Subversion ...... 82
5.9 Verifica e validazione ...... 83
5.9.1 Unit testing (analisi dinamica) ...... 83
5.10 Documentazione ...... 84
6 Conclusioni 85
6 Capitolo 1
Introduzione
1.1 Obiettivi
Lo studente avrà il compito di effettuare il refactoring1 completo di Infostudenti, il software gestionale web-based attualmente in uso al Conservatorio di Musica di Vicenza. Le funziona- lità del software dovranno ricalcare quelle attualmente esistenti ed essere integrate con nuove ed eventuali a seconda di quanto emerso dai colloqui con il personale del Conservatorio.
Infostudenti La prima incarnazione di Infostudenti nasce nel 1995, qualche anno dopo l’approvazione della legge di riforma dei Conservatori, che allineò le istituzioni statali di musica al modello europeo alla stessa maniera di quanto già avvenuto per le università.
Ciò ha significato uno stravolgimento dell’usuale percorso di studi, che è stato suddiviso nell’ormai famoso 3+2, ossia un primo triennio (laurea di I livello) ed un secondo biennio al termine del quale si consegue una laurea specialistica. La prima stesura del software è nata principalmente come ausilio alla compilazione dei piani di studio dei bienni e trienni, il cui laborioso processo di approvazione (cfr. 3.5.1 nella pagina 27) ha reso necessario una qualche via di automatizzazione e controllo dei parametri . A tale principale attività sono poi andate aggiunte tutta una serie di funzioni ausiliari quali la gestione di corsi, insegnamenti, docenti
1Code refactoring is the process of changing a computer program’s internal structure without modifying its external functional behavior or existing functionality, in order to improve internal quality attributes of the software. Reasons include to improve code readability, to simplify code structure, to change code to adhere to a given programming paradigm, to improve maintainability, to improve performance, or to improve extensibility. [1]
7 1.2. PROBLEMATICHE CAPITOLO 1. INTRODUZIONE e studenti. Nelle ultime fasi è stata implementata la gestione degli esami con relativi appelli e voti, potendo così arrivare alla stampa dell’intera carriera scolastica di ciascuno studente.
Si rimanda all’analisi dei requisiti (cfr. 2 nella pagina 11) per una più dettagliata panoramica delle funzionalità di Infostudenti.
1.2 Problematiche
Si riporta una panoramica delle principali problematiche affrontate e le soluzioni adottate per risolverle. Per l’approfondimento di ciascuna soluzione si faccia riferimento alle successive sezioni.
Manutenzione ed ampliamento L’intero sistema è stato progettato senza l’ausilio di alcuna specifica o ben definita architettura software, così che qualsiasi attività di manuten- zione si è dimostrata essere estremamente complicata e prona ad errori (umani e non). Per il medesimo motivo qualsiasi ulteriore ampliamento è difficile da pianificare sia in termini di fattibilità tecnica che di performance ed impatto sulle altre componenti. Molte funzioni sono poi duplicate o frammentate, senza alcuna logica di razionalizzazione del codice. L’utilizzo di un framework rigidamente strutturato secondo una ben definita architettura software ha permesso di standardizzare il codice ed organizzarlo secondo una struttura più razionale.
Controlli di consistenza ed integrità Il software in uso è frutto di svariate modifiche architetturali e funzionali avvenute negli anni conseguenti al primo rilascio. Non avendo mai implementato alcun sistema di mantenimento della consistenza ed integrità dei dati
(nè a livello codice nè a livello database) dopo 4 anni d’uso ci si è trovati di fronte ad un database con un alto grado di inconsistenza dei dati. L’estensivo utilizzo di chiavi esterne con opportune clausole trigger, l’utilizzo delle transazioni SQL, un’attenta tipizzazione dei campi di database e l’implementazione di un meccanismo di ulteriore controllo d’integrità, garantito dal framework stesso, ha permesso di ovviare ai problemi fin qui riportati.
Sicurezza e permessi Non è mai stata posta grande rilevanza alla sicurezza del software, essa intesa sia dal punto di vista della confidenzialità che dell’integrità dei dati. Non esisten-
8 CAPITOLO 1. INTRODUZIONE 1.2. PROBLEMATICHE do alcuna ACL 2 i permessi dei vari ruoli in gioco sono stati gestiti con bassa granularità; non sono inoltre mai state adottate tecniche di data sanitization, ossia di pulizia e controllo dei parametri per evitare vulnerabilità ad attacchi esterni (es. XSS3) o fughe di informa- zione. L’utilizzo di un framework particolarmente attento a tali problematiche, in grado di occuparsene tramite un rigido controllo dei tipi e la sanitizzazione di tutti i dati in entrata e in uscita, ha permesso di ottenere un buon livello di sicurezza; la possibilità poi di dele- gare sempre al framework l’intero processo di autenticazione (cfr. 4.3.1 nella pagina 59) ha consentito di avvalersi di una procedura di login particolarmente solida e valida.
Scarsa usabilità L’impossibilità di strutturare razionalmente il software, frutto di conti- nue modifiche negli anni, ha reso impossibile porre particolare attenzione all’usabilità del software, che prevede logiche di funzionamento controintuitive o contorte o funzionalità fram- mentate in sezioni diverse o inadeguate. L’utilizzo di un layout tabellare ha poi impedito di svincolare i contenuti dalla visualizzazione, impedendo di procedere con un eventuale resty- ling grafico/strutturale. Grazie all’estensivo uso di Javascript e tecnologie di caricamento asincrono si è ovviato alla macchinosità di molte azioni, che ora possono essere portate a termine in una maniera più simile alle tradizionali applicazioni desktop-based; si è poi pro- ceduto con una generale rivisitazione delle funzionalità di ciascuna sezione, semplificando alcune procedure e minimizzando il numero di quelle restanti tramite una generale integra- zione di funzioni simili o doppiate. Dal punto di vista del layout si è abbandonato lo schema tabellare in favore di uno completamente tableless e basato su CSS, ricorrendo alle tabelle nei soli punti in cui tale uso fosse semanticamente corretto o assolutamente necessario. L’u- tilizzo di framework sia dal lato CSS che Javascript ha poi appianato le incompatibilità tra browser e piattaforme differenti, garantendo così una base di partenza coerente ed omogenea dal punto di vista della compatibilità cross-browser.
2With respect to a computer file system, an access control list (ACL) is a list of permissions attached to an object. An ACL specifies which users–or system processes–are granted access to objects, as well as what operations are allowed to be performed on given objects. [3] 3Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications which enable malicious attackers to inject client-side script into web pages viewed by other users. An exploited cross-site scripting vulnerability can be used by attackers to bypass access controls such as the same origin policy. Cross-site scripting carried out on websites were roughly 80% of all documented security vulnerabilities as of 2007 [2]
9 1.2. PROBLEMATICHE CAPITOLO 1. INTRODUZIONE
Performance Lo scarso utilizzo di Javascript e l’assoluta esclusione delle tecnologie di caricamento asincrono (cfr. 5.4 nella pagina 78), unito alla scarsa razionalizzazione di molte sezioni, ha portato alla creazione di un software lento e poco reattivo, rendendone frustante l’utilizzo per l’utente finale. Tramite l’utilizzo di tecniche di manipolazione dinamica del
DOM4 della pagine e il caricamento asincroni di dati si è ottenuto un miglioramento della velocità percepita dagli utenti del sistema; aggiungendo a ciò una particolare attenzione nella stesura del codice PHP e nell’invocazione delle query di database si è riusciti ad ottenere un buon incremento di velocità ed efficienza.
Documentazione A causa dello sviluppo disordinato il software non è corredato da alcun tipo di documentazione, nè cartacea nè a livello codice. Durante lo sviluppo si è quindi proceduto con una parallela attività di documentazione del codice e successivamente me- diante phpDocumentor (cfr. 5.10 nella pagina 84) si è generata la documentazione finale per ciascuna classe. E’ stata generata anche una basilare documentazione per l’utente finale, corredata da immagini esemplificative.
4The Document Object Model (DOM) is a cross-platform and language-independent convention for representing and interacting with objects in HTML, XHTML and XML documents. [48]
10 Capitolo 2
Analisi dei requisiti
Trattandosi di un lavoro di refactoring l’analisi dei requisiti si è dimostrata certamente più semplice poichè si è potuto lavorare su aspetti di più alto livello e comunque su una base di requisiti ben consolidati. Si è quindi proceduto con la formalizzazione delle funzionalità at- tualmente implementate nella vecchia versione del software, ponendo particolare attenzione alle funzionalità che in passato hanno portato ai maggiori problemi, e le si è integrate con quanto emerso dai colloqui con il personale del Conservatorio.
2.1 Requisiti di prodotto
Si procede con la formalizzazione delle funzionalità, suddividendole per area di competenza degli enti a cui afferiscono (cfr. 3.5.1 nella pagina 27). Viene mantenuta la legenda utilizzata per il progetto di Ingegneria del Software (o: obbligatorio, d: desiderabile, z: opzionale).
11 2.1. REQUISITI DI PRODOTTO CAPITOLO 2. ANALISI DEI REQUISITI
2.1.1 Segreteria
Tipologia Requisito o pregresso: inserimento voti ed assegnazione esami o appelli: approvazione, visualizzazione e storico o preiscrizioni: gestione ed approvazione (formalizzazione in utenti del sistema) d certificazioni studenti: esenzioni, borse di studio, contratti 150 ore, stato carriere, tasse o anagrafiche studenti/docenti: aggiunta, rimozione, modifica
Tabella 2.1: Segreteria: tabella dei requisiti
2.1.2 Secondo livello
Le funzioni di secondo livello sono svolte dai direttori di ciascun corso o da speciali docenti nominati allo scopo. Loro compito principale è l’assegnazione di eventuali debiti e la prima scrematura dei piani di studio ricevuti da parte degli studenti.
Tipologia Requisito o assegnazione e modifica debiti nei piani di studio
Tabella 2.2: Secondo livello: tabella dei requisiti
2.1.3 Terzo livello
Il terzo livello è rappresentanto dai responsabili della didattica, incaricati dell’ultima fase di approvazione necessaria per la conferma dei piani di studi; è anche l’unica entità capace di riaprire le pratiche riguardanti i piani di studio confermati. In quanto supervisori finali dell’uniformità e correttezza della formulazione dei piani possono procedere con qualsiasi modifica degli stessi.
Tipologia Requisito o conferma e modifica piani di studio o rientro: possibilità di riapertura pratiche dei piani di studio o riconoscimento crediti ed autorizzazioni alla frequentazione di insegnamenti in altri istituti: inserimento, modifica, cancellazione o laboratori, crediti pregressi, altre attività: inserimento, modifica, cancellazione z statistiche studenti-corsi-insegnamenti
Tabella 2.3: Terzo livello: tabella dei requisiti
12 CAPITOLO 2. ANALISI DEI REQUISITI 2.1. REQUISITI DI PRODOTTO
2.1.4 Direttore
Il direttore ha responsabilità di supervisione sull’operato dell’intero Conservatorio. Ha quin- di bisogno di statistiche incrociate per rilevare eventuali anomalie e prendere decisioni per porre rimedio ad eventuali discrepanze.
Tipologia Requisito z statistiche studenti-docenti-insegnamenti
Tabella 2.4: Direttore: tabella dei requisiti
2.1.5 Docenti
I docenti devono poter gestire la propria classe ed i dati inerenti le proprie docenze.
Tipologia Requisito o appelli: richiesta approvazione da parte della segreteria, modifica d gestione voti e frequenza delle classi di competenza o dati docenza: inserimento e modifica (es. programmi degli insegnamenti svolti)
Tabella 2.5: Docenti: tabella dei requisiti
2.1.6 Studenti
Nel corso di una definita finestra temporale gli studenti possono procedere alla compilazione della prima stesura del proprio piano di studi, che inizierà poi il percorso di approvazione
(cfr. 3.5.1 nella pagina 27).
Tipologia Requisito o piani di studi: visualizzazione e modifica limitata d iscrizione agli appelli d’esame
Tabella 2.6: Studenti: tabella dei requisiti
2.1.7 Utenti esterni
Anche gli utenti esterni (ossia coloro che non hanno le credenziali per accedere al siste- ma) possono usufruire di una parte di Infostudenti, poichè alcune sezioni informative sono pubbliche.
13 2.2. REQUISITI DI PROCESSO CAPITOLO 2. ANALISI DEI REQUISITI
Tipologia Requisito o lista e dettagli insegnamenti, docenti e programmi o preiscrizione al prossimo A.A.
Tabella 2.7: Utenti esterni: tabella dei requisiti
2.1.8 Amministratore
L’amministratore si occupa degli aspetti più tecnici della gestione di Infostudenti.
Tipologia Requisito o anni accademici: aggiunta, modifica parametri o insegnamenti: aggiunta, modifica, cancellazioneo o insegnamenti assegnabili come debiti: aggiunta, modifica, cancellazione o docenze: aggiunta, modifica, cancellazione o corsi: aggiunta, modifica, cancellazione o piani di studio consigliati: aggiunta, modifica, cancellazione o aule: aggiunta, modifica, cancellazione o strumenti: aggiunta, modifica, cancellazione o utenti: aggiunta, modifica, cancellazione, cambio permessi o testi descrittivi: aggiunta, modifica, cancellazione d gestione storico delle azioni compiute da tutti gli utenti del sistema
Tabella 2.8: Amministratore: tabella dei requisiti
2.1.9 Funzionalità condivise tra gli utenti autenticati
Esistono alcune funzionalità che devono essere accessibili a tutti gli utenti autenticati in
Infostudenti.
Tipologia Requisito o modifica profilo (specifico per tipologia di utente) d ricerca studenti e docenti o visualizzazione lista insegnamenti con relative docenze d visualizzazione calendario appelli
Tabella 2.9: Requisiti comuni a tutti gli utenti autenticati in Infostudenti
2.2 Requisiti di processo
• web-application basata su framework PHP MVC object-oriented
• consistenza, integrità e confidenzialità dei dati
14 CAPITOLO 2. ANALISI DEI REQUISITI 2.3. CONSUNTIVO FINALE
• estensivo uso di caricamento asincrono (AJAX) per
– velocizzazione di operazioni precedentemente implementate in modo sincrono
– alleggerimento complessivo delle pagine (caricamento di componenti solo su ri-
chiesta)
• manutenibilità ed estensibilità
• parametrizzazione dei valori
• layout adatto per permetterne la stampa di qualsiasi pagina del software
2.3 Consuntivo finale
Tutti i requisiti obbligatori e desiderabili sono stati soddisfatti mentre quelli opzionali verranno eventualmente sviluppati con un lavoro extra-stage.
15 2.3. CONSUNTIVO FINALE CAPITOLO 2. ANALISI DEI REQUISITI
16 Capitolo 3
Specifica tecnica
3.1 Architettura MVC
Come da requisiti funzionali si è riprogettato l’intero sistema in ottica MVC:
Why use MVC? Because it is a tried and true software design pattern that turns
an application into a maintainable, modular, rapidly developed package. Crafting
application tasks into separate models, views, and controllers makes your appli-
cation very light on its feet. New features are easily added, and new faces on
old features are a snap. The modular and separate design also allows developers
and designers to work simultaneously, including the ability to rapidly prototype.
Separation also allows developers to make changes in one part of the application
without affecting others. [6]
Il recente fiorire di un gran numero di framework PHP ha visto emergere un’architettura software sulle altre: la relativa semplicità di MVC e la possibilità di contare sui framework più noti e stabili ha quindi praticamente obbligato l’adozione di tale architettura, che comunque possiede le caratteristiche richieste dai requisiti di processo rilevati per il refactoring del sistema.
Layer MVC In una tipica architettura MVC esistono 3 layer intercomunicanti:
• Model: contiene i dati e la business logic dell’applicazione
17 3.1. ARCHITETTURA MVC CAPITOLO 3. SPECIFICA TECNICA
Figura 3.1: Architettura MVC
• Controller: gestisce gli eventi generati dalla View tramite l’invocazione delle ap- posite funzionalità del Model
• View: si occupa della visualizzazione dei risultati e dell’interazione con l’utente
Esempio di richiesta MVC Si espone la logica sottostante ad una richiesta esaudita da una sistema basato su architettura MVC
1. l’utente interagisce con l’interfaccia utente (per esempio, clicca su un’icona) e genera
eventi
2. il controller gestisce l’evento generato tramite notifica del model
3. il model esegue l’azione richiesta e risponde direttamente alla view (in alcune imple-
mentazioni la risposta passa tramite il controller, che in questo caso funziona da puro
dispatcher)
18 CAPITOLO 3. SPECIFICA TECNICA 3.1. ARCHITETTURA MVC
Figura 3.2: Architettura MVC implementata in CakePHP
Ciclo completo MVC CakePHP Si espone la logica sottostante ad una richiesta portata a termine tramite il framework CakePHP su architettura MVC
1. il client richiede una pagina
2. il dispatcher si occupa del parsing della richiesta tramite distinzione di controller,
action e parametri. Possono essere eventualmente seguite Routes (“percorsi”) differenti
anche non aderenti allo standard /controller/action/parameters.
3. il controller compie l’azione richiesta e raccoglie i dati necessari per la visualizzazione
dei risultati, eventualmente tramite l’uso delle sue estensioni, definite Component. Può
richiedere l’ausilio di uno o più Model, che a loro volta possono fare uso di specifiche
estensioni (Behavior). I dati ricevuti dal Model possono poi essere ulteriormente
elaborati dal Controller.
4. i dati vengono inviati alla View, che può fare uso di particolari classi Helper di supp-
porto o di file (Element) la cui inclusione può aiutare a non ripetere codice necessario in più parti del sistema
5. la View viene visualizzata dall’utente, con la quale può interagire e far ricominciare il ciclo MVC
19 3.1. ARCHITETTURA MVC CAPITOLO 3. SPECIFICA TECNICA
Scelte MVC Si è adottata la tecnica “fat model skinny controller”[5] che consiste nel man- tenere nel Model gran parte della business logic in maniera da ottenere controller snelli e veloci, atti al solo dispatching delle richieste loro pervenute.
3.1.1 Layer MVC implementati in CakePHP
Si procede con una panoramica dei layer MVC con particolare accezione all’implementazione fornita dal framework CakePHP.
Model I Model rappresentano il cuore dell’applicazione: in essi viene infatti racchiusa buona o intera parte della business logic. Il framework fornisce alcuni metodi di base per caricamen- to, aggiornamento, salvataggio e ricerca dei dati, poi manipolabili prima di essere ritornati al Controller.I Model rappresentano l’astrazione necessaria per l’accesso al data layer, che non necessariamente è dato dal classico database relazionale (CakePHP ad esempio supporta un’ampia gamma di sorgenti quali file CSV o server LDAP1).
Behavior
Behaviors work as ways to add common functionality between models. For exam-
ple, if you store user data in a tree structure, you can specify your User model
as behaving like a tree, and gain free functionality for removing, adding, and
shifting nodes in your underlying tree structure. [20]
I behavior rappresentano l’equivalente dei Component per i Controller: si occupano di fun- zionalità aggiuntive dei modelli, funzionalità che può essere utile avere comuni per tutti i modelli o che semplicemente risulta opportuno separare per motivi architetturali od orga- nizzativi. Alcuni metodi standard offerti dai behavior sono beforeSave(), afterSave(), beforeDelete(), afterDelete(), beforeFind(): come intuibile rappresentano una sorta di parallelo con i trigger2 implementati in molti RDBMS. La possibilità di automatizzare tali azioni sotto determinate condizioni permette di ridurre al minimo la possibilità di errori
1The Lightweight Directory Access Protocol, or LDAP, is an application protocol for querying and modifying directory services running over TCP/IP [7] 2A database trigger is procedural code that is automatically executed in response to certain events on a particular table or view in a database. The trigger is mostly used for keeping the integrity of the information on the database. [8]
20 CAPITOLO 3. SPECIFICA TECNICA 3.1. ARCHITETTURA MVC umani derivanti dalla dimenticanza di azioni obbligatorie all’atto del salvataggio di nuovi record o il compimento di sequenze di azioni particolarmente delicate.
Proprio nei behavior è possibile ricercare una buona parte del peso della community
CakePHP, poichè vengono rilasciati settimanalmente nuove classi progettate ad hoc per specifici ambiti applicativi.
Un esempio di behavior al momento non implementato nel sistema ma di cui si può prevedere un’inclusione nelle prossime release è il cosiddetto SoftDeletableBehavior: tale classe si occupa di gestire la SoftDeletion ossia la rimozione logica e non fisica dei record di database, tramite l’utilizzo di un apposito flag booleano deleted.
Controller I controller CakePHP fungono da tramite tra View e Model. In alcuni casi possono procedere ad una ulteriore modellazione dei dati ricevuti da e per i due layer.
Component
A Component is a class that aids in controller logic. If you have some logic
you want to share between controllers (or applications), a component is usually
a good fit. [. . . ] Rather than writing a controller method in a single controller
that performs this logic, you can package the logic so it can be shared. [19]
Le classi Component permettono di estendere la logica presente nei controller, ma considerato il modello “fat model skinny controller”[5] adottato per l’intero sistema non si è ritenuto opportuno procedere con la progettazione di alcun Component. E’ però bene sottolineare come si sia invece fatto ampio uso di Component offerti nativamente dal framework CakePHP (cfr. 4.3.1 nella pagina 58).
View Il View layer si occupa della visualizzazione dei dati all’utente finale e del ritorno al controller degli eventuali input ricevuti dall’utilizzatore. Dato che ciascuna View non rappresenta altro che una delle possibili rappresentazioni per una serie di dati ricevuti dal
Model, è stato possibile implementare differenti visualizzazioni per medesime azioni; un esempio è dato dalla visualizzazione del piani di studio confermati: tramite la richiesta
/students/plan/14 viene richiesta la visualizzazione XHTML di default, mentre tramite la richiesta /students/plan/14.pdf o /students/plan/14.rtf vengono richieste le cor-
21 3.2. WEB APPLICATION (CLIENT-SERVER) CAPITOLO 3. SPECIFICA TECNICA rispondenti viste PDF o RTF, rispettivamente per la stampa di certificati da parte degli studenti o la modifica da parte della segreteria.
Helper
A Helper is a class that aids in view logic. Much like a component used among
controllers, helpers allow presentational logic to be accessed and shared between
views. [...] Most applications have pieces of view code that are used repeatedly.
CakePHP facilitates view code reuse with layouts and elements. [21]
Le classi Helper rappresentano il parallelo dei Behavior rispetto ai Model: sono cioè delle estensioni delle classi View, delle quali raccolgono i metodi comuni. Un esempio di helper presente di default in CakePHP è l’HTMLHelper (cfr. 4.4.1 nella pagina 60), una classe atta all’output di elementi HTML opportunamente formattati.
3.2 Web application (client-server)
In software engineering, a web application or webapp is an application that is ac-
cessed via a web browser over a network such as the Internet or an intranet. The
term may also mean a computer software application that is hosted in a browser-
controlled environment (e.g. a Java applet) or coded in a browser-supported
language (such as JavaScript, possibly combined with a browser-rendered mar-
kup language like HTML) and reliant on a common web browser to render the
application executable.
Web applications are popular due to the ubiquity of web browsers, and the con-
venience of using a web browser as a client, sometimes called a thin client. The
ability to update and maintain web applications without distributing and instal-
ling software on potentially thousands of client computers is a key reason for
their popularity, as is the inherent support for cross-platform compatibility. [57]
Viene illustrato il funzionamento della transazione utente - web-application.
1. l’utente effettua una richiesta tramite il proprio browser al web-server su cui risiede
l’applicazione web
22 CAPITOLO 3. SPECIFICA TECNICA 3.3. AJAX
Figura 3.3: Funzionamento web-application (modello client-server)
2. il server web gestisce la richiesta, in questo caso redirigendola alla web-application (nel
caso di Infostudenti redirige la richiesta al processore PHP)
3. la web-application genera la risposta alla richiesta dell’utente, eventualmente richie-
dendo a sua volta l’ausilio del database server per il reperimento dei dati necessari
4. il web-server accoglie la risposta generata dalla web-application e si fa carico di reca-
pitarla all’utente
3.3 AJAX
Dall’analisi dei requisiti è emersa la necessità di velocizzare e razionalizzare l’interfaccia utente di Infostudenti. Per tale motivo si è ricorso a metodologie di caricamento asincrono.
AJAX (Asynchronous JavaScript And XML) is a group of interrelated
web development techniques used on the client-side to create interactive web ap-
plications. With Ajax, web applications can retrieve data from the server asyn-
chronously in the background without interfering with the display and behavior
of the existing page. The use of Ajax techniques has led to an increase in inte-
ractive or dynamic interfaces on web pages. Data is usually retrieved using the
XMLHttpRequest object. [51]
23 3.3. AJAX CAPITOLO 3. SPECIFICA TECNICA
Figura 3.4: Diagramma di funzionamento tecnologia AJAX
Si esplicita un esempio di interazione asincrona per la velocizzazione delle pagine del sistema.
1. L’utente finale richiede al server la pagina necessaria per l’inserimento di nuovi elementi
nel proprio piano studi
2. il server risponde in modo sincrono inviando la pagina richiesta, che viene visualizzata
sul browser dell’utente
3. l’utente clicca sull’icona dell’elemento che vuole inserire: tramite Javascript viene in-
viata (in background e senza alcuna cognizione da parte dell’utente) una richiesta
asincrona al server, che risponde con il solo form necessario per l’inserimento dell’e-
lemento richiesto. Tale form viene “iniettato” nel codice della pagina così che possa
essere immediatamente utilizzato dall’utente
Tale tecnologia non rappresenta una novità in senso stretto nel mondo del web, dato che altro non è che un utilizzo particolarmente specifico di tecnologie pre-esistenti. In questi ultimi anni si è però assistito ad un fiorire di librerie capaci di semplificare, standardizzare e portare a pienezza tale incrocio di tecnologie. Nel caso specifico di Infostudenti si è fatto uso di jQuery (cfr. 5.3.2 nella pagina 75), un framework Javascript capace di gestire tutti gli aspetti di basso livello delle transazioni asincrone, permettendo così allo sviluppatore di concentrarsi su aspetti più specifici per il successo dell’applicativo.
24 CAPITOLO 3. SPECIFICA TECNICA 3.4. ORM
Tipologia Peso (in kb) Pagina base (senza form) 30 Form 3 Richiesta AJAX 1
Tabella 3.1: Peso (in kb) delle componenti di una ipotetica transazione web
Tipologia Peso (in kb) Pagina base (senza form) 30 Richiesta pagina con form 1 Pagina base con form 33 Totale 64
Tabella 3.2: Dati trasferiti in una ipotetica transazione che non faccia uso di AJAX
Tipologia Peso (in kb) Pagina base (senza form) 30 Richiesta AJAX 1 Form 3 Totale 34
Tabella 3.3: Dati trasferiti in una ipotetica transazione che faccia uso di AJAX
Performance Tramite il caricamento asincrono si risparmia sul caricamento di una pagi- na completa, poichè si riesce a caricare solo la porzione necessaria all’aggiornamento della stessa. Considerati i valori medi di una transazione (cfr. tabelle in pagina) è facile calcolare come tra una pagina senza AJAX ed una con AJAX vi sia un risparmio di trasferimento dati corrispondente ad un’intera pagina. Tale risparmio si riflette in primis in termini di migliore esperienza utente, non costringendo l’utilizzatore ad attendere inutilmente il carica- mento dell’intera pagina ma soltanto la frazione di secondo necessaria per trasferire l’unico frammento aggiornato; in secondo luogo si assiste ad un alleggerimento del carico del server, non costretto a soddisfare una potenziale richiesta aggiuntiva.
3.4 ORM
Object-relational mapping (ORM, O/RM, and O/R mapping): in com-
puter software is a programming technique for converting data between incompa-
tible type systems in relational databases and object-oriented programming lan-
25 3.5. INFOSTUDENTI CAPITOLO 3. SPECIFICA TECNICA
guages. This creates, in effect, a "virtual object database" that can be used from
within the programming language. [25]
Figura 3.5: Diagramma di funzionamento di un generico Object Relational Mapping
Grazie all’utilizzo di tale tecnologia si è potuto ottenere un livello di astrazione e controllo del database, il cui accesso è quindi disciplinato tramite apposite chiamate di libreria del framework. Tale scelta ha permesso di slegare il software dal database sottostante ma soprattutto semplificare e alleggerire il codice sorgente (“the fewer the lines of code in a program, the fewer the errors contained within them”). L’inevitabile overhead aggiunto da questo nuovo layer di astrazione è stato giudicato trascurabile se bilanciato con l’estremo controllo degli accessi al database e la pulizia del codice ottenuta tramite il suo utilizzo. La specifica implementazione ORM adottata (Active Record, cfr. 5.1.2 nella pagina 66) viene discussa nella successiva Definizione di prodotto.
3.5 Infostudenti
Si procede con la specifica del funzionamento delle sezioni di Infostudenti che sono risultate non banali o che hanno causato i maggiori problemi durante il refactoring.
26 CAPITOLO 3. SPECIFICA TECNICA 3.5. INFOSTUDENTI
3.5.1 Piani di studio
Figura 3.6: Diagramma di stato dei piani di studio
Si esplicita il ciclo di approvazione a cui è soggetto un piano di studi:
1. lo studente esterno fa richiesta di preiscrizione tramite l’apposito form online
2. la segreteria può decidere di approvare o rigettare la richiesta. In caso positivo
27 3.5. INFOSTUDENTI CAPITOLO 3. SPECIFICA TECNICA
(a) lo studente viene registrato nel sistema e gli vengono assegnate delle credenziali
di accesso
(b) allo studente viene assegnato un basilare piano di studi comprensivo dei soli
insegnamenti obbligatori per il corso scelto oppure il piano di studi consigliato
(cfr. 3.5.2 nella pagina successiva) precedentemente compilato dal personale del
conservatorio
3. lo studente può accedere al sistema e procedere con la compilazione del proprio piano
di studi
4. una volta completata la compilazione del proprio piano di studi lo studente può
confermare il proprio piano, che passa al secondo livello
5. il secondo livello può modificare il piano inserendo o modificando nuovi debiti; se lo
approva il piano passa al terzo livello. In caso di rifiuto il piano torna allo studente
6. il terzo livello può modificare il piano in qualsiasi sua parte e infine approvarlo: il
piano viene così confermato e approvato definitivamente. Può anche rifiutare il piano
e farlo tornare al secondo livello
7. il terzo livello può riaprire la pratica di specifici piani di studio confermati per poterli
modificare a proprio piacimento
28 CAPITOLO 3. SPECIFICA TECNICA 3.5. INFOSTUDENTI
3.5.2 Piani di studio consigliati
Figura 3.7: Diagramma di stato per un piano di studi consigliato
Si esplicita il ciclo di richiesta per un piano di studi consigliato per un ipotetico corso X:
1. il piano di studi consigliato esiste: il personale del conservatorio può modificarlo come
qualsiasi altro piano di studi
2. il piano di studi consigliato non esiste: viene creato uno studente con relativo uten-
te fittizio, al cui piano di studi vengono preliminarmente assegnati gli insegnamenti
obbligatori per il corso X
29 3.5. INFOSTUDENTI CAPITOLO 3. SPECIFICA TECNICA
3.5.3 Esami
Figura 3.8: Diagramma di stato degli esami
Si esplicita il ciclo di approvazione a cui è soggetto un esame:
1. il docente fa richiesta dell’appello compilando l’apposito form
2. la segreteria considera la richiesta ed eventualmente modifica i dati dell’esame
3. la segreteria può confermare l’appello, al quale da quel momento possono cominciare ad
iscriversi gli studenti, oppure rifiutare e farlo tornare al docente per ulteriori modifiche
30 CAPITOLO 3. SPECIFICA TECNICA 3.5. INFOSTUDENTI
3.5.4 Creazione nuovi utenti
Figura 3.9: Diagramma di stato per la creazione di nuovi utenti
Si esplicita il procedimento tramite cui vengono creati nuovi utenti:
1. indipendentemente dal tipo di utente richiesto viene creato un utente completo di
username e password (necessarie per poter accedere al sistema)
2. in caso di richiesta di creazione di nuovo studente: creazione studente associato all’u-
tente di cui sopra ed assegnazione insegnamenti obbligatori o piano di studi consigliato,
a discrezione della segreteria
3. in caso di richiesta di creazione di nuovo docente: creazione docente assegnato all’u-
tente di cui sopra ed assegnazione dei ruoli permessi
4. in caso di richiesta di creazione di altro personale (diverso da studente e docente):
assegnazione all’utente di cui sopra dei soli ruoli permessi
31 3.5. INFOSTUDENTI CAPITOLO 3. SPECIFICA TECNICA
3.5.5 Crediti insegnamenti
Si espone la logica sottostante alla determinazione dei crediti attribuili a ciascun insegna- mento.
Figura 3.10: Diagramma di stato per i crediti di un insegnamento
Si esplicita il procedimento tramite cui vengono determinati i crediti di un insegnamento:
1. la riga di piano di studi cui appartiene l’insegnamento ha una docenza assegnata: i
crediti sono già stati assegnati
2. la riga di piano di studi cui appartiene l’insegnamento non ha alcuna docenza asse-
gnata: viene determinata la tipologia espressa nella riga di piano di studi e ricercati i
crediti predefiniti per tale insegnamento e tipologia. Se esistono vengono ritornati al
chiamante.
32 CAPITOLO 3. SPECIFICA TECNICA 3.5. INFOSTUDENTI
3.5.6 Crediti riga di piano di studi tipo C
Si espone la logica sottostante alla determinazione dei crediti attribuili a riconoscimenti di crediti o autorizzazioni di insegnamenti svolti in altri istituti.
Figura 3.11: Diagramma di stato per i crediti di una riga di piano di studi tipo C
33 3.5. INFOSTUDENTI CAPITOLO 3. SPECIFICA TECNICA
Si esplicita il processo tramite cui vengono determinati i crediti di una riga di piano studi tipo C:
1. la riga è contrassegnata come svolta: vengono ritornati i crediti già salvati
2. la riga è contrassegnata come da svolgere: vengono calcolati i crediti a partire dalla
durata e dal genere salvati nella riga in oggetto
(a) genere “pratico”: i crediti sono ottenuti dal rapporto tra la durata (in ore) e
l’apposito coefficiente annuale “ore di pratica per credito”. Se tale numero di
crediti è superiore al numero massimo di crediti assegnabili per singolo insegna-
mento pratico allora viene ritornato tale numero massimo, altrimenti il rapporto
precedentemente calcolato
(b) genere “teorico”: i crediti sono ottenuti dal rapporto tra la durata (in ore) e
l’apposito coefficiente annuale “ore di teoria per credito”. Se tale numero di cre-
diti è superiore al numero massimo di crediti assegnabili per singolo insegna-
mento teorico allora viene ritornato tale numero massimo, altrimenti il rapporto
precedentemente calcolato
(c) genere “laboratorio”: i crediti sono ottenuti dal rapporto tra la durata (in ore)
e l’apposito coefficiente annuale “ore di laboratorio per credito”. Se tale nume-
ro di crediti è superiore al numero massimo di crediti assegnabili per singolo
laboratorio allora viene ritornato tale numero massimo, altrimenti il rapporto
precedentemente calcolato
3.5.7 Crediti riga di piano di studi tipo D
Si espone la logica sottostante alla determinazione dei crediti attribuili a laboratori, attività formative pregresse o altre attività fin qui non contemplate.
34 CAPITOLO 3. SPECIFICA TECNICA 3.5. INFOSTUDENTI
Figura 3.12: Diagramma di stato per i crediti di una riga di piano di studi tipo D
Si esplicita il procedimento tramite cui vengono determinati i crediti di una riga di piano studi tipo D:
1. la riga è contrassegnata come da svolgere: vengono ritornati durata e crediti preven-
tivati nella stessa riga
2. la riga è contrassegnata come svolta: viene effettuata la somma della durata e dei
crediti degli elementi tipo D associati (crediti definitivi)
35 3.5. INFOSTUDENTI CAPITOLO 3. SPECIFICA TECNICA
36 Capitolo 4
Definizione di prodotto
Si procede con una descrizione dettagliata dei componenti del sistema Infostudenti.
4.1 Database
4.1.1 Modellazione concettuale
Il modello concettuale riportato nella pagina seguente contempla le classi principali del sistema Infostudenti. Per evidenti motivi grafici non è stato possibile inserire le proprietà di ciascuna classe, comunque incluse nei successivi schemi di modellazione relazionale.
4.1.2 Specifiche di modellazione relazionale
Vengono discusse le scelte effettuate in fase di rimodellazione del database sottostante al sistema Infostudenti.
Chiavi esterne Per garantire la consistenza dei dati si è fatto uso di chiavi esterne1 ogni- qualvolta ne fosse possibile l’uso. E’ stato inoltre minimizzato il numero di chiavi esterne settabili a NULL, in maniera da obbligare ad un rigoroso controllo preventivo dei dati inseriti.
Piani di studio temporanei Nella precedente versione del database la distinzione tra piani di studio temporanei (ossia in stato di modifica) e piani di studio confermati era ottenuta
1In the context of relational databases, a foreign key is a referential constraint between two tables. [35]
37 4.1. DATABASE CAPITOLO 4. DEFINIZIONE DI PRODOTTO
Figura 4.1: Modellazione concettuale del database
38 CAPITOLO 4. DEFINIZIONE DI PRODOTTO 4.1. DATABASE
39
Figura 4.2: Modello precedente 4.1. DATABASE CAPITOLO 4. DEFINIZIONE DI PRODOTTO tramite l’utilizzo di tabelle con i medesimi campi ma nomi differenti (es. piano_studi e piano_studi_temp). Tale scelta progettuale ha portato negli anni alla duplicazione o inutile complicazione di funzioni (dovendo operare su differenti tabelle) ma soprattutto ad un gran numero di errori di inconsistenza (dovendo ogni volta far riferimento ad una delle varie versioni di tabelle disponibili). Si è quindi scelto di unificare tali tabelle temporanee e definitive per mezzo di un campo booleano (tinyint(1)) “temp” che andasse a svolgere il ruolo di discriminatore. Un esempio pratico di semplificazione è dato dalle varie funzioni di assegnazione docenza, voto ed esame, che è stato possibile riprogettare con un unico parametro d’ingresso, ossia l’identificatore della riga interessata (senza quindi dover più fare riferimento alla tabella di riferimento).
Piani di studio extra Analogamente a quanto fatto per le righe temporanee si è deciso di dotare le tabelle dei piani di studio di un ulteriore campo booleano “extra”, necessario per la distinzione tra righe di piano di studi il cui insegnamento non è previsto dal proprio corso di studi.
Parametrizzazione dei valori Si è cercato di affidare al database quanti più parametri possibile in maniera da svincolarli dal codice (parametri hard-coded). Un esempio pratico
è dato dagli stati possibili per un esame e per un piano di studi, ora interamente gestiti tramite chiavi esterne.
Campi booleani In varie tabelle vengono utilizzati campi come “maschio/femmina”, “sì/no” al posto di più pratici e standard campi booleani. Grazie a tale standardizzazione si è potuto semplificare il codice di gestione ed ottimizzare la tipizzazione del database.
Rimozione campi inutilizzati Tramite un controllo campo per campo si è proceduto con la rimozione dei campi inutilizzati o inutilmente ridondanti.
Tipizzazione dei dati Tutti i campi di database sono stati rivisti per garantirne una più corretta tipizzazione. Grazie alla stretta relazione del framework CakePHP con il sottostante modello database si è ottenuta così una più rigida validazione dei dati: il framework è infatti in grado di rilevare dinamicamente il tipo dei campi di database e agire di conseguenza, sia in fase di validazione dei dati che in fase di inserimento di nuovi record.
40 CAPITOLO 4. DEFINIZIONE DI PRODOTTO 4.1. DATABASE
Figura 4.3: Stralcio di codice SQL commentato
Chiavi ed indici In un’ottica di conseguimento delle migliori performance si è valutato l’uso di indici sui campi maggiormente utilizzati o che comunque fossero utilizzati come chiavi esterne. Alla stessa maniera si è predisposto l’uso di chiavi UNIQUE nei campi in cui si sia ritenuto necessario ottenere univocità, comunque garantita anche a livello di codice sorgente tramite appositi metodi e controlli forniti dal framework.
Rimozione campi ENUM Il fatto che il framework CakePHP presenti alcuni problemi nella gestione dei campi ENUM, unito alla scarsa versatilità e sicurezza di tale soluzione (la modifica delle opzioni di un ENUM è possibile soltanto mediante l’alterazione della struttura stessa della tabella interessata) ha portato alla sostituzione di tali campi con più pratiche chiavi esterne verso tabelle create ad-hoc. In tale maniera è stato possibile irrobustire il sistema e predisporre le basi per eventuali ampliamenti futuri.
Standardizzazione dei nomi dei campi Dopo una preventivo adeguamento dei campi di database secondo le convenzioni del framework scelto (cfr. 4.1.3 nella pagina successiva) si è deciso di procedere con una standardizzazione generale dei nomi dei campi utilizzati in tabelle diverse, così da ridurre i casi di ambiguità di significato ed interpretazione. In contemporanea ci si è avvalsi della funzionalità di commentazione offerta da MySQL per commentare ciascun campo.
41 4.1. DATABASE CAPITOLO 4. DEFINIZIONE DI PRODOTTO
4.1.3 Convenzioni di database del framework CakePHP
Il framework scelto permette di mantenere nomi arbitrari per le tabelle di database ma incoraggia l’adozione di specifiche convenzioni per ottenere una maggiore standardizzazione dei progetti e velocizzare il lavoro di sviluppo. Si è deciso di aderire a tale convenzioni come da regole sotto elencate:
• tutte le tabelle utilizzate dal framework devono possedere una singola chiave primaria
per identificare univocamente ciascuna riga
• i nomi delle classi dei Model sono singolari e camel-cased2 es. Course
• i nomi delle tabelle corrispondono ai rispettivi Model con il nome pluralizzato e senza
spazi (sostituiti da underscore _) es. courses
• le relazioni hasMany, belongsTo or hasOne sono definite tramite il nome singolare della
tabella relazionata seguita dal suffisso _id es. nel modello Plan (tabella plans) si fa
riferimento al modello Course (tabella courses) tramite il campo course_id
• le relazioni molti a molti (dal framework definite HABTM, da Has-A-and-Belongs-To-Many) sono definite da una tabella intermedia definita dai nomi dei due modelli interessati,
pluralizzati e separati da underscore es. modello User può avere molti Role tramite
la tabella roles_users
• in caso una tabella possieda un campo title o name tale campo verrà utilizzato di
default come campo di visualizzazione es. campo name nel modello Teaching: ogni- qualvolta venga richiesta la generazione di una selectbox del modello verrà utilizzato
il campo name come campo di visualizzazione e il campo id come campo valore
• in caso una tabella possieda un campo created (tipo DATE) o modified (tipo DATE) il framework ne provvederà automaticamente alla gestione, rispettivamente all’atto della
creazione o della modifica del modello relazionato
2CamelCase or medial capitals is the practice of writing compound words or phrases in which the elements are joined without spaces, with each element’s initial letter capitalized within the compound, and the first letter can be upper or lower case — as in LaBelle, BackColor, MacGyver, or iPod. The name comes from the uppercase "bumps" in the middle of the compound word, suggestive of the humps of a camel [9]
42 CAPITOLO 4. DEFINIZIONE DI PRODOTTO 4.1. DATABASE
Figura 4.4: Modello relazione finale (completo di proprietà)
43 4.1. DATABASE CAPITOLO 4. DEFINIZIONE DI PRODOTTO
Figura 4.5: Modello relazionale finale (solo chiavi primarie ed esterne)
44 CAPITOLO 4. DEFINIZIONE DI PRODOTTO 4.2. CLASSI MODEL
Figura 4.6: Gerarchia classe Model ed Helper
4.2 Classi Model
Le classi Model rappresentano il cuore dell’intero sistema poichè si è adottata la tecnica
“fat model skinny controller”[5]. Ciascun modello estende AppModel che a sua volta estende
Model, così che tutti i modelli si trovano ad ereditare i seguenti campi:
• array validate: contiene le regole di validazione per ciascun campo del modello.
CakePHP fornisce un set di regole comuni come email, numeric, minLength, boolean,
date, notEmpty, url, estendibili tramite overloading, oppure è possibile crearne di nuove ad-hoc
• array hasOne, hasMany, belongsTo, hasAndBelongsToMany: attributi rappresen-
tanti le relazioni tra i modelli es. Student->hasMany(array(’Student’ => array(’foreign_key’
=> ’course_id’)))
45 4.2. CLASSI MODEL CAPITOLO 4. DEFINIZIONE DI PRODOTTO
• bool useTable: settato a false in caso il modello non si appoggi ad una tabella di database
• string primaryKey: di default settato a id, rappresenta la chiave primaria del-
la tabella di un modello es. nella tabella years si è deciso di utilizzare il campo
anno come chiave primaria, motivo per cui nella classe Year si sia definito definito
this->primaryKey=’anno’
• array _schema: contiene lo schema della tabella di database del modello, comprensiva di tipi e relazioni
Alla stessa maniera tutti i modelli si trovano ad ereditare alcuni metodi di utilità, di cui viene qui esposta una panoramica dei più utilizzati durante il refactoring di Infostudenti:
• public bool save(array data, boolean validate=true, array fieldList=array()): permette di aggiornare i dati del modello sul quale è invocato o crearni di nuovi, a
seconda della presenza o meno dell’indice data[’Model’][’id’] (dove data rappre- senta l’array associativo contenente i dati passati al modello). Il parametro opzionale
validate è necessario invece per disabilitare al bisogno la validazione dei campi, vali- dazione che viene automaticamente effettuata dal framework ogni volta venga richiesto
un salvataggio di dati. L’ultimo parametro opzionale fieldList rappresenta una lista dei campi interessati, in maniera che si possano decidere a priori i campi che verranno
aggiornati (questo perchè altrimenti il framework cerca di salvare tutti i campi presenti
nell’array data).
• public bool saveAll(array data, array options=array()): il metodo in ogget- to si occupa del salvataggio dei dati del modello su cui è invocato e contemporaneamen-
te dei dati relazionati (es. i dati di un modello associato con una relazione hasMany). Se invocato su un database supportante le transazioni riesce a garantire l’atomicità del
salvataggio. Si è rivelato fondamentale in moltissime parti del sistema proprio per la
sua capacità di salvataggio di diversi tipi di dati correlati, semplificando enormemente
la base di codice e garantendo l’integrità della base dati.
46 CAPITOLO 4. DEFINIZIONE DI PRODOTTO 4.2. CLASSI MODEL
• public bool updateAll(array fields, array conditions): trasposizione della
funzione SQL UPDATE, permette l’aggiornamento di più campi sottostanti alle con- dizioni passate come parametro (in forma di array associativo)
• public bool saveField(string fieldName, string fieldValue, validate=false): metodo ausiliario che permette di salvare un singolo campo di un determinato modello
es. $this->Student->saveField(’studentstatus’, 2)
• public bool delete(int id, boolean cascade = true): permette di eliminare
un record del modello sul quale è invocato; tramite il parametro booleano cascade (di
default impostato a true) il framework si occupa di eliminare anche i dati relazionati la cui eliminazione è stata pianificata in fase di progettazione del sistema (in sostan-
za è un parallelo della clausola ON DELETE CASCADE ottenuta con le chiavi esterne di
MySQL). Si noti che gran parte di tali clausole ON sono state impostate a RESTRICT così da obbligare la gestione esplicita dei dati relazionati.
• public array view(int id): metodo non ereditato da Model ma definito in gran parte dei modelli per il reperimento del dettaglio dei dati di un singolo record. In caso
tale metodo non sia stato definito viene utilizzato il metodo public array read(array
fields, int id). Per i modelli particolarmente pesanti si è però evitato tale appro-
cio di default poichè read() legge tutti i dati relazionati, operazione che può risultare particolarmente onerosa in caso di modelli con un gran numero di chiavi esterne.
Si procede ora con una panoramica dei modelli definiti per il sistema Infostudenti.
4.2.1 Application
Il modello gestisce le iscrizioni degli studenti agli esami e le relative presenze/assenze agli appelli.
4.2.2 Check
Il modello gestisce i controlli eseguiti dalla segreteria su ciascuno studente: esenzioni, borse di studio, contratti 150 ore.
47 4.2. CLASSI MODEL CAPITOLO 4. DEFINIZIONE DI PRODOTTO
4.2.3 Classroom
Il modello gestisce le aule d’esame.
4.2.4 Course
Il modello gestisce i corsi d’insegnamento. Si procede con una panoramica dei metodi specifici.
• array public lista(array conditions): ritorna la lista dei corsi completa degli studenti associati e aderenti alle condizioni passate. Metodo utilizzato in tutte le
sezioni del software in cui sia necessaria la selezione di studenti a partire dal corso di
appartenenza
• int piano_consigliato(int course_id): controlla l’esistenza ed in caso negativo procede con la creazione di un piano di studi consigliato per il corso passato. Ritor-
na l’ID dello studente fittizio associato al piano di studi consigliato (cfr. 3.5.2 nella
pagina 29)
• bool insegnamento_obbligatorio(int course_id, int teaching_id, int anno_frequenza): controlla se l’insegnamento passato sia obbligatorio per il corso e anno passati come
parametri
4.2.5 CoursesTeaching
Il modello gestisce le relazioni corso-insegnamento, ossia gli insegnamenti relativi a ciascun corso e le loro caratteristiche (tipologia, obbligatorietà).
4.2.6 Exam
Il modello gestisce gli esami. Si procede con una panoramica dei metodi specifici.
• public array lista_esami_per_docenza(int qualification_id): ritorna un ar- ray associativo contenente la lista degli esami disponibili per una data docenza
• public bool confirm(int exam_id): ritorna un booleano rappresentante l’esito della conferma di un esame
48 CAPITOLO 4. DEFINIZIONE DI PRODOTTO 4.2. CLASSI MODEL
• public array esami_per_studente(int student_id): ritorna un array associati- vo contenente gli esami cui può iscriversi uno studente
4.2.7 Examstatus
Il modello gestisce gli stati possibili per un singolo esame es. confermato dalla segreteria, rifiutato.
4.2.8 Genre
Il modello gestisce i generi associabili ad un piano di studi di tipo C es. pratico, teorico.
4.2.9 Grant
Il modello gestisce le relazioni utente-ruolo, ossia i permessi di ciascun utente.
4.2.10 Instrument
Il modello gestisce gli strumenti musicali associabili a ciascuno studente.
4.2.11 Log
Il modello gestisce lo storico delle azioni effettuate nel sistema, in maniera da poter mante- nere una traccia di chi ha fatto cosa.
• public bool log_user(int user_id, int planstatus_id, string note=null): sal-
va una riga di storico per l’utente passato, dove planstatus_id rappresenta l’identi- ficatore dello stato del piano di cui viene richiesto il salvataggio
• public bool log_student(int student_id, int planstatus_id, string note=null):
salva una riga di storico per lo studente passato. Fa uso del metodo log_user per il completamento della richiesta
4.2.12 Page
Il modello gestisce i testi introduttivi o di ausilio a particolari sezioni del software es. norme ministeriali per il secondo livello.
49 4.2. CLASSI MODEL CAPITOLO 4. DEFINIZIONE DI PRODOTTO
4.2.13 Plan
Il modello gestisce le righe di piani di studio che rappresentano insegnamenti e debiti. Si procede con una panoramica dei metodi specifici.
• public array get(int plan_id): ritorna l’array associativo contenente la riga di piano di studi identificata dall’ID passato. Si occupa di reperire anche tutti i dati
relazionati. Viene utilizzata soprattutto via AJAX.
• private void popola_docenti(array &plan): popola la riga di piano di studi pas- sata per riferimento con i docenti aventi docenze per l’insegnamento rappresentato
nella riga
• private void popola_crediti(array &plan): popola i crediti della riga di piano di studi passata per riferimento (cfr. 3.5.5 nella pagina 32)
• private void popola_docenza(array &plan): popola la riga di piano di studi pas- sata per riferimento con le docenze assegnate al docente ed insegnamento scelto
• private void popola_lista_voti(array &plan): popola la lista dei voti assegna- bili alla riga di piano di studi passata per riferimento es. assolto/idoneo/voto numerico
• private void popola_lista_esami(array &plan): popola la lista degli esami as- segnabili alla docenza della riga di piano di studi passata per riferimento
• private int crediti(array &plan): ritorna il numero di crediti per la riga di piano di studi passata per riferimento (cfr. 3.5.5 nella pagina 32)
4.2.14 Planstatus
Il modello gestisce gli stati possibili per un piano di studi es. confermato, rientro.
4.2.15 Preiscription
Il modello gestisce le richieste di iscrizione da parte di utenti esterni al sistema, poi even- tualmente confermate e formalizzate dalla segreteria.
50 CAPITOLO 4. DEFINIZIONE DI PRODOTTO 4.2. CLASSI MODEL
4.2.16 Presence
Il modello gestisce i possibili tipi di presenza dei singoli studenti iscritti a ciascun esame es. studente presente, studente assente.
4.2.17 Qualification
Il modello gestisce le docenze, ossia le relazioni docente-insegnamento-anno accademico es.
Mario Rossi insegna Pianoforte nell’A.A. 2008/2009. Si procede con una panoramica dei metodi specifici..
• public int esiste_docenza_per_docente(int teacher_id, int teaching_id, int
aa): ritorna l’identificatore della docenza avente docente, insegnamento ed anno accademico passato. In caso tale docenza non esista viene ritornato 0.
• public array docenze_per_docente(int teacher_id, int teaching_id=0, int aa=0): ritorna un array associativo contenente la lista delle docenze per il docente, insegna-
mento ed anno accademico passato. Si noti che il solo parametro obbligatorio è dato
dall’ID docente, in maniera da poter combinare i vari parametri non obbligatori e poter
riutilizzare la medesima funzione per ricerche più o meno mirate.
4.2.18 Requirement
Il modello gestisce le propedeuticità degli insegnamenti, ossia gli insegnamenti obbligatori per poter accedere a specifici insegnamenti es. Arte scenica I è propedeutico per Arte scenica
II.
4.2.19 Role
Il metodo gestisce i ruoli assumibili da ciascun utente es. segreteria, III livello. Si noti che un utente non studente può avere da un minimo di un ruolo fino ad un massimo di tutti i ruoli (cfr. 3.5.4 nella pagina 31).
51 4.2. CLASSI MODEL CAPITOLO 4. DEFINIZIONE DI PRODOTTO
4.2.20 Student
Il modello gestisce gli studenti registrati nel sistema. Si procede con una panoramica dei metodi specifici.
• private array get_contain_conditions(bool temp=0): ritorna l’array associati-
vo opportunamente formattato contenente le condizioni per il Behavior Containable, necessario per il reperimento di tutti i dati relazionati ad un piano di studi. Il parame-
tro booleano temp è necessario per la discriminazione tra piani di studio in modifica e definitivi
• private void crediti_stats(array &plan): popola le statistiche dei crediti per il piano di studi completo passato per riferimento
• private void durata_piano(array &plan): determina la durata del piano di studi passato per riferimento
• private void plan_stats(array &plan): popola le statistiche del piano di studi
passato per riferimento. Fa uso di funzioni ausiliari come crediti_stats(student)
• private current_teachings(int student_id, int temp=0, int extra=0): ritor- na un array contenente gli insegnamenti già contenuti nel piano di studi di uno stu-
dente. Si notino i parametri non obbligatori temp ed extra, rispettivamente per la selezione di piani di studio temporanei o extra. E’ utilizzata principalmente tramite
chiamate AJAX
• public array plan(int student_id): ritorna un array associativo contenente l’in- tero piano di studi confermato dello studente passato
• public array temp_plan(int student_id): ritorna un array associativo contenen- te l’intero piano di studi non confermato dello studente passato
• private bool check_matricola(string matricola): funzione ausiliaria invocata all’atto della creazione di nuovi studenti. Controlla l’univocità della matricola passata
(comunque garantita a basso livello dalla chiave UNIQUE posta sull’analogo campo di database)
52 CAPITOLO 4. DEFINIZIONE DI PRODOTTO 4.2. CLASSI MODEL
• private bool check_piano(int student id, array params): funzione ausiliaria per le procedure di rientro, effettua un controllo di coerenza del database. Ritorna
true se non esistono righe di piano di studi aderenti alle condizioni passate come secondo parametro
• private bool finalizza_piano(int student_id): funzione ausiliaria per le proce- dure di avanzamento piano. Si occupa della conferma di un piano di studi temporaneo.
• public bool plan_confirm(int student_id): fa avanzare un piano di studi es. da secondo livello a terzo livello. In caso il piano sia in rientro o terzo livello provvede
alla conferma tramite la funzione finalizza_piano.
• private int planstatus(int student_id): funzione ausiliaria che ritorna l’ID del- lo stato del piano di studi dello studente passato
• private bool rientro(int student_id): fa rientrare il piano di studi di uno stu-
dente confermato. Ritorna true in caso il rientro vada a buon fine o la pratica sia già stata riaperta.
• private bool inserisci_insegnamenti_obbligatori(int student_id): inserisce nel piano di studi temporaneo dello studente passato gli insegnamenti obbligatori per
il corso di studi scelto
• private int get_course_id(int student_id): ritorna l’ID corso dello studente passato
• public bool inizializza_studente(int student_id, int course_id=0, bool copia_def=true):
si occupa dell’inizializzazione del piano di studi dello studente passato; in caso course_id sia diverso da zero assegna il piano di studi consigliato, altrimenti i soli insegnamenti
obbligatori previsti. Il parametro copia_def definisce se debba essere creata una copia definitiva delle righe temporanee create (uno studente deve sempre avere un piano di
studi confermato parallelo a quello in stato di modifica).
• private bool assegna_piano_consigliato(int student_id, int course_id): as- segna allo studente passato il piano di studi consigliato per il corso passato
53 4.2. CLASSI MODEL CAPITOLO 4. DEFINIZIONE DI PRODOTTO
• private bool assegna_docenze_docente_scelto(int student_id, int teacher_id): assegna al piano di studi dello studente le docenze disponibili per il docente passato
come parametro
• public array crediti_per_tipologia(int student_id, bool check=false): ri- torna un array contenente i crediti di uno studente suddivisi per anno e tipologia. In
caso il parametro check sia positivo l’array viene integrato con i controlli sui crediti massimi e minimi attribuili per ciascuna tipologia ed anno
• private bool set_planstatus(int student_id, int planstatus_id): setta il nuo- vo stato del piano di studi dello studente passato occupandosi contemporaneamente
delle operazioni di compilazione dello storico
4.2.21 Studentstatus
Il modello gestisce gli stati possibili per uno studente es. laureato, ritirato.
4.2.22 Tax
Il modello gestisce le tasse pagate dagli studenti.
4.2.23 Teacher
Il modello gestisce i docenti inseriti nel sistema. Si procede con una panoramica dei metodi specifici.
• public array listing(): ritorna un array associativo della lista docenti nella forma
{’teacher-id’ => ’cognome nome’}
• public array classe(int qualification_id): ritorna un array associativo con- tenente gli studenti interessati dalla docenza passata
4.2.24 Teaching
Il modello gestisce gli insegnamenti inseriti nel sistema.
54 CAPITOLO 4. DEFINIZIONE DI PRODOTTO 4.2. CLASSI MODEL
4.2.25 Teachingstatus
Il modello gestisce gli stati possibili per ciascun insegnamento es. ordinario, debito.
4.2.26 TipoCPlan
Il modello gestisce le righe di piani di studio rappresentanti riconoscimenti di crediti o autorizzazioni di insegnamenti svolti in altri istituti. Si procede con una panoramica dei metodi specifici.
• public array get(int tipo_c_plan_id): ritorna l’array associativo contenente la riga di piano di studi identificata dall’ID passato. Si occupa di reperire anche tutti i
dati relazionati. Viene utilizzata principalmentre via AJAX
• public int crediti(array &plan): ritorna il numero di crediti assegnati alla riga di piano di studi passata per riferimento (cfr. 3.5.6 nella pagina 33)
4.2.27 TipoCType
Il modello gestisce i tipi di piani di studio di tipo C es. riconoscimento, autorizzazione.
4.2.28 TipoDElement
Il modello gestisce gli elementi associati ad alcuni piani di studio di tipo D.
4.2.29 TipoDPlan
Il modello gestisce le righe di piani di studio rappresentanti laboratori, crediti per attività formative pregresse o altre attività. Si procede con una panoramica dei metodi specifici.
• public array get(int tipo_d_plan_id): ritorna l’array associativo contenente la riga di piano di studi identificata dall’ID passato. Si occupa di reperire anche tutti i
dati relazionati. Viene utilizzata principalmente via AJAX
• private array durata_e_crediti_effettivi(array plan): effettua i necessari cal- coli per la stima della durata e dei crediti effettivi associati ad una riga di piano di
studi avente elementi di tipo D associati
55 4.2. CLASSI MODEL CAPITOLO 4. DEFINIZIONE DI PRODOTTO
• public int crediti(array &plan): ritorna il numero di crediti assegnati alla riga di piano di studi passata per riferimento (cfr. 3.5.7 nella pagina 34)
4.2.30 TipoDType
Il modello gestisce i tipi di piani di studio di tipo D es. laboratorio a progetto, crediti per attività formative pregresse.
4.2.31 TipoDTypology
Il modello gestisce le tipologie di piani di studio di tipo D es. stage, tirocinio.
4.2.32 Tipology
Il modello gestisce le tipologie associabili a ciascun insegnamento:
• tipologia A: di base (la cui presenza è possibile in tutti i piani di studi)
• tipologia B: caratterizzanti (specifici per il corso di studi intrapreso)
• tipologia C: affini (affini al corso di studi intrapreso)
• tipologia D: altro fin qui non contemplato
4.2.33 User
Il modello gestisce gli utenti del sistema indipendentemente dai ruoli assunti. Si procede con una panoramica dei metodi specifici.
• public string generate_unique_username(string seed=null): genera un nuovo username univoco, eventualmente usando il seed opzionale passato come parametro
• private bool check_unique_username(string username): funzione ausiliaria al- l’atto della creazione di nuovi utenti. Controlla l’univocità del nome utente passato
(comunque garantito a basso livello dalla chiave UNIQUE posta come vincolo sull’analogo campo di database)
56 CAPITOLO 4. DEFINIZIONE DI PRODOTTO 4.2. CLASSI MODEL
Figura 4.7: Array Containable per il reperimento dei dati relativi ad un piano di studi
4.2.34 Years
Il modello gestisce gli anni accademici inseriti nel sistema ed i relativi parametri. Si procede con una panoramica dei metodi specifici.
• public bool check_periodo_compilazione_piano_studi(): controlla che la data corrente sia compresa nella finestra temporale in cui gli studenti possono procedere
alla compilazione del proprio piano di studi
4.2.35 Classi Behavior
ContainableBehavior
This model behavior allows you to filter and limit model find operations. Using
Containable will help you cut down on needless wear and tear on your database,
increasing the speed and overall performance of your application. The class will
also help you search and filter your data for your users in a clean and consistent
way. [58]
Il behavior Containable ha rappresentato un punto fondamentale nelle modalità di sviluppo: potendo contare sul reperimento dei dati relazionati tramite la dichiarazione di semplici array associativi, si è eliminato non meno del 30% del codice del precedente si- stema, incrementando al contempo affidabilità e performance complessive. Si noti come il codice SQL generato tramite Containable non rappresenti sempre la soluzione ottimale in
57 4.3. CLASSI CONTROLLER CAPITOLO 4. DEFINIZIONE DI PRODOTTO termini di prestazioni assolute, poichè durante la sua progettazione sono state intraprese specifiche scelte architetturali per poterne garantire il funzionamento nella più ampia varie- tà di contesti, a volte però a discapito delle prestazioni; non a caso uno dei punti principali della roadmap di CakePHP è dato dall’ottimizzazione di tale behavior. Per quanto riguarda il caso specifico di Infostudenti l’overhead rilevato è stato giudicato trascurabile e nessun metodo ha richiesto l’utilizzo di query SQL manuali.
DateConverterBehavior Tramite questo behavior si è gestita la conversione delle date in formato italiano dalle View ai Model, poichè il database necessita di date in formato standard yyyy-mm-dd hh:ii:ss
FixCalculatedFieldsBehavior Tramite questo behavior si è gestita la riformattazione di alcuni array generati dal framework CakePHP: normalmente infatti i campi generati tramite funzioni SQL quali MAX(), MIN(), AVG() vengono inserite su indice 0 invece che nell’array associativo del modello di riferimento. Tramite questo behavior si è potuto ovviare a tale particolarità e velocizzare il parsing dei risultati.
4.3 Classi Controller
Come da accordi con il relatore non vengono discusse le classi Controller poichè stretta- mente mappate sulle funzionalità implementate nei Model, verso le quali funzionano da meri dispatcher da e per il View layer, come previsto dalla logica “fat model skinny controller”[5].
4.3.1 Classi Component
Si procede con una panoramica delle classi Component utilizzate per il refactoring del sistema Infostudenti.
RequestHandler
The Request Handler component is used in CakePHP to obtain additional in-
formation about the HTTP requests that are made to your applications. You
can use it to inform your controllers about Ajax as well as gain additional in-
sight into content types that the client accepts and automatically changes to the
58 CAPITOLO 4. DEFINIZIONE DI PRODOTTO 4.3. CLASSI CONTROLLER
Figura 4.8: Organizzazione delle view basata sui tipi di richiesta ricevuti
appropriate layout when file extensions are enabled. [...] When used in con-
junction with Router::parseExtensions() RequestHandler will automatically switch the layout and view files to those that match the requested type. [59]
Grazie all’utilizzo di tale componente, capace di distinguere le richieste automaticamente in base alla loro modalità di trasmissione ed alla loro estensione (es. trasmissione asincrona
AJAX oppure estensione .pdf), è stato possibile mantenere un’organizzazione rigorosa del codice e distinguere con facilità le modalità di risposta necessarie. Un esempio è dato dalle modalità di richiesta del piano di studi di un medesimo studente: /students/plan/14 risponde alla normale visualizzazione XHTML, /students/view/14.rtf all’emissione di certificati in formato RTF e /students/view/14.pdf all’emissione di certificati in formato
PDF, tutte richieste riconducibili allo stesso metodo del controller public array plan(int id) ma a View differenti, come previsto dall’architettura MVC.
AuthComponent La presenza di un componente nativo per l’autenticazione e la gestione degli utenti ha rappresentato sicuramente un motivo di forte preferenza verso CakePHP.
Grazie a tale componente è stato infatti possibile delegare al framework l’intera procedura di autenticazione degli utenti ed ottenere nel contempo un processo di login solido e quanto più sicuro possibile, potendo contare sui controlli di un’intera community di sviluppatori.
SessionComponent L’utilizzo di uno specifico componente per la manipolazione delle ses- sioni3 HTTP ha permesso di delegare al framework gran parte delle problematiche relative
3In computer science, in particular networking, a session is a semi-permanent interactive information interchange, also known as a dialogue, a conversation or a meeting, between two or more communicating devices, or between a computer and user [...]. A session is set up or established at a certain point in time, and torn down at a later point in time. [...] A session is typically, but not always, stateful, meaning that at
59 4.4. CLASSI VIEW CAPITOLO 4. DEFINIZIONE DI PRODOTTO alla sicurezza delle stesse, oltre a garantire l’indipendenza dall’implementazione, potendo contare su tre differenti tipi di mantenimento dei dati di sessione (file, cache, database).
Nel caso di Infostudenti si è optato per le sessioni file-based, ritenute essere il miglior compromesso tra prestazioni, facilità di implementazione e sicurezza dei dati.
4.4 Classi View
Per ciascuna action pubblica di ciascun controller è predisposto un file nella directory
/app/view/:controller/:action. In caso vi sia stata la richiesta di gestire differenti tipi di dato per una medesima action si sono predisposte le directory /app/view/:controller/:extension/:action.
4.4.1 Helper
HTMLHelper Di tale helper, nativo di CakePHP, si sono utilizzati prevalentemente due soli metodi, preferendo affidarsi a codice HTML customizzato per qualsiasi altra necessità.
• public string link(string title, array url=null, array htmlAttributes=null,
string confirmMessage=null, bool escapeTitle=true): ritorna il codice HTML
di un link puntante verso l’URL interno o esterno passato come parametro url, di cui
viene preventivamente effettuato il parsing dalla classe statistica Router
• public string image(string path, array htmlAttributes=array()): ritorna il codice HTML dell’immagine passata come parametro. Fa riferimento alla directory
/app/webroot/img
FormHelper La classe FormHelper si occupa delle generazione di elementi di input nel corretto formato HTML. Se vengono rispettate particolari convenzioni nelle modalità di tra- sferimento dati dal controller alla view è capace di popolare automaticamente gli elementi di input, oltre che selezionare il corretto elemento HTML da utilizzare. Il metodo principa- le, public string input(string fieldName, array options=array()), è infatti capace di rilevare automaticamente la presenza di eventuali dati provenienti dal controller e uti- lizzare il corretto markup HTML per la visualizzazione. Se ad esempio viene richiamato least one of the communicating parts needs to save information about the session history in order to be able to communicate, as opposed to stateless communication, where the communication consists of independent requests with responses. [22]
60 CAPITOLO 4. DEFINIZIONE DI PRODOTTO 4.4. CLASSI VIEW
Figura 4.9: Esempio di utilizzo della classe FormHelper
$form->input(’course’) ed esiste un array associativo contenente la lista di corsi, l’helper si occuperà di stampare una selectbox popolata con gli opportuni valori e chiavi.
JavascriptHelper ed AjaxHelper Il framework permette di autogenerare anche codice
Javascript ma si è deciso di non avvalersi di tali funzionalità, preferendo mantenere l’intera base di codice Javascript in file separati e denominati da estensione .js. Ciò ha permesso di mantenere il codice HTML estremamente pulito e leggibile e nel contempo ha consentito di separare quanto più possibile markup e logica di business.
TimeHelper L’helper ha permesso di convertire le date e gli orari ottenuti dal database in opportuno formato italiano.
InfostudentiGenericHelper Questo helper, sviluppato ad hoc per il sistema Infostuden- ti, ha permesso di centralizzare le funzionalità di visualizzazione necessarie per più view.
Elenchiamo i metodi che compongono la classe.
• public string fullname(array user): ritorna cognome e nome di un utente. Vie- ne utilizzato in qualsiasi parte del software in cui un utente debba essere esplicitato
• public void voto(array &plan): stampa e formatta stilisticamente la tipologia di voto corretta per la riga di piano di studi passata per riferimento
• public void esame(array &plan): stampa e formatta stilisticamente data e link dell’esame correlato alla riga di piano di studi passata per riferimento
• private string esplicita_numero(int numero): funzione ausiliaria per l’esplici- tazione in lettere di un dato intero passato
61 4.4. CLASSI VIEW CAPITOLO 4. DEFINIZIONE DI PRODOTTO
• public string menu(array links, array htmlAttributes=array()): ritorna un menù dinamico basato su CSS a partire dall’array di link passati. Si occupa anche
dell’evidenziazione della voce di menù correntemente attiva
• public string link_piano_studi(array &student): ritorna un link opportuna- mente formattato e diretto al piano di studi di uno studente passato per riferimento.
Tale link può variare a seconda dello stato del piano di studi dello studente
InfostudentiPlanHelper Si occupa della specifica formattazione di array concernenti i piani di studio degli studenti.
• public array certificato(&student): ritorna una versione opportunamente for- mattata del piano di studi passato. E’ necessario per la standardizzazione degli ar-
ray passati alle view di espostazione in PDF ed RTF (cfr. 5.6 nella pagina 81), che
necessitano di una minima parte dei dati visualizzati in quelle XHTML.
62 Capitolo 5
Strumenti utilizzati
5.1 PHP Framework
A software framework, in computer programming, is an abstraction in which
common code providing generic functionality can be selectively overridden or
specialized by user code providing specific functionality. Frameworks are a special
case of software libraries in that they are reusable abstractions of code wrapped
in a well-defined API, yet they contain some key distinguishing features that
separate them from normal libraries. [37]
I framework permettono di concentrare la propria attenzione sugli aspetti di più alto livello o più specifici per il successo dell’applicativo piuttosto che su tutti gli aspetti di basso livello che solitamente si ripetono di progetto in progetto. I framework offrono infatti un layer di librerie, funzionalità e componenti riutilizzabili sui quali è possibile basare altri software, che vanno quindi a poggiare su una base di codice solitamente ben testato, frutto di soluzioni standardizzate, mantenute ed aggiornate nel tempo, sia dal punto di vista funzionale che della sicurezza. Un buon numero di framework obbliga poi all’utilizzo di convenzioni archi- tetturali e progettuali nei confronti del software in sviluppo, aiutando ad incrementarne il grado di qualità o comunque di facilitarne la standardizzazione e le conseguenti possibilità di manutenzione ed ampliamento.
E’ doveroso comunque sottolineare come l’utilizzo di framework e in generale di librerie di terze parti porti inevitabilmente ad un ampliamento della base di codice, parte della
63 5.1. PHP FRAMEWORK CAPITOLO 5. STRUMENTI UTILIZZATI quale sarebbe stato possibile evitare poichè non utile ai fini del progetto specifico. Non è poi da sottovalutare la più o meno ripida curva d’apprendimento che deve essere valutata e bilanciata con gli eventuali benefici apportati dal framework per il successo e la qualità del progetto finale. Alcuni sviluppatori lamentano anche la rigidità dei framework, che a volte rende complicate azioni che di base non lo sarebbero. Inoltre in caso di problemi o di necessità di debug è più difficile risalire alle cause, considerando la mole di righe di codice di cui solitamente consta un framework di medie dimensioni.
5.1.1 Caratteristiche valutate per la scelta
Si procede con una lista delle caratteristiche valutate per la scelta del framework.
Architettura Come da requisiti non funzionali il framework deve implementare una solida architettura MVC, in maniera da poterne sfruttare tutti i vantaggi (cfr. 3.1).
Autenticazione Il framework deve obbligatoriamente possedere un modulo di autentica- zione, in maniera da poter delegare questo sensibile aspetto del sistema.
ORM L’accesso al database deve avvenire tramite apposite chiamate di libreria funzionanti da wrapper e non direttamente tramite query scritte a mano, poco flessibili e passibili di un gran numero di errori di sintassi. Tale layer di astrazione sul database layer deve poter consentire di utilizzare tecniche di caching in caso vengano trattate query particolarmente onerose.
AJAX L’utilizzo di AJAX e in generale di metodi di caricamento asincrono deve essere favorito e semplificato.
Data validation and sanitization Il framework deve occuparsi delle fasi di validazione dei tipi di dati e della sanitizzazione di quelli problematici che potrebbero dare adito a problemi di sicurezza es. XSS (cfr. 1.2).
Object-oriented Il framework deve essere orientato agli oggetti per garantire solidi paradig- mi di progettazione quali incapsulamento, ereditarietà e polimorfismo, capaci di assicurare
64 CAPITOLO 5. STRUMENTI UTILIZZATI 5.1. PHP FRAMEWORK sicurezza dei dati e flessibilità di sviluppo e facilitare la manutenzione e l’ampliamento del sistema.
Scaffolding, CRUD code generation
Scaffolding is a meta-programming method of building database-backed software
applications. It is a technique supported by some model-view-controller fra-
meworks, in which the programmer may write a specification that describes how
the application database may be used. The compiler uses this specification to
generate code that the application can use to create, read, update and delete da-
tabase entries, effectively treating the template as a "scaffold" on which to build
a more powerful application. [39]
La possibilità di auto-generazione delle parti di codice CRUD 1permette di ottenere un prototipo funzionante in brevissimo tempo: dopo un’attenta modellazione database in Ca- kePHP è infatti sufficiente invocare da console il comando bake per ottenere rapidamente il codice di base di modelli, controller e view su cui poter cominciare a lavorare. Tale automa- tismo permette di evitare molti banali errori umani e minimizzare il tempo necessario per la stesura delle sezioni di codice ripetitivo.
Apprendimento Considerate le tempistiche del progetto è stato necessario valutare anche la difficoltà insita in ciascun framework e le relative curve d’apprendimento; in tale compito sono stati di estremo aiuto articoli e recensioni reperibili in rete oltre naturalmente alla documentazione ufficiale accompagnante ogni framework.
Qualità della documentazione Considerando che i framework PHP sono in massima parte progetti relativamente giovani (nell’ordine dei 3-4 anni) è necessario valutare la presenza e la qualità di documentazione a supporto delle librerie e componenti fornite.
Community di supporto Considerata la natura in continuo sviluppo della stragrande maggioranza dei framework considerati è bene valutare l’attività e la qualità delle community
1Create, read, update and delete (CRUD) are the four basic functions of persistent storage. Sometimes CRUD is expanded with the words retrieve instead of read or destroy instead of delete. It is also sometimes used to describe user interface conventions that facilitate viewing, searching, and changing information; often using computer-based forms and reports. [38]
65 5.1. PHP FRAMEWORK CAPITOLO 5. STRUMENTI UTILIZZATI
Figura 5.1: Google Trends: comparazione framework PHP al 26.11.2009 orbitanti attorno a ciascun framework, in maniera da poter valutare lo stato di salute dei progetti ed avere supporto in caso di eventuali problemi non risolvibili autonomamente.
5.1.2 CakePHP (v. 1.2.5)
CakePHP è il framework scelto per il sistema Infostudenti. Si procede quindi con una panoramica delle caratteristiche peculiari che hanno portato a preferirlo nei confronti dei concorrenti.
Ruby on Rails Il framework CakePHP è stato progettato riprendendo molti aspetti del più famoso Ruby on Rails [41] per il linguaggio Ruby. Tale framework ha ispirato una buona parte dei framework PHP oggi esistenti, rappresentando un punto di svolta nel mondo dello sviluppo web. Purtroppo presunti problemi di performance [42] e scalabilità [43] del linguaggio Ruby hanno ridotto la sua capacità di adozione: ciononostante ha avuto il grande pregio di avere aperto e favorito la strada a framework scritti in altri linguaggi ma con le medesime caratteristiche e funzionalità. Da Ruby on Rails CakePHP riprende i paradigmi
• DRY ("Don’t Repeat Yourself ”): le definizioni devono essere poste una volta soltanto
• "Convention Over Configuration": lo sviluppatore deve aver bisogno di mettere mano
alla configurazione soltanto per ciò che differisce dalle convenzioni
Active Record Pattern
66 CAPITOLO 5. STRUMENTI UTILIZZATI 5.1. PHP FRAMEWORK
In software engineering, the Active Record Pattern is a design pattern found in
software that stores its data in relational databases. It was named by Martin
Fowler in his book “Patterns of Enterprise Application Architecture” [45]. The
interface to such an object would include functions such as Insert, Update, and
Delete, plus properties that correspond more-or-less directly to the columns in the
underlying database table. [. . . ] Active record is an approach to accessing data
in a database. A database table or view is wrapped into a class; thus an object
instance is tied to a single row in the table. [44]
CakePHP implementa ed estende il pattern ORM tramite una parziale l’implementazione di Active Record Pattern nei propri Model. L’accesso al database o ad una generica base dati viene quindi regolarizzato da apposite chiamate di libreria fornite dal framework, che permettono di mantenere l’indipendenza dal data layer sottostante.
Debug Il framework integra un buon tool di debug che permette la visualizzazione dello stack corrente e delle query generate dall’ORM. Tramite un apposito plugin2 è poi possibile ottenere statistiche e profiling3 del codice in maniera da poter ottimizzare il sistema e rilevare eventuali colli di bottiglia.
Motivi di scelta Il framework soddisfa la totalità dei requisiti posti in origine: architettura
MVC, autenticazione tramite il component AuthComponent, ORM, validazione e sanitizza- zione dei dati, oltre ad implementare e ampliare lo scaffolding classico tramite ulteriori utility di supporto (cfr. 5.1.1 nella pagina 65) allo sviluppatore per azioni ripetitive o meccaniche; rappresenta infine un buon compromesso tra potenza espressiva e difficoltà d’apprendimento, gode di grande popolarità e la documentazione è di buona qualità.
5.1.3 Zend Framework (v. 1.9.6)
Tra i framework qui elencati Zend Framework rappresenta sicuramente quello che più si av- vicina ad un mero insieme di librerie più che ad una piattaforma di sviluppo: con questo non
2CakePHP Debug Kit, http://thechaw.com/debug_kit 3In software engineering, program profiling, software profiling or simply profiling, a form of dynamic program analysis (as opposed to static code analysis), is the investigation of a program’s behavior using information gathered as the program executes. The usual purpose of this analysis is to determine which sec- tions of a program to optimize - to increase its overall speed, decrease its memory requirement or sometimes both. [24]
67 5.1. PHP FRAMEWORK CAPITOLO 5. STRUMENTI UTILIZZATI si voglia intendere che non sia un vero framework ma solamente che tale scelta progettuale ha contribuito a renderne l’uso più difficoltoso, dato che Zend Framework è configurabile in ogni sua forma proprio per permettere l’uso di singoli componenti. Al contrario degli altri framework offre infatti librerie per un gran numero di attività e architetture comuni, senza però obbligarne l’uso di una o tutte le parti (al contrario ad esempio di CakePHP che, a meno di particolari work-around, impone una scelta “o tutto o niente”).
Da una parte la possibilità estrema di configurazione rappresenta sicuramente un grande vantaggio, dall’altro rende però più difficoltoso l’apprendimento e la ricerca di esempi o documentazione per compiti specifici. Resta poi il fatto che la scelta di un framework è dettata in parte anche dalle preferenze dello sviluppatore e dalle tempistiche di sviluppo: nel caso di Infostudenti si è deciso di favorire un framework con convenzioni ben definite alle quali aderire, in maniera da sfruttare al massimo il tempo disponibile per lo sviluppo.
5.1.4 CodeIgniter (v. 1.7.2)
La caratteristica principale di CodeIgniter è data dalla velocità di esecuzione e dall’estrema leggerezza (low footprint). Lo stesso creatore di PHP, Rasmus Lerdorf, noto avversatore dei framework, lo preferisce “because it is faster, lighter and the least like a framework” [46].
CodeIgniter non è stato però scelto per la mancanza di caratteristiche indispensabili quali scaffolding, ORM ed autenticazione.
5.1.5 Ulteriori framework
Con tale breve panoramica non si ha certo la pretesa di esaurire l’ampio panorama dei framework PHP ma semplicemente illustrarne i protagonisti. Esistono infatti altri framework minori che sulla carta promettono quanto o più di CakePHP ma non se ne è considerato l’utilizzo principalmente per motivi di giovinezza o possibilità di discontinuazione di supporto a medio/lungo periodo. Si ritiene comunque che per poter giudicare in pienezza strumenti complessi quali i framework sia necessario avere sviluppato almeno un progetto con ciascuno di essi.
68 CAPITOLO 5. STRUMENTI UTILIZZATI 5.2. DATABASE
Figura 5.2: Comparazione framework PHP al 26.11.2009 [23]
5.2 Database
Si procede con una breve dissertazione sui motori di storage offerti dal RDBMS4 MySQL e dei motivi che hanno portato alla scelta di InnoDB.
5.2.1 Transazioni
Come illustrato nel diagramma riportato le transazioni rappresentano una peculiarità di alcuni database capaci di atomicizzare più azioni, in senso più pratico più query consecuti- ve. Ciò significa che l’esito di una sequenza di operazioni è dato dall’esito di ciascuna delle operazioni contemplate: in caso anche solo una di queste dovesse concludersi con insucces- so si deve tornare allo stato consistente precedente all’inizio della transazione per evitare l’insorgere di qualsiasi tipo di inconsistenze.
4A relational database management system (RDBMS) is a database management system (DBMS) that is based on the relational model as introduced by E. F. Codd. Most popular commercial and open source databases currently in use are based on the relational model. [40]
69 5.2. DATABASE CAPITOLO 5. STRUMENTI UTILIZZATI
Figura 5.3: Il diagramma di una transazione
In caso venga rilevato un qualsiasi errore tra le azioni il cui svolgimento è richiesto essere atomico, invocando il rollback è possibile portare il database alla situazione antecedente, evitando così possibili situazioni di inconsistenza dei dati. Se invece la sequenza di azioni si conclude senza aver riscontrato problemi è possibile effettuare il commit, ossia la conferma della transazione e il conseguente definitivo salvataggio del nuovo stato della base dati.
5.2.2 ACID
Per i motivi riportati di consistenza ed integrità dei dati è stato necessario selezionare uno storage engine ACID-compliant, ossia un motore le cui le transazioni (e i meccanismi che le implementano) soddisfino queste 4 proprietà[36]:
• Atomicità: la transazione è indivisibile nella sua esecuzione e la sua esecuzione deve
essere o totale o nulla, non sono ammesse esecuzioni parziali
• Coerenza: quando inizia una transazione il database si trova in uno stato coerente e
quando la transazione termina il database deve essere in uno stato coerente, ovvero non
deve violare eventuali vincoli di integrità, quindi non devono verificarsi contraddizioni
(inconsistency) tra i dati archiviati nel DB
• Isolamento: ogni transazione deve essere eseguita in modo isolato e indipendente
dalle altre transazioni, l’eventuale fallimento di una transazione non deve interferire
con le altre transazioni in esecuzione
70 CAPITOLO 5. STRUMENTI UTILIZZATI 5.2. DATABASE
Figura 5.4: Comparazione performance storage engine MySQL
• Durabilità: detta anche persistenza, si riferisce al fatto che una volta che una tran-
sazione abbia richiesto un commit, i cambiamenti apportati non dovranno essere più
persi. Per evitare che nel lasso di tempo fra il momento in cui la base di dati si impegna
a scrivere le modifiche e quello in cui li scrive effettivamente si verifichino perdite di
dati dovuti a malfunzionamenti, vengono tenuti dei registri di log dove sono annotate
tutte le operazioni sulla base dati
5.2.3 Database abstraction layer
CakePHP garantisce l’astrazione dallo specifico database layer, supportando un vasto gamma di database commerciali e non: MySQL, PostgreSQL, Firebird DB2, Microsoft SQL Server,
Oracle e SQLite [47]. Resta però da considerare come sia necessario un database con motore
ACID-compliant per permettere a CakePHP di gestire correttamente le transazioni.
MySQL rappresenta il database d’elezione per CakePHP, motivo che, oltre alla pre- cedente esperienza universitaria acquisita durante il corso di Basi di Dati, ha portato al restringimento della valutazione dei motori di storage offerti dal solo MySQL.
5.2.4 Comparazione motori di storage MySQL
InnoDB
InnoDB is a transaction-safe (ACID compliant) storage engine for MySQL that
has commit, rollback, and crash-recovery capabilities to protect user data. In-
71 5.2. DATABASE CAPITOLO 5. STRUMENTI UTILIZZATI
noDB row-level locking (without escalation to coarser granularity locks) and
Oracle-style consistent nonlocking reads increase multi-user concurrency and per-
formance. [...] To maintain data integrity, InnoDB also supports FOREIGN
KEY referential-integrity constraints. [15]
Grazie alle sue peculiarità InnoDB ha rappresentato la scelta ideale per le necessità di con- sistenza dell’intero software: chiavi esterne e transazioni hanno infatti rappresentato un requisito obbligatorio per la scelta dello storage engine. CakePHP lo supporta specifica- tamente tramite alcuni metodi nevralgici (cfr. 4.2), capaci di utilizzare le transazioni per salvare set di dati in modo atomico.
L’integrità referenziale è mantenuta tramite le seguenti possibili clausole, specificate all’atto della creazione o modifica di una tabella di database, rispettivamente per la modifica
(ON UPDATE) o la rimozione (ON DELETE) di valori:
• RESTRICT: impedisce la rimozione di valori dalla tabella madre se viene rilevata una qualsiasi relazione esistente con un’altra tabella per il valore per cui si è richiesta la
rimozione
• CASCADE: aggiorna i valori nella tabella figlia partendo dal valore della tabella madre
• SET NULL: imposta a NULL i valori relazionati nelle tabelle figlie
Sempre in un’ottica di integrità dei dati InnoDB è in grado di ovviare a possibili crash in tempi estremamente più brevi rispetto a MyISAM, che deve preventivamente procedere con una scansione completa della tabella interessata, al contrario di InnoDB che può basare il recovery su specifici log capaci di delimitare la zona interessata dal danno.
La recente acquisizione di Innobase (2005), la compagnia finlandese a capo dello svilup- po di InnoDB, da parte di Oracle, storica concorrente di MySQL sul mercato enterprise, ha gettato qualche ombra sul futuro dello storage engine: Oracle stessa ha però pronta- mente annunciato che “intends to continue developing the InnoDB technology and expand our commitment to open source software”[17], quindi non si è ritenuto rischioso procedere con lo sviluppo di Infostudenti sulla base di InnoDB. Si ricorda inoltre che in caso di qual- siasi problema grazie all’object relational mapper è possibile cambiare data layer in modo trasparente al soprastante sistema software.
72 CAPITOLO 5. STRUMENTI UTILIZZATI 5.2. DATABASE
MyISAM
MyISAM is the default storage engine. It is based on the older ISAM code
but has many useful extensions. [...] All numeric key values are stored with
the high byte first to allow better index compression. [...] [14]
MyISAM rappresenta il motore di storage di default di MySQL e viene utilizzato nel data- base della precedente versione del software. A suo vantaggio ha l’estrema velocità, l’esigua richiesta di risorse di sistema e una capacità di compressione dei dati maggiore rispetto ad InnoDB, al contrario del quale però non supporta chiavi esterne e transazioni, motivo principe che ha portato a scartarlo per l’uso in Infostudenti.
Falcon
Falcon combines the world’s most popular open source database with a modern
transactional engine designed especially for high-traffic, online, transactional ap-
plications and systems storing information such as pictures and scanned docu-
ments. Falcon in MySQL Server 6.0 is a next-generation engine designed to
make optimal use of modern large-memory multi-CPU/multi-core hardware. It
is fully ACID, MVCC-compliant 5, and supports online parameters, tablespaces,
automatic file extension/space reclamation, and distributed transactions. [30]
Falcon sulla carta rappresenta un passo oltre InnoDB, purtroppo si è dovuto scartarlo pre- liminarmente per motivi di gioventù (verrà ufficialmente rilasciato solo con la prossima versione di MySQL). In aggiunta il framework scelto non lo supporta ufficialmente.
5.2.5 Migrazione dati
Per la migrazione dei dati dal vecchio al nuovo sistema si è creata una classe PHP atta allo scopo. Tale classe permette di migrare i dati secondo i nomi dei nuovi campi adottati, provvede alla conversione dei campi booleani ed è capace di effettuare il merge dei dati di più tabelle, eventualmente tramite l’utilizzo di appositi flag booleani (cfr. 4.1.2). Si faccia riferimento al file utils/DB/SchemaMigrator.class.php per maggiori informazioni. 5Multiversion concurrency control (abbreviated MCC or MVCC), in the database field of computer scien- ce, is a concurrency control method commonly used by database management systems to provide concurrent access to the database. MVCC provides each user connected to the database with a "snapshot" of the data- base for that person to work with. Any changes made will not be seen by other users of the database until the transaction has been committed.
73 5.3. JAVASCRIPT FRAMEWORK CAPITOLO 5. STRUMENTI UTILIZZATI
Ci si è poi avvalsi di una apposita procedura SQL [26] per il rilevamento delle violazioni delle chiavi esterne che sono state evidenziate dopo il passaggio ad InnoDB. Tramite il suo ausilio si è poi proceduto con la bonifica di quelle correggibili e la rimozione di quelle non risolvibili.
5.3 Javascript framework
Parallelamente al framework PHP si è scelto di uilizzare un framework Javascript per stan- dardizzare lo sviluppo del codice client-side. La scelta del framework Javascript è stata particolarmente rilevante considerato il requisito di velocizzazione espresso dal committen- te, non ottenibile in altra maniera che con il caricamento asincrono di parti di pagina e l’utilizzo estensivo di tecniche di manipolazione dinamica del DOM.
5.3.1 Benefici derivanti dall’utilizzo di un framework Javascript
Si elencano una serie di vantaggi ottenibili dall’adozione di un framework Javascript.
DOM elements selectors, traversal and manipulation Grazie a sintassi modellate in parallelo a quella dei CSS, i framework Javascript permettono un accesso più semplice, rapido e preciso agli elementi del DOM, che possono poi essere manipolati tramite specifiche funzioni ausiliarie solitamente fornite dai framework
Compatibilità cross-browser I framework si occupano di gestire e risolvere le incongruen- ze tra browser differenti, offrendo allo sviluppatore una base consistente e comune; in questa maniera è possibile concentrarsi sugli aspetti di business logic dell’applicazione e non sui workaround necessari per ovviare alle inconsistenze tra browser e piattaforme differenti.
Parsing Gran parte dei framework si occupano del parsing automatico di vari formati di
file: in tale maniera è possibile ad esempio delegare il compito del parsing di file JSON ricevuti via AJAX ed ottenere in ritorno degli oggetti Javascript preventivamente popolati con i dati ricevuti.
74 CAPITOLO 5. STRUMENTI UTILIZZATI 5.3. JAVASCRIPT FRAMEWORK
Effetti grafici In questi ultimi anni grazie al progressivo miglioramento delle capacità dei motori Javascript si è potuto assistere ad una riduzione degli effetti grafici e di animazione sviluppati con tecnologia Flash per assistere ad un boom degli effetti basati su Javascript, effetti che, al contrario di quelli basati su Flash, solitamente permettono di mantenere un alto grado di accessibilità: tramite il loro uso è infatti possibile far degradare correttamente una pagina HTML in caso di assenza delle tecnologie necessarie per il loro funzionamento, mantenendo nel contempo l’accessibilità dei contenuti. Gran parte dei framework Javascript integrano la possibilità di applicare effetti d’animazione agli elementi HTML.
5.3.2 jQuery (v. 1.3.2)
La libreria JQuery [31] rappresenta un buon compresso tra facilità d’uso, quantità e qualità di documentazione e performance di utilizzo. Tale libreria viene utilizzata da colossi quali
Google, Dell, Digg, NBC, CBS, Mozilla, Technorati ed è integrata in progetti open-source di grande fama e spessore quali Wordpress e Drupal. E’ inoltre sostenuta da una fiorente comunità di supporto, rappresentando al giorno d’oggi la libreria d’elezione del web 2.06. E’ stata scelta per l’utilizzo in Infostudenti. jQuery UI La scelta di utilizzo di Jquery è stata favorita anche dall’esistenza di una sua libreria di appoggio denominata jQuery UI, specializzata nell’implementazione in puro
Javascript di RIA7.
jQuery UI provides abstractions for low-level interaction and animation, ad-
vanced effects and high-level, themeable widgets, built on top of the jQuery Ja-
vaScript Library, that you can use to build highly interactive web applications.
[55]
La libreria ha ormai raggiunto un buono stato di maturità ed è mantenuta ed aggiornata in contemporanea con jQuery. Permette di ottenere effetti solitamente ottenibili soltanto 6The term "Web 2.0" is commonly associated with web applications that facilitate interactive information sharing, interoperability, [...] and collaboration on the World Wide Web. Examples of Web 2.0 include web- based communities, hosted services, web applications, social-networking sites, [...]. A Web 2.0 site allows its users to interact with other users or to change website content, in contrast to non-interactive websites where users are limited to the passive viewing of information that is provided to them. [49] The term is closely associated with Tim O’Reilly because of the O’Reilly Media Web 2.0 conference in 2004 [50] 7Rich Internet applications (RIAs) are web applications that have most of the characteristics of desktop applications, typically delivered either by way of a standards based web browser, via a browser plug-in, or independently via sandboxes or virtual machines. Examples of RIA frameworks include Ajax, Curl, GWT, Adobe Flash/Adobe Flex/AIR, Java/JavaFX, Mozilla’s XUL and Microsoft Silverlight. [56]
75 5.3. JAVASCRIPT FRAMEWORK CAPITOLO 5. STRUMENTI UTILIZZATI
Figura 5.5: Esempio di utilizzo di jQuery UI per il datepicker di Infostudenti
in ambito desktop, quali drag-and-drop, finestre di dialogo modali, barre di scorrimento, calendari inline, tab.
5.3.3 Prototype (v. 1.6.1)
Nonostante la buona documentazione la libreria è stata scartata per motivi di performance
(cfr. 5.3.4), inoltre non integra effetti grafici (motivo per cui si appoggia ad ulteriori librerie esterne quali script.aculo.us8 o mootools9).
5.3.4 Comparazione performance
La scelta tra jQuery e Prototype è stata fatta in favore del primo per evidenti motivi di performance anche su browser datati o non standard quali Internet Explorer 6 e 7 [32].
8http://script.aculo.us/ 9http://mootools.net/
76 CAPITOLO 5. STRUMENTI UTILIZZATI 5.3. JAVASCRIPT FRAMEWORK
Figura 5.6: Esempio di utilizzo di jQuery UI per una finestra di dialogo modale
Figura 5.7: Comparazione performance framework Javascript
77 5.4. SCAMBIO DATI ASINCRONO CAPITOLO 5. STRUMENTI UTILIZZATI
Figura 5.8: Esempio di file in formato JSON
5.4 Scambio dati asincrono
5.4.1 AJAX ed XML
Come definito in 3.3 la X del termine AJAX corrisponde ad XML, poichè XML rappresenta il formato utilizzato in origine per lo scambio asincrono. Avendo ormai raggiunto la sua maturità, molti sviluppatori stanno però mettendo in discussione XML come formato di scambio in favore di formati terzi più leggeri o semplicemente con caratteristiche più spe- cifiche per particolari ambiti applicativi. Nel caso di Infostudenti si è ritenuto opportuno utilizzare altri formati di scambio, per motivi di leggerezza e conseguentemente velocità di reazione dell’interfaccia.
5.4.2 AJAJ: AJAX e JSON
JSON (JavaScript Object Notation) is a lightweight data-interchange for-
mat. It is easy for humans to read and write. It is easy for machines to parse
and generate. It is based on a subset of the JavaScript Programming Langua-
ge, Standard ECMA-262 3rd Edition - December 1999. JSON is a text format
that is completely language independent but uses conventions that are familiar to
programmers of the C-family of languages, including C, C++, C#, Java, Java-
Script, Perl, Python, and many others. These properties make JSON an ideal
data-interchange language. [33]
78 CAPITOLO 5. STRUMENTI UTILIZZATI 5.4. SCAMBIO DATI ASINCRONO
Vengono elencati alcuni dei motivi che hanno spinto alla preferenza di JSON nei confronti di XML [34].
Comparazione JSON - XML
• semplicità: JSON è sintatticamente più semplice e meno pesante (“less verbose”) di
XML, portendo vantare una grammatica ridotta e mappando i propri tipi direttamente
verso i tipi standard previsti dai più comuni linguaggi di programmazione
• estensibilità: JSON non è estensibile e non ha la pretesa di esserlo, dato che non è un
linguaggio di markup
• interoperabilità: JSON ha il medesimo potenziale di interoperabilità di XML
• apertura agli standard e alla modifica: JSON è aperto almeno quanto XML, forse
anche di più non essendo al centro di tentativi di standardizzazione
• parsing: il parsing di JSON può avvenire più rapidamente grazie alla sua caratteristica
di possedere una grammatica più piccola e semplice
• internazionalizzazione: entrambi i formati supportano Unicode10
• formato di scambio comune: JSON è migliore per lo scambio di dati e tipi usati nei
linguaggi di programmazione, mente XML è più adatto per lo scambio di documenti
(“use the right tool for the right job”)
Adozione nel sistema Per i motivi sopra riportati si è deciso di adottare JSON come formato utilizzato in gran parte degli scambi asincroni. Sia il framework PHP che quello
Javascript supportano nativamente tale formato.
5.4.3 AJAH: AJAX ed HTML
L’utilizzo di XML e JSON come formati di scambio dati implica il parsing client-side dei dati ricevuti dal server: se infatti viene ricevuto un array di elementi è necessario procedere al
10Unicode is a computing industry standard allowing computers to represent and manipulate text expressed in most of the world’s writing systems consistently. Developed in tandem with the Universal Character Set standard and published in book form as The Unicode Standard, the latest version of Unicode consists of a repertoire of more than 107,000 characters covering 90 scripts, [...] and bidirectional display order (for the correct display of text containing both right-to-left scripts, such as Arabic or Hebrew, and left-to-right scripts). [53]
79 5.5. CSS CAPITOLO 5. STRUMENTI UTILIZZATI parsing di tale array in maniera da creare una apposito elemento HTML che possa poi essere inserito nel DOM, con conseguente onero prestazionale a carico del client. Per ovviare a tale problema, in casi in cui non sia praticabile o estremamente dispendioso il parsing dei dati ricevuti dal server si è deciso di utilizzare direttamente l’HTML come formato di scambio. Il server quindi risponde asincronamente con frammenti di codice HTML che verranno iniettati nel DOM una volta ricevuti. Tale modalità di caricamento asincrono è più pesante dal punto di vista della quantità di dati scambiati ma ha semplificato enormemente il codice di gestione client-side; è importante dire poi che in alcune situazioni non è stato possibile procedere in altra maniera poichè effettuare il parsing dei dati ricevuti dal server avrebbe significato effettuare una duplicazione del codice PHP in linguaggio Javascript, in disaccordo con il principio DRY (cfr. 5.1.2 nella pagina 66).
5.5 CSS
Trattandosi di un progetto web-based si è posta particolare rilevanza all’aspetto grafico, così che l’uso di CSS è risultato la scelta naturale. In particolar modo è risultato opportuno abbandonare il layout basato su tabelle per approdare ad una pagina totalmente table- less, proprietà che ha poi anche facilitato la stampa di qualsiasi pagina del sistema, grazie all’utilizzo di appositi fogli di stile preimpostati per la stampa. Per motivi di performance e di separazione dei contenuti l’intero codice CSS è stato inserito in appositi file esterni, evitando l’utilizzo di CSS inline e di gran parte del codice HTML che non avesse valenza semantica.
5.5.1 Blueprint CSS framework (v. 0.9.1)
Si è deciso di utilizzare un framework CSS per eliminare quanto più possibile le discrepanze di visualizzazione tra browser. I framework CSS altro non sono che fogli di stile di base particolarmente attenti ai workaround necessari per ottenere consistenza grafica tra browser differenti. Grazie a Blueprint11 si è inoltre potuto contare su una griglia basata su CSS così da facilitare il lavoro di restyling grafico, che comunque non rientra nelle competenze del refactoring ma che potrà essere affidato ad apposito studio grafico esterno.
11http://www.blueprintcss.org/
80 CAPITOLO 5. STRUMENTI UTILIZZATI 5.6. LIBRERIE DI ESPORTAZIONE
5.5.2 Stampa
L’utilizzo esclusivo di CSS per il layout ha permesso di evitare la creazione di viste progettate appositamente per la stampa: è stato infatti sufficiente creare un foglio di stile specifico e abilitato in sola fase di stampa.
5.5.3 Validazione W3C
Più dell’80% del codice HTML generato ha passato la validazione online W3C (http:// validator.w3.org/).
5.6 Librerie di esportazione
La necessità di creazione di certificati ufficiali documentanti i piani di studio degli studenti ha imposto l’utilizzo di apposite librerie di esportazione. Per il momento sono state im- plementate le sole esportazioni in PDF ed RTF ma si è predisposto un metodo dell’helper
InfostudentiGenericHelper (public array certificato(&student)) 4.4.1 nella pagi- na 61 per facilitare implementazione di ulteriori librerie.
5.6.1 TCPDF (v. 4.8.16)
Ci si è avvalsi della libreria TCPDF12 per via del suo continuo aggiornamento e del pieno supporto di Unicode (cfr. 10 nella pagina 79). Da alcuni test preventivi si è rivelata essere anche estremamente veloce rispetto alle concorrenti FPDF13 ed R&OS 14. Per le sue buone capacità di conversione da HTML a PDF è inclusa in alcuni rilevanti progetti web quali
Drupal, Joomla e phpMyAdmin.
5.6.2 RTF (v. 0.3.0)
La necessità di esportazione in un formato modificabile con programmi di largo consumo ha imposto l’utilizzo del formato .doc di Microsoft Word: si è però ritenuto opportuno non legarsi a formati proprietari ed utilizzare il formato RTF, letto e modificato senza alcun problema dalla quasi totalità dei sistemi operativi odierni[52].
12http://www.tcpdf.org/ 13http://www.fpdf.org/ 14http://www.ros.co.nz/pdf/
81 5.7. PIATTAFORMA DI SVILUPPO CAPITOLO 5. STRUMENTI UTILIZZATI
La libreria PhpRtf 15 rappresenta lo standard de facto per la generazione di file RTF da linguaggio PHP, non esistendo veri e propri concorrenti degni di nota. La libreria è comunque ben documentata e completamente object-oriented, non ha dato particolari problemi e si è rivelata estremamente veloce nella generazione dei documenti, anche più della controparte
PDF (probabilmente per la struttura interna del formato RTF, sintatticamente più semplice di quella PDF).
5.7 Piattaforma di sviluppo
L’intero progetto è stato sviluppato su sistema operativo Mac OS X 10.6.1, server web
Apache 2.2.13, processore PHP 5.3.0 e browser Mozilla Firefox 3.5.3. L’utilizzo di tale browser ha permesso l’utilizzo dell’estensione Firebug16 (v. 1.4.5), capace di effettuare profiling e debug del codice Javascript, monitorare le richieste di rete (anche asincrone), favorire le attività di manipolazione del DOM e in generare semplificare le attività correlate allo sviluppo di applicazioni web.
5.8 Versionamento
Si è fatto uso di un sistema di controllo versione per il mantenimento degli avanzamenti del codice e la collaborazione tra lo studente e il referente esterno.
5.8.1 Subversion
Scartando a priori il vecchio CVS si è utilizzato un repository Subversion17 interfacciato tramite Trac18, un’interfaccia web-based di gestione dell’intero repository. Ciò ha permesso anche lo scambio di ticket tra il referente esterno e lo studente.
15http://www.phprtf.com/ 16http://getfirebug.com/ 17hosting offerto da svnrepository.com 18http://trac.edgewall.org/
82 CAPITOLO 5. STRUMENTI UTILIZZATI 5.9. VERIFICA E VALIDAZIONE
Figura 5.9: Esempio di unit testing mediante l’uso della struttura offerta da CakePHP
5.9 Verifica e validazione
Il lavoro di verifica accerta che l’esecuzione delle attività di processo non abbia introdotto errori, mentre quello di validazione accerta che il prodotto realizzato dai processi eseguiti corrisponda alle attese. Per tali scopi ci si è avvalsi dei tool di unit testing offerti dal framework CakePHP, che hanno permesso di predisporre più agevolmente gli opportuni test black-box.
5.9.1 Unit testing (analisi dinamica)
Il framework CakePHP fornisce i tool necessari per i test di unità del sistema tramite la libreria SimpleTest19, di cui lo studente ha precedente esperienza per il progetto di Ingegneria del Software. Lo stesso codice del framework è testabile accedendo all’URL /test.php, dalla cui interfaccia è possibile avviare i test sui singoli componenti del framework.
Modelli e controller Oltre alla possibilità di effettuare unit testing sul codice del fra- mework, CakePHP offre una suite di testing che facilita il lavoro dello sviluppatore tramite alcuni accorgimenti. Il principale di questi è dato dalle fixtures, dati di esempio utilizza- bili per poter effettuare test senza problemi di manipolazione o interferenza con quelli di produzione.
19http://www.simpletest.org/
83 5.10. DOCUMENTAZIONE CAPITOLO 5. STRUMENTI UTILIZZATI
5.10 Documentazione
Per la documentazione inline del codice ci si è avvalsi del tool phpDocumentor20. Tramite tale strumento si è ereditato da una parte uno stile di commentazione standardizzato e ben definito (PHPDoc21), dall’altra è stato possibile generare documentazione in formato HTML per ciascuna delle classi del sistema, rendendone più agevole la consultazione.
20http://www.phpdoc.org/ 21http://en.wikipedia.org/wiki/PHPDoc
84 Capitolo 6
Conclusioni
Scostamento dalla pianificazione delle attività Rispetto a quanto pianificato in fase di accettazione del progetto di stage vi è stato un leggero scostamento dovuto al minor tempo richiesto per la messa in opera dei tool di sviluppo, tempo che è stato quindi possibile investire per la creazione dello script di migrazione dei dati (utile per lavorare con una copia dei dati reali provenienti dal precedente sistema) e l’anticipo di parte del lavoro previsto per la settimana successiva. Durante le fasi finali si sono dovuti sacrificare alcuni giorni di verifica e validazione per destinarli alla revisione della documentazione del codice, aspetto sul quale il committente ha desiderato porre particolare attenzione in vista della scadenza dello stage.
Analisi critica del prodotto Ritengo di essere abbastanza soddisfatto del prodotto, anche se alcune scelte implementative non hanno potuto avere luogo causa la ristrettezza dei tempi: ad esempio considero non ottimale l’implementazione dell’ACL, che a mio parere dovrebbe essere maggiormente raffinata. Per i medesimi motivi di tempo non si è potuto procedere con un profiling accurato del software, così da rilevare eventuali colli di bottiglia o procedere con basilari tecniche di ottimizzazione delle performance.
Valutazione strumenti utilizzati Il framework CakePHP ha rappresentato un punto di svolta nelle mie abitudini di programmazione, riuscendo ad automatizzare molti compiti ripetitivi e proni ad errori, ma soprattutto permettendomi di concentrare l’attenzione sulla
85 CAPITOLO 6. CONCLUSIONI logica di business e di conseguenza aumentare la mia produttività. Alla conclusione dello stage mi sento di padroneggiare buona parte del framework ma ritengo sia necessario del tempo ulteriore per poterlo conoscere nei dettagli; in particolare vorrei approfondirne lo studio di alcune parti del codice in maniera da poter aiutare nello sviluppo.
Utilizzo del prodotto Il committente stima di poter utilizzare il prodotto nel secondo trimestre dell’anno 2010.
Analisi critica del lavoro di stage Il lavoro di stage ha accresciuto la mia padronanza di utilizzo di molte delle odierne tecnologie riguardanti il web, oltre che fornirmi una visione di massima di come possa funzionare un software complesso quale Infostudenti. Il supporto da parte del tutor esterno, Ing. Stefano Gualtieri, è stato estremamente professionale e non ha fatto pesare le mie lacune riguardanti alcuni argomenti più specifici: a lui vanno i miei ringraziamenti per avermi permesso di lavorare su un progetto così ambizioso.
86 Bibliografia
[1] http://en.wikipedia.org/wiki/Code_refactoring
[2] http://en.wikipedia.org/wiki/Cross-site_scripting
[3] http://en.wikipedia.org/wiki/Access_control_list
[4] Golding David, Beginning CakePHP, Apress 2008
[5] Chan Kai - Omokore John - Miller Richard K., Practical CakePHP Projects, Apress
2008
[6] http://book.cakephp.org/view/12/Benefits
[7] http://en.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol
[8] http://en.wikipedia.org/wiki/Database_trigger
[9] http://en.wikipedia.org/wiki/CamelCase
[10] Matt Curry, Advanced CakePHP Tips, 2009 (http://www.pseudocoder.com/
free-cakephp-book)
[11] http://www.mysqlperformanceblog.com/2009/01/12/should-you-move-from-myisam-to-innodb/
[12] http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon%
20-benchmarks-part-1/
[13] http://dev.mysql.com/doc/refman/5.0/en/storage-engines.html
[14] http://dev.mysql.com/doc/refman/5.0/en/myisam-storage-engine.html
[15] http://dev.mysql.com/doc/refman/5.0/en/innodb.html
87 BIBLIOGRAFIA BIBLIOGRAFIA
[16] http://book.cakephp.org/view/12/Benefits
[17] http://www.oracle.com/innodb/index.html
[18] http://en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93controller
[19] http://book.cakephp.org/view/15/Controller-Extensions-Components
[20] http://book.cakephp.org/view/17/Model-Extensions-Behaviors
[21] http://book.cakephp.org/view/16/View-Extensions-Helpers
[22] http://en.wikipedia.org/wiki/Session_%28computer_science%29
[23] http://www.phpframeworks.com/
[24] http://en.wikipedia.org/wiki/Profiling_%28computer_programming%29
[25] http://en.wikipedia.org/wiki/Object-relational_mapping
[26] http://forge.mysql.com/tools/tool.php?id=11
[27] http://en.wikipedia.org/wiki/Multiversion_concurrency_control
[28] http://www.mysqlperformanceblog.com/2007/10/12/myisam-scalability-and-innodb-%
20falcon-benchmarks/
[29] http://en.wikipedia.org/wiki/Rollback_%28data_management%29
[30] http://www.mysql.com/news-and-events/on-demand-webinars/display-od-86.
html
[31] http://docs.jquery.com/Main_Page
[32] http://blog.creonfx.com/javascript/mootools-vs-jquery-vs-prototype-vs-yui-%
20vs-dojo-comparison-revised
[33] http://www.json.org/
[34] http://json.org/xml.html
[35] http://en.wikipedia.org/wiki/Foreign_key
88 BIBLIOGRAFIA BIBLIOGRAFIA
[36] http://it.wikipedia.org/wiki/ACID
[37] http://en.wikipedia.org/wiki/Software_framework
[38] http://en.wikipedia.org/wiki/Create,_read,_update_and_delete
[39] http://en.wikipedia.org/wiki/Scaffold_%28programming%29
[40] http://en.wikipedia.org/wiki/Relational_database_management_system
[41] http://rubyonrails.org/
[42] http://shootout.alioth.debian.org/u32q/benchmark.php?test=all&lang=
php&lang2=yarv&box=1#mandelbrot
[43] http://www.techcrunch.com/2008/05/01/twitter-said-to-be-abandoning-ruby-on-rails/
[44] http://en.wikipedia.org/wiki/Active_record_pattern
[45] http://books.google.com/books?id=FyWZt5DdvFkC&lpg=PA1&dq=Patterns%20of%
20Enterprise%20Application%20Architecture%20by%20Martin%20Fowler&pg=
PT187#v=onepage&q=active%20record&f=false
[46] http://www.sitepoint.com/blogs/2008/08/29/rasmus-lerdorf-php-frameworks-think-again/
[47] http://book.cakephp.org/view/28/Requirements
[48] http://en.wikipedia.org/wiki/Document_Object_Model
[49] http://lindipendente.splinder.com/post/15354690/World+2.0
[50] http://oreilly.com/web2/archive/what-is-web-20.html
[51] http://en.wikipedia.org/wiki/Ajax_%28programming%29
[52] http://en.wikipedia.org/wiki/Rich_Text_Format
[53] http://en.wikipedia.org/wiki/Unicode
[54] http://en.wikipedia.org/wiki/Database_trigger
[55] http://jqueryui.com/
89 BIBLIOGRAFIA BIBLIOGRAFIA
[56] http://en.wikipedia.org/wiki/Rich_Internet_application
[57] http://en.wikipedia.org/wiki/Web_application
[58] http://book.cakephp.org/view/474/Containable
[59] http://book.cakephp.org/view/174/Request-Handling
90 Elenco delle figure
3.1 Architettura MVC ...... 18
3.2 Architettura MVC implementata in CakePHP ...... 19
3.3 Funzionamento web-application (modello client-server) ...... 23
3.4 Diagramma di funzionamento tecnologia AJAX ...... 24
3.5 Diagramma di funzionamento di un generico Object Relational Mapping . . . 26
3.6 Diagramma di stato dei piani di studio ...... 27
3.7 Diagramma di stato per un piano di studi consigliato ...... 29
3.8 Diagramma di stato degli esami ...... 30
3.9 Diagramma di stato per la creazione di nuovi utenti ...... 31
3.10 Diagramma di stato per i crediti di un insegnamento ...... 32
3.11 Diagramma di stato per i crediti di una riga di piano di studi tipo C . . . . . 33
3.12 Diagramma di stato per i crediti di una riga di piano di studi tipo D . . . . . 35
4.1 Modellazione concettuale del database ...... 38
4.2 Modello precedente ...... 39
4.3 Stralcio di codice SQL commentato ...... 41
4.4 Modello relazione finale (completo di proprietà) ...... 43
4.5 Modello relazionale finale (solo chiavi primarie ed esterne) ...... 44
4.6 Gerarchia classe Model ed Helper ...... 45
4.7 Array Containable per il reperimento dei dati relativi ad un piano di studi . . 57
4.8 Organizzazione delle view basata sui tipi di richiesta ricevuti ...... 59
4.9 Esempio di utilizzo della classe FormHelper ...... 61
91 ELENCO DELLE FIGURE ELENCO DELLE FIGURE
5.1 Google Trends: comparazione framework PHP al 26.11.2009 ...... 66
5.2 Comparazione framework PHP al 26.11.2009 [23] ...... 69
5.3 Il diagramma di una transazione ...... 70
5.4 Comparazione performance storage engine MySQL ...... 71
5.5 Esempio di utilizzo di jQuery UI per il datepicker di Infostudenti ...... 76
5.6 Esempio di utilizzo di jQuery UI per una finestra di dialogo modale ...... 77
5.7 Comparazione performance framework Javascript ...... 77
5.8 Esempio di file in formato JSON ...... 78
5.9 Esempio di unit testing mediante l’uso della struttura offerta da CakePHP . . 83
92