Progetto “Tecnologie di Sviluppo di Applicazioni Internet”

Progetto “Tecnologie di Sviluppo di Applicazioni Internet”
Progetto “Tecnologie di Sviluppo di Applicazioni
Internet”
1.
Obiettivo
Lo scopo di questo documento è quello di descrivere e pianificare un’attività di analisi e valutazione degli ambienti software che permettono di generare e modificare (semi-) automaticamente codice di applicazioni, eventualmente a partire da una specifica grafica basata
su formalismi predefiniti.
Si vuole quindi comprendere sia qual è la classe delle applicazioni che si possono specificare per mezzo dei formalismi grafici sia quali sono le modalità con cui questi ambienti permettono di specificare, generare e manutenere il codice.
La valutazione viene condotta in modo comparativo seguendo due approcci: uno di tipo
metodologico, che analizza il modo con cui le caratteristiche rilevanti per questo tipo di ambienti sono realizzate in ognuno degli ambienti considerati; l’altro di tipo sperimentale, provando ad implementare uno stesso caso d’uso in ognuno degli ambienti esaminati.
Viene sempre utilizzato lo schema di riferimento delle architetture software conosciuto
come Model-View-Controller
2.
Ambienti da esaminare
Gli ambienti che possono essere utilizzati nel progetto sono i seguenti (in ordine decrescente di preferenza):
1. Ruby on Rails (RoR)
2. Symfony http://www.symfony-project.com/
3.
Akelos http://trac.akelos.org/
4.
www.radicore.org
5.
CakePHP http://www.cakephp.org/
6. PHPopenbiz http://www.phpopenbiz.org/document/
7.
http://www.pradosoft.com/
8.
http://www.phpontrax.org/
9.
http://seagull.phpkitchen.com/
10.
http://framework.zend.com/
11.
http://www.codeigniter.com/
12.
http://p4a.sourceforge.net/
Se si utilizza un ambiente diverso da RoR bisogna confrontarne le caratteristiche con RoR.
E’ possibile svolgere progetti sviluppati “orizzontalmente”: applicazione semplice sviluppata
utilizzando più ambienti (in tal caso l’enfasi è sull’aspetto metodologico). Oppure “vertical-
versione 1.1 del 3 Gennaio 2008
pag. 1 di 8
Progetto “Tecnologie di Sviluppo di Applicazioni Internet”
mente”: applicazione complessa sviluppata utilizzando un singolo ambiente (in tal caso
l’enfasi è sull’aspetto sperimentale).
3.
Approccio metodologico
Vengono investigate le seguenti cinque classi di caratteristiche
1. Definizione Model
 Linguaggio e modalità utilizzate per la definizione del modello, con riferimento
alla possibilità di importare/esportare SQL e dati esistenti
 Utilizzo ORM o pattern Active Record
 Tipi di dato supportati
 di base (testo, numerico, data, ecc.)
 avanzati (file, foto, ecc.)
 Definizione di chiavi primarie
 Definizione di chiavi esterne
 Definizione di relazioni tra tabelle di varia cardinalità (1-1, 1-N, M-N, M-N through). Supporto single-table inheritance o associazioni polimorfiche.
 Definizione di viste
 Definizione di vincoli sul formato e sul contenuto dei dati
 supporto validazione lato client (p.e. Javascript)
 supporto validazione lato server
 Importazione ed esportazione dei dati (testo, xml, pdf, xls,...)
2. Definizione View
 Linguaggio target dell'applicazione generata (p.e. HTML, libreria GUI Swing per
Java, ....)
 Generazione automatica moduli
 inserimento record
 modifica record
 eliminazione record
 ricerca record
 elenco risultati (ordinamento singolo campo, ordinamento campi multipli, paginazione, ecc.)
 Possibilità di operare su più record contemporaneamente
 Facilità di personalizzazione della grafica (p.e. mediante l'utilizzo di template,
temi grafici, ecc..)
 Gestione degli interventi di personalizzazione della grafica con particolare riferimento alla sopravvivenza di tali interventi in seguito ad aggiornamenti dell'applicazione effettuate nell'ambiente
 Definizione e gestione di menu
 Progettazione visuale della struttura dell'interfaccia grafica
 Supporto AJAX
