Generazione model-driven di interfacce utente per dispositivi mobili

iv 
 
Introduzione 
Contesto 
La continua ed incessante evoluzione delle reti ha portato negli ultimi anni ad una 
parallela crescita di tecnologie che basano la propria esistenza sulle opportunità che 
una tale copertura capillare garantisce. 
Il fenomeno del Cloud Computing prende piede proprio in questo panorama, tale 
modello di business si discosta da quello classico, secondo cui le risorse hardware e 
software sono intese come prodotti, identificando gli stessi come servizi. Esistono 
diverse modalità di erogazione per tali servizi una delle quali è il Platform As A 
Service che prevede di fornire all’utente un insieme di strumenti, librerie, programmi 
per lo sviluppo e servizi di deploy ed erogazione delle web application. I vantaggi 
che apporta tale approccio allo sviluppo sono un taglio netto di tutti gli aspetti 
relativi all’organizzazione interna e alle gestione del servizio che vengono visti a 
scatola chiusa da parte dell’utente, scalabilità ed affidabilità garantite dal fornitore 
del servizio, assenza degli onerosi costi iniziali e di tutte le problematiche ad esso 
associate come ad esempio una stima errata delle risorse necessarie. 
In tale contesto si inserisce Livebase, una piattaforma realizzata dalla azienda 
Fhoster. Essa consente la generazione semi automatica di applicazioni web per la 
gestione dei dati partendo da modelli descritti in un linguaggio derivato dall’UML. 
Tale approccio riduce drasticamente i tempi di sviluppo e dà, anche ad utenti con 
limitata conoscenza informatica, la possibilità di creare autonomamente una 
applicazione per le proprie esigenze. 
Le applicazioni generate con Livebase sono offerte all’utente proprio come servizi 
del cloude, esso si occuperà di manutenerle ed offrirle agli utilizzatori. Tali 
applicazioni saranno presentate in modalità Software As A Service, cioè la modalità 
secondo cui viene offerta una applicazione in remoto, un prodotto finale e non 
un’intera piattaforma con tutti gli strumenti associati.
v 
 
Obiettivi 
La modalità di fruizione delle applicazioni generate con Livebase, finora è stata 
vincolata all’utilizzo del browser di un personal computer. Con la crescita del settore 
mobile, negli utilizzatori, è nato però il bisogno di avere a disposizione 
l’applicazione anche su qualunque device mobile ed è in questo contesto che si 
colloca la mia esperienza in azienda. La prima fase ha previsto un’attività finalizzata 
alla realizzazione di una applicazione Javascript lato client, ottimizzata per l’utilizzo 
su dispositivi mobile. Essa doveva consentire l’interazione con la parte server 
dell’applicazione attraverso un insieme di servizi REST che questa offriva. Tale 
applicazione avrebbe dovuto offrire, se non tutte le funzionalità presenti nella 
versione dell’applicazione client esistente, almeno quelle più importanti. 
La seconda attività è stata la realizzazione di una applicazione Java per la 
generazione di applicazioni mobile strutturate sulla base del prototipo realizzato. 
Il lavoro assegnato è stato completato ed ha tracciato il solco per successive attività, 
quali l’aggiunta di nuove funzionalità nell’applicazione client generata e 
l’integrazione con la piattaforma esistente. 
Struttura 
Capitolo 1 
Viene descritta la piattaforma Livebase, dettagliando gli aspetti che hanno riguardato 
il mio lavoro, l’applicazione client e i servizi REST. 
Capitolo 2 
Sono descritti gli aspetti metodologici che hanno guidato l’attività in azienda e che 
sono stati alla base del lavoro svolto. 
Capitolo 3 
Sono presentati gli strumenti utilizzati, sia relativi ai progetti intrapresi che alla 
gestione e organizzazione del lavoro.
vi 
 
Capitolo 4 
Si percorrono i vari step che hanno portato alla generazione dell’applicazione client 
prototipo. Sono presentate le varie alternative per la realizzazione di applicazioni 
mobile con annesso confronto e motivazioni che hanno portato alla scelta di una di 
esse, del linguaggio di programmazione e dello stile architetturale adottato. 
Capitolo 5 
E’ descritta l’attività di realizzazione del generatore e sono introdotte alcune 
soluzioni volte a risolvere specifici problemi che affliggono i generatori attualmente 
presenti nella piattaforma. 
Capitolo 6 
Sono raccolte le conclusioni riguardo l’attività svolta, gli sviluppi futuri che tale 
progetto avrà e un resoconto personale dell’esperienza.
1 
 
