Analisi e utilizzo di un framework per lo sviluppo di applicazioni web · 2018. 3. 12. · Michele Basile matr. ... studio: la realizzazione di un’applicazione web per lo scambio

Facoltà di Ingegneria Corso di Studi in Ingegneria Informatica

tesi di laurea

Analisi e utilizzo di un framework per lo sviluppo di applicazioni web

Anno Accademico 2011/2012 relatore Ch.mo prof. Marcello Cinque correlatore Ing. Fabio De Paolis candidato Michele Basile matr. 534/3239

…a tutte le persone che in questi anni mi hanno sostenuto…

Indice

Introduzione 1

1 Web Development Frameworks 3

1.1 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.1.1 Architettura Three-tier . . . . . . . . . . . . . . . . . . . . . . . 5

1.1.2 Model-View-Controller . . . . . . . . . . . . . . . . . . . . . . . 5

1.2 Tipologie di applicazioni web . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3 Piattaforme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

1.3.1 LAMP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.2 WISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.3.3 Java EE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4 I Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

1.4.1 Zend Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 13

1.4.2 Google Web Toolkit . . . . . . . . . . . . . . . . . . . . . . . . 16

1.4.3 Django . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2 Il framework Carassio 23

2.1 Perché Carassio? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.1.1 Vantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25

2.2 Il paradigma MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

iii


2.2.1 Vantaggi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.3 Piattaforma e tecnologie di sviluppo . . . . . . . . . . . . . . . . . . . . 28

2.4 Architettura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

2.4.1 Clientside . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.4.2 Serverside . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.4.3 Site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3 Caso di studio: Analisi e progettazione 38

3.1 Analisi e specifica dei requisiti . . . . . . . . . . . . . . . . . . . . . . . 39

3.1.1 Funzionalità . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.1.2 Diagramma dei casi d’uso . . . . . . . . . . . . . . . . . . . . . 48

3.2 Progettazione . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

3.2.1 Progettazione della base dati . . . . . . . . . . . . . . . . . . . . 50

3.2.2 Progettazione architetturale e intermedia . . . . . . . . . . . . . . 58

3.2.3 Progettazione di dettaglio . . . . . . . . . . . . . . . . . . . . . 59

4 Caso di studio: Sviluppo e testing 64

4.1 Installazione e configurazione del framework . . . . . . . . . . . . . . . 65

4.2 I moduli del framework . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

4.3 Esempi di codice . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68

4.3.1 Navigazione tra le cartelle . . . . . . . . . . . . . . . . . . . . . 68

4.3.2 Modifica dei permessi di accesso per una cartella . . . . . . . . . 72

4.3.3 Upload di uno o più file . . . . . . . . . . . . . . . . . . . . . . 75

4.4 Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

4.4.1 Test per il download di un file . . . . . . . . . . . . . . . . . . . 80

4.4.2 Test per la rinomina di una cartella . . . . . . . . . . . . . . . . . 81

4.4.3 Test per la creazione di un gruppo . . . . . . . . . . . . . . . . . 82

iv


4.5 Collaudo per il livello presentazione . . . . . . . . . . . . . . . . . . . . 84

Conclusioni e sviluppi futuri 86

Ringraziamenti 88

Bibliografia 90

v

Elenco delle figure

1.1.1 Layered Application Architecture . . . . . . . . . . . . . . . . . . . . . 4

1.1.2 Esempio di applicazione basata su architettura Three-tier [1] . . . . . . . 6

1.1.3 Struttura del pattern MVC [2] . . . . . . . . . . . . . . . . . . . . . . . . 7