3. Definizione Controller
 Formalismo / linguaggio di specifica e realizzazione (p.e. reti di Petri, Statecharts, diagrammi delle transizioni di stato, evento/condizione/azione)
 Possibilità di generazione di codice e, in caso affermativo, linguaggio di programmazione e infrastruttura utilizzati (Servlet, Web Services, etc...)
 Routing (mapping tra URL ed azioni / metodi)
versione 1.1 del 3 Gennaio 2008
pag. 2 di 8
Progetto “Tecnologie di Sviluppo di Applicazioni Internet”
 Supporto RESTful services
4. Applicazione generata
 Chiarire se l'applicazione generata viene interpretata a runtime oppure c'è una
fase di generazione di codice relativo a Model, View e Controller.
 Requisiti sistemistici dell'applicazione generata (p.e. indipendenza da uno specifico DBMS)
 Supporto all'internazionalizzazione
 gestione utenti e gruppi
 gestione autorizzazioni
5. Ambiente generatore
 Requisiti sistemistici dell'ambiente generatore
 Disponibilità di ambienti e strumenti di sviluppo che supportano il framework
 Convenzioni di naming
 Supporto al ciclo di vita
 Modularità delle modifiche/personalizzazioni
 Supporto pattern observer
 Generazione automatica di dati di test
 Supporto allo sviluppo basato su “test di unità”
 Gestione upgrade e downgrade tra versioni
 Disponibilità e qualità della documentazione (tutorial, manuali, ecc..) e di supporto in genere
 Organizzazione e dimensioni della comunità di sviluppatori
 Costo dell'ambiente e licenza utilizzata (commerciale o opensource: GPL, BSD,
MIT, ecc...) con particolare riferimento ai vincoli allo sfruttamento commerciale
4.
Approccio sperimentale
Di seguito si descrivono alcune applicazioni utilizzati per valutare gli ambienti precedentemente indicati. Generalmente sono abbastanza semplici, ma sufficientemente generali per
evidenziare empiricamente le differenze e somiglianze tra le funzionalità e le capacità di
questi ambienti.
Le specifiche delle seguenti applicazioni sono intese come indicative e soggette ad ulteriori
modifiche e raffinamenti.
4.1. Elenco applicazioni
4.1.1
LIBRERIA
Assumiamo che tale applicativo gestisca una libreria, permettendo le operazioni di visualizzazione, inserimento, modifica, eliminazione e ricerca. Da un punto di vista concettuale i
dati sono modellati mediante tre entità: Libro, Autore, Editore e due relazioni Ha-Scritto, tra
Libro e Autore con cardinalità M a N, e Ha-Pubblicato, tra Editore e Libro con cardinalità 1
a N.
La base di dati sottostante deve avere le seguenti tabelle:
libro con i seguenti attributi:
 libro_id (o id) automaticamente assegnato dal DBMS (chiave primaria)
versione 1.1 del 3 Gennaio 2008
pag. 3 di 8
Progetto “Tecnologie di Sviluppo di Applicazioni Internet”






editore_id campo obbligatorio, chiave esterna della tabella Editore
titolo stringa, campo obbligatorio
prezzo numerico
libro_stato enumerato, con dominio: {fuori commercio, disponibile, esaurito,ordinato}
copertina, stringa (corrisponde al nome di un file contenente l’immagine della copertina)
data_pubblicazione, data
autore con i seguenti attributi:

autore_id (o id) automaticamente assegnato dal DBMS (chiave primaria)

nome stringa
editore con i seguenti attributi:
 editore_id (o id) automaticamente assegnato dal DBMS (chiave primaria)
 casa_editrice stringa
ha-scritto con i seguenti attributi:
 ha-scritto_id (o id) automaticamente assegnato dal DBMS (chiave primaria)
 libro_id campo obbligatorio, chiave esterna della tabella Libro
 autore_id campo obbligatorio, chiave esterna della tabella Autore
 note, tipo testo (non stringa)