Capitolo 1 - La Piattaforma Livebase 
Questo capitolo è un’introduzione riguardante il contesto nel quale mi sono trovato a 
svolgere la tesi. Dopo una rapida descrizione per percorso che ha portato Livebase ad 
essere il prodotto che attualmente è, verranno introdotti dei concetti per facilitare la 
comprensione dei capitoli successivi. Infine sarà presentata l’architettura hardware e 
software della piattaforma.  
Il prodotto 
Livebase è una piattaforma sviluppata dalla Fhoster che permette la creazione di 
applicazioni web data centriche a partire da modelli concettuali in modo automatico. 
Il sistema garantisce inoltre la possibilità di testare, offrire agli utilizzatori ed 
amministrare l’applicazione generata. 
Il target cui si riferisce il prodotto copre un’ampia gamma di categorie che vanno 
dalle piccole e medie aziende fino ad arrivare a quelle di grandi dimensioni. Per quel 
che riguarda le realtà più contenute, spesso si ha a che fare con difficoltà nella 
gestione dei propri dati attraverso DBMS o, ancora peggio, attraverso l’uso di fogli 
Excel; le applicazioni generate con Livebase risolvono i problemi che ne conseguono 
come ridondanza dei dati o difficolta nella consultazione. Nei casi di grandi aziende 
invece può essere utilizzato come sistema “usa e getta” per la gestione di progetti di 
dimensioni inferiori, che richiedono la realizzazione di un sistema in tempi brevi. 
Le applicazioni generate con Livebase offrono funzionalità che riescono a coprire la 
totalità dei bisogni della maggior parte degli utilizzatori, garantendo semplicità 
nell’utilizzo. Le funzionalità fornite ampliano il panorama delle offerte che i vari 
DBMS erogano, ma non coprono per intero quelle proposte dalle soluzioni ERP. 
Queste ultime offrono però, funzionalità molto spesso non necessarie al target di 
riferimento a cui Livebase è rivolto, inoltre costringono l’azienda a notevoli sforzi 
economici legati ai prezzi d’acquisto e al dover sottostare, da parte degli utilizzatori, 
ad una poco ripida curva di apprendimento del software.
2 
 
Come accennato, un punto di forza di Livebase è il tempo richiesto per la 
realizzazione del sistema per la gestione dei dati che, grazie all’innovativo approccio 
grafico tramite cui l’applicazione viene letteralmente disegnata, è drasticamente 
ridotto. In conseguenza di ciò anche i costi di realizzazione e gestione 
dell’applicazione risultano inferiori e altamente concorrenziali rispetto agli ERP. 
Tra gli altri vantaggi vi sono: 
 Assistenza: Il team degli sviluppatori è a disposizione per ogni tipo di assistenza 
tecnica, relativa alla modellazione iniziale e a successive modifiche 
dell’applicazione. 
 Nessuna installazione: L’applicazione è disponibile sul web ed è possibile 
accedervi da qualunque postazione con una connessione ad internet senza 
bisogno di alcuna installazione. 
 Sicurezza: Garantita dall’utilizzo di un DBMS con tutte le funzionalità che esso 
assicura come backup e ripristini. 
 Scalabilità: Garantita dal Cloud, risulta totalmente trasparente all’utilizzatore 
finale. 
 Modificabilità: L’applicazione generata può essere modificata in qualsiasi 
momento semplicemente modificando il modello associato senza perdita di dati. 
Storia 
Il progetto Livebase rappresenta attualmente il traguardo di un lungo percorso 
iniziato nel 2000 col progetto JEDI (Java Enterprise Development Infrastructure). 
Esso era rivolto a un target di esperti e mirava alla generazione di sistemi informativi 
data centrici, a partire da modelli. 
Col successivo progetto WAGNER (Web Application Generator), la nascita del 
modello di business SaaS,  indirizza lo sviluppo verso l’architettura web. 
Nel 2007 l’avvento del PaaS segna la nascita dell’attuale progetto Livebase, che 
aggiunge all’offerta disponibile servizi aggiuntivi quali il deploy, il mantenimento e 
il testing delle applicazioni generate.
3 
 
Concetti fondamentali 
Cloudlet 
Un cloudlet è un sistema informativo generato e accessibile ad un indirizzo internet, 
è composto da 3 componenti che collaborando tra loro rendono disponibile la web 
application. 
 Community: L’insieme dei membri che il cloudlet gestisce. 
 Engine: Il motore vero e proprio, che definisce al suo interno il modello su cui 
l’applicazione verrà generata, i profili dei vari membri e le policy associate. 
 Database Relazionale: Generato a partire dal modello contenuto nell’engine. 
Esistono 2 tipologie di utente: 
 Utenti Amministratori: Registrati su Livebase e gestori della propria 
applicazione. 
 End User: Utilizzatori finali dell’applicazione, i quali potrebbero tranquillamente 
essere all’oscuro del fatto che l’applicazione sulla quale lavorano sia creata con 
Livebase. 
All’interno del cloudlet è possibile gestire i diversi engine esistenti settando quello 
da utilizzare, è possibile modificare l’insieme dei membri e operare sul DB.  
Il cloudlet può essere avviato soltanto nel momento in cui l’engine è compatibile col 
DB, in caso ciò non accada, ad esempio in seguito ad una modifica dell’engine, è 
presente una feature che, se tale risoluzione non comporta perdita di dati, risolve il 
problema automaticamente, altrimenti mostra il problema all’utente che attraverso 
uno wizard risolve il conflitto. 
Le operazioni sul cloudlet comportano lo stop dell’erogazione del servizio per gli 
end user, i quali saranno impossibilitati ad accedere all’applicazione che si troverà 
down.
4 
 