1.2.1 Java Web Frameworks [3] . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.1 Lo stack LAMP [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.4.1 Architettura di una applicazione sviluppata con GWT [10] . . . . . . . . 18

1.4.2 Piattaforma di riferimento per il framework Django [12] . . . . . . . . . 21

2.1.1 Logo del framework Carassio . . . . . . . . . . . . . . . . . . . . . . . . 24

2.2.1 Il paradigma MVC nel framework Carassio [14] . . . . . . . . . . . . . . 27

2.4.1 UML Component Diagram per Carassio Clientside . . . . . . . . . . . . 30

2.4.2 UML Component Diagram per Carassio Serverside . . . . . . . . . . . . 30

2.4.3 Carassio plugin: esempio di applicazione per la gestione di album foto-

grafici . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4.4 Smarty Template Engine [15] . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1.1 Diritti di accesso per operatori aziendali e partner . . . . . . . . . . . . . 41

3.1.2 Esempio per uno studio medico . . . . . . . . . . . . . . . . . . . . . . . 42

3.1.3 Notifiche via email: scadenza e caricamento di un file . . . . . . . . . . . 45

3.1.4 UML Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . 49

vi


3.2.1 Diagramma ER . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

3.2.2 Diagramma ER ristrutturato . . . . . . . . . . . . . . . . . . . . . . . . 55

3.2.3 Diagramma delle tabelle . . . . . . . . . . . . . . . . . . . . . . . . . . 56

3.2.4 UML Component Diagram iniziale per FileShare . . . . . . . . . . . . . 58

3.2.5 UML Class Diagram per il Model . . . . . . . . . . . . . . . . . . . . . 60

3.2.6 Layout dell’applicazione . . . . . . . . . . . . . . . . . . . . . . . . . . 62

3.2.7 UML Component Diagram finale per FileShare . . . . . . . . . . . . . . 63

4.1.1 Struttura delle cartelle di un progetto . . . . . . . . . . . . . . . . . . . . 65

4.3.1 FileShare: Area personale . . . . . . . . . . . . . . . . . . . . . . . . . . 69

4.4.1 Esecuzione test di unità per la classe fs_file . . . . . . . . . . . . . . . . 81

4.5.1 Firebug: Analisi HTML . . . . . . . . . . . . . . . . . . . . . . . . . . . 84

4.5.2 Firebug: monitoring delle richieste HTTP . . . . . . . . . . . . . . . . . 85

vii

Elenco delle tabelle

1.1 Piattaforme web a confronto [4] . . . . . . . . . . . . . . . . . . . . . . 9

1.2 Caratteristiche di Zend Framework . . . . . . . . . . . . . . . . . . . . . 14

3.1 Dizionario dei dati: Entità . . . . . . . . . . . . . . . . . . . . . . . . . 51

3.2 Dizionario dei dati: Relazioni . . . . . . . . . . . . . . . . . . . . . . . . 52

3.3 Attributi per le entità . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52

3.4 Attributi per le relazioni . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4.1 Principali moduli di riferimento per i controllori . . . . . . . . . . . . . . 67

viii

Introduzione

Al giorno d’oggi lo scenario applicativo che abbiamo di fronte è piuttosto ampio, sia per

l’eterogeneità dei settori verso i quali questo è rivolto, sia per il sempre più crescente

numero di persone che si approccia alle nuove tecnologie. Malgrado tale vastità, si è vi-

sta una complessiva e graduale trasformazione dei prodotti software in generale. Questo

perché Internet, insieme ai più recenti strumenti web, da un lato ci ha aperto a nuove possi-

bilità e dall’altro permesso di ristrutturare applicazioni inizialmente create per l’ambiente

desktop.

Testimone di questo cambiamento è la NAXE, società impegnata nel settore del web en-

gineering, presso la quale è stata svolta l’attività di tirocinio. Infatti, se nel passato veni-

vano commissionati progetti per lo sviluppo di applicazioni da eseguire in locale, adesso

la tendenza è quella di offrire ai clienti soluzioni web, spesso anche molto articolate.

In questo contesto dunque, appare evidente come si necessiti di strumenti atti a gover-

nare la complessità di dette applicazioni. Tra questi assumono particolare rilievo i fra-

mework, nati appunto per consentire agli sviluppatori di concentrare i loro sforzi sulle ri-

chieste dell’applicazione, piuttosto che sui vari meccanismi di più basso livello necessari

al funzionamento del sistema.

Obiettivo di questa tesi è quindi quello di far luce sulle differenti soluzioni adottate in

questo particolare ambito, mettendo in risalto i benefici ottenibili da ognuna di esse. Ci si

soffermerà in particolare su quella realizzata e utilizzata da Naxe, il framework Carassio,

mediante cui è stata portata a termine la fase di sviluppo inerente un ben preciso caso di

studio: la realizzazione di un’applicazione web per lo scambio di file. La tesi si compone

1


di quattro capitoli.

Il primo di questi espone per via del tutto generale il discorso sui framework per il web

development, tenendo presenti quelle che sono oggi le suite più rilevanti.

Il secondo capitolo è dedicato al framework Carassio. Saranno date le motivazioni per

tale scelta e approfondite le tematiche concerni la sua architettura.

Il terzo e quarto, invece, faranno riferimento ad un caso di studio. Ripercorrendo le fasi

tipiche del ciclo di vita del software, cioè partendo dall’analisi dei requisiti fino al te-

sting, si mostrerà come è stato possibile, grazie all’impiego del framework, realizzare

un’applicazione web inserita nel contesto del filesharing.

Seguiranno delle considerazioni personali sul lavoro svolto e possibili soluzioni per sce-

nari futuri.

2

Capitolo 1

Web Development Frameworks

In termini del tutto generali, un framework è una struttura di supporto su cui un software

può essere organizzato e progettato. Può essere visto come un’astrazione attraverso cui

vengono fornite funzionalità generiche a una specifica applicazione. Mette a disposizione

una collezione di librerie software utilizzabili con uno o più linguaggi di programmazione

e in molti casi, anche degli strumenti di sviluppo, come ad esempio un IDE o un debugger.

Più specificatamente, nell’ambito del web development, un framework è progettato per

sostenere lo sviluppo di siti web dinamici, applicazioni web e servizi web, con lo scopo

di alleviare l’overhead associato alle attività più comuni. Molti sono i framework che, per

esempio, forniscono librerie per l’accesso ai database, piattaforme di templating e session

management.

1.1 Architettura

Prima che vengano riportate alcune tra le soluzioni più annoverate nell’ambito dei fra-

mework per il web development, è necessario fare riferimento sulle scelte architetturali

maggiormente adottate. Queste infatti rappresentano, per l’inizio di un progetto, una

fase fondamentale per il processo di sviluppo e possono dare un notevole contributo al

successo o al fallimento del progetto stesso.

3


Figura 1.1.1: Layered Application Architecture

Gestire un progetto per il quale è stato previsto uno sviluppo non strutturato e mono-

litico potrebbe essere molto difficoltoso, se non impossibile. Tipici problemi di questo

approccio sono la cattiva distribuzione del lavoro all’interno del team di sviluppo, lo stra-

volgimento a livello implementativo in caso di variazione dei requisiti o introduzione di

nuove funzionalità e l’onere che si riscontra durante le fasi di testing.

Per ovviare a queste problematiche nel tempo sono stati introdotti diversi paradigmi, pri-

mo tra tutti il Layered Application Architecture. Secondo quest’ultimo un sistema soft-

ware è suddiviso in tre distinti livelli, ognuno dei quali porta a termine un determinato

compito, senza interferire con gli altri ma scambiando con essi le informazioni necessarie

all’esecuzione di elaborazioni anche molto complesse.

I tre livelli sono quelli rappresentati nella Figura 1.1.1:

• Livello di Presentazione, ha il compito di interagire direttamente con l’utente del

sistema, acquisire i dati di input immessi da quest’ultimo e visualizzare i risul-

tati dell’elaborazione effettuata dal sistema stesso. In sostanza, definisce la GUI

(Graphic User Interface) ossia l’interfaccia grafica dell’applicazione;

• Livello Applicativo, implementa la logica di business dell’applicazione ed è per

4


questo il centro dell’elaborazione dei dati;

• Livello di Gestione Dati, si occupa della gestione della persistenza e dell’accesso

ai dati, per cui è tipicamente caratterizzato da un DBMS (DataBase Management

System).

Come si intuisce da questa schematizzazione, ogni livello è indipendente dagli altri e

quindi la modifica di uno di essi non ha effetto sui restanti. Resta comunque possibile la

comunicazione e lo scambio di informazioni tra essi.

Questo paradigma ben si sposa con l’architettura Client-Server tipica dei sistemi web,

trovando applicazione in due delle più famose architetture, quella Three-tier e quella MVC

(Model-View-Controller).

1.1.1 Architettura Three-tier

A seconda di come i livelli scambino tra di loro informazioni, si ha una diversa topologia

architetturale.

Come si può vedere dalla Figura 1.1.2, un’applicazione basata su architettura three-tier è

suddivisa in livelli che sono costruiti l’uno sopra l’altro, analogamente a quanto avviene

per il modello ISO/OSI. È da notare quindi come il livello di presentazione non comunichi

mai direttamente con quello dati. Questo perché appunto lo scambio di informazioni

avviene sempre tra un determinato livello e quello immediatamente superiore/inferiore.

1.1.2 Model-View-Controller

Sebbene al momento esistano numerosi framework per il web development, tutti grosso

modo fanno riferimento al pattern architetturale MVC. Originariamente impiegato dal

linguaggio Smalltalk, è oggi un punto di riferimento per moltissimi framework, siano

essi basati su PHP (Symfony, Zend Framework, CakePHP), su Ruby (Ruby on Rails), su

5


Figura 1.1.2: Esempio di applicazione basata su architettura Three-tier [1]

Python (Django, TurboGears, Pylons, Web2py), su Java (Swing, JSF, Struts), su Objective

C o su .NET.

Il pattern si basa sulla separazione dei compiti fra i componenti software che interpretano

tre ruoli principali:

• il model fornisce i metodi per accedere ai dati utili all’applicazione;

• la view visualizza i dati contenuti nel model e si occupa dell’interazione con utenti

e agenti;

• il controller riceve i comandi dell’utente (in genere attraverso la view) e li attua

modificando lo stato degli altri due componenti.

Come si può vedere dalla Figura 1.1.3, differentemente da quanto avveniva nell’archi-

tettura Three-tier, dove tutte le comunicazioni dovevano passare attraverso il livello in-

6


Figura 1.1.3: Struttura del pattern MVC [2]

termedio, nel pattern MVC lo scambio di informazioni avviene mediante una topologia

triangolare.

Si badi però che quella mostrata in figura, è una struttura in cui le interazioni tra i tre

oggetti software dipendono molto dalle tecnologie usate (linguaggio di programmazio-

ne, eventuali librerie, middleware e via dicendo) e dal tipo di applicazione (per esempio

se si tratta di un’applicazione web, o di un’applicazione desktop). Essa deve pertanto

considerarsi un semplice riferimento e non un dogma a cui attenersi.

Nel seguito quindi, particolarizzeremo tale struttura per poterla adattare allo specifico

contesto cui faremo riferimento.

1.2 Tipologie di applicazioni web

Scegliere un framework da adottare per lo sviluppo di applicazioni web può essere diffi-

coltoso. Si potrebbe pensare che esistano delle migliori soluzioni in assoluto. In realtà,

una giusta comparazione andrebbe fatta in riferimento alle proprie esigenze. Bisogna dun-

que capire quali sono i requisiti della specifica applicazione, innanzitutto identificandone

la classe di appartenenza.

Possiamo suddividere le applicazioni web nelle seguenti categorie, di cui verrà fornita una

breve descrizione.

7


Classical Web Application Si tratta di applicazioni tradizionali (e.g. Amazon) che fanno

largo uso di server-side scripting, per fornire un’interfaccia utente con struttura mul-

tipagina. La navigazione, che è quella tipica dei siti web, favorisce il bookmarking

e l’utilizzo dei classici bottoni indietro e avanti.

Rich Internet Application (RIA) Sono applicazioni che forniscono caratteristiche e fun-

zionalità tipiche dell’ambiente desktop, senza la necessità dell’installazione su di-

sco fisso. Poiché i dati vengono elaborati per lo più a livello client, queste applica-

zioni sono note per fornire interattività, multimedialità e velocità di esecuzione.

Rich Client Uniscono le caratteristiche tipiche delle applicazioni web classiche con quel-

le delle RIA. Tuttavia si distinguono da quest’ultime perché il loro scopo non è

fornire un’interfaccia utente dall’aspetto moderno, ma migliorare l’usabilità di un

contesto già diffuso e accettato.

CRUD Questa tipologia è conforme alle applicazioni web classiche. Tuttavia, offre in

primo luogo funzionalità per creare, leggere, aggiornare ed eliminare i dati.

La Figura 1.2.1 mostra come, per esempio, sono distribuiti i framework basati su JVM

lungo le varie categorie appena citate.

Il concetto chiave si concretizza dunque nella frase: Right Tool for Right Job, ovvero il

giusto strumento (web framework) per il giusto lavoro (tipo di web application).

1.3 Piattaforme

Nella scelta di un framework, un altro aspetto di particolare rilievo è assunto dalle piatta-

forme sui cui fanno riferimento le applicazioni web.

Le piattaforme hanno caratteristiche differenti e pertanto occorre, prima di iniziare un

progetto, analizzare i vantaggi apportati da ognuna di esse.

Di notevole importanza sono le soluzioni LAMP, WISA e Java EE, di cui ne riportiamo

un confronto nella Tabella 1.1.

8


Fattore LAMP WISA JAVA EE

Costi di licenza - Nessun costo di licenza - Costi di licenza elevati - Nessun costo di licenza

Costi e opzioni di

supporto

- Gratuito attraversocommunity

- Disponibili opzioni di

supporto a pagamento







Sistemi operativi - Molteplici - Solamente Windows - Molteplici

Costi hardware - Funziona su server molto

economici

- Richiede server un po’

più costosi

- Richiede server molto

costosi

Personale - Un po’ difficile trovare

personale con elevate

competenze

- Molto facile trovare

personale qualificato,

seppur con limitate

competenze

- Ragionevolmente facile

trovare personale

qualificato

Hosting esterno - Ampiamente disponibile

e poco costoso

- Ampiamente disponibile,

ma più costoso

- Non ampiamente

disponibile

Sicurezza - Molto buona - Storicamente pessima,

ma di recente ha avuto

qualche miglioramento

- Buona

Prestazioni - Molto buone - Spesso richiede

hardware più costoso

- Spesso richiede una

notevole configurazione e

hardware costoso

Scalabilità - Altamente scalabile - Difficilmente scalabile - Ben scalabile quando

configurata correttamente

Amministrazione - Difficile: spesso richiede

lettura di documentazione

e modifica di file di testo

- Facile: spesso è attuata

mediante un’interfaccia

punta e clicca

- Moderata: a volte può

essere fatta visivamente

Configurazione e

facilità d’uso

- Può essere difficile da

configurare correttamente

- Facile da configurare - Moderatamente difficile

da configurare

Flessibilità di

configurazione

- Estremamente flessibile - Non molto flessibile - Moderatamente flessibile

Framework - Molti disponibili: spesso

è difficile fare una scelta

- Presenza di un

framework standardizzato

- Presenza di un

framework standardizzato

Componenti - Ampiamente disponibili - Ampiamente disponibili - Ampiamente disponibili

Compatibilità - Molto buona:

solitamente le nuove

versioni sono

retro-compatibili

- Moderata: spesso le

nuove versioni

interrompono le

funzionalità

- Pessima: ci sono molti

problemi tra le vecchie e

le nuove versioni

Tabella 1.1: Piattaforme web a confronto [4]

9


Figura 1.2.1: Java Web Frameworks [3]

1.3.1 LAMP

Il termine LAMP è stato coniato nel 1998 da Michael Kunze sulle pagine di c’t, una nota

rivista di informatica in lingua tedesca. Tale acronimo deriva dalle componenti Linux,

Apache, MySQL e PHP, tecnologie fondamentali per la costruzione di applicazioni libere,

economiche e distribuite.

I protagonisti di una applicazione LAMP sono dunque:

• il famoso sistema operativo GNU/Linux;

• Apache il più versatile ed usato web server al mondo;

• MySQL un potente database relazionale che si è imposto come "standard" per tante

applicazioni free software;

• PHP un linguaggio di scripting capace di adattarsi e rispondere alle più disparate

esigenze.

Sebbene rappresentino un riferimento, questi non sono gli unici a poter comporre una

applicazione LAMP. Basti pensare infatti che la "P" potrebbe stare per Python o Perl,

10


Figura 1.3.1: Lo stack LAMP [5]

o che l’acronimo potrebbe mutare in LAPP (PostgreSQL al posto di MySQL), WAMP

(Windows al posto di Linux), MAMP (Macintosh al posto di Linux) e altre combinazioni

ancora.

A prescindere dalle varianti, ciò che davvero conta è il fatto che tutte queste tecnologie

siano disponibili come software libero, quindi utilizzabili da chiunque senza restrizioni,

e che nel loro complesso formino una vera e propria piattaforma di sviluppo. Tale solu-

zione può trovare applicazione in numerosi campi: dal sito web, all’ufficio, alla pubblica

amministrazione. Non ha quindi nulla da invidiare rispetto a quelle proprietarie.

1.3.2 WISA

WISA è l’acronimo per il solution stack proposto da Microsoft, le cui lettere stanno per:

• Windows, ovvero il sistema operativo;

• Internet Information Services, file/web server entrato ormai a far parte della fami-

glia Windows Server;

• SQL Server, database managment system contraddistinto da elevata disponibilità e

buone prestazioni, largamente utilizzato sia in ambito enterprise che nei data center;

• ASP.NET, noto insieme di tecnologie di sviluppo software per il web, commercia-

lizzato appunto da Microsoft.

11


È contraddistinto da una serie di vantaggi quali: varietà di linguaggi, facilità di installa-

zione, varietà di supporto.

1.3.3 Java EE

Prodotta da Oracle, Java Enterprise Edition è una piattaforma riservata tipicamente al

business. Di fatto si impone come standard industriale per la realizzazione di applicazioni

di tipo enterprise e mission critical. Il risultato prodotto da questa piattaforma è dunque il

rilascio di applicazioni robuste, portabili, sicure e scalabili.

Tale obiettivo è raggiunto mediante la definizione di specifiche alle quali tutti i produttori

di software Java EE devono attenersi. Queste includono molte tecnologie che estendono le

funzionalità già previste dalla piattaforma Java. In particolare vengono descritti i seguenti

componenti:

• Gli Enterprise JavaBeans, che costituiscono il cuore della specifica e forniscono un

ambiente entro il quale vengono eseguiti gli oggetti di un’applicazione Java EE;

• Il JNDI, che fornisce un sistema per identificare e elencare risorse generiche, come

componenti software o sorgenti di dati;

• Il JDBC, che mette a disposizione un sistema standard di accesso ai dati;

• Il JTA, per supportare le transazioni distribuite;

• Il JAXP, per la gestione dei file in XML;

• Il Java Message Service, che consente l’invio e la gestione dei messaggi.

1.4 I Framework

Nel seguito verranno mostrate le caratteristiche di tre framework di spiccato interesse. In

particolare dedicheremo la nostra attenzione sulla soluzione Zend Framework, nata per

12


supportare lo sviluppo di applicazioni web PHP-based, su quella proposta da Google,

ovvero GWT, oggi notevole punto di riferimento per applicazioni web altamente interat-

tive, e su Django, framework basato sul linguaggio Python, che in ambito opensource sta

riscuotendo parecchio successo.

1.4.1 Zend Framework

Zend Framework (d’ora in poi ZF) è un web application framework open source creato

per semplificare e rendere più efficace sotto ogni punto di vista la produzione di appli-

cativi e servizi web PHP-based. Esso contiene un insieme di componenti riutilizzabili

che soddisfano i tipici requisiti richiesti da un’applicazione web. Tali componenti sono

interamente basate sul PHP, linguaggio di scripting che nella sua ultima versione, la 5, ha

abbracciato il paradigma OOP (Object Oriented Programming).

Ciò che differenzia ZF da altri framework PHP è la sua particolare struttura "a comparti-

menti stagni": l’indipendenza delle sue componenti permette di utilizzare solo il necessa-

rio per il proprio progetto, ma allo stesso tempo, se utilizzate insieme, esse si integrano in

un substrato incredibilmente potente e semplice da imparare, indirizzando il lavoro dello

sviluppatore verso soluzioni basate sui principi di riutilizzo del codice, di estensibilità,

leggibilità e manutenzione.

ZF è rilasciato sotto licenza BSD: questo permette al framework di essere inserito nella

maggior parte dei progetti, siano questi open source o proprietari, con le minori restrizioni

possibili per gli utilizzatori.

Come accennato in precedenza, è di vitale importanza capire che ZF non è la soluzione

a tutti i nostri problemi di sviluppo, e soprattutto non è l’unica alternativa: ogni progetto

ha i suoi requisiti e le sue caratteristiche, ed è solo dopo un attento studio di questi, an-

che in relazione alle alternative proposte, che possiamo decidere l’architettura del nostro

applicativo.

13


Tabella 1.2: Caratteristiche di Zend Framework

1.4.1.1 I Vantaggi

Perché dunque utilizzare Zend Framework? I concetti chiave su cui si basa questo fra-

mework sono i seguenti.

Rapidità e semplicità di sviluppo Zend Framework velocizza l’estensione o l’aggiunta

di nuove funzionalità per i nostri progetti web. La rapidità diventa evidente quan-

do dobbiamo implementare progetti che hanno bisogno di funzionalità aggiuntive:

generazione dinamica di pdf, l’invio di mail, la gestione dei form e del multilingua.

Tutto questo codice è già stato scritto e testato per noi, dunque tutto ciò che dob-

biamo fare è scrivere esclusivamente il codice necessario per il nostro applicativo,

includendo lì dove è necessario le classi messe a disposizione dal framework.

Design Moderno ZF è scritto interamente in PHP5 seguendo le tecniche della program-

mazione orientata ad oggetti ormai consolidate da anni e sfruttando moderne tec-

niche di design del software. Zend Framework fa un uso massiccio dei design

pattern per permettere la massima flessibilità agli sviluppatori alleggerendo di mol-

to il loro lavoro. Difatti, ogni componente all’interno del framework ha pochissime

dipendenze con ogni altro componente. Lo sviluppatore può usare solo le parte del

framework che sono strettamente necessarie al suo progetto.

Facilità di apprendimento La modularità e l’indipendenza dei componenti fanno si che

questi possano essere studiati separatamente, favorendo quindi l’apprendimento.

Documentazione completa Può sembrare poco rilevante, ma se riflettiamo sulla quan-

tità di tempo che perdiamo quando utilizziamo strumenti poco documentati risulta

chiaro il contrario. Per questo il team di sviluppo ha documentato in maniera at-

tenta e completa tutto il framework. Esistono inoltre due livelli di documentazione:

14


quella per l’utente finale e quella dedicata alle API (Application Program Interface)

per gli sviluppatori ZF.

Community Driven La costante crescita della community Zend Framework contribuisce

di molto alla diffusione di questa tecnologia: essa rappresenta la fonte principale

di ispirazione per lo studio di nuove funzionalità o per migliorare quelle esistenti,

giocando dunque un ruolo di primo piano in questo contesto.

1.4.1.2 Architettura

I componenti di Zend Framework possono essere raggruppati in sei macro categorie:

1. Core: Qui sono presenti tutti i componenti generici che non rientrano in nessuna

della altre categorie. Appartengono a questo gruppo, ad esempio, il componente

che si occupa della generazione dei file in formato PDF, quello che gestisce l’invio

di email e quello che gestisce il caching.

2. MVC: Rientrano tutti i componenti fondamentali per l’implementazione del pattern

MVC. Solitamente vengono impiegati quando un’applicazione è creata da zero con

ZF.

3. Autenticazione e accesso: Attraverso questi componenti si fornisce un meccani-

smo di autenticazione (solitamente realizzato mediante l’inserimento di una coppia

di token come user e password) e di controllo degli accessi.

4. Internationalization: Zend Framework supporta diversi livelli di internazionaliz-

zazione, permettendo di avere un controllo pressocché totale sulle impostazione

della localizzazione, sui set di caratteri e ovviamente sul multilingua.

5. Servizi Web: L’integrazione e la comunicazione tra web service è ormai di vitale

importanza per una web application: negli ultimi anni, soprattutto con l’avvento dei

social network, è diventato praticamente impossibile pensare ad una applicazione

che non sia in grado ad esempio di leggere un Feed RSS o di interfacciarsi con

15


Facebook, Flicker o Twitter. Zend Framework, sfruttando le caratteristiche della

sua struttura a componenti, permette di integrare rapidamente e in maniera asso-

lutamente trasparente qualsiasi tipo di web service: i componenti con il prefisso

Zend_Service sono proprio quelli che rientrano in questa categoria.

6. Interapplication communication: La comunicazione tra applicazioni viene im-

plementata principalmente attraverso tre tecniche: SOAP (Simple Object Access

Protocol), XML-RPC e REST (Representational State Transfer). Zend Framework

offre strutture solide per supportare sia questi formati sia soluzioni personalizza-

te in caso di requisiti particolari. Inoltre, per quelle applicazioni che si avvalgono

di Ajax, è stato introdotto il componente Zend_Json per gestire ogni aspetto della

comunicazione attraverso il protocollo JSON (JavaScript Object Notation), parti-

colarmente indicato per gestire il dialogo tra JavaScript e PHP nelle applicazioni

Ajax.

1.4.2 Google Web Toolkit

Molte persone conosceranno i servizi di Google. Tra questi vale la pena ricordare i famosi

GMail, Google Docs e Google Maps.

Alla base di queste web application c’è una tecnologia su cui Google ha iniziato ad in-

vestire molti anni fa: Google Web Toolkit (GWT), un framework di sviluppo Java con il

quale è possibile scrivere applicazioni AJAX tanto complesse quanto veloci, mantenendo

allo stesso tempo una fortissima compatibilità verso gli standard web.

1.4.2.1 AJAX, la colonna portante di GWT

Google ha dato una pronta risposta al tedioso problema incontrato dagli sviluppatori web:

il tempo speso per risolvere problemi di incompatibilità legati ai browser e la natura poco

modulare del linguaggio JavaScript.

16


Quest’ultimo infatti, sebbene sia dotato di ottime librerie che aiutano nello sviluppo di

web application (jQuery, Dojo, Scriptaculous, YUI e tante altre), pone dei forti limiti

a coloro che vogliano rendere le loro applicazioni scalabili in termini di dimensioni e

complessità. Se aggiungiamo a questo scenario la scarsa disponibilità di tool di sviluppo

e debugging, si intuisce quanto caro possa costare lo sviluppo di un’applicazione scritta

interamente in JavaScript.

D’altra parte questo linguaggio, grazie alle funzionalità che consentono chiamate HTTP

asincrone (XMLHttpRequest in particolare), ha dimostrato quanto fosse solida la tecnica

di sviluppo AJAX e di manipolazione del DOM.

Una applicazione web è scritta in Java ed il toolkit di Google la traduce in codice Java-

Script e HTML, generando una soluzione AJAX altamente aderente agli standard web,

consolidata e compatibile con tutti i browser.

Lo sviluppatore può quindi scrivere la propria web application con il suo IDE preferito

(Eclipse, NetBeans o altro), fare debug in ogni singolo punto dell’applicazione, integrarla

con librerie JavaScript di terze parti, testarla, compilarla e pubblicarla sotto forma di

file HTML e JavaScript. È sufficiente un semplice browser per vedere quale magnifico

risultato possiamo ottenere con un toolkit di tale potenza.

Fortissima interoperabilità e amore verso gli standard web: in questo modo Google è riu-

scita a trovare una soluzione brillante che tanti altri competitor (Adobe, Microsoft, Oracle

ed altri) sono riusciti a risolvere con soluzioni proprietarie ben lontane dalle specifiche

del W3C.

1.4.2.2 Il motore GWT

Nello sviluppo di questo framework i progettisti di Google hanno cercato di seguire le

seguenti linee guida:

• Programmare il codice client (UI inclusa) in linguaggio Java;

• Tradurre il codice Java in codice JavaScript;

17


Figura 1.4.1: Architettura di una applicazione sviluppata con GWT [10]

• Mantenere la compatibilità con i framework JavaScript e CSS di terze parti;

• Programmare la comunicazione client/server con il minimo sforzo, mantendendo

una forte compatibilità verso JSON e XML, così da garantire l’integrazione con

server di qualunque tipo (php, ruby, java, etc.);

• Facilitare la programmazione del codice server facendo leva sullo standard Java

delle Servlet;

• Fornire un framework in grado di facilitare la programmazione delle Rich Inter-

net Applications (Widget, Pannelli, Internazionalizzazione, comunicazione RPC,

History Management, etc.).

Da questi pochi requisiti è nato il Google Web Toolkit, che è oggi composto da questi

strumenti:

• Un compilatore da Java a JavaScript;

18


• Uno strato di Emulazione JRE (l’ambiente runtime Java), scritto interamente in

JavaScript;

• Una interfaccia per definire metodi nativi JavaScript (JSNI);

• Le GWT API: una suite di API Java pensate espressamente per l’implementazione

di client AJAX.

Se volessimo immaginare ad un semplice processo di sviluppo, potremmo dire che il

programmatore sviluppa il suo progetto di web application interamente in Java, con il

suo ambiente di sviluppo Java preferito. Il progetto è quindi testato con le JUnit e com-

pilato infine in JavaScript e HTML (si può immaginare facilmente una analogia con la

traduzione in bytecode Java).

Quando l’utente aprirà la pagina HTML, all’interno di un ambiente di runtime che emula

il JRE, le chiamate avverranno in realtà completamente in JavaScript. Potremmo dire che

questo è il meccanismo di base con il quale GWT è riuscito a coniugare la potenza di Java

con la flessibilità dell’ambiente JavaScript.

1.4.2.3 Le API di GWT

Per semplificare lo sviluppo della propria Rich Internet Application, Google Web Toolkit

mette a disposizione delle API, raggruppate nelle seguenti categorie:

• Widgets e Panels. Queste sono le API fornite per disegnare le nostre interfacce

utente, con una architettura delle UI molto simile a Swing, pur nei limiti imposti

dagli elementi HTML. La UI è composta infatti da elementi (widget) e da conte-

nitori (panel) che li contengono. I widget sono interattivi e possono rappresentare

ad esempio bottoni, checkbox, tabelle e cosi via. I panel sono pensati per dispor-

re automaticamente i widget in un’area della pagina HTML, con gli usuali layout

verticali, orizzontali, flow (la disposizione HTML predefinita) ed altri ancora. Al-

cuni pannelli infine possono anche essere interattivi e sono in grado sia di contenere

widget che di rispondere a degli eventi di UI (ad esempio i TabPanel);

19


• I18I. Questo sono le API per fornire la localizzazione e internazionalizzazione

alla nostra applicazione. GWT fornisce le API per definire sia staticamente che

dinamicamente la localizzazione delle risorse di testo;

• Request Builder, JSON e XML Parser. Queste API si occupano di facilitare la

comunicazione con i server che espongono servizi in XML e JSON. Si occupano di

costruire le richieste al server e poi di processare i dati di risposta;

• RPC. Se vogliamo comunicare con un server Java, GWT ha specificato un pro-

tocollo RPC che possiamo usare per implementare un servizio client/server con

poche linee di codice. Queste API sollevano il programmatore dalla gestione della

comunicazione e dal processo di marshalling/unmarshalling dei dati;

• History Management. Le applicazioni AJAX generate da GWT sono costruite su

di una singola pagina HTML. Queste API offrono uno strumento, compatibile con

il browser, per definire le regole di historing e di navigazione all’interno della stessa

pagina HTML (vedi GMail);

• Integrazione con JUnit. Queste API discendono direttamente dalle best practice

per gli Unit Test, e servono all’integrazione con JUnit.

1.4.3 Django

Django è un web application framework opensource, scritto in Python, che segue il pattern

architetturale model-view-controller. Venne concepito inizialmente per gestire diversi si-

ti di notizie per la World Company di Lawrence (Kansas), e venne rilasciato sotto una

licenza BSD a luglio 2005.

Seguendo la definizione riportata nel sito web ufficiale:

“Django is a high-level Python Web framework that encourages rapid

development and clean, pragmatic, design. . . The Web framework for perfec-

tionists with deadlines”

20


Figura 1.4.2: Piattaforma di riferimento per il framework Django [12]

Django offre un certo numero di funzionalità che facilitano lo sviluppo rapido di applica-

zioni per la gestione di contenuti, enfatizzando concetti come la riusabilità e “pluggabili-

ty” dei componenti, e aderendo al principio DRY (Don’t Repeat Yourself).

Il linguaggio su cui è basato viene utilizzato in tutto, dalle impostazioni ai modelli di dati.

Django fornisce inoltre dei moduli opzionali di amministrazione, che vengono generati

automaticamente. Questi consentono di creare, aggiornare e eliminare contenuti rappre-

sentati come oggetti e di tenere traccia di tutte le operazioni effettuate. Tramite interfaccia

grafica è possibile anche gestire utenti e gruppi di utenti, inclusi i permessi associati.

1.4.3.1 I componenti

Il core del framework mvc Django è composto da un object-relational mapper che fa da

intermediario tra i modelli di dati (definiti come classi Python) e un database relazionale

(“Model”), un sistema per la gestione di template (“View”) e un dispatcher URL basato

sulle espressioni regolari (“Controller”).

Sono inoltre inclusi nel core framework:

• Un leggero web server standalone per lo sviluppo e il testing;

21


• Un sistema di validazione per i form che trasforma i dati di input in valori ammis-

sibili per l’archiviazione nel database;

• Un sistema "middleware" per lo sviluppo di funzionalità aggiuntive (ad esempio,

componenti middleware che forniscono caching);

• Un sistema dispatcher interno che consente ai componenti di una applicazione di

comunicare tra loro eventi attraverso segnali predefiniti;

• Un sistema di internazionalizzazione, che include anche le traduzioni dei compo-

nenti di Djanco in molteplici lingue;

• Un sistema per estendere le capacità del motore di template;

• Una interfaccia per il framework di unit test integrato in Python.

1.4.3.2 Bundled Applications

La distribuzione principale di Django include anche un certo numero di applicazioni

esterne, le cosiddette Bundled Application, raccolte nel package denominato “contrib”:

• Un sistema di autenticazione estensibile;

• Interfaccia amministrativa dinamica;

• Funzionalità per la creazione di feed RSS e/o Atom;

• Un sistema flessibile di commenti;

• Strumenti per la generazione di Google Sitemaps;

• Strumenti per la protezione da Cross-site request forgery;

• Un framework per la creazione di applicazioni GIS (Geographic Information Sy-

stem).

22

Capitolo 2

Il framework Carassio

Quelle che abbiamo visto in precedenza sono solo alcune delle soluzioni tra quelle esi-

stenti. In questo capitolo concentreremo l’attenzione su Carassio, framework opensource

sviluppato dalla Naxe, presso cui si è tenuta l’attività di tirocinio.

Rilasciato con licenza GPLv3, Carassio è un progetto giovane, nato da poco, ma che offre

tutta una serie di potenzialità che nel seguito andremo ad analizzare.

Che si tratti di applicazioni web, desktop o qualsiasi altro prodotto software, durante un

progetto è necessario fare riferimento a dei principi che ne regolino il cosiddetto “ciclo di

vita”. Porgendo particolare attenzione sulla fase di sviluppo, un framework nasce proprio

con quest’obiettivo.

Lo stesso vale per Carassio, il quale fa tesoro dei principi impartiti dall’ingegneria del

software, garantendo piena adesione ai concetti quali modularità e riutilizzo del codice.

Quotidianamente infatti gli sviluppatori, malgrado gli scenari eterogenei, sono impegnati

nella risoluzione di problematiche ricorrenti, che spesso si traducono nel vano tentativo

di dover reinventare la ruota. Pertanto, essere in possesso di strumenti come quelli offerti

da Carassio, significa ridurre i tempi di sviluppo (e quindi abbattere i costi), produrre

software di qualità e agevolare le attività di manutenzione.

Oltre le tematiche concerni il riutilizzo però un altro aspetto da tenere in considerazio-

ne è il principio di separazione degli interessi, che Carassio ben attua grazie all’ado-

23


Figura 2.1.1: Logo del framework Carassio

zione del pattern architetturale Model-View-Controller, argomento che approfondiremo

opportunamente.

2.1 Perché Carassio?

Da quanto detto nel capitolo precedente si è capito che per quanto riguarda lo sviluppo

web, l’insieme costituito dai framework è davvero molto vasto. Molti di questi sono

prodotti da vere e proprie aziende leader nel settore: Zend Technologies, Adobe, Google e

Microsoft ne sono giusto un esempio. Altri sono invece proposti da comunità distribuite

di sviluppatori e costituiscono alternative molto valide (un esempio può essere l’Apache

Software Foundation con il suo framework Struts).

Viene dunque da chiedersi perché la scelta sia ricaduta proprio su Carassio. Per for-

nire un’adeguata risposta è bene contestualizzare lo scenario in cui questo ha trovato

applicazione.

Un primo approccio a Carassio si è avuto a seguito di un progetto, realizzato esattamente

presso la sede in cui tale framework ha preso vita. Il caso di studio affrontato ha previsto

la progettazione e lo sviluppo di un’applicazione web, denominata FILESHARE, destinata

alla condivisione e scambio di file in ambiente enterprise.

Chiaramente, applicazioni come queste sono l’ordine del giorno per un’azienda specia-

lizzata nel web-engineering. Diventa quindi cruciale poter disporre di strumenti che, non

solo siano di supporto al progetto stesso, ma che si adattino naturalmente al modo di

operare dell’azienda.

Possiamo dunque affermare che lo scopo di Carassio è proprio questo, ossia quello di

24


fornire un totale controllo dei suoi meccanismi, affinché meglio si adatti alle esigenze

della specifica impresa.

Ovviamente questo discorso non deve scoraggiare coloro che intendono utilizzare Caras-

sio in un altro contesto, che sia lavorativo o meno. Tale framework difatti nasce come

progetto opensource e può essere pertanto studiato, esteso e modificato in ogni sua par-

te affinché possa adattarsi a scenari anche completamente differenti da quelli previsti in

partenza.

Inoltre, rispetto a framework del calibro di Zend, Carassio offre una soluzione molto più

leggera. Questo perché molto spesso i framework integrano moduli che raramente sono

utilizzati, di cui gli sviluppatori forse non hanno proprio conoscenza. Certo, per alcuni

di essi è possibile utilizzare i vantaggi tipici della modularità, ma iniziare un progetto

dovendo prima fare una cernita di tutti i moduli può essere davvero controproducente.

Carassio nei suoi 5 MB di formato compresso, mette a disposizione tutto quello di cui uno

sviluppatore ha bisogno per essere subito produttivo. In questo senso Carassio supporta il

cosiddetto RAD (Rapid Application Development).

2.1.1 Vantaggi

Tuttavia, al di là del contesto aziendale è opportuno riferirsi ai benefici che Carassio

apporta allo sviluppo di un progetto. Ecco perché riportiamo di seguito una sintesi delle

caratteristiche principali:

1. Forte adesione al modello MVC per la separazione delle logiche. I vantaggi

di questo pattern sono stati già evidenziati nel capitolo precedente, ma in seguito

vedremo come questo meccanismo è attuato e soprattutto quali sono le soluzioni

impiegate dal framework per colmare il gap che si instaura tra i ruoli di Coder e

Designer.

2. Modularità. Carassio è sviluppato in compartimenti tra di loro indipendenti. Ciò

implica non solo benefici per la fase di manutenzione del framework stesso, ma

25


anche per gli utilizzatori che possono operare una scelta selettiva sui moduli messi a

disposizione, al fine di integrare nella propria applicazione il giusto indispensabile.

3. Chiara distinzione tra moduli Client-side e Server-side. Molti framework na-

scondono l’interazione che è alla base del paradigma Client-Server. È questo per

esempio il caso di Google Web Toolkit, che come abbiamo avuto modo di vedere in

precedenza, ha il sostanziale ruolo di trasformare il codice Java in un mix di HTML

e JavaScript. Un comportamento del genere non sempre è desiderabile, specie se si

vuole avere maggiore controllo sull’applicativo.

4. Espandibilità con altri strumenti opensource. Un importante lavoro è stato svol-

to nella selezione e integrazione di moduli e componenti, individuati tra quanto di

meglio offerto nel mondo opensource (in questo senso Carassio propone una so-

luzione best of the breed). Ciò permette da un lato di avvicinare gli utilizzatori a

strumenti già noti e standardizzati (Smarty, MooTools, etc.), dall’altro di avere a

disposizione prodotti già ampiamente collaudati.

5. Supporto alla didattica. La curva di apprendimento ha davvero tempi molto ri-

dotti. Basti pensare infatti che sono stati opportunamente documentati dei tutorial,

con livelli di difficoltà incrementali, che permettono uno studio più agevole del

framework.

2.2 Il paradigma MVC

Il fondamento di Carassio è proprio l’utilizzo del design pattern MVC. Grazie a questo

è possibile separare completamente la logica di business da quella di presentazione, fa-

vorendo lo sviluppo di applicazioni in ambienti in cui il carico di lavoro è distribuito tra

persone con competenze differenti.

Nella Figura 2.2.1 si possono identificare quattro attori:

1. Il Browser. Rappresenta l’utente che interagisce con l’applicazione.

26


Figura 2.2.1: Il paradigma MVC nel framework Carassio [14]

2. Il Controllore. Posto al centro di tutte le comunicazioni, questo componente ri-

ceve i comandi impartiti dall’utente (sotto forma di richieste HTTP), facendo da

intermediario tra quest’ultimo e il resto dell’applicazione.

3. Il Modello. Implementa la vera e propria logica di business dell’applicazione. A

questo componente, tramite il controllore, viene demandato l’onere di recuperare

ed elaborare i dati necessari al soddisfacimento di una richiesta.

4. La Vista. Una volta in possesso dei dati necessari, il controllore li invia alla vi-

sta che, dovendo gestire la logica di presentazione, provvede a costruire la veste

grafica dell’applicazione senza preoccuparsi di come tali informazioni siano state

recuperate.

Il processo si conclude quando il controllore fornisce all’utente il risultato atteso sotto

forma di risposta HTTP. A questo punto si è pronti per iniziare un nuovo ciclo di richieste.

27


2.2.1 Vantaggi

Strutturare un’applicazione in questo modo senz’altro aumenta la complessità, richieden-

do pertanto un lavoro progettuale più impegnativo. Tuttavia, specie in progetti di medie/-

grosse dimensioni, diventa auspicabile mettere in pratica una tale metodologia. I benefici

che questa apporta sono di interesse infatti per le seguenti tematiche:

• Riutilizzo. Difatti più una parte del lavoro è indipendente più possibilità ci sono

perché questa venga integrata in altri progetti.

• Suddivisione del lavoro. Vi è una naturale distribuzione del carico di lavoro,

che dà la possibilità ad ogni sviluppatore di focalizzarsi su singoli componenti,

indipendentemente dal resto dell’applicazione.

• Manutenibilità. Essendo l’applicazione suddivisa in moduli indipendenti, è più

semplice apportarne delle modifiche, siano queste correttive o perfettive.

2.3 Piattaforma e tecnologie di sviluppo

Nel capitolo precedente abbiamo detto che un framework va scelto in riferimento al tipo

di applicazione (che può o meno garantire dinamicità attraverso tecnologie come Ajax) e

al tipo di piattaforma.

Carasso in particolare fa affidamento sul solution stack LAMP, che come abbiamo avuto

di vedere, grazie anche alla comparazione in Tabella 1.1, offre tutti i vantaggi tipici del

free software. Del resto non potrebbe essere stato altrimenti, essendo il framework in

oggetto fondato sugli stessi principi.

Altro aspetto tecnologico è il linguaggio di programmazione. Nel nostro caso la scelta

è ricaduta su PHP (acronimo ricorsivo di "PHP: Hypertext Preprocessor"), che sebbene

inizialmente sia stato concepito come linguaggio di scripting per la realizzazione di pagine

web dinamiche, è oggi ampiamente utilizzato per sviluppare applicazioni web lato server.

28


A rendere la sua fama ancor più affermata ha contribuito l’introduzione del paradigma

di programmazione orientata ad oggetti, di cui Carassio è il primo beneficiario. Tutti i

moduli serverside infatti abbracciano questa filosofia, mettendola in pratica specie quando

si ha la necessità di estendere funzionalità di terze parti.

Altri benefici di questo linguaggio sono da ricercare nella vastissima documentazione a

supporto, nella comunità estesa di sviluppatori, nei tool messi a disposizione. Di que-

sti ultimi ricordiamo: phpDocumentor, per la capacità di produrre in modo automatico

documentazione di elevata qualità, PHPUnit eccelsa piattaforma di testing.

Per i moduli che invece sono progettati per il livello client, ovvero quelli che sono eseguiti

localmente presso l’utente, la scelta è ricaduta sull’impiego di un framework molto noto,

ovvero MooTools. Tra le tantissime disponibilità che vi sono in ambito JavaScript, Moo-

Tools è stato scelto, oltre che per la sua compattezza e modularità, anche per la sua sintassi

completamente orientata ad oggetti (non a caso il nome deriva da My Object Oriented ja-

vascript Tools). Presentandosi come prodotto full-featured, troviamo all’interno strumenti

dedicati ad ogni aspetto del web 2.0: è possibile creare richieste Ajax complesse, creare

richieste in formato JSON, creare animazioni multifunzione, settare o modificare i cookie,

lavorare con gli stili, le proprietà e le dimensioni degli elementi, utilizzare i selettori CSS

e molto, molto altro ancora.

Ciò però non costringe lo sviluppatore ad essere vincolato a questo particolare strumento,

tant’è che lo stesso Carassio promuove l’utilizzo di ulteriori framework JavaScript, come

ad esempio jQuery.

2.4 Architettura

Se fin’ora ci siamo concentrati sulle tecnologie del framework, adesso rivolgiamo la no-

stra attenzione sulle architetture alla base di Carassio. Il framework in oggetto si compone

di tre package principali:

29


Figura 2.4.1: UML Component Diagram per Carassio Clientside

Figura 2.4.2: UML Component Diagram per Carassio Serverside

30


1. Clientside. Mostrato nella Figura 2.4.1, rappresenta tutti i moduli necessari per lo

sviluppo lato client di una applicazione. È dunque l’insieme dei componenti a cui

viene delegato l’onere di gestire l’interattività con l’utente, tipica delle rich internet

application. Ancora una volta si vede come Carassio sia predisposto all’estensibi-

lità e all’integrazione con altri prodotti. Scegliendo infatti tra le migliori soluzioni

previste nel settore, questo non si prefigge lo scopo di reinventare le cose, piutto-

sto di far interagire diversi strumenti al fine di ottenere una più completa e ricca

piattaforma. Ne sono un esempio significativo le inclusioni degli ottimi framework

JavaScript MooTools e jQuery.

2. Serverside. Visibile nella Figura 2.4.2, costituisce il vero e proprio cuore del fra-

mework. Carassio infatti è stato inizialmente prodotto per supportare lo sviluppo di

applicazioni web tradizionali, che fanno largo uso di scripting lato server. Tale pac-

kage è di vitale importanza, tant’è che il suo utilizzo coinvolge tutte le componenti

del pattern MVC.

3. Site. Più che un package, può essere visto come un set di configurazioni. L’uti-

lizzatore di Carassio sarà tenuto a specificare qui tutte le variabili di ambiente e le

impostazioni necessarie per il corretto funzionamento della particolare applicazio-

ne.

2.4.1 Clientside

L’intero package ha lo scopo di favorire l’interazione con l’utente ed è quindi costruito

attorno al linguaggio JavaScript. Tuttavia, malgrado le potenzialità che questo fornisce

alla programmazione lato client, Carassio ricorre all’utilizzo di framework esterni che ne

estendono gli orizzonti. Al di là degli effetti e delle animazioni, il vantaggio principale

introdotto da questi è la resa cross-browser degli script. Difatti, la gestione del DOM1 e

degli eventi, così come il modello di rendering, differisce di browser in browser.1Il Document Object Model (spesso abbreviato come DOM), letteralmente modello a oggetti del

documento, è una forma di rappresentazione dei documenti strutturati come modello orientato agli oggetti.

31


Figura 2.4.3: Carassio plugin: esempio di applicazione per la gestione di album fotografici

Include pertanto due framework diventati molto popolari, ossia MooTools e jQuery, che

da un lato aiutano lo sviluppatore nei suoi scopi, dall’altro permettono allo stesso Carassio

di definire nuovi moduli.

Ne sono un esempio quelli appartenenti al subpackage Carassio:

• filetype che ritorna utile quando si vogliono rappresentare dei file all’interno del-

la pagina web, in quanto permette di associare dinamicamente al loro mime-type

un’immagine significativa;

• picnik, pixlr che forniscono le API da utilizzare per l’image editing attraverso gli

omonimi servizi web Picnik e Pixlr;

• utils, necessario al mapping dinamico degli URL dei controlli.

Vi sono poi altri strumenti che sono stati integrati opportunamente:

• TinyMCE, famoso editor What You See Is What You Get basato su JavaScript e

indipendente da qualsiasi piattaforma;

• Plupload, potente strumento per il caricamento di uno o più file. Supportando i

più disparati runtime (Flash, HTML5, Silverlight e tanti altri) mette a disposizione

32


caratteristiche avanzate come: Chunking, Drag/Drop, Upload progress e tante altre

ancora.

2.4.2 Serverside

Questo componente è formato da tre subpackage:

1. Core;

2. External Packages;

3. Templates.

Il primo di questi, il Core, mette a disposizione quei moduli che vengono usati più

frequentemente e che sono dunque la base per ogni applicativo. Tra questi ricordiamo:

• FTP. Derivando il nome dall’omonimo protocollo di trasferimento file, questo è il

modulo che consente tutte le operazioni tipiche di un client ftp: accesso, gestione

delle permessi, delle cartelle e dei file;

• pdo. Estende PHP Data Objects, fornendo un’interfaccia unica per la gestione di

molteplici database (MySQL, SQLite al momento);

• form. Permette di definire in modo semplificato la struttura dei moduli elettronici

che saranno compilati dall’utente finale. Specificando i domini di ogni input (chec-

kbox, file, text, etc), è possibile integrare all’interno della propria pagina web form

anche molto complessi, per i quali è possibile prevedere delle forme di controllo,

che consentono la validazione dei dati sia lato client che lato server (ad esempio

tramite regular expression);

• session. Introdotto per facilitare la gestione delle sessioni, strumento assolutamente

necessario per la natura stateless del protocollo HTTP;

33


Figura 2.4.4: Smarty Template Engine [15]

• error. Permette di localizzare gli errori durante la fase di sviluppo. La potenzialità

di tale sistema è da ricercare nel mezzo di comunicazione di tali errori. Sono previsti

infatti diverse tipologie di canali: echo, file, json, email;

• template. Ridefinisce i moduli di Smarty Template Engine, per facilitare mag-

giormente il loro utilizzo e per adattarli alla struttura delle cartelle previste da

Carassio;

• email. Grazie all’uso del package esterno XPM4 vengono fornite interfacce sem-

plificate per l’invio di posta elettronica.

A questa serie di componenti si aggiungono gli External Packages:

• phpThumb per la manipolazione di immagini lato server;

• Smarty Template Engine. Questo componente è fondamentale, in quanto garanti-

sce supporto alla View del pattern MVC. Fornisce un modo semplice per separare la

logica di business da quella di presentazione. Oggetti protagonisti di questo motore

sono i template, nei quali viene specificata la veste grafica dell’applicazione (sotto

forma di HTML e CSS). I template sono costruiti portando un minimo di logica

34


a livello presentazione; giusto quella necessaria per operazioni come la selezione

(if..else), la ripetizione di blocchi (foreach) e l’utilizzo di modificatori di testo.

Ultimo, ma non meno importante è il package Templates, che come si intuisce dal nome,

è costituito da alcuni template già pronti e che semplificano enormemente lo sviluppo del

livello di presentazione. Per questi è previsto un meccanismo di estensione che permette

agli sviluppatori di ridefinire i modelli standard previsti da Carassio. L’utente quindi non

è assolutamente vincolato al framework, ma anzi può scegliere di impiegare la soluzione

che più si avvicina alle proprie esigenze.

2.4.3 Site

Come si è anticipato, qui vengono settate tutte le variabili d’ambiente e le configurazioni

per la specifica applicazione. Un esempio può essere dato dalla scelta della tipologia del

database, dallo SMTP server scelto per la spedizione delle email e tanti altri parametri

ancora.

2.4.3.1 Le Carassio Action

Particolare rilievo è assunto dal modulo denominato Carassio Action. Questo è nato con

lo scopo di colmare il gap che si viene ad instaurare tra i ruoli di Coder e Designer, in par-

ticolare per quanto riguarda la gestione degli URL2. Il progettista dell’interfaccia infatti

vuole poter disegnare la veste grafica prescindendo dalla realizzazione logica dell’appli-

cazione. Potrebbe persino non conoscere la esatta locazione dei controllori, né tanto meno

esserne interessato. Egli sa solo che deve riportare degli indirizzi per consentire una più

agevole navigazione all’utente.

Per favorire questo approccio, le Carassio Action mettono a disposizione un meccanismo

di mapping degli URL, che fa corrispondere ad ogni controllore una etichetta. Il progetti-

2Uniform Resource Locator o URL è una sequenza di caratteri che identifica univocamente l’indirizzodi una risorsa in Internet, tipicamente presente su un server, come ad esempio un documento, un’immagine,un video, rendendola accessibile ad un client che ne fa richiesta attraverso l’utilizzo di un web browser

35


sta del livello business non farà altro quindi che fornire al Designer la lista delle etichette

interessate, sicuro del fatto che una qualsiasi modifica del nome o della posizione di uno

dei qualsiasi controllori non si ripercuoterà sul livello di presentazione.

Le Carassio Action inoltre facilitano lo sviluppo di applicazioni orientate alle azioni. È

normale prassi infatti che un controllore gestisca più funzionalità. Per una pagina che per

esempio riporti un elenco di contatti, potremmo identificare le funzionalità “rinomina”

oppure “elimina” come azioni da intraprendere su un contatto. Sfruttando l’URL, grazie

ad un’opportuno passaggio di parametri, si fa in modo che il controllore richiamato attui

l’azione corrispondente. Ancora una volta, il Designer non deve sapere niente di tutto

ciò, in quanto la logica applicativa è di competenza altrui. Quest’ultimo sfrutterà quindi il

meccanismo delle etichette di cui abbiamo parlato, specificando però anche l’azione asso-

ciata, che attenzione, può avere tutt’altro nome rispetto a quella effettivamente utilizzata

dal rispettivo controllore.

Volendo proseguire con l’esempio sopra citato, vedremo il progettista del livello business

occuparsi del mapping degli URL, specificando le etichette per l’ambito e l’azione più la

locazione e i parametri del controllore:

carassio::action_register(’contatti’, ’rinomina’, ’contacts.php?a=rename&i=:

id_contact’);

carassio::action_register(’contatti’, ’elimina’, ’contacts.php?a=delete&i=:

id_contact’);

Il progettista dell’interfaccia grafica a questo punto, se volesse creare una lista di contatti,

cliccati i quali si è rimandati al controllore che gestisce la rinomina, non dovrà fare altro

che usare le etichette che il buon caro collega ha provveduto a fornirgli:

{foreach $contacts as $contact}

{$contact.name}<

br/>

{/foreach}

36


In tal modo il Designer non si preoccupa né di dover utilizzare il giusto URL, né di come

passargli i parametri necessari (l’id del contatto).

2.4.3.2 Secrets

Qui vanno specificati i parametri sensibili per la propria applicazione. L’accesso dall’e-

sterno è negato mediante un file .htaccess, un meccanismo messo a disposizione dal web

server Apache. Solitamente è qui che si specificano i parametri di accesso al database

(tipo, hostname, username, password, etc), ma anche altri come quelli che consentono

l’accesso ad un server FTP (difatti prima abbiamo visto che c’è un apposito modulo in

Serverside).

37

Capitolo 3

Caso di studio: Analisi e progettazione

Già è stato accennato che il caso di studio a cui faremo riferimento riguarda la progetta-

zione e lo sviluppo di una applicazione web inquadrata nell’ambito del filesharing.

Tale progetto, denominato appunto FILESHARE, si colloca all’interno di un contesto

aziendale e nasce con lo scopo di supportare la condivisione di file tra più persone. Lo

scopo che si prefigge non è quello di realizzare l’ennesimo cyberlocker (o comunemente

detto armadietto digitale), piuttosto quello di creare un prodotto particolarmente adat-

to all’ambiente enterprise, che quindi vede coinvolti enti e persone che hanno legami di

business tra loro: un’azienda con i propri clienti, fornitori, dipendenti e via dicendo.

Il perché di un progetto come questo appare piuttosto evidente. Infatti per un’azienda si

preferisce disporre di una soluzione che possa essere fatta propria e quindi ampliata e/o

personalizzata in base a specifiche esigenze.

Sebbene siano poste solide basi per l’ambiente enterprise, è da dire che il prodotto soft-

ware in questione, non attenendosi ad alcuna esplicita commessa, è stato concepito per un

contesto del tutto generale.

Naturalmente, visto che l’impiego di un framework riguarda per lo più la fase di sviluppo,

ci discosteremo da quello che è stato il discorso affrontato fin’ora. D’altra parte, gli argo-

menti che stiamo per introdurre rappresentano una tappa fondamentale nella realizzazione

di un prodotto software.

38


Nel corso di questo capitolo esporremo, dunque, le fasi iniziali del ciclo di vita del

software, ovvero quella di analisi e specifica dei requisiti e quella di progettazione.

3.1 Analisi e specifica dei requisiti

Questa è una fase molto importante del ciclo di vita. Qui vengono definiti infatti gli

obiettivi dell’applicazione, ovvero cosa il sistema software dovrà andare a fare, indipen-

dentemente dalla soluzione e dal dominio del problema (come).

È un’attività molto critica, dal momento che errori in questa fase si propagano in quelle

successive, con conseguenze devastanti per i costi e i tempi di sviluppo. Rappresenta,

inoltre, il principale punto di incontro con il committente e pertanto la chiave di volta per

l’approvazione dell’intero progetto.

Sebbene tale analisi avvenga solitamente come negoziazione tra le persone addette al-

la raccolta dei requisiti (gli analisti) e i clienti, nel nostro caso ci atterremo alle in-

dicazioni forniteci dall’azienda sede dello sviluppo. Questo perché, come accennato

precedentemente, FileShare non è un prodotto realizzato su specifica richiesta.

In ogni caso, identificheremo comunque i requisiti dell’applicazione, al fine di produrre

un Documento di Specifica dei Requisiti Software che sia completo, consistente, non

ambiguo e comprensibile.

Si vuole realizzare dunque un’applicazione web based che permetta a degli utenti di

condividere file in rete.

Lo scenario tipico è quello di un’azienda che necessita di condividere documenti, media

e file di qualsiasi altro genere con i propri partner (clienti, fornitori, dipendenti, etc.).

L’utente potrà dunque appartenere ad una delle seguenti categorie:

• Operatore aziendale;

• Partner.

39


L’applicazione dovrà prevedere una cartella di base, detta root directory, nella quale viene

creata una cartella personale per ogni partner, all’atto della sua registrazione. All’interno

della propria cartella personale l’utente partner godrà di tutti i privilegi per la gestione di

file e cartelle.

L’operatore aziendale, invece, dovrà avere a disposizione ogni tipo di privilegio su qual-

siasi cartella.

In alcuni casi, inoltre, un utente partner può essere abilitato dall’operatore aziendale ad

accedere al servizio tramite delle credenziali provvisorie. Questo accade prevalentemente

quando si parla di partner non abituali (detti spot), ai quali si vuole dare solo un accesso

temporaneo al portale.

L’applicazione dovrà includere una serie di funzionalità:

• per la gestione di file, consentendo ad un utente di muoversi nella sua area personale

e di organizzare i propri file;

• per la taggatura, permettendo di associare delle etichette a vari file così da facilitare

le operazioni di ricerca e catalogazione;

• per la gestione dei commenti, permettendo ad un utente di inserire delle note di

riferimento per un file;

• per le notifiche, grazie alle quali l’utente viene avvisato quando si verifica un evento

(ad esempio quando viene caricato un file nella sua cartella);

• per il controllo di accesso alle cartelle, mediante il quale è possibile specificare

come, quando e da chi una determinata cartella può essere acceduta;

• per la gestione dei partner spot;

• per la gestione delle scadenze, permettendo all’utente di specificare una data di sca-

denza per il file caricato. Si dovranno notificare all’utente sia l’imminente scadenza,

sia l’avvenuta scadenza del file;

40


Figura 3.1.1: Diritti di accesso per operatori aziendali e partner

• per l’associazione dei file.

Nella Figura 3.1.1 si evidenziano i diritti di accesso rispettivamente degli operatori azien-

dali e degli utenti partner. Gli operatori aziendali hanno accesso a tutte le cartelle del

portale, mentre gli utenti partner hanno accesso solo a quelle che gli sono state riservate.

Esempio

Uno studio medico ha la necessità di condividere dei documenti con i propri pazienti.

In questo caso l’operatore aziendale è rappresentato dal medico, mentre il partner dal

paziente.

Supponiamo che il medico voglia rilasciare un certificato medico ad un paziente e che

entrambi siano già registrati nel sistema. Il medico caricherà dunque il certificato nella

cartella riservata al paziente, il quale sarà poi notificato automaticamente dell’avvenuto

41


Figura 3.1.2: Esempio per uno studio medico

caricamento. A questo punto il paziente scaricherà il proprio certificato (si veda la Figura

3.1.2).

3.1.1 Funzionalità

Di seguito riporteremo nel dettaglio le funzionalità che precedentemente abbiamo prov-

veduto ad elencare.

Gestione file

Questo funzionalità consente di effettuare tutte le operazioni relative alla gestione ed

organizzazione dei file.

In particolare saranno possibili le seguenti operazioni:

• spostarsi tra le cartelle;

• caricare un file;

42


• scaricare un file;

• creare una cartella;

• copiare file e cartelle;

• spostare file e cartelle;

• rinominare file e cartelle;

• eliminare file e cartelle.

Taggatura

Questa funzionalità consente all’utente di poter associare delle etichette (che nel seguito

chiameremo tag1) al fine di migliorare le operazioni di ricerca e catalogazione dei file.

Chiaramente quando ci si riferisce ad una particolare etichetta, al fine di trovarne i file

associati, si otterranno risultati diversi in funzione della tipologia dell’utente. Un opera-

tore aziendale infatti disporrà di tutti i file del sistema aventi quella etichetta, mentre un

partner solo di quelli per cui ha diritto di accesso.

Gestione dei commenti

L’applicazione dovrà consentire all’utente la visualizzazione, l’inserimento e l’elimina-

zione di commenti per un file.

Mentre la visualizzazione e l’inserimento dei commenti sono concessi a chiunque abbia

diritto di accesso al relativo file, l’eliminazione deve poter essere effettuata soltanto dagli

operatori aziendali e dagli utenti autori del commento.

1Un tag è una parola chiave o un termine associato a un’informazione (un’immagine, una mappa geo-grafica, un post, un video clip ...), che descrive l’oggetto rendendo possibile la classificazione e la ricer-ca di informazioni basata su parole chiave. I tag sono generalmente scelti in base a criteri informali epersonalmente dagli autori/creatori dell’oggetto dell’indicizzazione.

43


Notifiche

Secondo questa funzionalità l’utente deve essere avvisato al verificarsi di determinati

eventi, quali:

• caricamento di un nuovo file;

• eliminazione di un file;

• rinomina di un file;

• scadenza imminente di un file;

• scadenza avvenuta di un file;

• scaricamento di un file;

• spostamento di un file.

Dovranno essere previste due modalità di notifica. Da un lato, l’utente dovrà disporre

di un’area di notifica, consultabile presso la propria area personale. Dall’altro si dovrà

prevedere un meccanismo in grado di inviare email automatiche all’utente.

Nel caso in cui l’evento rappresenti la scadenza di un file, allora il sistema notificherà

tutti gli utenti che condividono quel file. In tutti gli altri casi verrà notificato solo l’utente

interessato.

L’utente dovrà poter scegliere, mediante le impostazioni personali, gli eventi per i quali

sarà inviata una notifica email. In ogni caso l’area di notifica resterà sempre abilitata

mentre le opzioni relative all’invio delle email saranno per default tutte abilitate.

Nelle immagini in Figura 3.1.3 possiamo vedere come deve essere inoltrata una notifica

email, rispettivamente, nel caso di scadenza di un file e di un qualsiasi altro evento.

44


Figura 3.1.3: Notifiche via email: scadenza e caricamento di un file

45


Controllo di accesso alle cartelle

L’obiettivo principale di questa applicazione web è permettere agli utenti la condivisione

di file e cartelle. Per tale motivo, l’operatore aziendale deve poter disporre delle seguenti

funzionalità:

• organizzazione degli utenti in gruppi, ossia raggruppamenti logici ai quali assegnare

gli stessi permessi su una cartella;

• assegnazione dei permessi di accesso alle cartelle.

Gli utenti partner, all’atto della registrazione, vengono assegnati automaticamente ad

un gruppo di default il quale ha lo stesso nome dell’utente partner. Questo conferisce

all’utente partner i permessi di tipo full per accedere alla propria cartella personale.

Dovranno poter essere definiti tre tipi di accesso alle cartelle:

1. full. Deve consentire agli utenti di accedere alle cartelle e ai file in esse contenuti

con i massimi privilegi per la gestione dei file;

2. intermediate. Deve consentire agli utenti di accedere alle cartelle con i soli per-

messi per caricare e scaricare file;

3. limited. Deve consentire agli utenti di accedere alle cartelle con i soli permessi per

scaricare file.

Un operatore aziendale deve anche poter specificare dei vincoli temporali per l’accesso

ad una cartella tramite:

• una data a partire dalla quale la cartella può essere utilizzata;

• una data fino alla quale una cartella può essere utilizzata.

Per poter assegnare dei diritti di accesso ad una cartella si dovrà quindi specificare una

tripla:

46


• gruppi con cui la si vuole condividere;

• tipi di accesso (esclusivamente intermediate o limited);

• opzionalmente, i vincoli temporali di accesso.

Gestione dei partner spot

Quando parliamo di utenti spot facciamo riferimento ai partner aziendali che non hanno

un rapporto frequente con l’azienda. Pertanto c’è bisogno di funzionalità per la loro

gestione.

Dunque l’applicazione dovrà:

1. chiedere all’operatore aziendale di inserire l’indirizzo email dell’utente spot;

2. creare delle credenziali provvisorie per l’utente spot;

3. creare una cartella temporanea nella root directory, con i permessi di tipo limited,

in modo che i partner spot possano solo scaricare i file messi a disposizione;

4. inviare una email all’utente spot con l’URL della cartella temporanea e le relative

credenziali.

In tal modo il partner spot potrà accedere alla cartella che gli è stata riservata, reperire i

file messi a disposizione ed infine effettuare il logout.

Terminata la sessione, verrà cancellata la cartella del partner spot e i relativi file contenuti.

Gestione delle scadenze

Questa funzionalità deve consentire all’utente di assegnare ad un proprio file una data di

scadenza e di scegliere quanti giorni prima di tale data debbano essere avvisati tutti gli

utenti che condividono quel file.

47


Associazione file

Tale funzionalità deve consentire all’utente di associare un file sorgente ad un file desti-

nazione, dove per file sorgente si intende un qualsiasi file caricato dall’utente, mentre per

file destinazione si intende un qualsiasi altro file presente nella propria area personale. Un

esempio può essere l’allegamento di una fattura a un ordine di fornitura.

L’utente deve poter inserire una breve descrizione per l’associazione, visualizzare i file

allegati ed eliminare le associazioni per i file di cui è autore.

3.1.2 Diagramma dei casi d’uso

Per schematizzare meglio tutte le specifiche viste fin’ora, riportiamo in Figura 3.1.4 il

diagramma dei caso d’uso. Questo rappresenta le interazioni tra i diversi attori e il sistema,

catturando le funzionalità così come percepite dall’utente. Essendo comprensibile anche

ai “non addetti ai lavori”, il diagramma dei casi d’uso permette di avere a disposizione

uno strumento tanto semplice quanto utile.

Ragionare sui casi d’uso aiuta anche a scoprire ulteriori requisiti del sistema, che nel

nostro caso possono riassumersi nei seguenti punti:

• Un utente che non ha ancora le credenziali per poter accedere all’applicazione, deve

avere la possibilità di registrarsi;

• Un utente già registrato, prima di poter utilizzare le funzionalità messe a disposi-

zione, deve autenticarsi tramite la procedura di Login;

• Oltre alle normali funzionalità, un operatore aziendale deve poter gestire sia gruppi

che permessi e creare partner spot.

48


Figura 3.1.4: UML Use Case Diagram

49


3.2 Progettazione

Durante questa fase vengono scelte le modalità di passaggio dal cosa deve essere realiz-

zato (specifica dei requisiti) al come la realizzazione deve essere portata a termine. Sulla

base quindi delle specifiche prodotte in fase di analisi, definiremo come saranno soddisfat-

ti i requisiti, entrando nel merito della struttura che dovrà essere data al sistema software

da realizzare.

La progettazione può essere suddivisa su più livelli di dettaglio:

1. Livello Architetturale. Viene definita la struttura complessiva del sistema, iden-

tificando i moduli principali di cui è composto e le relazioni macroscopiche tra

essi;

2. Livello Intermedio. Si identificano i moduli e le classi dei moduli principali, al

fine di scomporre maggiormente il sistema;

3. Livello di Dettaglio. Si avvicina molto alla fase di codifica, infatti viene qui definita

la struttura di dettaglio delle classi.

Nel seguito terremo in considerazione però anche altri aspetti del sistema, tra cui la base

dati, il cui scopo è quello di memorizzare tutti i dati necessari all’applicazione, il lato

server, responsabile della logica applicativa e di controllo, e il lato client, attraverso cui si

gestisce la presentazione e l’interazione con l’utente.

3.2.1 Progettazione della base dati

Una base dati è fondamentale per qualsiasi applicazione, in particolar modo per quelle

web, che devono poter gestire una grossa mole di informazioni.

Una delle prime attività è stata quindi la progettazione della base dati, di cui analizzeremo

due fasi distinte: la progettazione concettuale e la progettazione logica.

50


Entità Descrizione

User Utente genericoBusiness Operator Operatore aziendale, amministratore

del sistemaPartner Utente normaleEvent Evento attivabile, che il sistema di

notifica è tenuto a registrareGroup Raggruppamento logico di utentiFile Documenti che possono essere

caricati o scaricati dagli utentiFolder Cartella che può contenere file e

cartelleTag Etichetta associabile ad un file

Tabella 3.1: Dizionario dei dati: Entità

3.2.1.1 Progettazione Concettuale

Obiettivo della progettazione concettuale è individuare, nel rispetto delle specifiche, le

entità, le relazioni e i vincoli di interesse per l’applicazione. Il problema viene quindi

affrontato ad un alto livello di astrazione, in modo da individuare tutte le componenti

della realtà, indipendentemente dalla rappresentazione informatica.

Il risultato di questa fase è appunto il Diagramma Entità-Relazioni, che rappresenta uno

schema concettuale della base dati (si veda la Figura 3.2.1).

Partendo dal Documento di Specifica dei Requisiti Softw

Documents

Analisi e utilizzo di un framework per lo sviluppo di applicazioni web · 2018. 3. 12. · Michele Basile matr. ... studio: la realizzazione di un’applicazione web per lo scambio