Variante n. 1: aggiungere entità Pubblicazione che si specializza in Libro e nella nuova entità Rivista.
Variante n. 2: aggiungere recensioni e valutazioni.
Variante n. 3: aggiungere funzionalità e-commerce.
4.1.2
GESTIONALE
Assumiamo che tale applicativo gestisca un negozio, permettendo le operazioni di visualizzazione, inserimento, modifica, eliminazione e ricerca. Da un punto di vista concettuale i
dati sono modellati mediante le seguenti entità: Cliente, Prodotto, Ordine,
e le seguenti relazioni
Riga-Ordine, tra Ordine e Prodotto con cardinalità M a N,
Ha-comprato, tra Cliente e Ordine con cardinalità 1 a N.
La base di dati sottostante che deve supportare queste funzionalità deve avere le seguenti
tabelle:
prodotto
cliente
ordine
riga_ordine
Possibile estensione: aggiungere un'entità Dipendente ed associare le righe dell'ordine a
zero oppure un dipendente.
versione 1.1 del 3 Gennaio 2008
pag. 4 di 8
Progetto “Tecnologie di Sviluppo di Applicazioni Internet”
4.1.3
TOUR-IST
Gli Autisti devono condurre i clienti attraverso le varie località in cui il loro tour prevede fermate. Queste possono aver luogo o presso alberghi o presso beni artistici/ambientali. Le
fermate, di entrambi i tipi, sono caratterizzate dal nome del bene o dell'albergo e dall'indirizzo, ed eventuale numero di telefono, di questi. L'autista vuole poter conoscere i dati temporali relativi a tutte le fermate del tour. In particolare per i beni da visitare è d'interesse la
giornata (relativamente alla data di partenza del tour) e l'ora d'inizio
della visita, mentre per gli alberghi si vogliono sapere le giornate e le ore di arrivo e di partenza. Ogni tour può essere replicato in più date. Altri dati dei tour sono la data di ritorno e
il numero totale di Km.
Gli Autisti desiderano avere informazioni circa i tour cui sono stati assegnati e i pullman
che dovranno guidare. Inoltre necessitano dei dati (nome, regione, stato) non solo delle località in cui il tour si fermerà, ma di tutti quelli utili a tracciare con precisione il percorso del
tour. A tal fine sarebbe d'aiuto poter disporre delle distanze tra le principali località come
pure di mappe con diversi livelli di dettaglio (e indicazione della zona laddove la mappa sia
relativa solo a parte di una città). Gli Autisti, e i pullman loro assegnati, hanno come unità
minima di lavoro il tour giornaliero e a loro disposizione è un cellulare fornito dall'agenzia.
Infine, per quanto riguarda i pullman, si dovranno memorizzare le seguenti informazioni:
numero di posti, ingombri del veicolo, sua autonomia, targa e il valore del contatore di km
(aggiornato dall'autista al termine del tour).
versione 1.1 del 3 Gennaio 2008
pag. 5 di 8
Progetto “Tecnologie di Sviluppo di Applicazioni Internet”
4.2. Funzionalità da implementare
Come detto, le funzioni che devono essere fornite sono quelle standard di manipolazione
dei dati note anche con l’acronimo CRUD (Create, Read, Update, Delete), cioè inserimento, lettura, aggiornamento, cancellazione.
La lettura avviene sia in forma sintetica, consultando un elenco (paginabile ed ordinabile in
base a qualunque attributo) di tutti gli elementi presenti nella tabella, sia in forma dettagliata, consultando tutti i campi di un elemento, visualizzato singolarmente.
L’ordinamento deve essere ricordato quando si cambia pagina.
In fase di inserimento di ognuno degli elementi vengono forniti i dati che non sono chiavi
primarie della tabella nella quale viene inserito.
versione 1.1 del 3 Gennaio 2008
pag. 6 di 8
Progetto “Tecnologie di Sviluppo di Applicazioni Internet”
La modifica e cancellazione possono avvenire sia selezionando un elemento su di un elenco (paginabile ed ordinabile in base a qualunque attributo) che visualizza l’intero contenuto
di una tabella, sia fornendo direttamente l’ID dell’elemento stesso. Si noti che in fase di modifica devono essere editabili esclusivamente i campi che non sono chiave primaria. Sia
cancellazione che modifica chiedono la conferma riepilogando le modifiche che si stanno
per apportare. Si noti che in fase di modifica devono essere editabili esclusivamente i campi che non sono chiave primaria.
Per la ricerca, infine, si richiede che l'utente possa cercare un'arbitraria sottostringa, che
deve inserire in un apposito campo di testo, e che selezioni tramite delle checkbox i campi
nei quali desidera ricercare.
In breve, l'interfaccia della ricerca dovrà disporre di un campo di testo e di tanti checkbox
quanti sono i campi nei quali è possibile ricercare.
La funzione restituisce tutti i libri che soddisfano i criteri di ricerca in un elenco paginato, ordinabile, ecc. I risultati della ricerca devono essere ricordati quando si cambia pagina.
Gestire in maniera appropriata le relazioni, visualizzando campi significativi per le tabelle
collegate, non gli id.
Se sono specificate azioni da eseguire su tabelle referenziate e referenzianti in caso di
cancellazione o di modifica, chiedere sempre conferma all’utente prima di eseguirle.
In ciascun progetto, anche se non specificato esplicitamente, deve essere sempre presente una tabella contenente almeno:
 un attributo di tipo stringa testuale (varchar)
 un attributo di tipo numerico
 un attributo di tipo data oppure ora oppure data-ed-ora
 un attributo di tipo file allegato
 un attributo di tipo testo (text)
4.3. Autenticazione
Il sistema deve prevedere un meccanismo di autenticazione basato su nome utente e password.
La tabella utente supporta il rispetto delle seguenti misure minime di sicurezza:
* le password sono di lunghezza pari almeno ad 8 caratteri
* le password sono registrate nella tabella in modo cifrato con un algoritmo one-way
MD5
* si impone all'utente il cambiamento della password se sono passati più di 6 mesi dall'ultimo cambiamento della password stessa
* le utenze che non hanno fatto alcun accesso durante gli ultimi 6 mesi vengono disabilitate
versione 1.1 del 3 Gennaio 2008
pag. 7 di 8
Progetto “Tecnologie di Sviluppo di Applicazioni Internet”
La tabella utente, che tiene traccia nel DB degli account degli utenti registrati nel sistema e
delle loro credenziali di accesso, ha pertanto la seguente struttura ed uso degli attributi:
* usernameMail, indirizzo email col vincolo "unique"
* password, autoesplicativo
* passwordLastChanged, con dominio timestamp, memorizza la data dell'ultimo cambiamento password, per forzare una nuova password dopo 6 mesi di non accesso)
* expired, con dominio {S, N}, dove S=disattivato, N=attivo
* flagFirstEntry, con dominio {S, N}, dove S=primo accesso, si forza il cambiamento della
password inviata, N=accesso successivo
* lastAccess, con dominio timestamp, memorizza la data dell'ultimo accesso al sistema,
per la disattivazione dopo 6 mesi di non accesso)
* role, con dominio numerico descrive il tipo di utente
Il cambiamento della password cambiata più di 6 mesi prima (si usa il valore standard di
180 giorni) viene automaticamente forzato al primo accesso che viene effettuato nel momento in cui è stata superata la scadenza per il cambiamento della password stessa. Questo vuol dire che si forza il cambiamento se al momento dell'accesso l'ultimo cambiamento
della password risale a più di 180 giorni prima.
5.
Elementi di valutazione del progetto
La valutazione del lavoro terrà conto dei seguenti aspetti:
 architettura del programma
 aderenza paradigma MVC
 aderenza alle specifiche
 usabilità ed accessibilità
 Efficienza
 utilizzo di tecnologie e funzionalità avanzate (AJAX, REST)
 presenza di test automatici
 gestione di casi particolari e/o loro discussione nella documentazione
 duplicazione del codice
 leggibilità e chiarezza dichiarativa del codice (uso di costanti, scelta dei nomi per le
costanti, le variabili, le funzioni, i metodi)
 documentazione interna (commenti nel codice)
 documentazione esterna
versione 1.1 del 3 Gennaio 2008
pag. 8 di 8