Capitolo 1 – Introduzione
6
informazioni. Queste prime applicazioni sono essenzialmente statiche, ed un
chiaro esempio di tale tipologia di applicazioni è dato dai CD ROM multimediali
ed dai cosiddetti siti web “vetrina”, il cui unico scopo è quello di fornire
informazioni.
Una prima evoluzione ha portato al diffondersi di applicazioni web
caratterizzate da una notevole componente dinamica [6]. Questa seconda
generazione di applicazioni fornisce il supporto, oltre che alla navigazione, anche
alle “tradizionali” operazioni, come i processi transazionali. Grazie a queste
applicazioni, gli utenti finali, quindi, oltre ad accedere alle informazioni possono
usufruire di servizi e interagire con l’applicazione modificandone lo stato. Le
applicazioni di e-commerce, di home banking ed i sistemi di prenotazione di vario
genere sono solo alcuni esempi di questa seconda generazione di Web
Application.
Lo sviluppo della tecnologia, ed in particolare la nascita di device mobili
di dimensioni ridotte (palmari e mobile phone) e delle nuove tecnologie di
connessione (WAP ed i futuri UMTS e GPRS), ha portato ad un’ulteriore
evoluzione. Oggi si parla di Ubiquitous Web Applications [8]: applicazioni per il
web fruibili da tipologie diverse di utenti, accessibili mediante più dispositivi (ad
esempio palmari, mobile phone, interactive-TV) ed in qualunque istante e luogo si
trovi l’utente. Questa nuova generazione di applicazioni aumenta la necessità di
personalizzazione nell’accesso alle informazioni ed alle operazioni. Il
comportamento e lo stato dell’applicazione varia in base alle esigenze della
categoria a cui appartiene un utente, alle sue specifiche preferenze, ed ai device
utilizzati per accedere al sistema. Un’applicazione per la gestione di carte
bancomat e conti correnti che consenta ad un cliente della banca di verificare la
disponibilità del proprio credito su un conto, e che suggerisca il più vicino
sportello bancomat presso cui effettuare un prelievo, attraverso il proprio telefono
cellulare o un palmare, e che possa essere utilizzata dal PC di casa per richiedere
l’acquisto di una particolare carta bancomat, è un chiaro esempio di cosa possa
essere una applicazione web ubiqua.
Capitolo 1 – Introduzione
7
All’interno del settore delle applicazioni web di ultima generazione, si
pone il Progetto UWA il quale si interessa della creazione di un framework di
metodologie a supporto del design delle Ubiquitous Web Application, sostenendo
[8] che la qualità, l’efficacia ed il successo di questa tipologia di applicazioni sono
strettamente legati, appunto, alla qualità del loro design. Una maggior attenzione a
questo aspetto si traduce in un risparmio di tempo e di costi nelle successive fasi
di implementazione e manutenzione e porta alla creazione di applicazioni più
vicine alle aspettative ed alle esigenze degli utenti finali. A tal proposito si è
osservato che il maggior tempo impiegato per realizzare un miglior design
consente di realizzare ovviamente applicazioni migliori, caratterizzate da una
migliore usabilità. Si valuta che il ritorno in termini di usabilità, sperimentata
dagli utenti finali dell’applicazione, giustifichi e ripaghi il maggiore sforzo
iniziale di design.
1.2 Obiettivi del lavoro di tesi
Il presente lavoro di tesi è strettamente integrato con le attività del Progetto
UWA, ed in particolare si inserisce nell’attività di verifica e valutazione della
metodologia mediante l’applicazione della stessa ad un caso reale: la
progettazione di un’applicazione di e-banking per Banca 121, partner del progetto.
In seguito ad un’analisi complessiva delle attività svolte e dei servizi già
offerti on-line da Banca 121 è stata selezionata, come applicazione pilota
necessaria per testare la metodologia UWA, l’applicazione che tratta la vendita e
gestione on-line di carte bancomat. Questa Web Application costituirà una parte
dei servizi resi disponibili on-line dalla banca e sarà accessibile dal sito
istituzionale di Banca 121. Sebbene l’applicazione si concentri sulla vendita di
carte bancomat, essa è rappresentativa dell’intera classe di applicazioni per la
vendita on-line di servizi bancari.
Capitolo 1 – Introduzione
8
In questo contesto il presente lavoro di tesi si prefigge i seguenti obiettivi:
™ Effettuare l’analisi e la progettazione dell’applicazione pilota selezionata
utilizzando la metodologia proposta da UWA e fornire ai partner tecnici
del progetto un feedback sulla metodologia, sfruttando l’esperienza
compiuta dall’applicazione della stessa ad un caso reale.
™ Individuare i requisiti per i tool di supporto alla metodologia, sfruttando
l’esperienza acquisita dall’applicazione manuale della stessa nel corso
della progettazione dell’applicazione.
™ Valutare l’efficacia della metodologia e verificare gli effetti
dell’applicazione del framework UWA, confrontando l’analisi e la
progettazione, ottenuta con UWA, con i corrispondenti risultati ottenuti
mediante l’applicazione delle tecniche di progettazione normalmente
impiegate in Banca 121.
La collaborazione con il Progetto UWA si è concretizzata nella
partecipazione, insieme agli altri partner, alla stesura del documento tecnico
“Deliverable 11: Requirements and Design specification for Banca121 Pilot
Application” disponibile pubblicamente sul sito ufficiale del progetto [S1]. In
questo documento è presentato il design dell’applicazione pilota, secondo
l’approccio UWA, insieme ad un’analisi critica dei diversi aspetti della
metodologia ricavata dall’esperienza acquisita durante il lavoro di progettazione
dell’applicazione in questione.
Capitolo 1 – Introduzione
9
1.3 Metodologia di lavoro
La metodologia di lavoro seguita per il raggiungimento degli obiettivi
preposti è quella rappresentata schematicamente in Figura 1-1.
Attività di supporto
Siti Web
Documentazione tecnica
sul framework UWA
Bibliografia
Progetti in corso
Attività principali
Legenda
Attività
Flussi di
Input/Output
Flussi tra le
Attività
Input/Output
Studio della modellazione
secondo l’approccio UWA
Analisi di applicazioni
ipermediali di esempio
Interviste
Analisi preliminare e
indagine sui requisiti
Descrizione informale
dell’applicazione
Bibliografia sull’analisi
dei requisiti
Sito ufficiale
di Banca 121
Modelli UWA dei
diversi aspetti di design
Analisi critica
sulla metodologia
Feedback verso i
partner del progetto
Modellazione con UWA
dell’applicazione pilota
Conclusioni
Figura 1-1: Metodologia di lavoro
Capitolo 1 – Introduzione
10
Come si può osservare dallo schema, le fasi iniziali sono state più che altro
di supporto per le successive, in quanto hanno consentito di acquisire il
background, sulla modellazione di Web Application e sulla metodologia UWA,
necessario per poter affrontare il lavoro proposto. In queste prime fasi,
parallelamente allo studio della documentazione tecnica sul framework UWA, è
stata effettuata un’analisi di applicazioni ipermediali di esempio, prendendo in
considerazione siti reali o progetti in corso, per verificare l’applicabilità dei
concetti evidenziati dall’approccio UWA ai singoli aspetti del processo di design
di una Web Application.
Grazie ai risultati ottenuti nelle fasi di supporto, si è potuto procedere con
la parte centrale del lavoro. Innanzitutto, è stata effettuata una prima descrizione
ed analisi dell’applicazione pilota di Banca 121, utilizzando un approccio
tradizionale. Per fare ciò si è tenuto conto delle informazioni ricavate dalle
interviste avute con i manager di banca 121 e dall’analisi del sito esistente. Al
termine di questa attività è stata prodotta una prima descrizione informale
dell’applicazione che raccoglie le informazioni riguardo alle tipologie di utenti, ai
device utilizzati, ai requisiti in termini informativi e funzionali dell’applicazione
stessa.
Nel corso dell’attività successiva è stata modellata l’applicazione pilota
seguendo l’approccio proposto da UWA. Per ciascun aspetto del design di una
Web Application sono stati realizzati i modelli UWA per l’applicazione pilota di
Banca 121. Durante questa attività è stato necessario un aggiornamento ed una
rielaborazione continua dei modelli prodotti per tener allineato il design
dell’applicazione alla metodologia UWA in evoluzione. Le considerazioni critiche
sulla metodologia UWA, emerse dall’applicazione della stessa a questo caso di
studio, costituiscono un ulteriore ed importante risultato di questa attività.
In ultimo, si traggono le conclusioni sul lavoro svolto, sui risultati ottenuti
e sulla validità della metodologia utilizzata.
Capitolo 1 – Introduzione
11
1.4 Struttura della tesi
Questa tesi è organizzata in due parti che includono 7 capitoli.
La parte prima è costituita dai capitoli 1 e 2 ed è introduttiva al problema
affrontato in questa tesi. Nel capitolo 1 si espone il contesto in cui è inserito il
lavoro di tesi, la metodologia seguita, la struttura d’insieme, nonché gli obiettivi
preposti. Nel capitolo 2 si effettua un’analisi dello stato dell’arte nel settore della
progettazione di applicazioni per il web e viene definito il contesto in cui si
colloca il Progetto UWA, del quale sono poi evidenziati gli obiettivi, le
motivazioni e l’approccio proposto.
La seconda parte del lavoro va dal capitolo 3 al capitolo 7 ed è incentrata
sull’applicazione della metodologia UWA alla progettazione dell’applicazione di
vendita on-line di carte bancomat, e sulle considerazioni emerse in questa fase.
Nel capitolo 3 viene presentata l’applicazione pilota mediante una descrizione
informale, individuando le tipologie di utenti, il contenuto informativo ed i
requisiti funzionali della stessa. Si tratta di una pre-analisi dei requisiti effettuata
seguendo la metodologia tradizionale.
Nel capitoli 4, 5 e 6 vengono illustrati i modelli prodotti, seguendo
l’approccio UWA, in relazione ai diversi aspetti che caratterizzano il design
dell’applicazione modellata. Per ciascun aspetto sono evidenziate: l’innovazione
introdotta da UWA, le difficoltà incontrate nell’utilizzo e le considerazioni
critiche nate da questa esperienza di modellazione, che sono servite da feed-back
al progetto per il miglioramento della metodologia. Il capitolo 4, in particolare, si
occupa della “Requirements Elicitation”: l’individuazione ed analisi dei requisiti
dell’applicazione. Il capitolo 5 sviluppa le problematiche legate alla modellazione
ipermediale dell’applicazione: definizione delle strutture informative, delle
strategie navigazionali, della presentazione e delle operazioni dell’applicazione. In
questo capitolo vengono trattati anche gli aspetti di “customisation” rispetto alle
diverse tipologie di utenti e device impiegati. Il capitolo 6 si occupa della
modellazione delle transazioni.
Nel capitolo 7, infine, si traggono le conclusioni sul presente lavoro di tesi.
Capitolo 2 – Contesto e Stato dell’Arte
12
2 Contesto e Stato dell’Arte
2.1 Contesto
In ambito industriale, l’impiego di metodologie sistematiche nella
progettazione e sviluppo di applicazioni è, molto spesso, trascurato soprattutto a
causa dei vincoli sui tempi di produzione imposti dal “time to market” [1].
D’altra parte l’ingegneria del software promette sostanziali miglioramenti,
nel processo produttivo e nei risultati raggiungibili, a patto però di un maggiore
sforzo nella fase iniziale di progettazione. Ciò è ancor più vero nel settore delle
Web Application nel quale è auspicabile [2-5] l’utilizzo di approcci più
sistematici. Ed, infatti, gli approcci attualmente impiegati nella progettazione delle
Web Application soffrono dell’insieme di problemi di seguito elencati:
™ Mentre i siti web tradizionali erano principalmente contenitori di
informazioni, che consentivano agli utenti di eseguire ricerche e navigare
attraverso grandi quantità di informazioni, i siti web moderni, invece,
offrono all’utente la possibilità di eseguire anche operazioni, che possono
essere molto complesse (ad es. invocazione di transazioni sofisticate).
Purtroppo oggi non esistono modelli o metodologie che integrino questi
due aspetti del design (multimedialità ed operazioni) in modo da
assicurarne la consistenza.
™ Correntemente, le metodologie più consolidate coprono solo specifici
aspetti del design di un’applicazione web, come la Requirements
Elicitation ad esempio. Sarebbe necessario un ambiente che integri le
diverse attività svolte durante la progettazione in modo consistente.
™ Oggi, inoltre, si tende a progettare singole applicazioni. La progettazione
di famiglie di applicazioni, invece, consentirebbe di riutilizzare il
Capitolo 2 – Contesto e Stato dell’Arte
13
contenuto ed il software in diverse situazioni e per diversi scopi, di ridurre
lo sforzo complessivo di design e di assicurare una maggiore consistenza
tra le applicazioni tra loro correlate.
™ Le applicazioni web stanno diventando ubique, cioè accessibili
indipendentemente dalla posizione fisica degli utenti, e la “location
awareness” sta diventando un ingrediente importante nelle applicazioni.
Un cliente che acceda, mediante un dispositivo mobile, al sito web della
propria banca si aspetta che l’applicazione web reagisca in modo
appropriato ad una richiesta del tipo “dove posso effettuare un prelievo
bancomat? ”. L’applicazione, sulla base dell’attuale posizione fisica del
cliente, dovrebbe suggerire il più vicino sportello bancomat a cui il cliente
può recarsi. Per realizzare delle applicazioni di qualità elevata è
importante, quindi, che si tenga conto dell’ubiquità nelle diverse fasi che
compongono il design e non solo alla fine, come si tende a fare oggi.
™ Il multi-device è un aspetto delle Web Application destinato ad assumere
una importanza sempre maggiore nel prossimo futuro. Le applicazioni
web saranno accessibili da diversi dispositi: PC, PDA, cellular phone,
interactive TV, ect. Questi dispositivi, pur potendo eseguire lo stesso
software, si distinguono per differente tipo di connessione, larghezza di
banda, e stili di interazione. Le applicazioni multi-device condividono
informazioni ed operazioni, però è necessario che siano adattate per
ciascun dispositivo. Per effettuare questo adattamento bisogna considerare
diversi fattori: la strategia di visualizzazione, il layout, lo stile di
interazione, le strutture informative, i cammini di navigazione e le
operazioni rese disponibili agli utenti. Quindi, per le applicazioni, che
prevedono l’utilizzo di più dispositivi, non dovrebbero essere realizzati
design separati, uno per ciascun dispositivo, come si tende a fare oggi. Si
dovrebbe pensare, invece, alla progettazione di una famiglia di
applicazioni, di un “Application Framework” che preveda gli adattamenti
necessari per supportare molteplici device.
Capitolo 2 – Contesto e Stato dell’Arte
14
™ Si osserva, in ultimo, che per una Web Application è fondamentale
l’aspetto di personalizzazione. Il modo in cui l’applicazione interagisce
con uno specifico utente varia in base a quelle che sono le sue esigenze, il
suo profilo, i suoi gusti o le situazioni d’uso. Anche questo è un aspetto
che è necessario prendere in considerazione fin dall’inizio nel processo di
progettazione.
2.2 Stato dell’arte
Nel presente paragrafo è illustrato lo stato dell’arte, nella progettazione di
Applicazioni Web di ultima generazione, relativamente agli aspetti che il Progetto
UWA [8] ha evidenziato quali rilevanti in tale settore.
2.2.1 Requirements Engineering
Durante la fase di specifica ed analisi dei requisiti si tende ad individuare i
goal del mondo reale, i servizi offerti ed i vincoli che caratterizzano un sistema
software. Siccome la qualità di un sistema è legata a quanto il sistema rispetta i
requisiti su cui è modellato, la direzione principalmente seguita per migliorare un
sistema consiste nell’assicurarsi che i requisiti del sistema siano determinati in
modo accurato e che l’attenzione sui requisiti sia mantenuta nel corso del processo
di sviluppo del software.
L’importanza di questa attività ha portato al diffondersi di differenti
tecniche, metodologie e notazioni che vanno da semplici approcci euristici a
complessi tentativi di formalizzazione. Un elenco non esaustivo di tali
metodologie è in [9-12]. La maggior parte degli approcci tendono a distinguere i
requisiti in due categorie: requisiti funzionali e non funzionali. La prima categoria
descrive servizi e funzioni che il sistema deve offrire. I requisiti non funzionali,
invece, si riferiscono a tutti gli altri aspetti che rappresentano dei vincoli che il
sistema deve rispettare. Alcuni requisiti non funzionali hanno una natura
Capitolo 2 – Contesto e Stato dell’Arte
15
tecnologica (ad esempio viene richiesta la portabilità verso particolari device o
piattaforme software), altri si riferiscono ad aspetti di usabilità, identificando le
condizioni sotto cui un sistema è easy-to-use. Infine un requisito non funzionale
può avere una natura sociale, legale o politica [12,14].
2.2.2 Hypermedia Design
HDM (Hypertext Design Model) [4,13] ha fornito il primo insieme di
concetti e primitive di modellazione per aiutare i progettisti a gestire la
complessità nel progettare applicazioni data-intensive e navigazionali. HDM fu il
precursore di un numero di modelli, includendo tra i più famosi: RMM [15],
OOHDM [16], WSDM [17], WebML [18]. I vari modelli differiscono
principalmente nella complessità e completezza delle primitive proposte. Ad
esempio, OOHDM, WSDM e WebML includono primitive per descrivere aspetti
di presentazione. OOHDM e WebML forniscono un insieme di semplici pattern
per la progettazione della navigazione.
Alcuni modelli, come ad esempio HDM-lite [5], Araneus e WebML
supportano in modo esplicito la progettazione di siti web data-intensive che si
appoggiano su un DBMS sottostante. In particolare Araneus supporta la
generazione di strutture ipertestuali sul web, che rappresentano delle “viste” su un
database.
2.2.3 Customisation Design
La natura multi-utente e multi-canale, che caratterizza le applicazioni web
ubique, aggiunge alla progettazione una nuova dimensione, connessa alla
necessità di adattare un’applicazione web non solo ai differenti profili utenti ma
anche alle situazioni d’uso, alla posizione fisica dell’utente (“location
awareness”), ed ai vincoli imposti dai differenti dispositivi di accesso
all’applicazione.
Ricevi informazioni sui nostri servizi, sulle offerte e non perdere news e consigli su università e lavoro.
