-
UNIVERSITA` DEGLI STUDI DI MODENA
E REGGIO EMILIA
Facolta` di Ingegneria - Sede di Modena
Corso di Laurea in Ingegneria Informatica
Modellazione concettuale diinterfacce web
Relatore Tesi di Laurea diChiar.mo Prof. Sonia Bergamaschi
Silvia Balugani
Correlatore ControrelatoreDott. Ing. Maurizio Vincini Chiar.mo
Prof. Paolo Tiberio
Anno Accademico 2002 - 2003
-
Parole chiave:Applicazioni Web
Modellazione concettualeFront-end ipertestuale
-
RINGRAZIAMENTI
Desidero ringraziare la prof.ssa Bergamaschi e tutti coloro che
hannocreduto in me e mi hanno aiutato in questo periodo cos`
intenso
-
Contents
Introduction 1
1 La modellazione concettuale dei componenti front-end 5
1.1 Il ruolo della modellazione nella fase di proget-tazione e
nellutilizzo dei CASE tool per la pro-duzione di un componente
software . . . . . . . . 5
1.2 La modellazione concettuale e le applicazioni web 7
1.3 I componenti dello strato front-end di una webapplication .
. . . . . . . . . . . . . . . . . . . . . 10
1.3.1 Architettura software a tre livelli . . . . . 11
1.3.2 Architettura multilivello di unapplicazioneweb . . . . . .
. . . . . . . . . . . . . . . 13
Individuazione dei componenti front-end . 14
2 Requisiti necessari per un linguaggio di model-lazione web
19
2.1 Categorizzazione dei requisiti sulla base
dellarchitetturainformativa e funzionale . . . . . . . . . . . . .
. 19
2.1.1 Requisiti funzionali . . . . . . . . . . . . . 20
Capacita` di modellare integrazione e con-nettivita` . . . . . .
. . . . . . . 20
Abilita` di supportare luso di patterns . . 20
Abilita` di rappresentare i concetti indipen-dentemente dalla
tecnologia . . . 21
i
-
ii CONTENTS
2.1.2 Requisiti legati allinformazione . . . . . . 21
Abilita` di modellare concetti di presen-tazione . . . . . . . .
. . . . . . 21
Abilita` di modellare la navigazione . . . . 22
Abilita` di modellare le interazioni tra ut-ente ed informazione
. . . . . . . 23
Abilita` di modellare i ruoli di utenti e gruppidi utenti . . .
. . . . . . . . . . . 24
Abilita` di modellare il contenuto . . . . . . 24
2.1.3 Requisiti generali . . . . . . . . . . . . . . 25
Abilita` di collegare funzionalita` ed infor-mazione . . . . . .
. . . . . . . . 25
Abilita` di mantenere lintegrita` del sistema 25
Abilita` di modellare a vari livelli di as-trazione . . . . . .
. . . . . . . . 26
Abilita` di supportare la gestione del ciclodi vita delle
applicazioni web . . 26
Supporto di un CASE tool . . . . . . . . . 26
2.2 Categorizzazione dei requisiti sulla base di tre di-mensioni
ortogonali . . . . . . . . . . . . . . . . . 27
2.2.1 Livelli:Contenuto,Ipertesto,Presentazione . 27
2.2.2 Aspetti:Struttura e Comportamento . . . . 29
2.2.3 Fasi:Analisi,modellazione concettuale,logica,fisicaed
implementazione . . . . . . . . . . . . . 30
3 Analisi e confronto dei linguaggi proposti per lamodellazione
di interfacce web 31
3.1 Linguaggi di modellazione web nellambito dellHypermedia
34
3.1.1 HDM:Hypertext Design Model . . . . . . . 35
Analisi di HDM sulla base dei requisitilegati alle tre
dimensioni ortog-onali . . . . . . . . . . . . . . . . 39
3.1.2 HDM-lite/AutoWeb . . . . . . . . . . . . 39
-
CONTENTS iii
Analisi di HDM-lite/AutoWeb sulla basedei requisiti legati alle
tre dimen-sioni ortogonali . . . . . . . . . . 41
3.1.3 WebML . . . . . . . . . . . . . . . . . . . 42
I modelli WebML . . . . . . . . . . . . . . 44
Analisi di WebML sulla base dei requisitilegati alle tre
dimensioni ortog-onali . . . . . . . . . . . . . . . . 54
3.2 Linguaggi di modellazione web nellambito deiDatabase systems
. . . . . . . . . . . . . . . . . . 55
3.2.1 RMM . . . . . . . . . . . . . . . . . . . . 55
Relationship Management Data Model (RMDM) 56
Relationship Management Design Method-ology (RMM) . . . . . . .
. . . . 59
Analisi di RMM sulla base dei requisitilegati alle tre
dimensioni ortog-onali . . . . . . . . . . . . . . . . 63
3.2.2 Araneus . . . . . . . . . . . . . . . . . . . 64
Fasi 1 e 2 : Il processo di modellazione deldatabase . . . . . .
. . . . . . . . 65
Fase 3 : Modellazione concettuale dellipertesto: il modello NCM
. . . . . . . . . 67
Fase 4 : Modellazione logica dellipertesto: il modello ADM . . .
. . . . . . 72
Fase 5 : Modellazione della presentazione . 80
Fase 6 : Mapping dellipertesto sul databasee generazione delle
pagine . . . . 81
Analisi di Araneus sulla base dei requisitilegati alle tre
dimensioni ortog-onali . . . . . . . . . . . . . . . . 82
3.2.3 Strudel . . . . . . . . . . . . . . . . . . . . 83
Confronto tra i progetti Strudel ed Araneus 85
-
iv CONTENTS
Analisi di Strudel sulla base dei requisitilegati alle tre
dimensioni ortog-onali . . . . . . . . . . . . . . . . 86
3.3 Linguaggi di modellazione web nellambito dellObject-oriented
modelling . . . . . . . . . . . . . . . . . 87
3.3.1 OOHDM . . . . . . . . . . . . . . . . . . . 87
La modellazione concettuale . . . . . . . . 88
La modellazione navigazionale . . . . . . . 89
La modellazione dellinterfaccia astratta . 92
Limplementazione . . . . . . . . . . . . . 92
Analisi di OOHDM sulla base dei requisitilegati alle tre
dimensioni ortog-onali . . . . . . . . . . . . . . . . 93
3.3.2 OO-H Method . . . . . . . . . . . . . . . . 94
Il processo di design . . . . . . . . . . . . 96
Il catalogo dei patterns . . . . . . . . . . . 97
Il Navigational Access Diagram (NAD) . 98
L Abstract Presentation Diagram (APD) 99
L implementazione dellADP . . . . . . . 102
Analisi del metodo OO-H sulla base dei re-quisiti legati alle
tre dimensioniortogonali . . . . . . . . . . . . . 103
3.3.3 UML esteso di Conallen . . . . . . . . . . 104
Analisi dellestensione dellUML di Conallensulla base dei
requisiti legati alletre dimensioni ortogonali . . . . . 113
3.3.4 Koch-UWE . . . . . . . . . . . . . . . . . 114
Specifica dei requisiti attraverso gli UseCases UML . . . . . .
. . . . . . 117
Modellazione concettuale attraverso il dia-gramma delle classi
UML . . . . 118
Modellazione della navigazione attraversodiagrammi delle classi
stereotipati 119
-
CONTENTS v
Modellazione della presentazione attraversodiagrammi delle
classi stereotipati 121
Modellazione degli scenari web attraversostatechart UML e
diagrammi diinterazione UML . . . . . . . . . 123
Modellazione dei compiti attraverso i dia-grammi delle attivita`
UML . . . 123
Rappresentazione della distribuzione deicomponenti web
attraverso il dia-gramma di deployment UML . . 125
Analisi della metodologia UWE sulla basedei requisiti legati
alle tre dimen-sioni ortogonali . . . . . . . . . . 126
3.4 Conclusioni dellanalisi dei linguaggi di model-lazione web
sulla base dei requisiti legati alle tredimensioni ortogonali . . .
. . . . . . . . . . . . . 128
3.5 Valutazione dei linguaggi di modellazione web sullabase dei
requisiti individuati nel capitolo 2, sezione2.1 . . . . . . . . .
. . . . . . . . . . . . . . . . . 130
3.5.1 Analisi sulla base dei requisiti funzionali . 130
3.5.2 Analisi sulla base dei requisiti legati
allinformazione130
3.5.3 Analisi sulla base dei requisiti di caratteregenerale . .
. . . . . . . . . . . . . . . . . 132
3.5.4 Le limitazioni dei linguaggi analizzati . . . 133
3.5.5 Conclusioni . . . . . . . . . . . . . . . . . 137
4 Strumenti di sviluppo web 139
4.1 Strumenti di sviluppo model-driven . . . . . . . . 140
4.1.1 Oracle 9i Designer . . . . . . . . . . . . . 142
4.1.2 OracleJDeveloper . . . . . . . . . . . . . . 143
4.1.3 WebRatio Site Development Studio . . . . 145
WebRatio IDE . . . . . . . . . . . . . . . 145
Generatore di codice WebRatio . . . . . . 149
-
vi CONTENTS
Applicazione di WebRatio ad un caso pratico154
4.1.4 Rational Rose XDE . . . . . . . . . . . . . 196Lambiente e
le funzionalita` di Rational
XDE . . . . . . . . . . . . . . . . 196La modellazioneWeb con
Rational XDE:un
esempio pratico . . . . . . . . . . 1994.1.5 Confronto tra i due
strumenti utilizzati . . 208
Bibliography 214
-
List of Figures
1.1 Generica architettura a tre livelli . . . . . . . . . 13
1.2 Architettura multilivello di unapplicazione web . 15
2.1 Dimensioni della modellazione di applicazioni web27
3.1 Origini e relazioni dei linguaggi di modellazioneWeb . . . .
. . . . . . . . . . . . . . . . . . . . . 34
3.2 Esempio di modello strutturale in WebML . . . . 45
3.3 Esempio di Data Unit . . . . . . . . . . . . . . . 46
3.4 Esempio di Multi-Data Unit . . . . . . . . . . . . 47
3.5 Esempio di Index Unit . . . . . . . . . . . . . . . 47
3.6 Esempio di Multi-Choice Index Unit . . . . . . . 48
3.7 Esempio di Hierarchical Index Unit . . . . . . . . 48
3.8 Esempio di Entry Unit . . . . . . . . . . . . . . . 48
3.9 Esempio di Scroller Unit . . . . . . . . . . . . . . 48
3.10 Esempio di selettore definito su una relazione . . 49
3.11 Esempio di link contestuale . . . . . . . . . . . . 50
3.12 Esempio di create unit . . . . . . . . . . . . . . . 52
3.13 Esempio di delete unit . . . . . . . . . . . . . . . 52
3.14 Esempio di modify unit . . . . . . . . . . . . . . . 53
3.15 Esempio di connect unit . . . . . . . . . . . . . . 53
3.16 Esempio di disconnect unit . . . . . . . . . . . . . 53
3.17 Le primitive del modello RMDM(Relationship Man-agement Data
Model) . . . . . . . . . . . . . . . 57
vii
-
viii LIST OF FIGURES
3.18 Esempi di costrutti di accesso RMDM . . . . . . 59
3.19 La metodologia RMM . . . . . . . . . . . . . . . 60
3.20 Diagramma delle slices per un corpo docente . . 62
3.21 La metodologia Aranues . . . . . . . . . . . . . . 66
3.22 Esempio di schema E/R:lo schema di un diparti-mento . . . .
. . . . . . . . . . . . . . . . . . . . 67
3.23 Esempio di schema relazionale:lo schema relazionaledel
dipartimento . . . . . . . . . . . . . . . . . . 68
3.24 Rappresentazione grafica dei costrutti NCM . . . 71
3.25 Esempio di schema NCM . . . . . . . . . . . . . . 73
3.26 Rappresentazione grafica dei costrutti ADM . . . 75
3.27 Esempio di mapping di macroentita` in schemi dipagina . . .
. . . . . . . . . . . . . . . . . . . . . 76
3.28 Esempio di mapping di macroentita` in tuple . . . 76
3.29 Esempio di mapping di relazioni direzionate . . . 78
3.30 Esempio di mapping di relazioni direzionate . . . 79
3.31 Esempio di mapping di aggregazioni . . . . . . . . 80
3.32 Architettura di Strudel . . . . . . . . . . . . . . .
84
3.33 Il metodo OO-H . . . . . . . . . . . . . . . . . . . 95
3.34 Metodo OO-H:il processo di design . . . . . . . . 96
3.35 Associazione build tra pagina sever e pagina client 106
3.36 Uso dei parametri di link . . . . . . . . . . . . . .
107
3.37 Collaborazioni del client . . . . . . . . . . . . . .
108
3.38 Collaborazioni del server . . . . . . . . . . . . . .
109
3.39 Modellazione delle forms . . . . . . . . . . . . . .
110
3.40 Esempio di modellazione di frames . . . . . . . . 112
3.41 Il processo UWEXML . . . . . . . . . . . . . . . 116
3.42 Modello Use Case di unapplicazione di libreriaonline . . .
. . . . . . . . . . . . . . . . . . . . . 119
3.43 Modello concettuale di unapplicazione di libreriaonline . .
. . . . . . . . . . . . . . . . . . . . . . 119
3.44 Modello dello spazio di navigazione di unapplicazionedi
libreria online . . . . . . . . . . . . . . . . . . . 120
-
LIST OF FIGURES ix
3.45 Icone degli stereotipi per gli elementi daccesso . .
121
3.46 Modello della stuttura di navigazione di unapplicazionedi
libreria online . . . . . . . . . . . . . . . . . . . 122
3.47 Schizzo della classe navigazionale Pubblicazionedi una
libreria online . . . . . . . . . . . . . . . . 122
3.48 Diagramma statechart della presentazione web . . 124
3.49 Modello del compito Cancella pubblicazione me-diante
diagramma delle attivita` . . . . . . . . . . 125
3.50 Diagramma di deployment basato sullelementoPubblicazione
dellesempio di libreria online . . . 127
4.1 Le aree dellinterfaccia utente di WebRatio SiteDevelopment
Studio . . . . . . . . . . . . . . . . 146
4.2 Le tre prospettive dellalbero di progetto . . . . . 147
4.3 La barra degli strumenti principale . . . . . . . . 147
4.4 La barra degli strumenti per lediting della struttura148
4.5 La barra degli strumenti per lediting delle siteviews . . .
. . . . . . . . . . . . . . . . . . . . . . 149
4.6 Architettura di unapplicazione WebRatio . . . . 151
4.7 Le entita` predefinite User,Group e SiteView . . . 155
4.8 Modello strutturale complessivo . . . . . . . . . . 157
4.9 Proprieta` della site view FacoltaWeb . . . . . . . 161
4.10 Visione globale della site view FacoltaWeb . . . . 163
4.11 Area Corsi di Studio della site view FacoltaWeb . 164
4.12 Area Insegnamenti della site view FacoltaWeb . . 165
4.13 Area Sessioni dEsame della site view FacoltaWeb 166
4.14 Porzione dellarea Docenti,AreediRicerca e Pub-blicazioni
riguardante le home pages dei docenti . 167
4.15 Porzione dellarea Docenti,AreediRicerca e Pub-blicazioni
riguardante le aree di ricerca . . . . . . 167
4.16 Porzione dellarea Docenti,AreediRicerca e Pub-blicazioni
riguardante la ricerca di pubblicazioniper anno . . . . . . . . . .
. . . . . . . . . . . . . 168
-
x LIST OF FIGURES
4.17 Porzione dellarea Docenti,AreediRicerca e Pub-blicazioni
riguardante la ricerca di pubblicazioniper parole chiave . . . . .
. . . . . . . . . . . . . 168
4.18 Home page della site view FacoltaWeb con entryunit per il
login . . . . . . . . . . . . . . . . . . . 169
4.19 Proprieta` della site view FacoltaContentManage-ment1 . . .
. . . . . . . . . . . . . . . . . . . . . 170
4.20 Visione globale della site view FacoltaContent-Management1
. . . . . . . . . . . . . . . . . . . . 171
4.21 Area PROPRI ESAMIdella site view FacoltaCon-tentManagement1
. . . . . . . . . . . . . . . . . . 172
4.22 Area PROPRIA TESI della site view
Facolta-ContentManagement1 . . . . . . . . . . . . . . . 173
4.23 Home Page della site view FacoltaContentMan-agement1 . . .
. . . . . . . . . . . . . . . . . . . 174
4.24 Logout Page della site view FacoltaContentMan-agement1 . .
. . . . . . . . . . . . . . . . . . . . 174
4.25 Proprieta` della logout unit . . . . . . . . . . . . .
175
4.26 Proprieta` della site view FacoltaContentManage-ment2 . . .
. . . . . . . . . . . . . . . . . . . . . 176
4.27 Visione globale della site view FacoltaContent-Management2
. . . . . . . . . . . . . . . . . . . . 178
4.28 Area AREE DI RICERCA della site view
Fa-coltaContentManagement2 . . . . . . . . . . . . . 179
4.29 Area APPELLI della site view FacoltaContent-Management2 . .
. . . . . . . . . . . . . . . . . . 180
4.30 Porzione dellarea PUBBLICAZIONI della siteview
FacoltaContentManagement2 . . . . . . . . . 181
4.31 Porzione dellarea PUBBLICAZIONI della siteview
FacoltaContentManagement2 . . . . . . . . . 182
4.32 Proprieta` della site view FacoltaAdministrator . . 183
4.33 Visione globale della site view FacoltaAdmin . . . 184
-
LIST OF FIGURES xi
4.34 Porzione della site view FacoltaAdmin riguardantela
gestione degli utenti . . . . . . . . . . . . . . . 185
4.35 Porzione della site view FacoltaAdmin riguardantela
gestione delle relazioni tra utenti e gruppi . . . 185
4.36 Bottone per i warning di struttura-navigazione . . 186
4.37 Vista di mapping dellalbero di progetto con databasedi
supporto dellapplicazione . . . . . . . . . . . . 188
4.38 Bottone per i warning di mapping . . . . . . . . . 189
4.39 Setting della piattaforma nella specifica della
pre-sentazione . . . . . . . . . . . . . . . . . . . . . . 190
4.40 Scelta del foglio di stile e del layout di pagina perla
site view FacoltaWeb . . . . . . . . . . . . . . . 190
4.41 Specifica del posizionamento delle units di unapagina della
site view FacoltaContentManagement2191
4.42 Bottone per i warning di presentazione . . . . . . 191
4.43 Bottone per la generazione dei descrittori XML . 192
4.44 Bottone per la generazione dei templates di pagina192
4.45 Bottone per i warning di presentazione . . . . . . 192
4.46 La home page della site view FacoltaWeb . . . . . 193
4.47 La pagina Appelli Editing dellarea APPELLI dellasite view
FacoltaManagement2 . . . . . . . . . . . 194
4.48 Icona del comando Generate WebMLDoc nellabarra principale
degli strumenti . . . . . . . . . . 194
4.49 Scelta della directory di output per la documen-tazione di
progetto . . . . . . . . . . . . . . . . . 195
4.50 Documentazione del progetto ProgettoWebFacolta 195
4.51 Vista Navigator del progetto EsempioSessioni . . 201
4.52 Porzione del modello directory virtuale del pro-getto
EsempioSessioni . . . . . . . . . . . . . . . 205
4.53 La form FormAA nella vista Model Explorer . . . 205
4.54 La relazione JSPUseBeans nella pagina ViewSes-sioneEsame
nella vista Model Explorer . . . . . . 206
-
xii LIST OF FIGURES
4.55 Porzione del modello directory virtuale del pro-getto
EsempioSessioni . . . . . . . . . . . . . . . 206
4.56 Porzione del modello directory virtuale del pro-getto
EsempioSessioni . . . . . . . . . . . . . . . 207
-
List of Tables
3.1 Esempio di composizione di unentita` HDM . . . 373.2 Analisi
dei linguaggi di prima e seconda gener-
azione sulla base dei requisiti funzionali . . . . . . 1313.3
Analisi dei linguaggi di terza generazione sulla
base dei requisiti funzionali . . . . . . . . . . . . . 1313.4
Analisi dei linguaggi di prima e seconda gener-
azione sulla base dei requisiti legati allinformazione1323.5
Analisi dei linguaggi di terza generazione sulla
base dei requisiti legati allinformazione . . . . . . 1333.6
Analisi dei linguaggi di prima e seconda gener-
azione sulla base dei requisiti di carattere generale 1343.7
Analisi dei linguaggi di terza generazione sulla
base dei requisiti di carattere generale . . . . . . . 135
xiii
-
Introduzione
La crescita esponenziale e la capillare diffusione del web
hannointrodotto una nuova generazione di applicazioni ,
caratterizzateda una relazione diretta tra il business ed il
cliente.Le applicazioni web sono divenute ormai un ingrediente
fonda-mentale delle nostre attivita` lavorative,sociali e di
relazione.Tali applicazioni vengono oggi definite Data-Intensive
WebApplications, infatti oggi il web e` sempre piu` usato
comepiattaforma per sistemi informativi complessi,dove
unenormequantita` di dati soggetti a continui cambiamenti e`
gestita daiDBMS sottostanti. Le nuove aree di applicazione sono
dominicome il commercio elettronico, siti web di organizzazioni
pri-vate e pubbliche, le librerie digitali ed i corsi a distanza.
Leinterfacce web(interfacce HTTP) infatti sono spesso consid-erate
come lo strumento piu` potente per un efficace presen-tazione e
diffusione dellinformazione in quanto la combinazionedi
testi,suoni,video ed immagini permette diverse rappresen-tazioni
dei concetti e luso di links rende naturale e flessibilelaccesso
allinformazione.
Lo sviluppo delle applicazioni web e` sempre piu`
complicato,risulta dunque fondamentale una correttamodellazione
nellambitodel ciclo di vita di tali applicazioni per aumentarne la
compren-sione e facilitare la comunicazione allinterno del team di
pro-getto.
1
-
Oggi i progettisti modellano le applicazioni web sulla base
dellaloro conoscenza individuale,dunque applicando metodologie
stan-dard utilizzate nella modellazione delle applicazioni
tradizion-ali, come le applicazioni object-oriented. Tali
metodologie sonoadatte per modellare la parte convenzionale della
modellazionedelle web applications,come il design delle strutture
dati e dellalogica di business; ma risultano inadeguate per
modellare cio` checaratterizza tali applicazioni: visualizzare
contenuti e metterea disposizione servizi utilizzando un front-end
ipertestuale,cioe` un Web browser. La modellazione di tali
interfacce websegue infatti dei patterns e delle regole abbastanza
consolidatenella pratica ma scarsamente dcumentate e supportate
daglistrumenti di design tradizionali e dai linguaggi di
modellazionestandard.
Attualmente e` forte lesigenza di trovare una notazione chiara
edefficace per rappresentare le funzionalita` dei componenti
front-end dello strato web e la complessita` della loro iterazione
edintegrazione,allo scopo di generare diagrammi e documenti
dispecifica che permettano di ragionare ad un alto livello di
as-trazione senza vincolarsi a dettagli architetturali ed
implemen-tativi.
Lo scopo principale di questa tesi e`: ricercare, analizzare e
con-frontare i linguaggi e formalismi attualmente proposti per
lamodellazione di interfacce web, per valutarne lo stato
dellarte;dopo aver inizialmente individuato i componenti
front-end(siaserver-side che client-side) nellambito di una tipica
architetturamultilivello di unapplicazione distribuita, per
comprendere ef-fettivamente cosa si ha la necessita` di
modellare.Obiettivo della tesi e` studiare in modo approfondito un
parti-colare linguaggio di modellazione web con applicazione ad
uncaso pratico , possibilmente utilizzando leventuale CASE tool
2
-
supportato da tale linguaggio ed arrivando a produrre la
docu-mentazione formale del design di una interfaccia.
La tesi e` organizzata nel seguente modo:
Capitolo 1In questo capitolo vengono descritti il ruolo della
modellazionenella fase di progettazione e nellutilizzo dei CASE
tools perla produzione di un componente software e gli standard
at-tualmente usati per la modellazione concettuale nei vari
ambitidel software.Inoltre,viene descritta larchitettura
multilivello diun tipico sistema informativo distribuito con
particolare risaltoallindividuazione dei componenti dello strato
front-end.
Capitolo 2In questo capitolo vengono individuati i requisiti
fondamentaliper un linguaggio di modellazione web,proponendo due
punti divista differenti per la suddivisione di tali requisiti in
categorie.
Una prima categorizzazione prevede la suddivisione dei
requi-siti sulla base dei due aspetti dellarchitettura tecnica
delle ap-plicazioni web : larchitettura dellinformazione e
larchitetturafunzionale.Si possono individuare tre categorie:
Requisiti legati allinformazione:come viene gestita e
strut-turata e laccesso ad essa;
Requisiti legati alle funzionalita` del sistema;
Requisiti di carattere generale .
La seconda categorizzazione prevede la suddivisione dei
requi-siti sulla base delle tre dimensioni ortogonali da
considerare nella
3
-
modellazione delle applicazioni web:livelli,aspettie fasi.
Capitolo 3In questo capitolo viene studiato lo stato dellarte
dei linguaggiproposti per la modellazione di interfacce web,tali
linguaggi ven-gono analizzati e confrontati tra loro sulla base dei
requisiti in-dicati nel capitolo precedente.
Capitolo 4In questo capitolo vengono descritti gli strumenti di
sviluppoweb model-driven;in particolare vengono descritti,applicati
adun caso pratico e confrontati due esempi significativi di
CASEtools model-driven: WebRatio Site Development
Studio,concepitoal Politecnico di Milano e basato su un relativo
linguaggio dimodellazione(WebML),e Rational Rose XDE ,la versione
delpopolare CASE tool Rational Rose che fornisce alcuni profiliUML
per la modellazione Web adottando una particolare pro-posta di
estensione di UML per il Web(UML esteso di Conallen).
4
-
Chapter 1
La modellazione concettuale deicomponenti front-end
1.1 Il ruolo della modellazione nella fase di
progettazione e nellutilizzo dei CASE tool
per la produzione di un componente soft-
ware
Nella fase di progettazione nel ciclo di vita di un
componentesoftware e` fondamentale modellare il contesto
applicativo gia` de-lineato nelle specifiche dei requisiti.La
modellazione e` una parte centrale delle attivita` che per-mettono
lo sviluppo di un buon software (che soddisfa le ne-cessita` degli
utenti) , in quanto aiuta a comprendere e gestiresistemi
complessi.Nella fase di modellazione viene creata una
do-cumentazione formale della struttura e delle interrelazioni di
unsistema facendo uso di diagrammi che esprimono modelli
utiliz-zando notazioni grafiche.Luso di modelli rende espliciti i
requisiti di progetto,realizza unamigliore comunicazione tra i
membri del team eliminando le am-biguita` del linguaggio naturale,
diminuisce i tempi di sviluppoma sopratutto rende piu` chiari e
mantenibili i documenti di de-sign in quanto permette di ragionare
ad un alto livello di as-
-
6 La modellazione concettuale dei componenti front-end
trazione senza essere vincolati a dettagli implementativi.I
mo-delli aiutano a comprendere il sistema semplificando alcuni
det-tagli ; la scelta di cosa modellare e` dunque fondamentale
perlanalisi del problema e lindividuazione della soluzione.
Modellare il contesto applicativo di un prodotto software
sig-nifica analizzare il sistema da tre punti di vista:
Statico : si analizza e modella la realta` da inserire nel
sis-tema ad un certo istante e si modella il database che
con-terra` i dati di interesse.
Dinamico : si analizza e modella il comportamento dinam-ico del
sistema, cioe` levoluzione nel tempo delle entita` chelo compongono
e le relazioni tra esse.
Funzionale : si analizza e modella il sistema dal punto divista
delle funzioni che deve mettere a disposizione,si trattadellaspetto
piu` percettibile dallutente finale.
Nellambito della modellazione si distingue tra linguaggio
dimodellazione e metodologia:
Un linguaggio di modellazione e` la notazione(aspetto grafico
deimodelli) usata nelle metodologie per esprimere le
caratteristihedi un progetto.
Una metodologia e` costituita da un linguaggio di modellazionee
da processo che e` una serie di consigli riguardanti le varie
fasidella produzione del progetto. Naturalmente il linguaggio
dimodellazione e` la parte piu` importante della metodologia,
infattimodellando il sistema allo scopo di ottenere una
comunicazionemeno ambigua, e` fondamentale la conoscenza del
linguaggio co-mune utilizzato.
-
1.2 La modellazione concettuale e le applicazioni web 7
La creazione di modelli puo` attenersi piu` o meno
strettamentealle notazioni del linguaggio di modellazione a seconda
delloscopo per il quale ci si propone di utilizzare tali
modelli.Sesi ha a disposizione un Computer-Aided Software
Engi-neering(CASE)tool per la generazione di codice,nella fase
dimodellazione bisogna attenersi strettamente
allinterpretazionefornita dallo strumento per ottenere codice
accettabile; se invecesi utilizza la modellazione per la
comunicazione lo sviluppo e` piu`libero.Naturalmente i benefici
della modellazione vengono moltiplicatise sono disponibili tools
adeguati che supportano i linguaggi dimodellazione utilizzati.
1.2 La modellazione concettuale e le appli-
cazioni web
Nellambito della modellazione vengono utilizzate notazioni
conlivelli di astrazione diversi:
A livello concettuale viene effettata una
rappresentazioneastratta del sistema usando primitive di alto
livello;
A livello logico vengono utilizzate rappresentazioni di liv-ello
piu` basso vicine alle necessita` dellimplementazione ,maancora
indipendenti dalla tecnologia utilizzata;
A livello fisico viene effettuato un design dipendente
dallatecnologia e strettamente legato a dettagli
implementativi.
La modellazione concettuale viene utilizzata con successoin
molti campi del software,in quanto permette di ragionare adun alto
livello di astrazione senza essere vincolati a dettagli
ar-chitetturali o di implementazione.Nella modellazione dei
database ,ad esempio,il modello Entity-Relationship(E/R) [1]
fornisce una notazione intuitiva e di alto
-
8 La modellazione concettuale dei componenti front-end
livello per la comunicazione dei requisiti legati ai dati tra i
de-signers e persone non-tecniche ed e` la base per creare schemi
didatabase di alta qualita`.Piu` recentemente,con il crescere della
complessita` e delle dimen-sioni delle applicazioni software e`
nata la necessita` di ottimizzarenon tanto il prodotto,cioe` la
singola applicazione,quanto il pro-cesso di produzione,cioe` il
modo in cui unapplicazione viene con-cepita,progettata,realizzata e
verificata. Nel settore dei sistemiinformatici questo mutamento si
e` accellerato negli anni Novantagrazie al successo delle
metodologie di sviluppo ad oggetti.In particolare si e` affermata
lidea che le fasi iniziali dello sviluppodi unapplicazione,lanalisi
dei requsiti e la progettazione,fosserocruciali e dovessero essere
sostenute da opportune notazioni for-mali e da adeguati strumenti
software. La caratteristica comunedelle diverse metodologie
proposte e` la modellazione con-cettuale basata su linguaggi
visuali semplici ed intuitivi,maal tempo stesso rigorosi e a volte
formali.Grazie alluso dellamodellazione concettuale e` possibile
generare automaticamenteparte del codice a partire dai diagrammi ad
oggetti.Proprio gli anni Novanta vedono la progressiva diffusione
deglistrumenti di CASE che offrono unampia copertura del ciclodi
vita delle applicazioni,fornendo assistenza nelle fasi di
ana-lisi,progettazione,produzione automatica del codice e
testing.Un punto di svolta nellevoluzione degli strumenti e dei
metodidi sviluppo e` rappresentato dallavvento dellUnified
ModellingLanguage(UML) [2],una notazione che racchiude concetti
prove-nienti dalle metodologie ad oggetti , accettata oggi come
stan-dard de facto per la progettazione e largamente condivisa
daanalisti e sviluppatori.Il capostipite dei CASE tools basati su
UML,Rational Rose,e` ormai ampiamente diffuso nelle aziendee
consente la gestionecollaborativa e la manutenzione di progetti di
grandi dimensioni.
-
1.2 La modellazione concettuale e le applicazioni web 9
Le moderne Data-Intensive Web Applications differisconoin vari
aspetti dalle applicazioni informatiche tradizionali:
Sfruttano unarchitettura client-server basata sul protocolloHTTP
e su client leggeri(thin client),spostando cos` granparte delle
funzioni applicative al lato server.
Fanno uso di linguaggi di mark-up,come HTML, per lacostruzione
dellinterfaccia utente,il che comporta spessola generazione
dinamica delle interfacce a tempo di esecu-zione.
Laccesso universale da parte di utenti con poca abilita`nelluso
di tali applicazioni web introduce la necessita` dinuove interfacce
in grado di catturare lattenzione dellutentee facilitare laccesso
allinformazione.Assumono dunque moltaimportanza aspetti
comunicativi come la qualita` della vestegrafica,la
personalizzazione , la coerenza ed usabilita` dellinterfacciautente
e lofferta allutente dellesplorazione libera
dellinformazionemediante la navigazione ipertestuale.
La disponibilita` globale di sorgenti di informazione
etero-genee richiede una gestione integrata di dati strutturati (ad
esempio,database records) e non-strutturati (ad esem-pio, elementi
multimediali), memorizzati in sistemi diffe-renti(database, file
systems, multimedia storage devices) edistribuiti su piu` siti.
Tali caratteristiche rendono lo sviluppo di queste
applicazioniunattivita` molto complessa che richiede tutti gli
strumenti ele tecniche dellingegneria del software ,tra cui un
processo disviluppo del software ben organizzato, linee guida su
come con-durre le varie attivita` e ,sopratutto, appropriati
concetti di de-sign e notazioni.
-
10 La modellazione concettuale dei componenti front-end
Nasce dunque la necessita` di poter applicare i benefici
dellamodellazione concettuale riscontrati nelle applicazioni
softwaretradizionali anche alle Data-Intensive Web Applications ,le
qualidevono essere specificate utilizzando una notazione grafica,
intu-itiva e di alto livello,facilmente comunicabile ad utenti non
tec-nici e di grande aiuto per limplementazione dellapplicazione.Le
metodologie tradizionali risultano inadeguate per la model-lazione
della parte specifica delleWeb Applications che
riguardalinterfaccia ipertestuale verso lutente.Notazioni standard
comeUML descrivono un mondo qualsiasi in termini di oggetti
edassociazioni tra oggetti. Nel contesto Web e` necessario
definirequali siano gli oggetti giusti per rappresentare gli
elementi emeccanismi caratteristici del front-end delle
applicazioni Web ecostruire strumenti in grado id fornire
unautomazione maggioredi quella offerta oggi dagli strumenti basati
sulla modellazionead oggetti generale di UML.
1.3 I componenti dello strato front-end di una
web application
Nella fase di modellazione la scelta di quali elementi del
sistemamodellare e` di fondamentale importanza in quanto permette
didelineare la realta` che si vuole rappresentare stabilendo
qualisono le caratteristiche significative del contesto applicativo
damodellare.Larchitettura software di riferimento dellapplicazione
e` il soggettodella modellazione , infatti ad ogni livello
architetturale si de-vono individuare gli elementi piu`
significativi da modellare estabilire il corretto livello di
astrazione e di dettaglio da seguirenella costruzione del
modello.Larchitettura di riferimento per leWeb Applications e`
unarchitettura
-
1.3 I componenti dello strato front-end di una web application
11
multilivello (Multi-tier Architecture) , specializzazione nel
casoweb della piu` generale architettura software a tre livelli
(Three-tier Architecture).Entrambe le architetture vengono
descritte in seguito con par-ticolare risalto allindividuazione dei
componenti del front-endtier delle applicazioni web per le quali
linterfaccia verso lutentee linterazione con esso risultano di
fondamentale importanza equindi necessitano di essere
modellate.
1.3.1 Architettura software a tre livelli
Nelle architetture a tre livelli ,a differenza di quelle a due
livellidove i programmi del client interagiscono direttamente con
ilDBMS ,e` presente un livello intermedio tra il client ed i dati
checoncentra la logica di business dellapplicazione.Tale
livello,detto Middle tier,realizza la gestione dei processi
perlesecuzione della logica di business.Disporre di un livello
intermadio nel quale iene centralizzata lalogica di processo rende
piu` facile la gestione delle modifichelocalizzando le
funzionalita` del sistema in modo che sia suffi-cente che i
cambiamenti vengano scritti una sola volta e postinel middle-tier
perche` siano visibili da tutto il sistema.Larchitettura a tre
livelli viene utilizzata quando e` necessarioun effettivo design
client-sever distribuito in quanto aumenta leprestazioni,la
flessibilita` e la scalabilita` mascherando allutentela
complessita` dei processi distribuiti.
Nelle Three-tier Architectures(vedi figura 1.1)si distinguono
iseguenti livelli:
Tier 3: Data tierTale livello riguarda lorganizzazione dei dati
in databaseso in file systems e la gestione di questi.La
consistenza deidati viene assicurata attraverso luso del data
locking e della
-
12 La modellazione concettuale dei componenti front-end
replicazione.Questo livello e` dedicato ai servizi legati ai
datio ai files che possono essere ottimizzati senza utilizzare
illinguaggio specifico di un particolare DBMS.
Tier 2: Middle tierTale livello rappresenta la gestione della
logica dellapplicazione:vengono create le corrispondenze tra i dati
memorizzati neifiles o databases e linformazione accessibile
dallutente, inmodo da permettere laccesso a strutture dati
complesse erealizzare le operazioni in tempi rapidi.In tale livello
ven-gono condensate parti consistenti della logica di
business(business logic) riguardanti la gestione dei processi
relativiai servizi che si devono fornire (Middle-Tier
Services).
Tier 1: Client tierTale livello rappresenta linterfaccia tra il
sistema e lutentefinale; dunque la gestione di tutti i servizi
legati allinterazionecon lutente,come la gestione della sessione di
lavoro, del di-alogo con lutente e dei dati forniti in input
dallutente.
Le architetture a tre livelli facilitano lo sviluppo del
softwarepoiche` ogni livello puo` essere costruito ed eseguito su
una pi-attaforma separata e sviluppato in un linguaggio diverso,in
modoche lorganizzazione dellimplementazione risulta piu`
facile.
-
1.3 I componenti dello strato front-end di una web application
13
Figure 1.1: Generica architettura a tre livelli
1.3.2 Architettura multilivello di unapplicazione web
Spesso il livello intermedio delle architetture a tre livelli,
il Mid-dle tier,e` diviso in due o piu` unita` con differenti
funzioni : taliarchitetture sono dette Multi-tier Architectures.E`
questo il casodelle attuali applicazioni web su larga scala, le
quali presen-tano unarchitettura software di riferimento a piu`
livelli (vedifigura1.2).In tale architettura il livello logico
intermedio, il Middle tierrisulta suddiviso in : Presentation layer
e Business Logic layer.Il Presentation layer genera le pagine web
ed il loro contenuto di-namico che generalmente proviene da un
database (ad esempiouna lista di prodotti con determinate
caratteristiche,una listadelle transazioni effettuate nellultimo
mese,etc.).Laltro com-pito fondamentale del Presentation layer e`
quello di decodifi-care le informazioni ritornate dal client,cioe`
individuare i datiforniti in input dallutente ed inviare tale
informazione al Busi-ness Logic layer.Il livello logico
Presentation layer viene imple-
-
14 La modellazione concettuale dei componenti front-end
mentato allinterno di un Web Server.Il Business Logic layer
rappresenta la logica dellapplicazione,le funzionalita` di tale
livello sono:realizzare tutti i calcoli e levalidazioni
richieste,gestire il workflow,cioe` il flusso di lavoroche gestisce
gli eventi provocati dallutente(incluso tenere trac-cia della data
della sessione) e laccesso ai dati per il Presen-tation layer.Tale
livello logico viene implementato allinterno diun Application
Server.Un Application Server e` dunque una pi-attaforma software ,
distinta dal web server,dedicata ad unesecuzioneefficente del
business per supportare la costruzione di pagine di-namiche.Nelle
architetture moderne generalmente il Web Serverrisultamolto
semplificato e si limita alla gestione delle richieste HTTPdel
client,spostando tutta la logica di generazione delle
paginenellApplication Server.
Individuazione dei componenti front-end
Il front-end di unapplicazione ,indipendentemente dalla
dis-tribuzione delle funzionalita` tra i dispositivi ai vari
livelli dellarchitetturadi riferimento,e` composto dagli elementi e
meccanismi tecno-logici che costituiscono linterfaccia
dellapplicazione verso lutentefinale in contrapposizione al
back-end,il quale fa riferimentoalla gestione ed al mantenimento
dei dati di interesse.
Le applicazioni web presentano un front-end ipertestuale perla
visualizzazione dellinformazione e la realizzazione di servizi.Un
ipertestoe` un insieme di nodi connessi tramite dei links,doveogni
nodo rappresenta un concetto ed i links collegano concettiin
relazione tra loro.Analizzare e modellare lipertesto significa
dunque specificarelorganizzazione dellinterfaccia di front-end di
unapplicazioneweb.
-
1.3 I componenti dello strato front-end di una web application
15
Figure 1.2: Architettura multilivello di unapplicazione web
Gli aspetti che compongono tale front-end ipertestuale sono
glielementi caratteristici delle applicazioni web:la divisione
logicadellapplicazione in moduli e la topologia dellipertesto di
ognimodulo in termini di pagine,che contengono dati ed
informazionie sono collegate tra loro per poter supportare la
navigazionedellutente e linterazione con esso.Gli elementi del
front-end damodellare sono dunque le pagine,i links e la
generazione dinam-ica del contenuto delle pagine sulla base delle
azioni dellutente.
-
16 La modellazione concettuale dei componenti front-end
Se si tiene conto della distribuzione delle funzionalita` tra i
dis-positivi ai vari livelli logici dellarchitettura web e quindi
sianalizzano lipertesto ed i suoi componenti ad un minore liv-ello
dastrazione rispetto allorganizzazione delle pagine e deilinks, per
ogni pagina si possono considerare laspetto client elaspetto server
e quindi individuare meccanismi tecnologici ,siaserver-side che
client-side, legati al front-end ipertestuale.
Dal lato client,ogni pagina web richiesta dal browser al
webserver e` un insieme di contenuti e di istruzioni di
formattazione,espressein HTML.Le pagine web possono includere
client-side scriptsche definiscono un ulteriore comportamento
dinamico per la vi-sualizzazione delle pagine ed interagiscono con
il contenuto dellepagine e con altri controlli ( Applets eActiveX
controls)allinternodelle pagine stesse.Dalla prospettiva del client
dunque una pa-gina web e` un documento HTML formattato e gli
elementi daconsiderare nella modellazione del front-end
ipertestuale sono iclient-side scripts (come JavaScript), le
Applets e gli ActiveXcontrols.
Dal lato server,la visione delle pagine web risulta piu`
compli-cata.Nelle prime applicazioni web le pagine dinamiche
eranocostruite attraverso la Common Gateway Interface(CGI ),la
qualedefiniva uninterfaccia standard per i programmi allo scopo
diaccedere allinformazione richiesta.Ogni volta che la richiesta
in-cludeva una URL riferita ad un programma eseguibile, il
CGIscript,il web server eseguiva tale programma ritornando
allutenteloutput dellesecuzione.Oggi i web server sono stati estesi
conapplication execution engine,ambienti di esecuzione efficente
epersistente dove vengono processate le pagine web (esempi sonole
Microsofts Active Pages ASP e le Java Server Pages JSP).Dalla
prospettiva del server dunque elementi significativi sono i
-
1.3 I componenti dello strato front-end di una web application
17
server-side scripts e le risorse server-side come i componenti
diaccesso ai database .Altri meccanismi da considerare sono :
Le Forms , il principale meccanismo di data entry per lepagine
web legato sia al client che ne deve compilare i campiche al server
che ne deve processare linvio.
I Frames , i quali permettono che piu` pagine siano attivee
visibili allutente e dunque rappresentano un comporta-mento legato
allaspetto client.
Gli elementi ,come le pagine ed i links, e i meccanismi
tecnologiciindividuati sono componenti specifici delle applicazioni
web edel loro front-end ipertestuale; si ha la necessita` di
modellare lacomplessita` della loro interazione e realizzare la
loro integrazionecon i modelli del resto del sistema .
-
Chapter 2
Requisiti necessari per unlinguaggio di modellazione web
2.1 Categorizzazione dei requisiti sulla base
dellarchitettura informativa e funzionale
Per uno sviluppo efficace delle applicazioni web si devono
consid-erare due aspetti dellarchitettura tecnica:larchitettura
dellinformazionee larchitettura funzionale [3].I linguaggi di
modellazione web,usati nello sviluppo di tali ap-plicazioni, devono
essere in grado di catturare e comunicare en-trambi gli aspetti.In
particolare,un linguaggio di modellazioneweb(WML1) deve mettere a
disposizione funzioni per facilitarela comprensione, specifica,
comunicazione, visualizzazione e costruzionedi un design
dettagliato.Si possono dunque individuare due gruppi di requisiti
necessariper un WML relativi agli aspetti dellinformazione e della
fun-zionalita`,insieme ad alcuni requisiti piu` generali.
1Usiamo WML per indicare un Web Modelling Language
-
20 Requisiti necessari per un linguaggio di modellazione web
2.1.1 Requisiti funzionali
Le caratteristiche funzionali delle applicazioni web
impongonoalcuni requisiti ai linguaggi di modellazione utilizzati
per rapp-resentare tale funzionalita`.Molti di questi requisiti
sono relativi alla natura specifica dellarchitetturadi tali
applicazioni.
Capacita` di modellare integrazione e connettivita`
In molte organizzazioni ,le nuove web applications lavorano
astretto contatto con sistemi legacy preesistenti tipicamente
ori-entati verso il back-end.La necessita` dellintegrazione dei
compo-nenti web introduce requisiti specifici per i
WMLs.Infatti,poiche`lintegrazione di componenti dipende in gran
parte dalle definizionidellinterfaccia,i WMLs devono essere in
grado di modellare edocumentare le interfacce dei componenti in
modo accurato eprivo di ambiguita`.Come interfaccia di front-end di
molte organizzazioni, le appli-cazioni web connettono una grande
varieta` di sorgenti di infor-mazione e di servizi;dunque i
linguaggi di modellazione devonosupportare la rappresentazione
della connettivita` e dei mecca-nismi di accesso.
Abilita` di supportare luso di patterns
Lesperienza sia pratica che di ricerca suggerisce che e`
auspi-cabile utilizzare dei patterns nella modellazione di sistemi
soft-ware.I benefici potenziali dei patterns includono:
- Luso di patterns fornisce unaiuto per lo sviluppo del
soft-ware,in modo che le decisioni per un design corretto
possanoessere prese con il minimo sforzo.
-
2.1 Categorizzazione dei requisiti sulla base
dellarchitetturainformativa e funzionale 21
- Poiche` molti patterns appropriati sono comunemente ac-cettati
come standard di alta qualita`, il loro utilizzo puo`aumentare la
qualita` totale dellapplicazione web.
- Luso di patterns puo` aumentare linterconnettivita`
dellapplicazione,in quanto tali patterns sono normalmente condivisi
dai varisviluppatori software,specialmente in domini applicativi
sim-ili.
Abilita` di rappresentare i concetti indipendentemente dalla
tec-nologia
Poiche` le tecnologie nellambito del web cambiano molto
rap-idamente e` impossibile e poco utile effettuare un design
delleapplicazioni web con riferimento ad una specifica
tecnologia.E` dunque necessario che i WMLs permettano di
rappresentare iconcetti specifici del web indipendentemente dalla
tecnologia.
2.1.2 Requisiti legati allinformazione
I requisiti legati allinformazione tipicamente coprono
aspetticome:la gestione del contenuto,come viene strutturata
linformazionee laccesso ad essa,la contestualizzazione dellutente
,il designdella navigazione, i punti di vista dellinformazione ed i
prob-lemi di presentazione.
Abilita` di modellare concetti di presentazione
Il design delle applicazioni web legato alla presentazione ha
dellecaratteristiche specifiche, tra cui:
- Funzioni piu` complete e sofisticate a livello di
presentazione,comeconseguenza della necessita` di aumentare la
qualita` delle in-terfacce con lutente.
-
22 Requisiti necessari per un linguaggio di modellazione web
- Varie tipologie di dati a livello di presentazione,come
testi,grafici,videoed audio.
- I WMLs devono essere usati da personale tecnico ,ma an-che da
designers grafici,autori,analisi di mercato in quantolo sviluppo di
applicazioni web e` unattivita` che racchiudenon solo elementi
tecnici ma anche manageriali, sociali edartistici.
I WMLs devono dunque supportare la modellazione in un modoche
sia consistente con tali caratteristiche.
Abilita` di modellare la navigazione
E` necessario modellare laspetto strutturale e
comportamentaledella navigazione, come uno degli elementi piu`
caratteristici delleapplicazioni web.Dal punto di vista strutturale
si devono model-lare i links tra le pagine web, i quali possono
essere:
- Contestuali : connettono pagine in modo coerente con le
re-lazioni semantiche tra i concetti che tali pagine
contengono.Unlink contestuale permette il passaggio di
informazione( chia-mata contesto tra le pagine.
- Non-Contestuali : connettono le pagine in modo
totalmentelibero,cio e` indipendentemente dai loro contenuti e
dallerelazioni semantiche tra questi.
Dal punto di vista comportamentale si tratta di modellare i
com-portamenti legati alla navigazione,ad esempio la decisione a
run-time dellendpoint di un certo link.
-
2.1 Categorizzazione dei requisiti sulla base
dellarchitetturainformativa e funzionale 23
Abilita` di modellare le interazioni tra utente ed
informazione
Rispetto ai sistemi software tradizionali,i sistemi web
tendonoad avere interazioni piu` sofisticate con gli utenti.Di
conseguenzai WMLs devono essere in grado di modellare queste
particolariinterazioni in modo completo e non ambiguo affinche`
possanoessere individuate,comprese,modellate ed implementate.Nel
rap-porto con lutente si possono individuare alcune
caratteristicherilevanti,discusse di seguito.
Le differenti sorgenti di informazioneLe applicazioni web devono
connettere varie sorgenti di informa-zione differenti tra loro
come,ma non solo, database,file servero document repositories.I
WMLs devono modellare le differentisorgenti di informazione ed i
meccanismi di comunicazione adesse associati.
Il modo daccessoLe applicazioni web possono interagire con le
sorgenti di infor-mazione in modo reattivo o in modo proattivo.Nel
modo reattivo,lazione daccesso e` richiesta dallutente eviene
eseguita dallapplicazione web;mentre nel modo proattivolazione di
accesso viene iniziata automaticamente dallapplicazionestessa.I
WMLs devono permettere di poter differenziare e modellarequesti due
modi daccesso.
La distribuzione dellinformazioneLa distribuzione
dellinformazione deve essere supportata dallarchitetturatecnica con
una connettivita` costante ed affidabile,richiede ilsupporto della
definizione del profilo utente in modo che l infor-mazione venga
fornita allutente o gruppo di utenti interessatoed inoltre richiede
un controllo della sicurezza per assicurare
-
24 Requisiti necessari per un linguaggio di modellazione web
la segretezza dellinformazione.I WMLs devono supportare
tuttiquesti aspetti e specialmente la loro connessione.
Abilita` di modellare i ruoli di utenti e gruppi di utenti
Il successo delle applicazioni web dipende in gran parte
dallasoddisfazione dellutente che si puo` ottenere ,ad
esempio,fornendofunzionalita` sofisticate, semplici interfacce ed
una navigazioneben strutturata.Lo scopo e` quello di evitare il
disorientamentodellutente fornendo un conteso adatto e funzioni di
orienta-mento in grado di fornire allutente la chiara percezione
dellapropria posizione nellinformation space.WMLs devono dunque
presentare tali capacita`,incluse la definizionedei profili utente
edei gruppi di utenti, la connessione tra utentie gruppi di utenti
ed il legame tra profili utente e le interazionidegli utenti
stessi.
Abilita` di modellare il contenuto
La modellazione della struttura del contenuto
informativo,spessoespressa come lo schema di un database, risulta
di fondamen-tale importanza per le applicazioni web che spesso
devono gestiregrandi quantita` di dati.I WMLs devono dunque fornire
la pos-sibilita` di modellare il contenuto informativo proponendo
nuovenotazioni o utilizzando le tecniche tradizionali (come il
modelloE/R o il diagramma delle classi UML).
-
2.1 Categorizzazione dei requisiti sulla base
dellarchitetturainformativa e funzionale 25
2.1.3 Requisiti generali
Abilita` di collegare funzionalita` ed informazione
Lintegrita` e la coesione di unapplicazione web dipende da
unastretta e flessibile connessione tra i due aspetti
dellarchitetturatecnica analizzati:quello funzionale (sez. 2.1.1) e
quello legatoallinformazione (sez. 2.1.2).I WMLs devono dunque
supportare non solo la modellazionedi elementi funzionali ed
informativi,ma anche lintegrazione diessi in modo coesivo e
consistente.
Abilita` di mantenere lintegrita` del sistema
Lintegrita` di un sistema web puo` essere compromessa da:
- La complessita` delle applicazioni web su larga scala,ricchedi
funzioni complesse;
- I frequenti cambiamenti deirequisiti da parte di clienti
in-certi;
- I rapidi cambiamenti delle tecnologie;
- La combinazione di varie discipline coinvolte nello
sviluppodelle applicazioni web.
I WMLs possono mantenere tale integrita` fornendo
definizionisemantiche sia per gli elementi dei modelli che per le
relazionitra di loro.Con laiuto di CASE tools lintegrita` ed il
controlloreferenziale possono essere realizzati in modo automatico
o semi-automatico.
-
26 Requisiti necessari per un linguaggio di modellazione web
Abilita` di modellare a vari livelli di astrazione
Nelle varie fasi del ciclo di vita di unapplicazione web,come di
unprodotto software in generale, i modelli vengono utilizzati
comesupporto (sez 1.1).Per soddisfare i requisiti specifici di ogni
fase,i WMLs devono fornire modelli a diversi livelli di astrazione
(sez1.2) ed inoltre devono supportare la coesione dellintero
modellomettendo a disposizione interconnessioni coordinate tra
questilivelli di astrazione.
Abilita` di supportare la gestione del ciclo di vita delle
applicazioniweb
Per la maggioranza delle applicazioni,tra cui le applicazioni
web,la fase di progettazione e` solo linizio dellintero ciclo di
vita.Nelleapplicazioni web in particolare, la fase di mantenimento
assumeun ruolo sempre piu` importante.I WMLs devono dunque
facili-tare la gestione di tutto il ciclo di vita delle
applicazioni web,nonsolo della fase di progettazione.
Supporto di un CASE tool
Come sottolineato nella sez 1.1, per un linguaggio di
model-lazione e` di fondamentale importanza fornire notazioni
rapp-resentabili dagli strumenti di design.In particolare un
WMLdeve essere facilmente supportato dalle tool suites
commercialiconosciute dagli sviluppatori,come Entity-Relationship e
UMLeditors e code generators,oppure da un CASE tool specifico
perquel linguaggio.
-
2.2 Categorizzazione dei requisiti sulla base di tre
dimensioniortogonali 27
2.2 Categorizzazione dei requisiti sulla base
di tre dimensioni ortogonali
I requisiti necessari per i linguaggi di modellazione web
possonoessere categorizzati anche sulla base delle tre dimensioni
ortog-onali da considerare nella modellazione delle applicazioni
web,come mostra la figura 2.1:livelli,aspettie fasi [4].
Figure 2.1: Dimensioni della modellazione di applicazioni
web
2.2.1 Livelli:Contenuto,Ipertesto,Presentazione
La prima dimensione nella modellazione delle applicazioni
webcomprende tre livelli differenti:
- Livello di contenuto: fa riferimento ai dati usati
dallapplicazioneed e` spesso gestito tramite database systems;
- Livello di ipertesto:denota la composizione logica delle
paginee la struttura della navigazione;
- Livello di presentazione:riguarda la rappresentazione
graficadel livello di ipertesto,cio e` il layout di ogni pagina e
linterazionecon lutente.
-
28 Requisiti necessari per un linguaggio di modellazione web
La separazione tra i livelli ed il mapping esplicito :
e`necessario che vi sia una chiara separazione tra questi tre
li-velli,ogniuno dei quali riguarda un particolare aspetto delle
ap-plicazioni web.Tale separazione puo` essere ottenuta
rendendoesplicite le interdipendenze,cioe` il mapping, tra i
livelli,facilitalevoluzione del modello,riduce la complessita` ed
aumenta laflessibilita`.Deve essere mantenuta:
- L indipendenza tra dati e presentazione:richiede che la
de-scrizione logica dei dati sia indipendente dal modo in cui idati
vengono presentati allutente,cio` permette di cambiareil formato
della presentazionesenza alterare lo schema deldatabase;
- L indipendenza tra dati ed ipertesto:favorisce luso dei datida
parte di applicazioni differenti e fornisce la possibilita` diavere
diverse viste dellinformazione sulla base del
profilodellutente;
- L indipendenza tra ipertesto e presentazione:permette diavere
presentazioni diverse per lo stesso ipertesto sulla basedelle
specifiche del browser o di elementi di personaliz-zazione,aumenta
la portabilita` rendendo possibile generareappliczioni su
piattaforme diverse.
Possibilita` di mapping flessibili:Le possibilita` di mappingtra
i vari livelli devono essere il piu` flessibili possibile e
devonoassicurare che si ottenga la derivazione di un livello
dallaltro,nonostante le differenze tra i vari livelli(ad esempio,la
ridon-danza dei dati e` presente a livello di presentazione per
facilitarela navigazione ma e` eliminata a livello di contenuto con
le tec-niche di normalizzazione).
Bottom-up e Top-down design:Unaltro requisito riguardantequesti
livelli e` che deve essere possibile seguire non solo un ap-
-
2.2 Categorizzazione dei requisiti sulla base di tre
dimensioniortogonali 29
proccio bottom-up nel design(cominciare a modellare il livellodi
contenuto e poi derivare i modelli degli altri livelli),ma ancheun
design top-down in cui il livello di contenuto viene derivatodagli
altri livelli.
2.2.2 Aspetti:Struttura e Comportamento
La seconda dimensione comprende gli aspetti di struttura e
com-portamento ,i quali sono ortogonali rispetto ai tre livelli
dellaprima dimensione,cio e` ad ogni livello devono essere
modellatisia gli aspetti strutturali che quelli
comportamentali.
1. A livello di contenuto:
Struttura : riguarda la creazione della struttura del do-minio
mediante i meccanismi di astrazione standardcome classificazione,
aggregazione e generalizzazione.
Comportamento : laspetto comportamentale riguarda
lapplicationlogic dipendente dal dominio.
2. A livello di ipertesto:
Struttura : riguarda la composizione delle pagine e le
re-lazioni tra esse in termini di navigazione.
Comportamento : un esempio di aspetto comportamen-tale legato
allipertesto e` la la decisione a runtime dellendpointdi un certo
link.
3. A livello di presentazione:
Struttura : riguarda gli elementi dellinterfaccia con lutentee
la loro composizione gerarchica.
Comportamento : riguarda le reazioni agli eventi di in-put (le
azioni dellutente,come premere un bottone),linterazione
-
30 Requisiti necessari per un linguaggio di modellazione web
e la sincronizzazione tra gli elementi dellinterfaccia
conlutente.
Anche se si potrebbe scegliere un diverso formalismo per
ognilivello,sarebbe molto utile luso di un unico formalismo per
rap-presentare struttura e comportamento a tutti i livelli;anche
alloscopo di rendere piu` semplice il mapping tra i vari livelli.Un
altro requisito per facilitare la rappresentazione dei due as-petti
indicati e` che i WMLs devono supportare luso di pat-terns per il
design a tutti i livelli.La maggior parte dei patternsdisponibili
riguarda i livelli di ipertesto e presentazione.
2.2.3 Fasi:Analisi,modellazione concettuale,logica,fisicaed
implementazione
La terza dimensione per la modellazione delle applicazioni
webcomprende le fasi del ciclo di vita di un prodotto
software,dallanalisiallimplementazione.Questa dimensione e`
ortogonale alle due presentate precedente-mente,infatti la
struttura ed il comportamento del contenuto,dellipertestoe della
presentazione devono essere modellati in ogni fase del pro-cesso di
sviluppo.Non ce` un consenso generale sul modello peril ciclo di
vita delle applicazioni web,tuttavia si puo` consider-are
appropriata una distinzione,come nel design dei databases,tra una
rappresentazione astratta del dominio chiamata model-lazione
concettuale,un design indipendente dalla
tecnologia,modellazionelogica ed un design dipendente dalla
tecnologia,modellazionefisica(sez. 1.2).
-
Chapter 3
Analisi e confronto deilinguaggi proposti per lamodellazione di
interfacce web
Il capitolo si propone di valutare lo stato dellarte dei
linguaggiper la modellazione di interfacce web.Tali formalismi
vengono analizzati sulla base del linguaggio dimodellazione
tradizionale da cui derivano e delle interdipen-denze tra essi e
confrontati tra loro sulla base dei requisiti indi-viduati nel
capitolo 2.I linguaggi e formalismi per la modellazione di
interfacce webhanno origine da tre principali ambiti del
software:
Hypermedia,avente come base il Dexter Reference Model [5]:- HDM
[6][7]
- HDM-lite/AutoWeb[8]
- WebML [9] [10]
Database systems,basati sul modello
Entity-Relationship(E/R)[1]:- RMM [11]
- Araneus [12]
- Strudel [13]
-
32Analisi e confronto dei linguaggi proposti per la modellazione
di
interfacce web
Object-oriented modelling,in termini diObject Oriented
Tec-nique(OMT ) [14] e di Unified Modelling Language(UML)[2]:
- OOHDM [15] [16] [17]
- Metodo OO-H [18]
- UML esteso di Conallen [19] [20]
- Koch-UWE [21] [22] [23]
La figura 3.1 mostra le origini differenti dei vari linguaggi
dimodellazione,le frecce rappresentano le interdipendenze tra
talilinguaggi proposti. Coerentemente con tali dipendenze,i
lin-guaggi di modellazione vengono classificati in 3
generazioni:daiformalismi di prima generazione a quelli di seconda
generazionefino alle proposte piu` recenti.Se si escludono approcci
indipendenti ,come Conallen e Strudelche derivano direttamente da
formalismi di base come UML eE/R rispettivamente,la maggior parte
dei linguaggi di ultimagenerazione citati si basano su metodi di
modellazione prece-denti aventi origini in ambiti del software
differenti rispettoalle tecniche che vengono effettivamente
utilizzate per la model-lazione.Ad esempio,come mostra la figura
3.1,i linguaggi RMMe OOHDM derivano entrambi dallambito
dellHypermedia e daHDM ma applicano tecniche differenti:le tecniche
dell Entity-Relationship e dellObject Oriented rispettivamente.E`
importante sottolineare che ,data la rapida evoluzione delWeb,i
formalismi delle tre generazioni sono stati concepiti perfar fronte
ad esigenze di modellazione molto differenti.Le metodologie delle
prime generazioni sono nate per modellaresiti web del tipo sola
lettura e dunque rappresentano i primitentativi di modellare
elementi ipermediali come le pagine,i linkse la navigazione.Tali
metodologie si concentrano sullorganizzazionedelle strutture
dellinformazione e dei cammini di navigazione e,per lo piu`,si sono
mantenute ad un livello propositivo teorico.
-
33
Le proposte piu` recenti devono invece far fronte alle esigenze
dimodellazione delle moderne applicazioni web che comportano
lagestione di grandi quantita` di dati e di operazioni per la
modi-fica di tali dati che risultano sempre piu` complesse e vanno
benoltre la semplice operazione di seguire un link.I formalismi
piu`recenti propongono notazioni per modellare tali aspetti
dinam-ici delle moderne applicazioni web e sono inseriti allinterno
diprocessi completi di sviluppo di applicazioni web supportati
daCASE tools per la generazione automatica o semi-automaticadel
codice.Naturalmente ,allo scopo di valutare lo stato dellarte dei
lin-guaggi di modellazione web,si devono analizzare e confrontarele
proposte di ultima generazione;tuttavia ,sulla base delle
in-terrelazioni tra i linguaggi rappresentate in figura 3.1, si
ritienesia utile descrivere e comprendere anche le proposte meno
re-centi dalle quali derivano i progetti di ultima generazione.
-
34Analisi e confronto dei linguaggi proposti per la modellazione
di
interfacce web
Figure 3.1: Origini e relazioni dei linguaggi di modellazione
Web
3.1 Linguaggi di modellazione web nellambito
dellHypermedia
Prima di analizzare i linguaggi di modellazione aventi origine
intale ambito,e` utile fornire una breve definizione di
Ipertesto,Presentazionemultimediale ed Hypermedia.
Un Ipertesto e` un insieme di concetti e links che colleganotra
loro tali concetti;viene modellato come una rete di nodicollegati
da un insieme di links;
Una Presentazione multimediale e` caratterizzata da
unacombinazione di testi,suoni,video e sopratutto si differen-zia
da altre presentazioni per linterazione dellutente;
Un Hypermedia e` una combinazione di ipertesto e presen-tazione
multimediale:i links possono essere definiti tra un
-
3.1 Linguaggi di modellazione web nellambito dellHypermedia
35
qualunque insieme di oggetti multimediali,inclusi suoni,videoe
realta` virtuale.
Il primo modello nellambito dellHypermedia ad essere accettatofu
il Dexter Reference Model [5].Tale modello forniva una terminologia
uniforme per rappresentarele diverse primitive messe a disposizione
dai sistemi per la costruzionedellipertesto.Nel Dexter Reference
Model i componenti rappre-sentano le parti di informazione che
costituiscono lipertesto edi links rappresentano la
navigazione,ossia i cammini percorribili.In seguito molte proposte
nel campo dellHypermedia si sonobasate sul Dexter Reference Model
ed hanno aggiunto primitivedi modellazione pi
sofisticate,semantiche formali e processi disviluppo
strutturati.
3.1.1 HDM:Hypertext Design Model
LHypertext Design model(HDM )[6] e` stato uno dei primi
metodisviluppati per definire la struttura e linterazione
nellambitodellHypermedia.Come mostra la figura (figura3.1),HDM e`
statosviluppato a partire dal Dexter Reference Model ma si
basasulla metodologia Entity-Relationship(E/R),che viene estesa
conunorganizzazione gerarchica.HDM introduce un chiara separazione
tra due aspetti:
- Authoring-in-the-large:comprende la modellazione
dellapplicazioneda un punto di vista strutturale e
globale,individuando ele-menti generali come entita`,componenti o
unita` e collegandocaratteristiche comuni ad applicazioni di un
certo dominio.
- Authoring-in-the-small :fa riferimento a dettagli
dellorganizzazionee del comportamento di una specifica applicazione
e dunquedipende dagli strumenti di implementazione.
-
36Analisi e confronto dei linguaggi proposti per la modellazione
di
interfacce web
HDM permette di identificare non solo i componenti
atomicidellipertesto ma anche i criteri per assemblare le
strutture.HDMin verita` tratta solamente gli aspetti
dellAuthoring-in-the-largee descrive solo la struttura
dellipertesto ,senza considerare speci-fici dettagli
implementativi.Tale struttura viene rappresentata estendendo il
concetto dientia` del modello E/R ed introducendo nuove primitive
comele unita`(corrispondenti ai nodi dellipertesto) ed i
links.Unentita` e` la piu` piccola parte di informazione che puo`
essereaggiunta o cancellata da unapplicazione;per esempio sono
entita`unopera lirica(Le Quattro Stagioni di Vivaldi,ad esempio)
oun pittore (Piero della Francescaad esempio) o una legge
(adesempio legge 8/11/2000).
Le entita` HDM rappresentano oggetti fisici o concettuali del
do-minio; si differenziano da quelle del modello E/R in quantohanno
una loro struttura interna gerarchica ed hanno associatauna
semantica per il browsing,cioe` la specifica di come puo`
essererealizzata la navigazione e come viene visualizzata
linformazione.Ogni entita` e` una gerarchia di componenti a loro
volta costituitida unita`.I componenti non sono autonomi ed
esistono solo come partedi unentita`;ad esempio possiamo
considerare Primavera uncomponente dellentita` Le Quattro Stagioni
o Il Battesimodi Cristoun componente dellentita` Piero della
Francesca.Ogni unita` che costituisce un componente mostra il
contenutodel componente da una particolare prospettiva.Una
prospettiva e` una presentazione differente dello stesso
con-tenuto;ad esempio in unapplicazione multilingua lo stesso
argo-mento pu o` essere descritto con linguaggi diversi.
Ununita` e` caratterizzata da un nome e da un body.Inserire
icontenuti nei bodies appropriati rappresenta
lAuthoring-in-the-
-
3.1 Linguaggi di modellazione web nellambito dellHypermedia
37
small.Ad esempio Piero della Francesca/vita italiana e`
lunita`che descrive in italiano la vita del pittore.Tutti i
componenti diunentita` devono avere associato lo stesso numero di
prospettivedellentita` stessa.Nella tabella3.1,ad esempio, ogni
componente dellentita` LeQuattro Stagioni contiene una
registrazione digitale,un pun-teggio musicale,commenti al testo in
inglese ed in italiano.
ENTITA` Le Quattro Stagioni di VivaldiCOMPONENTI primavera
estate inverno autunnoPROSPETTIVE Registrazione Punteggio Commenti
Commenti
Digitale Musicale Inglese ItalianoUNIT UNIT UNIT UNIT
Table 3.1: Esempio di composizione di unentita` HDM
Estendendo la definizione usata nellambito dei
database,unoschema HDM e` un insieme di definizioni di entita` e
links,mentreunistanza dello schema e` un insieme delle entita` e
dei links ef-fettivi che rispettano i vincoli definiti nello
schema.Lipertesto di una applicazione e` composto da
uniperbase,formatada entita`,componenti,unita` e links,e da un
insieme di strutturedaccesso,dette outlines.Un outline e` una parte
dellipertestocontenente informazioni sulla navigazione che permette
laccessoalle entita` delliperbase offrendo un entry point per
cominciarela navigazione e la possibilita` di individuare e
selezionare le en-tita`.Gli outlines definiti in HDM sono:
- Index links :connettono il nodo rappresentante una
collezionecon ogni membro della collezione.
- Guided tours :connettono tutti i nodi rappresentanti le
collezioniin una sequenza lineare in cui ogni membro e` collegato
con
-
38Analisi e confronto dei linguaggi proposti per la modellazione
di
interfacce web
il precedente e con il successivo. Nelle collezioni
circolarilultimo membro e` collegato con il primo.
- Collection links : sono index o guided tour links che
perme-ttono di visitare i nodi della collezione.
Gli outlines permettono allautore di organizzare un insieme
dilinks nelliperbase e non sono specificati nello schema,ma
pos-sono essere aggiunti nellapplicazione per fornire unentry
pointallutente.
Uno degli elementi di HDM che furono considerati piu`
interes-santi e` lintroduzione di differenti categorie di links che
tengonoconto delle diverse relazioni esistenti tra gli elementi
dellinformazione,comele relazioni tra entita` e le regole di
navigazione(come lutentepuo` muoversi allinterno della struttura
ipermediale. In HDMvengono definiti tre tipi di link:
- Links strutturali :connettono i componenti.
- Links di prospettiva:permettono di collegare le unita` con
icomponenti a cui fanno riferimento.
- Links di applicazione:connettono componenti ed entita`
dellostesso tipo o di tipo diverso e ,a differenza degli altri due
tipidi link che possono essere derivati automaticamente
dallastruttura delle entita`,sono definiti dallautore.
Per supportare il design della presentazione,cioe` il design
dicome il contenuto e le funzioni dellapplicazione vengono
pre-sentate allutente,HDM definisce due concetti:slot e frame.Uno
slot e` una parte atomica dellinformazione ,puo` essere sem-plice o
complesso,come un video sincronizzato con suoni.Un framee` ununita`
di presentazione,cioe` cio` che viene mostrato allutente.
-
3.1 Linguaggi di modellazione web nellambito dellHypermedia
39
Analisi di HDM sulla base dei requisiti legati alle tre
dimensioniortogonali
Gli elementi fondamentali di HDM descritti
precedentementepermettono di verificare se lHypermedia Design Model
soddisfao meno i requisiti dei linguaggi di modellazione web
categorizzatisulla base di tre dimensioni ortogonali nel capitolo
2,sezione 2.2.
Dal punto di vista dei livelli,HDM distingue solo tra livellodi
ipertesto e livello di presentazione e,anche se la sepa-razione tra
tali livelli e` chiara,non vengono descritti concettiper un mapping
esplicito e flessibile tra i livelli.
Dal punto di vista dei aspetti,in HDM gli aspetti strut-turali
sono considerati ad entrambi i livelli mediante lusodei concetti
descritti precedentemente,mentre gli aspetti dicomportamento
vengono considerati principalmente a liv-ello di presentazione
modellando linterazione con lutente.
Dal punto di vista delle fasi,HDM,come indicato preceden-temente
distingue tra le due fasi di
Authoring-in-the-largeeAuthoring-in-the-small.
3.1.2 HDM-lite/AutoWeb
AutoWeb[8] e` un progetto di ricerca che propone una
metodolo-gia ed uno strumento per lo sviluppo di siti Web
Data-intensive.Il processo di sviluppo di un sito Web in AutoWeb e`
organizzatoin tre fasi principali:
1. Definizione del sito web;
2. Generazione del database di supporto;
3. Implementazione del sito Web.
-
40Analisi e confronto dei linguaggi proposti per la modellazione
di
interfacce web
La prima fase e` basata su uno spcifico linguaggio
,chiamatoHDM-lite,e guida verso la definizione di un
iperschema,cioe` unadescrizione ad alto livello degli elementi piu`
rilevanti del sito in-dipendente dallimplementazione.HDM-lite
rappresenta unevoluzione di HDM di cui condensa iconcetti.Un
iperschema consiste di tre parti:
1. Schema strutturale:descrive le proprieta` strutturali dei
prin-cipali oggetti che compongono lapplicazione.
2. Schema navigazionale:viene imposto sullo schema
strutturaleallo scopo di specificare come sia possibile muoversi da
unoggetto allaltro ed indicare i cammini di accesso per
rag-giungere gli oggetti.
3. Schema di presentazione:descrive come rappresentare
grafi-camente gli schemi precedenti(strutturale e
navigazionale).
Hdm-lite mette a disposizione un ricco insieme di costrutti
dimodellazione per descrivere le tre parti delliperschema.Lo schema
strutturale viene descritto da una variante del mo-dello
Entity-Relationship:oggetti della stessa classe sono descrittida
tipi di entita`,i quali possono aggruppare una gerarchia di
com-ponenti,cioe` aggregazioni di pezzi atomici di informazione
dettislot ;inoltre vengono utilizzati tipi di link per descrivere
le re-lazioni binarie tra i tipi di entita`.Per descrivere lo
schema navigazionale HDM-lite mette a dispo-sizione traversals e
collections.I traversals possono essere definiti sulla base dei
tipi di linkdelloschema strutturale e vengono usati per specificare
come muoversida un oggetto ad un altro oggetto connesso.Le
collections vengono introdotte per decrivere la struttura
diaccesso.Sia i traversals che le collections sono associati con le
se-mantiche orperazionali della navigazione,cioe` con i dettagli
che
-
3.1 Linguaggi di modellazione web nellambito dellHypermedia
41
specificano lesecuzione a run-time di una navigazione.Infine la
presentazione e` modellata in HDM-lite attraverso il tipodi
pagina.Vi sono tre categorie di tipi di pagina:
- Tipi di pagina component :specificano la presentazione
deicomponenti;
- Tipi di pagina collection:specificano la presentazione
dellecollections;
- Tipi di pagina traversal :specificano la presentazione dei
traver-sals;
I tipi di pagina vengono considerati come griglie astratte ed
ognielemento della griglia ha uninsieme di proprieta` di
presentazioneche possono essere settate dallutente.Un ricco
ambiente grafico assiste il designer in ogni passo delprocesso di
definizione delliperschema.Una volta terminata la definizione
delliperschema,il sistema gen-era automaticamente il sito
attraverso due passi successivi:inizialmenteviene generato lo
schema di un database relazionale a partiredallo schema
strutturale;in seguito,sulla base del database,vengonogenerate le
pagine HTML per lo schema navigazionale e per itipi di pagina.
Analisi di HDM-lite/AutoWeb sulla base dei requisiti legati
alletre dimensioni ortogonali
Gli elementi fondamentali di HDM-lite/AutoWeb descritti
prece-dentemente permettono di verificare se tale progetto soddisfa
omeno i requisiti dei linguaggi di modellazione web
categorizzatisulla base di tre dimensioni ortogonali nel capitolo
2,sezione 2.2.
Dal punto di vista dei livelli,come HDM il livello di con-tenuto
non viene modellato separatamente ma piuttosto
-
42Analisi e confronto dei linguaggi proposti per la modellazione
di
interfacce web
insieme al livello di ipertesto attraverso lo schema
strut-turale,come descritto in precedenza.Inoltre,a livello di
ipertesto,viene definito anche uno schema navigazionale.Il livello
dipresentazione viene modellato attraverso uno schema
dipresentazione.Manca dunque la separazione del livello dicontenuto
dagli altri due livelli;inoltre ,bench e` sia possibilemappare pi
u` schemi di presentazione sugli schemi strut-turale e
navigazionale,non vengono forniti costrutti esplicitiper il
mapping.
Dal punto di vista dei aspetti,gli aspetti comportamentalinon
vengono trattati a nessun livello.
Dal punto di vista delle fasi,HDM-lite propone una
trasfor-mazione degli schemi concettuali in una
rappresentazionelogica e in un ulteriore rappresentazione
fisica.Per la primaparte,cioe` la trasformazione da modellazione
concettuale amodellazione logica,le tecniche ben conosciute di
trasfor-mazione dello schema concettuale E/R nello schema
logicovengono usate per trattare anche gli aspetti navigazionali
edi presentazione.Tali trasformazioni sono implementate dalsistema
AutoWeb
3.1.3 WebML
WebML (Web Modelling Language)[9] [10] e` un linguaggio
pro-posto in sede internazionale da un gruppo di ricercatori di
Mi-lano che ,come suggerisce il nome,si propone di adattare le
tec-niche della modellazione concettuale alle caratteristiche
distin-tive delle applicazioni web.WebML puo` essere considerato il
diretto discendente di Au-toWeb,infatti WebML eredita da AutoWeb
lapproccio basatosui modelli ,ma introduce meccanismi per la
gestione di aspetticomportamentali e percio` supporta lo sviluppo
non solo di siti
-
3.1 Linguaggi di modellazione web nellambito dellHypermedia
43
web,ma anche delle moderne applicazioni Web.WebML e` un
linguaggio concettuale in grado di supportare tuttele attivita` e
le prospettive della modellazione delle applicazioniweb
Data-Intensive.Il Web Modelling Language mette a disposizione
specifiche grafiche,maanche formali,inserite in un processo di
modellazione completoche puo` essere assistito da CASE tools
specifici.I principali obiettivi del processo di modellazione WebML
sono:
1. Esprimere la struttura di unapplicazione web mediante
unadescrizione di alto livello.
2. Mettere a disposizione piu` punti di vista dello stesso
con-tenuto.
3. Separare il contenuto informativo dalla sua composizione
inpagine,dalla navigazione e dalla presentazione che possonoessere
definite e sviluppate indipendentemente.
4. Memorizzare le meta-informazioni raccolte durante il
pro-cesso di modellazione in un Data-Repository che puo`
essereutilizzato durante la fase di operabilita` dellapplicazione
pergenerare dinamicamente pagine Web.
5. Modellare esplicitamente gli utenti ed i gruppi di utenti
alloscopo di permettere la specifica di politiche di
personaliz-zazione.
6. Permettere la specifica di operazioni per la manipolazionedei
dati allo scopo di modificare il contenuto dellapplicazioneo di
interagire con servizi esterni.
WebML puo` essere usato sia con un approccio top-down checon uno
bottom-up.Nel caso top-down le sorgenti di dati (adesempio un
database online) sono definite insieme con lapplicazione;nel
-
44Analisi e confronto dei linguaggi proposti per la modellazione
di
interfacce web
caso bottom-up,le sorgenti di dati esistono a priori e devono
es-sere integrate con il processo.Nello scenario bottom-up si
pos-sono applicare gli stessi principi ma il processo di
modellazionedeve includere un mapping esplicito delle strutture
dati con-cettuali in WebML nelle sorgenti di dati fisiche
preesistenti,lacui struttura e le cui primitive daccesso possono
influenzare oporre dei vincoli al processo di modellazione
WebML.
I modelli WebML
WebML assume un approccio step-by-step nella specifica
delleapplicazioni Web Data-Intensive,dove ogni step riguarda
unaprospettiva distinta della modellazione.Le tre prospettive
ortog-onali sono:
Modello strutturale : esprime lorganizzazione concettuale
deidati in termini di Entita` e di Relazioni rilevanti.Tale
mo-dello e` un sottoinsieme del modello Entity-Relationship edei
diagrammi UML delle classi.Gli elementi fondamentalidel modello
strutturale sono le entita`,definite come conteni-tori di dati, e
le relazioni ,definite come collegamenti se-mantici tra le
entita`.Come nel modello E/R le entita` hannoproprieta` con
nomi,chiamate attributi, con un proprio tipoassociato;le entita`
possono essere organizzate in gerarchiedi generalizzazionee le
relazioni possono essere ristrette davincoli di
cardinalita`.Tuttavia laspetto grafico e` molto diverso da quello
dellE/Rinfatti,come si puo` vedere dalla figura 3.2,la grafica e`
quelladei diagrammi delle classi UML anche se nelle classi nonsono
presenti i metodi in quanto le possibili operazioni suidati vengono
modellate in seguito.
Allo scopo di soddisfare il requisito di esprimere informa-zione
derivata o calcolata,il modello strutturale offre la pos-
-
3.1 Linguaggi di modellazione web nellambito dellHypermedia
45
Figure 3.2: Esempio di modello strutturale in WebML
sibilita` di supportare la derivazione.La derivazione e` il
processo di aggiungere dati rindondantiallo schema strutturale allo
scopo di aumentarne lespressivita`e definire viste diverse e
raggruppamenti dello stesso dato.Laderivazione viene espressa
attraverso delle queries ,in un lin-guaggio simile ad OQL,applicate
agli elementi dello schemastrutturale.Ogni elemento del modello
strutturale (entita`,attributi,relazioni)puo` essere derivato
attraverso le queries.Le operazioni piu` frequenti di derivazione
sono:limportazionedi attributi da unentita` allaltra ,la
definizione di attributicalcolati o la creazione di relazioni
derivate concatenandoo vincolando le relazioni gia` esistenti.
Modello dellIpertesto: descrive uno o piu` ipertesti che
pos-sono essere pubblicati dallapplicazione.Ogni ipertesto
,cioe`ogni insieme di pagine che realizzano un proposito
bendefinito dellapplicazione,viene immagazzinato in un costruttodi
modularizzazione,detto site-view.Una vista di sito e` un ipertesto
che assolve ai requisitidi una particolare classe di
utenti,offrendo interfacce nav-igazionali per accedere
allinformazione,manipolarla ed at-
-
46Analisi e confronto dei linguaggi proposti per la modellazione
di
interfacce web
tivare servizi.Sulla base dello stesso modello strutturale
possono esseredefinite piu` viste di sito per soddisfare le
necessita` di di-versi gruppi di utenti o per riarrangiare la
composizionedelle pagine allo scopo di adattare lapplicazione alle
pecu-liarita` dei vari dispositivi di accesso.La descrizione di
ogni vista di sito consiste di due sotto-modelli:
Modello di composizione: concerne la definizione dellepagine e
della loro organizzazione interna in termini dicontent units
elementari.Le pagine sono i contenitoridellinformazione fornite in
un certo istante allutente.Leunits sono elementi dal contenuto
atomico usati perrendere disponibile linformazione descritta nel
modellostrutturale.In WebML sono predefiniti sei tipi di content
units perla composizione delle pagine:
- Data units :sono usate per visualizzare linformazionedi un
singolo oggetto,cioe` listanza di unentita` (adesempio,un album
musicale-figura 3.3-).
Figure 3.3: Esempio di Data Unit
-
3.1 Linguaggi di modellazione web nellambito dellHypermedia
47
- Multi-Data units :vengono utilizzate per
visualizzarelinformazione di un insieme di oggetti,cioe` tutte
leistanze di unentita`(ad esempio,un insieme di
albummusicali-figura 3.4-).
Figure 3.4: Esempio di Multi-Data Unit
- Index units :sono usate per mostrare una lista dioggetti senza
presentare informazioni dettagliate perogni oggetto della lista (ad
esempio,una lista dialbum-figura 3.5-).
Figure 3.5: Esempio di Index Unit
Esistono due varianti di Index Units:
- Multi-Choice Index units :variante delle Index unitsin cui ad
ogni elemento della lista viene associ-ato un checkbox permettendo
allutente di com-piere piu` di una scelta (ad esempio,la scelta
dipiu` albums-figura 3.6-).
- Hierarchical Index units :variante delle Index unitsin cui gli
oggetti della lista sono organizzati inun albero multi-livello
(figura 3.7).
-
48Analisi e confronto dei linguaggi proposti per la modellazione
di
interfacce web
Figure 3.6: Esempio di Multi-Choice Index Unit
Figure 3.7: Esempio di Hierarchical Index Unit
- Entry units :utilizzate ogni volta che si vogliono
fareimmettere dei dati allutente utilizzando una Webform (ad
esempio,far inserire allutente lartista sulquale vuole avere
informazioni,figura 3.8).
Figure 3.8: Esempio di Entry Unit
- Scroller units :mostrano comandi per accedere aglielementi di
un insieme ordinato di oggetti (ad es-empio,per scorrere gli
albums,figura 3.9).
Figure 3.9: Esempio di Scroller Unit
-
3.1 Linguaggi di modellazione web nellambito dellHypermedia
49
Il contenuto delle content units viene estratto dalleentita`
specificate nello schema strutturale;dunque ognicontent unit e`
associata con unentita` sottostante,fattaeccezione per le Entry
units le quali non sono definitesu nessuna entita` poiche` esse non
pubblicano il con-tenuto del database ma accettano linput
dellutente.La specifica dellentita` sottostante indica il tipo di
oggettodal quale deriva il contenuto dellunita`,ma non iden-tifica
le istanze specifiche di quellentita` che devonoessere
utilizzate.Per questo motivo,quando e` appropri-ato,le unita`
possono essere associate con un selettore,cioe`un insieme di
condizioni che determinano le attuali is-tanze da usare come
contenuto dellunita`.Il selettorepuo` essere definito su un
attributo dellentita` o su unarelazione.Ad esempio,una index unit
definita sullentita`Album puo` avere un selettore costruito sulla
relazionetra autore ed album allo scopo di restringere
linsiemedegli album da mostrare ai soli album di
quellautorespecifico (figura 3.10).
Figure 3.10: Esempio di selettore definito su una relazione
Modello di navigazione: descrive i links tra le pagine ele
content units per formare lipertesto.Tali links assi-curano che la
necessaria informazione relativa al con-testo sia disponibile per
determinare il contenuto dellepagine e fornire meccanismi per
lindividuazione dellinformazione.Un link puo` avere i seguenti
propositi:
1. Spostare lattenzione dellutente da una pagina allaltra.
-
50Analisi e confronto dei linguaggi proposti per la modellazione
di
interfacce web
2. Passare informazioni da ununita` allaltra.
3. Essere associati ad operazioni per produrre effettispecifici
(ad esempio,lesecuzione di unoperazionedi modifica ).
Linformazione trasportata dai links e` chiamata con-testo
navigazionale o piu` semplicemente contesto.I links che trasportano
linformazione del contesto sonochiamati links contestuali :essi
collegano due unita` doveil conteuto dellunita` di destinazione del
link e` determi-nato sulla base dellinformazione proveniente
dallunita`sorgente.I links contestuali possono essere
intra-pagina,secollegano unita` della stessa pagina,oppure
inter-pagina,secollegano unita` di pagine diverse.I links che non
trasportano linformazione del contestosono chiamati links
non-contestuali :essi collegano duepagine semanticamente
indipendenti.Linformazione del contesto serve per poter definire
ilselettore dellunita` di destinazione del links:ad esempio(figura
3.11) ,nel link tra un autore ed i propri albumsverra`trasportata
linformazione dellidentificativo (OID)dellautore allo scopo di
poter definire il selettore sullarelazione autore-album.
Figure 3.11: Esempio di link contestuale
I links WebML,sia contestuali che non,possono esseredi tre
tipi:
-
3.1 Linguaggi di modellazione web nellambito dellHypermedia
51
1. Links normali :vengono navigati dallutente cliccan-dovi.
2. Links di trasporto:trasportano informazioni,ma
noninteragiscono con lutente,cioe` non compaiono nellapagina e non
possono essere cliccati.Graficamente i links di trasporto si
distinguono perche`rappresentati con una linea
tratteggiata,anziche` con-tinua.
3. Links automatici :trasportano il contesto di
default(lidentificatoredella sorgente)ma collegano pagine che
vengono car-icate automaticamente senza linterazione con
lutente.
Modello di presentazione :esprime il layout e laspetto
graficodelle pagineindipendentemente dal dispositivo daccesso
attraverso unasintassi XML astratta.Le specifiche di presenta