Engine 
E’ il cuore dell’architettura e senza di esso il cloudlet non può essere attivato. 
Contiene il modello concettuale del DB al cui interno sono presenti un insieme di 
applicazioni che a loro volta contengono un insieme di profili. Tra le altre cose 
assicura l’accesso concorrente al DB.  
Livebase mette a disposizione degli amministratori 2 librerie, quella privata e quella 
pubblica. La libreria privata contiene i modelli creati dal proprietario del cloudlet, 
con un meccanismo di versioning per il recupero delle versioni precedenti. La 
libreria pubblica contiene i modelli condivisi dalla comunità di Livebase e approvati 
dallo staff. Tale feature aiuta gli sviluppatori e invoglia la cooperazione tra essi. 
Architettura 
Hardware 
La piattaforma si compone di 3 array di server: 
 Portal Server: Attraverso essi gli utenti amministratori possono loggarsi ed 
accedere al back-end delle proprie applicazioni contenute nei Factory Server. Gli 
utilizzatori finali invece non vi accedono mai. 
 Factory Server: Contengono l’ambiente di sviluppo che consente le operazioni di 
creazione e amministrazione dei cloudlet. Questo array è diviso a sua volta in più 
array, uno composto dai Validation Server sui quali sono contenute le versioni in 
fase di sviluppo accessibili soltanto dal team degli sviluppatori ed uno relativo ai 
Production Server che sono utilizzati dagli utenti finali e attraverso i quali essi 
possono operare sugli engine per apportare modifiche all’applicazione. Essi 
contengono sia la logica per la generazione dell’applicazione che i DB associati. 
Infine vi sono i Database Server che sono remoti e condivisi da tutti i Factory 
Server, essi permettono la gestione di DB dei vari cloudlet. 
 Hosting Server: Ospitano i cloudlet creati nei Factory Server. Sono il punto di 
accesso all’applicazione per gli end user.
5 
 
E’ inoltre possibile per l’utente che abbia tale necessità, di mantenere i dati gestiti 
dall’applicazione presso uno hosting server privato, localizzato nella sede dell’utente, 
con l’unico vincolo di avere accesso alla rete. 
 
 
Figura 1 - Architettura HW di Livebase. 
Software 
Livebase adotta un’architettura a strati rilassati secondo cui la richiesta di servizi da 
parte di un componente può avvenire soltanto verso quelli che si trovano agli strati 
inferiori. Inoltre sono adottati i principi dello stile architetturale MVC.  
Le tecnologie utilizzate sono per lo più open source, come il DBMS MySQL, il web 
server Tomcat e librerie esterne come GWT. 
Ecco brevemente elencati i principali componenti: 
 Dashboard: E’ il componente che permette la gestione dei cloudlet da parte 
dell’utente amministratore. E una sorta di facciata dalla quale è possibile gestire
6 
 
le varie operazioni che l’amministratore ha a disposizione. Esso rappresenta la 
view del sistema.  
 DashboardServant: Risiede dietro la Dashboard e, facendo da controller, smista 
le richieste pervenutegli dalla view delegando le operazioni ai componenti 
specifici. 
 HostingServant: E’ un componente posto ad un livello basso nella gerarchia, 
accessibile tramite il DashboardServant che permette la gestione dei DB e la 
manipolazione dei file war dei cloudlet. 
 Designer: Permette la realizzazione del modello concettuale associato 
all’applicazione, mette a disposizione dell’utente un editor grafico molto 
efficiente ed intuitivo che si basa su un linguaggio proprietario derivante 
dall’UML. La modellazione avviene su più livelli tra cui database, applicazione e 
profili. Su ognuno di essi è possibile definire opportuni vincoli e caratteristiche 
dell’applicazione. 
 EngineModel: Contiene l’informazione ottenuta dall’attività nel Designer. E’ 
strutturato su più livelli, gli stessi modellati nel Designer. Tra le entità gestite vi 
sono le classi generate con i rispettivi attributi, le associazioni e le composizioni 
tra di esse.  
 EngineArchiver: Gestisce le librerie pubbliche e private degli engine, 
garantendo un sistema di versioning per la seconda categoria. 
 EngineBuilder: Componente che, utilizzando vari coder, si occupa della 
generazione del codice dell’applicazione sia lato client che lato server e dello 
schema logico del database a partire dallo schema concettuale presente 
nell’Engine Model. Tale componente è stato oggetto del lavoro di tesi, è stato 
infatti studiato e implementato un nuovo Coder per la generazione di applicazioni 
Javascript lato client destinate all’utilizzo su dispositivi mobile. 
 DatabaseCoder: Permette la generazione dello schema del database a partire dal 
modello. 
 EngineCoder: Permette la generazione dell’applicazione a partire dal modello, 
assemblando componenti precostituiti presenti all’interno dell’ 
EngineFramework.