Modellazione Concettuale Di Interfacce Web

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



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.


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


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.


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.


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


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.


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-


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.


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.


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


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.


- 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.


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


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.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.


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.


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


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.


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


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.


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-


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


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.


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.


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


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


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


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


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-


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-


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


- 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).


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


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.


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:


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

Modellazione Concettuale Di Interfacce Web

Documents

Transcript of Modellazione Concettuale Di Interfacce Web