UNIVERSITA’ DEGLI STUDI DI PISA
Facoltà di ingegneria
LS in: Ingegneria informatica per la gestione d’azienda
Realizzazione di un’applicazione web per la gestione
di un istituto scolastico di ogni ordine e grado
attraverso il linguaggio WebML
Candidato:
Antonio Testa
Relatori:
Chiar.mo Prof. Francesco Marcelloni Chiar.ma Prof.ssa Beatrice Lazzerini Dott. Samuele Dembelè
3 Indice:
1 LINGUAGGI DI MODELLAZIONE WEB ...10
1.1 Introduzione ...10
1.2 Progettazione di Applicazioni Web ...12
2. WEBML...14
2.1 Introduzione ...14
2.2 Target del linguaggio ...15
2.3 Modello strutturale...16
2.4 Modello Ipertestuale ...17
2.5 Modello Composizionale ...18
2.5.1 Pagine Annidate...19
2.5.2 Aree, landmark e pagina home...20
2.6 Unit...22
2.6.1 Data Unit...22
2.6.2 Multidata Unit...23
2.6.3 Index Unit ...23
2.6.4 Multi-choice Index Unit ...24
2.6.5 Hierarchical Index Unit ...24
2.6.6 Entry Unit ...25
2.6.7 Scroller unit ...25
2.7 Modello navigazionale...27
2.7.1 Specifica dei link ...27
2.8 Operation Unit...29 2.8.1 Operazioni Predefinite...29 2.8.2 Create Unit...29 2.8.3 Delete Unit...30 2.8.4 Modify Unit ...31 2.8.5 Connect Unit...32 2.8.6 Disconnect Unit ...33 2.9 Modello Presentazionale...35
3 ESTENSIONI UML PER IL WEB ...37
3.1 Introduzione ...37
3.2 Interfaccia Utente...38
3.2.1 Modellazione con UML...39
3.2.2 Flusso delle schermate...41
3.2.3 Input dell’utente e Mappa di navigazione ...41
3.3 Progettazione, descrizione Logica ...42
3.3.1 Interfaccia Utente ...42
4
3.3 Esempi di modelli di progetto con WAE... 47
3.5 Corrispondenza WebML-UML ... 48
3.6 Confronto tra WebML e WAE ... 54
3.6.1 Caratteri generali ... 54
3.6.2 Corrispondenze tra gli elementi WebML e WAE... 56
4 PROCESSO DI SVILUPPO CON WEBML ... 59
4.1 Introduzione... 59
4.2 Fasi del Processo di sviluppo... 61
4.3 Specifica dei requisiti ... 62
4.3.1 Raccolta dei requisiti... 62
4.4 Analisi dei requisiti... 65
4.4.1 Specifica dei gruppi... 65
4.4.2 Specifica dei casi d’uso ... 66
4.4.3 Specifica del dizionario dei dati ... 67
4.4.4 Specifica delle site view... 67
4.4.5 Specifica delle linee guida per lo stile grafico ... 68
4.5 Progettazione dei dati ... 68
4.6 Progettazione dell’ipertesto ... 70
4.6.1 Progettazione preliminare ... 71
4.6.2 Progettazione dettagliata ... 72
5 MODELLAZIONE DI PROCESSI E ATTIVITÀ AZIENDALI CON WEBML ... 74
5.1 Introduzione... 74 5.2 Struttura ... 76 5.3 Progettazione d’insieme... 78 5.4 Navigazione ... 79 5.4.1 IF Unit ... 79 5.4.2 Switch Unit... 80
5.5 Parte statica, inserimento consultazione dati... 81
5.6 Parte Dinamica, WorkFlow delle Procedure ... 82
5.7 Esempi di pattern ... 86
6 ANALISI DEI REQUISITI DELL’APPLICAZIONE “SISCUOLA” ... 88
6.1 Gerarchia di specializzazione ... 88
6.2 Specifica dei gruppi ... 89
6.3 Casi d’uso ... 94
6.3.1 Gruppo “utente esterno non registrato”... 94
6.3.2 Gruppo “utente interno registrato”... 96
6.3.3 Gruppo “amministratori”... 101
6.3.4 Gruppo “tutori”... 106
6.3.5 Gruppo “studenti” ... 108
6.3.6 Gruppo “pers_segreteria”... 109
5
6.3.8 Gruppo “dirigenti”...113
6.4 Diagrammi delle attività ...114
6.4.1 Personale di segreteria ...114
6.4.2 Amministratori...117
6.4.3 Utente interno registrato ...119
6.5 Linee guida per lo stile grafico ...120
7 PROGETTAZIONE DETTAGLIATA FUNZIONALITÀ DI SISCUOLA...122
7.1 Requisiti generali del sistema ...122
7.2 Le aree logiche del sistema ...122
7.2.1 Area Alunni ...123
7.2.2 Istruzione e formazione Tecnica Superiore...123
7.2.3 Obbligo Formativo ...124
7.3 Dettagli implementativi generali...125
7.4 Diagramma dei moduli sviluppati...126
7.4.1 Descrizione ...126
7.4.2 Diagramma ...127
7.5 Descrizione dei Moduli...129
7.5.1 Glossario...129
7.6 Modulo IFTS...130
7.6.1 Descrizione di Massima...130
7.6.2 Struttura ...131
7.6.3 Funzionalità implementate ...132
7.7 Modulo Obbligo Formativo ...140
7.7.1 Descrizione di massima ...140
7.7.2 Struttura ...141
7.7.3 Funzionalità implementate ...142
7.8 Modulo Alunni...151
7.8.1 Funzionalità implementate ...151
7.9 Modulo Gestione Dati...158
7.9.1 Funzionalità implementate ...158
7.10 Modulo Amministrazione Tabelle di decodifica ...165
7.10.1 Funzionalità implementate ...165
7.11 Modulo Privato Studenti ...168
7.11.1 Funzionalità implementate ...168
7.12 Modulo Informazioni Scuola ...169
7.12.1 Funzionalità implementate ...169
8 PROGETTAZIONE E SVILUPPO WEBML DI SISCUOLA...171
8.1 Struttura del sistema...171
8.2 Diagramma dei dati di SiScuola ...173
8.2.1 Esami e Iscrizione studenti...177
8.2.2 IFTS ...178
6
8.2.4 Obbligo Formativo ... 180
8.2.5 Organi Collegiali ... 181
8.2.6 Piani di studio e materie ... 182
8.2.7 Scuola ... 182
8.2.8 Valutazioni e Giudizi ... 183
8.3 Progettazione e sviluppo dell’Ipertesto di SiScuola... 185
8.4 Progettazione Preliminare... 185
8.5 Progettazione in dettaglio ... 186
8.6 Progettazione in dettaglio (sottoschemi di ipertesto) ... 188
8.6.1 Sezioni comuni ... 191
8.6.2 Modulo IFTS ... 192
8.6.3 Modulo Obbligo Formativo ... 198
8.6.4 Modulo Alunni ... 203
8.6.5 Modulo Gestione Dati ... 211
8.6.6 Modulo Amministrazione Tabelle di decodifica... 216
8.6.7 Modulo Privato Studenti ... 218
8.6.8 Modulo Informazioni Scuola ... 219
8.7 Risultato grafico di SiScuola ... 221
9 CONCLUSIONI E SVILUPPI FUTURI... 225
7 Indice delle figure:
Figura 1: Livelli nella progettazione WebML ...15
Figura 2: Esempio di diagramma E/R ...17
Figura 3: Esempio di schema WebML ...18
Figura 4: Sotto pagine AND ...19
Figura 5: Sotto Pagine OR...19
Figura 6: Esempio di aree con vari livelli di visibilità ...20
Figura 7: Notazione pagina home...21
Figura 8: Notazione pagina di default ...21
Figura 9: Notazione pagina landmark...21
Figura 10: Esempio di pagine con vari livelli di visibilità ...21
Figura 11: Notazione per Data Unit...22
Figura 12: Esempio di Data Unit con selettore su attributo ...22
Figura 13: Esempio di Data Unit con selettore di realzione...23
Figura 14: Notazione per Multi-data Unit ...23
Figura 15: Notazione per Index Unit ...23
Figura 16: Notazione per Multi-choice Index Unit ...24
Figura 17: Notazione per Hierarchical Index Unit ...25
Figura 18: Notazione per Entry Unit ...25
Figura 19: Notazione per Scroller Unit ...26
Figura 20: Esempio di link inter-pagina ...27
Figura 21: Esempio di link intra-pagina contestuali...28
Figura 22: Esempio di utilizzo di link di trasporto...29
Figura 23: Notazione per Create Unit...30
Figura 24: Esempio di utilizzo di una Create Unit ...30
Figura 25: Notazione per Delete Unit...30
Figura 26: Esempio di utilizzo di una Delete Unit ...31
Figura 27: Notazione per Modify Unit ...31
Figura 28: Esempio di utilizzo di una Modify Unit...32
Figura 29: Notazione per Connect Unit...32
Figura 30: Esempio di utilizzo di una Connect Unit ...33
Figura 31: Notazione per Disconnect Unit ...33
Figura 32: Esempio di utilizzo di una Disconnect Unit...34
Figura 33: Notazione per una Schermata...39
Figura 34: Modellazione con variabili di istanza array ...39
Figura 35: Modellazione con relazioni di composizione...40
Figura 36: Comportamento rappresentato come operazioni...41
Figura 37: Notazione per la navigazione tra schermate...41
Figura 38: Form con associazione ...41
Figura 39: Form con inclusione...41
Figura 40: Notazione per Pagina Server...44
8
Figura 42: Notazione per Form ... 44
Figura 43: Relazioni di base fra elementi WAE... 47
Figura 44: Java Server Page Model 2 Architecture... 47
Figura 45: Corrispondenza WebML UML, site view aree e pagine ... 49
Figura 46: Corrispondenza WebML UML, link ... 50
Figura 47: Corrispondenza WebML UML, Content unit-1 ... 51
Figura 48: Corrispondenza WebML UML, Content unit-2 ... 52
Figura 49: Corrispondenza WebML UML, Operation unit ... 52
Figura 50: Diagramma E/R in notazione UML... 53
Figura 51: Fasi dello sviluppo di una Applicazione Web ... 61
Figura 52: Esempio di diagramma dei gruppi in UML ... 66
Figura 53: Esempio di diagramma dei Casi d’uso in UML ... 67
Figura 54: Esempio WebML di progettazione preliminare delle Aree... 71
Figura 55: Struttura E/R del Sistema a Work-flow ... 76
Figura 56: If Unit... 79
Figura 57: Switch unit ... 80
Figura 58: Esempio di inserimento Dati... 81
Figura 59: Esempio di navigazione tra i processi... 82
Figura 60: Rappresentazione delle Procedure ... 82
Figura 61: Esempio di procedura completa degli elementi principali ... 83
Figura 62: Esempio di procedura con dettagliati i compiti ... 84
Figura 63: Esempio di procedure connesse... 85
Figura 64: Esempio di utilizzo di Switch Unit ... 85
Figura 65: Esempio 2 di utilizzo di Switch Unit ... 86
Figura 66: Esempio di utilizzo di If Unit ... 86
Figura 67: Esempio di Procedure complete in cascata... 87
Figura 68: Gerarchia di specializzazione ... 88
Figura 69: Caso D’uso utente non registrato... 94
Figura 70: Caso D’uso utente interno registrato ... 96
Figura 71: Caso D’uso utente amministratore... 101
Figura 72: Caso D’uso Tutori... 106
Figura 73: Caso D’uso Studenti ... 108
Figura 74: Caso D’uso Personale di Segreteria... 109
Figura 75: Caso D’uso Responsabile di Segreteria ... 111
Figura 76: Caso D’uso Dirigente... 113
Figura 77: Diagramma di attività “Gestisce Alunni” ... 114
Figura 78: Diagramma di attività “Gestisce Organi Collegiali” ... 115
Figura 79: Diagramma di attività “Gestisce IFTS” ... 116
Figura 80: Diagramma di attività “Gestisce Offerta Formativa” ... 116
Figura 81: Diagramma di attività “Crea Utente”... 117
Figura 82: Diagramma di attività “Gestisce Tabelle di sistema” ... 118
Figura 83: Diagramma di attività “Crea Gruppo” ... 118
Figura 84: Diagramma di attività “Login” ... 119
9
Figura 86: Diagramma E/R di SiScuola ...174
Figura 87: Diagramma E/R Esami e Iscrizioni...177
Figura 88: Diagramma E/R IFTS ...178
Figura 89: Diagramma E/R Indirizzi ...179
Figura 90: Diagramma E/R Obbligo Formativo...180
Figura 91: Diagramma E/R Organi Collegiali...181
Figura 92: Diagramma E/R Piani di Studio e Materie...182
Figura 93: Diagramma E/R Scuola...182
Figura 94: Diagramma E/R Valutazioni e Giudizi ...183
Figura 95: Progettazione preliminare IFTS ...185
Figura 96: Progettazione in dettaglio IFTS ...186
Figura 97: Progettazione in dettaglio Progetti IFTS...187
Figura 98: Grafico WebML Home Page Log-in...191
Figura 99: Grafico WebML Home Page Log-out...192
Figura 100: Grafico WebML complessivo IFTS...193
Figura 101: Grafico WebML Modifica Personale...195
Figura 102: Grafico WebML Modifica Composizione Piani...196
Figura 103: Grafico WebML Moduli e Studenti ...197
Figura 104: Grafico WebML Valutazioni ...198
Figura 105: Grafico WebML Anagrafe OF ...200
Figura 106: Grafico WebML Associazioni Studenti Moduli ...201
Figura 107: Grafico WebML Gestione Enti ...202
Figura 108: Grafico WebML Formazione Professionale ...203
Figura 109: Grafico WebML Gestione Assenze ...204
Figura 110: Grafico WebML Esami di Qualifica ...205
Figura 111: Grafico WebML Iscrizioni Studenti...206
Figura 112: Grafico WebML Modifica Iscrizione...207
Figura 113: Grafico WebML Modifica Tutore...208
Figura 114: Grafico WebML Ricerca Studenti ...210
Figura 115: Grafico WebML Inserimento Valutazioni ...211
Figura 116: Grafico WebML Creazione Organo...212
Figura 117: Grafico WebML Composizione Organo...213
Figura 118: Grafico WebML Piani di Studio ...214
Figura 119: Grafico WebML Inserimento dati Scuola...215
Figura 120: Grafico WebML Dati Sede ...216
Figura 121: Grafico WebML Pagine Amministrazione ...217
Figura 122: Grafico WebML Gestione Account ...218
Figura 123: Grafico WebML Pagella ...219
Figura 124: Grafico WebML informazioni IFTS ...220
Figura 125: Schermata SiScuola Amministrazione...222
Figura 126: Schermata SiScuola Segreteria ...222
Figura 127: Schermata SiScuola Gestione profili utenti ...223
10
1
Linguaggi di modellazione web
1.1 Introduzione
Scopo principale della presente tesi è quello di descrivere la fase di progettazione e sviluppo di un’Applicazione Web di notevoli dimensioni realizzata attraverso l’uso un linguaggio di modellazione concettuale per la specifica chiamato Web Modelling Language (WebML).
L’Applicazione Web è stata progettata e realizzata durante un periodo di tirocinio presso la TD Group S.p.A. Migliarino (Pisa) in collaborazione con due membri interni all’azienda stessa. Il nome dell’applicazione è
SiScuola e si propone di gestire un Istituto scolastico di ogni ordine e grado
fornendo un servizio modulare e multiscuola.
E’ stato utilizzato, per la realizzazione della stessa, un CASE tool grafico che supporta il processo di progettazione WebML dell’ipertesto ed Entità Relazioni del modello dei dati.
Nella tesi, inoltre, vengono presentati i dettagli relativi al linguaggio WebML, la descrizione di linguaggi alternativi, le modalità di progettazione basate sul WebML e la descrizione delle fasi dello sviluppo del progetto. Inizialmente vengono descritti gli elementi del modello WebML con pattern di utilizzo per esemplificarne il funzionamento. Il linguaggio viene presentato sotto quattro aspetti principali:
• Modello Strutturale: progettazione dello schema dei dati tramite diagramma Entità Relazioni;
• Modello Composizionale: Descrizione delle unit di contenuto e del modello delle site view, aree e pagine;
• Modello Navigazionale: Descrizione dei link per la navigazione tra gli elementi WebML;
• Modello Presentazionale: Aspetti di presentazione grafica.
Per effettuare un confronto con formalismi analoghi al WebML si espone la descrizione del WAE (Web Application Extension for UML) proposto da Jim Conallen. Il formalismo viene descritto e confrontato con il WebML. Successivamente viene effettuata una descrizione dettagliata delle fasi di sviluppo necessarie per la progettazione ottimale di un’Applicazione Web. Questo modello si basa e arricchisce, specializzandoli, i normali criteri
11
dell’ingegneria del software. Le principali fasi, descritte anche con l’ausilio di esempi sono:
• Specifica dei requisiti; • Progettazione dei dati; • Progettazione dell’ipertesto.
Come approfondimento al linguaggio WebML viene proposto un metamodello studiato per descrivere i processi aziendali dettagliandone le specificità fino alle singole procedure. Il divenire delle procedure viene modellato tramite una struttura a work flow.
La descrizione del lavoro di progettazione e sviluppo dell’applicazione
SiScuola avviene su più livelli:
• Descrizione della specifica dei gruppi, dei principali casi d’uso dell’applicazione e di alcuni diagrammi di sequenza;
• Descrizione dei moduli progettati e realizzati per SiScuola, il dettaglio arriva fino alla specifica delle funzionalità di ogni pagina sviluppata. Tale descrizione avviene in linguaggio naturale utilizzando formalismi non standardizzati;
• Descrizione delle fasi di progettazione/sviluppo dell’applicazione web SiScuola facendo riferimento al linguaggio WebML. La descrizione delle fasi segue l’ordine descritto nel capitolo relativo al processo di sviluppo. Si compone di:
• Diagramma dei dati: Descrizione del diagramma E/R del sistema con identificazione e descrizione delle più significative entità e relazioni;
• Progettazione preliminare: Descrizione della fase di progettazione preliminare della struttura dell’ipertesto attraverso la definizione di site-view, aree e pagine;
• Progettazione in dettaglio: Descrizione dettagliata dei principali pattern WebML per la realizzazione dell’applicazione.
Data la vastità del materiale risultante dalla Progettazione e Sviluppo del sistema SiScuola la scelta è stata quella di mostrare e descrivere solo qualche esempio. La selezione del materiale è avvenuta in base alla
12
significatività dello stesso, il fine è quello di presentare le principali modalità di progettazione WebML.
1.2 Progettazione di Applicazioni Web
La crescita esponenziale e la capillare diffusione del web hanno introdotto una nuova generazione di applicazioni caratterizzate da una relazione diretta tra il business e il client. Le Applicazioni Web sono divenute ormai un ingrediente di fondamentale importanza per le nostre attività lavorative e sociali. Attualmente il concetto di Applicazione Web si è espanso in modo significativo; si è passati dal semplice legame con il concetto di sito web fino a quello più generale di sistema complesso.
Nella realtà industriale e nell’ICT si assiste sempre ad una maggior diffusione di Applicazioni Web che vanno a coprire la maggior parte delle esigenze software che prima prevedevano l’impiego di soluzioni di tipo eterogeneo come applicazioni client-server programmate nelle più disparate modalità.
I vantaggi derivanti dall’utilizzo di Applicazioni Web sono molteplici e possono essere brevemente riassunti nel seguente elenco:
• Diffusione capillare di Web Browser: questo fa sì che una volta resa accessibile l’applicazione non risultino problemi di diffusione di eventuali client grafici da installare presso i fruitori del servizio;
• Diffusione di Internet: data la popolarità della rete mondiale risulta ormai naturale l’utilizzo di siti web, l’utente medio ne risulta più abituato e anche meno “spaventato”. Sistemi complessi come un gestionale realizzato sottoforma di un’Applicazione Web risultano, di norma, più user-friendly all’utente in quanto progettati secondo i dettami delle comuni pagine web;
• Manutenibilità: La struttura stratificata che contraddistingue le Applicazioni Web di moderna concezione si presta in modo ottimale, anche in un secondo tempo, sia alla modifica che all’espansione;
• Leggerezza: La mole di operazioni più costose avviene lato server, di norma, quindi l’interfaccia lato client risulta leggera e rapida nella consultazione.
La crescente diffusione di Applicazioni Web per la gestione di moli notevoli di dati (incentrate sui dati), ha creato un aumentato interesse verso la fase di
13
progettazione delle stesse, proponendo nuovi strumenti e paradigmi di modellazione. Esempi di applicazioni incentrate sui dati sono i siti per il commercio elettronico, siti istituzionali, librerie digitali, portali e siti di comunità virtuali, ecc.
L’ingegnerizzazione di Applicazioni Web incentrate sui dati di grandi dimensioni non può avvenire in modo “artistico” sulla base della conoscenza individuale del progettista, ma deve avvenire applicando metodologie standardizzate al pari della progettazioni di applicazioni Object-Oriented. I paradigmi standard di progettazione software non si adattano sempre in modo ottimale alla progettazione di Applicazioni Web che sono contraddistinte da aspetti tipici che vanno sfruttati per ottimizzare tale processo. I paradigmi convenzionali si possono utilizzare per la modellazione della parte standard come il design delle strutture dati o della logica di business, ma risultano inadeguati alla progettazione del front-end ipertestuale. Lo sviluppo e la manutenzione di Applicazioni Web necessita di tutti gli strumenti e le tecniche dell’ingegneria del software, compresa la definizione di un processo di sviluppo del software ben organizzato, concetti di progettazione, notazioni appropriate e linee guida per la conduzione delle varie attività.
14
2.
WebML
2.1 Introduzione
[4] WebML (Web Modelling Language) è un linguaggio proposto in sede
internazionale da un gruppo di ricercatori di Milano che, come suggerisce il nome, si propone di adattare le tecniche della modellazione concettuale alle caratteristiche distintive delle Applicazioni Web.
WebML è un linguaggio concettuale in grado di supportare tutte le attività e le prospettive della modellazione delle applicazioni Web incentrate sui dati. Il Web Modelling Language mette a disposizione specifiche grafiche, ma anche formali, inserite in un processo di modellazione completo che può essere assistito da CASE tools specifici.
WebML descrive ad alto livello un’applicazione Web attraverso più dimensioni tra loro ortogonali:
• i suoi dati (modello strutturale);
• le pagine che la compongono (modello composizionale); • la topologia dei link tra le pagine (modello navigazionale);
• il layout e i requisiti grafici per il disegno delle pagine (modello presentazionale);
• le caratteristiche della personalizzazione per l’accesso one-to-one ai contenuti (modello di personalizzazione).
15
Figura 1: Livelli nella progettazione WebML
Nella Figura 1 si notano le diverse prospettive e i vari passi per la realizzazione di un’applicazione utilizzando il linguaggio WebML.
Tutti i concetti di WebML sono associati a una notazione grafica ed a una sintassi testuale in formato XML. Le specifiche WebML sono indipendenti dal linguaggio lato client utilizzato per distribuire l’applicazione agli utentie non dipendono dalla piattaforma lato server usata per legare i dati alle pagine, ma possono essere comunque impiegate per produrre un’implementazione di un sito con una specifica impostazione tecnologica. WebML garantisce l’approccio model-driven allo sviluppo Web, il quale è un fattore chiave per definire una nuova generazione di strumenti CASE per la realizzazione di siti complessi dalle caratteristiche avanzate come l’accesso multi-dispostivo, la personalizzazione e la gestione integrata dell’evoluzione del sito.
2.2 Target del linguaggio
Il linguaggio è specifico per la definizione di Applicazioni Web di dimensione medio-grande incentrate sui dati, cioè con un largo uso di dati presenti su DB.
16 Per riassumere:
WebML OK WebML KO
• Grande quantità di dati
• Interfacce rivolte ad un pubblico generico
• orientate alla ricerca esplorativa
• orientate al browsing • personalizzate (1 ad 1)
• Piccoli siti (Homepages, …) • Siti statici
WebML utilizza un approccio per passi successivi nella definizione di un’Applicazione Web, in particolare sono presenti più modelli logici da definire in successione.
2.3 Modello strutturale
Il modello strutturale esprime il contenuto in dati del sito, in termini di entità e relazioni (vedi Figura 2). WebML non propone un altro linguaggio per la modellazione dei dati; piuttosto è compatibile con le notazioni classiche come il modello E/R, l’ODMG object-oriented model e i diagrammi di classe UML.
Il modello è composto da entità, definite come contenitori di dati strutturati e relazioni, che rappresentano le associazioni semantiche tra le entità. Le entità sono descritte tramite attributi caratterizzati da un tipo e possono essere organizzate in gerarchie di generalizzazione, per derivare concetti specifici a partire da concetti generali.
Le relazioni sono caratterizzate da vincoli di cardinalità, che servono per imporre delle restrizioni sul numero di istanze di una relazione a cui un oggetto può partecipare.
Nella Figura 2 sono rappresentate entità con i relativi attributi; sono presenti sia le gerarchie di generalizzazione che le relazioni: notare che l’attributo Nazione in Indirizzo è derivato dall’entità Nazione con cui è in relazione.
17
Figura 2: Esempio di diagramma E/R
Per affrontare il requisito di poter esprimere informazioni sia ridondanti che calcolate, il modello strutturale fornisce un linguaggio di interrogazione tipo OQL, con il quale è possibile specificare le informazioni derivate. Le operazioni più frequenti di derivazione sono:
• l'importazione di attributi da un'entità all'altra; • la definizione di attributi calcolati;
• la creazione di relazioni derivate concatenando o vincolando le relazioni già esistenti.
2.4 Modello Ipertestuale
A differenza della modellazione dei dati, che è un’attività ben consolidata, la modellazione ipertestuale è una disciplina molto più giovane, a cui manca ancora una base solida di concetti, notazioni e metodi di progettazione.
WebML fornisce le primitive per la modellazione ipertestuale, ereditando dal modello Entità-Relazione l’idea di utilizzare concetti semplici ed espressivi e di essere supportato da una notazione grafica intuitiva.
Gli elementi chiave del WebML sono:
• site view; • aree; • pagine;
18 • unit;
• link.
Le unit rappresentano le parti atomiche di contenuto da pubblicare; offrono modalità alternative per organizzare il contenuto estratto dinamicamente dalle entità e relazioni dello schema dei dati e permettono anche la specifica di moduli per l’inserimento di dati da parte dell’utente.
Le pagine rappresentano gli elementi di base del modello che vengono tipicamente costruite assemblando unit di vario tipo, per ottenere l’effetto di comunicazione desiderato. Le pagine e le unit sono collegate tra loro tramite link per formare una struttura ipertestuale.
Un insieme di pagine può essere raggruppato in una site view, che rappresenta un ipertesto coerente per soddisfare un insieme ben definito di requisiti, per esempio relativi a uno specifico gruppo di utenti.
La descrizione di una site-view si compone principalmente nella definizione del modello composizionale e navigazionale, i quali specificano contenuti e modalità di interazione con l’utente dell’Applicazioni Web.
2.5 Modello Composizionale
Il modello composizionale specifica quali pagine compongono la site view e quali content unit compongono la pagina.
Le pagine sono i contenitori dell'informazione fornite in un certo istante all'utente. Le units sono elementi dal contenuto atomico usati per rendere disponibile l'informazione descritta nel modello strutturale.
Una pagina corrisponde agli elementi di interfaccia forniti all’utente, tipicamente una pagina contiene diverse unit, raggruppate per comunicare dei concetti ben definiti.
La Figura 3 mostra un esempio elementare di pattern WebML; la visualizzazione di una scheda di uno studente estratto da una lista ordinata di tutti gli studenti esistenti nella base di dati tramite un link.
19 2.5.1 Pagine Annidate
Per modellare la struttura fisica di alcune pagine complesse, WebML offre la nozione di pagine annidate. Le pagine annidate permettono al progettista di dare una struttura gerarchica anche alle pagine, suddividendole in sottopagine.
• Le pagine annidate in forma congiuntiva (sotto-pagine AND) vengono usate per dividere la pagina contenuta in una schermata in porzioni, in modo tale che una porzione venga tenuta fissa e le altre mostrino informazioni variabili in base ai comandi degli utenti, in modo analogo al concetto di frame in HTML.
Figura 4: Sotto pagine AND
• Le pagine annidate in forma disgiuntiva (sottopagine OR) vengono usate per specificare che certe porzioni dello schermo possono contenere configurazioni di unit alternative, ognuna modellata come una pagina distinta.
Nella Figura 5 è presente un esempio di pagina OR. In questo caso il contenuto della pagina che include la pagina OR viene riempito con il contenuto di una sola delle pagine a scelta, in base a due parametri:
• La pagina di Default (marcata con D) viene caricata al normale caricamento della pagina.
• Un link che accede ad un elemento di una delle due pagine fa si che la pagina venga visualizzata.
20 2.5.2 Aree, landmark e pagina home
Molte applicazioni Web reali presentano una struttura gerarchica, in cui le pagine del sito sono raggruppate in sezioni relative ad argomenti omogenei. WebML fornisce le primitive per migliorare l’organizzazione delle site view e delle pagine tramite le aree, i landmark e il concetto di pagina Home. Le Aree sono contenitori di pagine o in modo ricorsivo, di altre sotto-aree, che possono essere utilizzate per dare un’organizzazione gerarchica a una site view. Anche alle aree possono essere associate le proprietà landmark e default:
• L’area di Default è la sottoarea a cui si accede di default quando si accede alla super-area che la racchiude. Se l’utente naviga un link che punta ad una super-area viene trasferito alla pagina oppure alla sottoarea di default;
• L’area landmark è un’area implicitamente raggiungibile da tutte le altre pagine della site view o della super-area in cui è racchiusa. Nell’esempio di Figura 6 si mostra la notazione per un’area che ne racchiude altre due, una delle quali è quella di di default (lettera D), tutte e tre sono landmark (lettera L).
Figura 6: Esempio di aree con vari livelli di visibilità
Le pagine all’interno di un’area o più in generale all’interno di una site view possono avere le seguenti proprietà (vedi Figura 10):
• La pagina home è la pagina all’indirizzo di default del sito e che viene presentata dopo che l’utente si collega all’applicazione tramite login. La pagina home deve essere unica all’interno della site view. Nella specifica grafica la proprietà home della pagina viene denotata con una “H” all’interno dell’icona della pagina, vedi Figura 7.
21
Figura 7: Notazione pagina home
• La pagina di default è la pagina presentata automaticamente quando si accede all’area che la racchiude. La pagina di default all’interno dell’area deve essere unica. Nella specifica grafica la proprietà home della pagina viene denotata con una “D” all’interno dell’icona della pagina, vedi Figura 8.
Figura 8: Notazione pagina di default
• Una pagina Landmark è raggiungibile da tutte le altre pagine o aree all’interno del modulo che la racchiude (site view o super area che la racchiude). Nella specifica grafica la proprietà landmark della pagina viene denotata con una “L” all’interno dell’icona della pagina, vedi
Figura 9.
Figura 9: Notazione pagina landmark
Nella Figura 10 si mostra la composizione di un’area e le tipiche tipologie di pagine racchiuse.
22
2.6 Unit
In WebML sono presenti sette diversi tipi di content unit, esse sono gli elementi utilizzati per specificare il contenuto di una pagina web. I sette tipi di unit di contenuto possono essere combinate per rappresentare pagine web di complessità arbitraria.
Le prime quattro unit modellano la pubblicazione di informazioni. 2.6.1 Data Unit
Pubblica i dati di un singolo oggetto di una determinata entità, ad esempio il profilo di uno studente (vedi Figura 11).
Figura 11: Notazione per Data Unit
Alla Data Unit è possibile associare un selettore che è un predicato che identifica un unico oggetto, il selettore è opzionale, ma si può omettere solo nel caso in cui l’entità sorgente abbia una sola istanza; altrimenti l’oggetto da visualizzare risulta indefinito.
Alla Data Unit è possibile specificare quali attributi dell’oggetto mostrare a video, ciò è possibile in tutte le unit di visualizzazione come le MultiData Unit o le Index Unit.
Nell’esempio di Figura 12 si mostra una Data Unit con un selettore per la selezione della scheda di uno studente che abbia come cognome Rossi, se non si tratta di un attributo chiave la Data Unit visualizzerà il primo degli studenti di cognome Rossi come comportamento di default.
23
Come condizione di selezione è possibile usare le relazioni tra le unità. Nell’esempio di Figura 13 si seleziona l’indirizzo di una persona, in particolare l’informazione relativa alla persona dovrà essere passato come parametro di un link entrante.
Figura 13: Esempio di Data Unit con selettore di realzione
2.6.2 Multidata Unit
Presenta un insieme di oggetti di un’entità, ripetendo la presentazione di molte Data Unit, ad esempio i profili di più utenti selezionati (vedi Figura
14)
Figura 14: Notazione per Multi-data Unit
Per la MultiData Unit è possibile definire una clausola di ordinamento che permetta la visualizzazione degli oggetti in un ordine definito. Tipicamente la clausola riguarda un attributo con ordinamento alfabetico ascendente, ma si possono ordinare secondo più attributi e in modo combinato.
2.6.3 Index Unit
Presenta un insieme di oggetti di un’entità come una lista.
24
Per capire meglio la differenza tra MultiData Unit e Index Unit, si mette in evidenza che la index è tipicamente usata per selezionare un oggetto da una lista, mentre la Multidata è utilizzata per la visualizzazione di un insieme di oggetti.
2.6.4 Multi-choice Index Unit
Ogni elemento della lista è associato ad una casella di scelta che permette all’utente di selezionare un insieme di oggetti anziché un singolo oggetto (vedi Figura 16)
Figura 16: Notazione per Multi-choice Index Unit
Un esempio di utilizzo di una Multichoice unit è quello di selezionare più oggetti e visualizzarne la scheda completa, per esempio tramite una MultiData Unit.
2.6.5 Hierarchical Index Unit
Unit in cui le voci dell’indice sono organizzate secondo un albero a più livelli. La gerarchia è rappresentata da una sequenza di N entità sorgenti, connesse da N-1 ruoli di relazione. La prima entità sorgente rappresenta le istanze di livello più alto nella gerarchia; la seconda entità sorgente, introdotta dalla clausola NEST, rappresenta le istanze al secondo livello della gerarchia, e così via. Ogni ruolo di relazione denota l’associazione padre-figlio tra due entità a due livelli consecutivi della gerarchia.
In Figura 17 si mostrano gli studenti e per ognuno gli indirizzi di appartenenza (questo non è evidenziato dalla figura in quanto il livello relativo agli indirizzi è stato specificato tramite software e non si evince dall’immagine).
25
Figura 17: Notazione per Hierarchical Index Unit
2.6.6 Entry Unit
Unit che supporta l’inserimento di dati tramite form. Viene utilizzata per ricevere l’input dall’utente, che viene tipicamente impiegato per:
• Effettuare ricerche all’interno di un insieme di oggetti di un’entità, per esempio per individuare le istanze di un’entità i cui attributi contengono una determinata parola chiave;
• Fornire i parametri a operazioni che aggiornano i contenuti della base di dati, per effettuare il login, ecc.
Figura 18: Notazione per Entry Unit
E’ possibile aggiungere i predicati di validità associati ai campi del form, questo permette di verificarne l’ammissibilità. Il predicato di validità può essere una qualsiasi espressione logica costruita utilizzando il nome del campo, un operatore applicabile al tipo di dato del campo e un termine costante oppure variabile. Il termine variabile può essere il nome di un altro campo; in questo modo è possibile effettuare il confronto tra i valori inseriti dall’utente in campi diversi, per esempio per assicurare che la data di morte sia successiva a quella di nascita.
All’interno del form i campi possono essere text area di dimensione settabile oppure combo box con valori inseriti manualmente o precaricati dal data base.
2.6.7 Scroller unit
Unit che fornisce i comandi per navigare una sequenza di oggetti, per esempio, se tutte le istanze di un’entità sono troppe da visualizzarsi tramite una Index Unit che sarebbe troppo lunga, con la Scroller Unit posso scorrerle a gruppi di N rendendo la visualizzazione più fruibile.
26
Figura 19: Notazione per Scroller Unit
Una proprietà importante è il Block Factor che specifica quanti oggetti devono essere visualizzati all’interno di una singola schermata, di default, se non specificato diversamente, vale uno, che indica che vengono visualizzati un oggetto per volta.
27
2.7 Modello navigazionale
Il modello navigazionale fa parte del modello ipertestuale e specifica i link tra le unit e le pagine e le proprietà dei link. In WebML le principali nozioni legate al modello sono:
• Link: collegamento orientato tra due pagine o unit;
• Parametro di un link: specifica dell’informazione che viene passata dalla sorgente alla destinazione del link (è un’astrazione del passaggio di attributi tra oggetti di una Applicazioni Web);
• Selettore Parametrico: selettore associato ad una unit i cui predicati contengono riferimenti a dei parametri di link.
2.7.1 Specifica dei link
I link astraggono la nozione fondamentale degli ipertesti: il concetto di ancora.
Un’ancora è un elemento attivo, per mezzo del quale l’utente può interagire con l’ipertesto. Si tratta di un’astrazione, in quanto in WebML per link si intendono sia le ancore HTML che i tasti di conferma nei form ecc.
In particolare, nella terminologia WebML, i link che attraversano i confini della pagina sono detti link inter-pagina, mentre i link la cui sorgente e destinazione appartengono alla stessa pagina sono detti link intra-pagina. I link sono rappresentati come archi orientati.
28
L’esempio di Figura 20 rappresenta un link non contestuale inter-pagina. Per link contestuale si intende un link che trasporta informazione, non contestuale nel caso contrario.
L’esempio di Figura 21 mostra il caso di un link intra-pagina contestuale in quanto connette due unit interne alla pagina e trasporta l’informazione relativa all’oggetto selezionato, nel caso in esame trasporta l’identificatore del Tutore selezionato. Come effetto del link avremo la visualizzazione della Index Unit Indirizzi Tutore con la lista degli indirizzi in relazione con il profilo Tutore selezionato (Il selettore fa riferimento a Persone e non direttamente a Tutore, questo va bene in quanto Tutore deriva da Persone tramite generalizzazione, quindi un tutore è a tutti gli effetti una persona, si veda la Figura 2)
Figura 21: Esempio di link intra-pagina contestuali
Si possono specificare altre due tipologie di link: i link automatici e i link di trasporto.
• Link automatico: link che viene “navigato” senza l’intervento dell’utente, quando si accede alla pagina che contiene la unit sorgente del link. Nel caso di unit comprendenti più oggetti come una Index Unit la selezione dell’oggetto da propagare nel link avviene secondo qualche criterio euristico, per esempio si può scegliere il primo oggetto della lista ordinata in qualche modo;
• Link di trasporto: Sono link usati per passare informazioni senza che vengano visualizzati bottoni o ancore cliccabili. E’ un link che abilita solamente il passaggio di parametri e non la navigazione da parte dell’utente.
29
Figura 22: Esempio di utilizzo di link di trasporto
La Figura 22 è un esempio di utilizzo di un link di trasporto: il risultato sarà che non appena verrà caricata la pagina verrà caricato dal DB il primo tutore inserito e si visualizzeranno tutti i suoi indirizzi (dando per assunto che nel passaggio di parametri del link sia stato specificato il passaggio dell’identificatore dell’oggetto tutore, es. la chiave)
2.8 Operation Unit
Le Operation Unit sono un tipo di unit che può essere posizionato all’esterno delle pagine e collegato ad altre operazioni oppure alle unit contenute nelle pagine tramite link. A differenza delle unit di contenuto, le operazioni non hanno lo scopo di pubblicare informazioni, esse eseguono delle azioni. Come le unit di contenuto possono avere link in ingresso e uscita, un oggetto sorgente e dei selettori.
Ogni operazione ha un link KO (in rosso) e un link OK (in verde) in uscita che possono essere usati dall’utente per gestire condizioni d’errore.
2.8.1 Operazioni Predefinite
Le operazioni predefinite sono definite dal linguaggio WebML, quelle basilari sono dedite alla gestione del contenuto dell’applicazione sul DB. 2.8.2 Create Unit
Permette la creazione di una nuova istanza di un’entità.
L’input è un insieme di valori che provengono, normalmente, da un link uscente da una Entry Unit. Una volta specificata l’entità sorgente che rappresenta l’entità della quale si vuol creare una nuova istanza, vengono definiti un insieme di assegnamenti che legano gli attributi dell’oggetto da creare con i valori dei parametri che provengono dai link in ingresso, o con dei valori costanti.
30
Il risultato della Create Unit è un nuovo oggetto nel DB con i dati passati tramite link, nel caso di successo si percorre il link Ok, in caso di errore di vario tipo il link KO che tipicamente condurrà ad una pagina di errore.
Figura 23: Notazione per Create Unit
Nella Figura 24 si mostra il tipico esempio di utilizzo di una Create Unit. L’utente specifica tramite un form i dati di un indirizzo e tramite il link passa alla Create Unit che permette la creazione di un nuovo oggetto Indirizzo nel DB. L’oggetto sarà composto con i dati passati tramite i parametri per l’accoppiamento del link tra i valori inseriti nel form e gli attributi dell’entità Indirizzo.
Figura 24: Esempio di utilizzo di una Create Unit
2.8.3 Delete Unit
La Delete Unit permette di cancellare uno o più oggetti di una determinata entità.
Una volta specificata l’entità sorgente che rappresenta l’entità da cancellare, si specificano quali oggetti dell’entità andranno rimossi e ciò avviene tramite un link in ingresso che trasporti l’informazione per identificare l’oggetto da rimuovere.
31
Nella Figura 26 si vede un esempio di utilizzo tipico di una Delete Unit. All’utente viene presentata una lista di Indirizzi, l’utente cliccando sul link a fianco dell’oggetto che intenderà rimuovere farà scattare il link e la Delete Unit che rimuoverà l’Indirizzo con l’identificatore ricevuto tramite il link. In caso di errore nella rimozione, la unit farà accedere alla Error Page tramite link KO (nell’esempio vuota), in caso di rimozione effettuata tramite link OK si tornerà alla pagina iniziale con il caricamento della Index Unit priva dell’oggetto rimosso.
Figura 26: Esempio di utilizzo di una Delete Unit
2.8.4 Modify Unit
La Modify Unit permette di aggiornare uno o più oggetti di una determinata entità.
Una volta specificata l’entità sorgente che rappresenta l’entità da modificare, si specifica quale oggetto dell’entità sarà oggetto della modifica e ciò avviene tramite un link in ingresso che trasporta l’informazione. Oltre a ciò in ingresso andrà specificato anche un link che trasporti i nuovi valori degli attributi per l’oggetto destinazione dell’operazione di modifica.
Figura 27: Notazione per Modify Unit
Nella Figura 28 si mostra il tipico utilizzo di una Modify Unit. Nella Entry Unit Modifica Indirizzo si precaricano i dati dell’oggetto da modificare (l’oggetto in questione è l’indirizzo caricato dal DB tramite la Data Unit Indirizzo da modificare, che va in ingresso anche alla Modify Unit tramite link di trasporto, per passare l’informazione di quale oggetto sarà modificato). Quando l’utente avrà apportato le modifiche necessarie ai
32
singoli attributi, cliccherà sul link uscente dalla Entry Unit che farà attivare la Modify Unit. Il link uscente dalla Entry Unit avrà specificato l’accoppiamento agli attributi da modificare.
Figura 28: Esempio di utilizzo di una Modify Unit
2.8.5 Connect Unit
La Connect Unit permette di creare nuove istanze di una relazione.
Più precisamente, una Connect Unit si applica ad uno dei possibili ruoli di una relazione e crea una o più istanze del ruolo della relazione che connette alcuni oggetti dell’entità sorgente con alcuni oggetti dell’entità destinazione.
Figura 29: Notazione per Connect Unit
L’esempio di Figura 30 mostra il caso di una creazione di un indirizzo e in cascata la connessione tra l’indirizzo creato e l’utente caricato tramite la Data Unit Scheda Tutore. In caso di fallimento di una delle due operazioni si accede ad una pagina di errore. Tra la creazione e la connessione in caso di successo si passa attraverso il link OK l’identificatore dell’oggetto creato che verrà usato per la connessione con l’oggetto Tutore.
33
Figura 30: Esempio di utilizzo di una Connect Unit
La Connect Unit realizza sul DB la relazione tra gli oggetti, in particolare mette in relazione le chiavi degli oggetti. Nel caso di una relazione n-aria da ambo le parti della relazione, ogni connessione aggiunge una tupla in una tabella di connessione con le chiavi affiancate dei due oggetti.
2.8.6 Disconnect Unit
La Disconnect Unit permette di cancellare le istanze di una relazione. Più precisamente, una Disconnect Unit si applica ad uno dei possibili ruoli di una relazione e rimuove le connessioni tra alcuni oggetti dell’entità sorgente e alcuni oggetti dell’entità destinazione.
Figura 31: Notazione per Disconnect Unit
L’esempio di Figura 32 mostra un uso tipico di una Disconnect Unit. Vengono visualizzati gli indirizzi del Tutore selezionato e cliccando su uno si attiva il link che disconnette l’oggetto Indirizzo con il Tutore. Nel caso di successo e quindi di percorrenza del link OK si caricherà di nuovo la pagina con un indirizzo in meno per il tutore selezionato.
In realtà l’oggetto non è stato rimosso dal DB in quanto non si è fatto uso di una Delete Unit: solamente la relazione con il Tutore in esame è stata rimossa. Si può comunque accedere all’indirizzo scelto e nulla vieterebbe di riassegnarlo al Tutore in un secondo momento tramite una Connect Unit.
34
Figura 32: Esempio di utilizzo di una Disconnect Unit
La Disconnect Unit realizza sul DB la rimozione di relazioni tra oggetti, in particolare, nel caso di relazioni tra entità di tipo n-ario da ambo le parti, la disconnect rimuove, dalla tabella ponte che mette in relazione le chiavi delle due entità, la tupla relativa alle chiavi degli oggetti implicati nell’operazione di disconnessione.
35
2.9 Modello Presentazionale
Il modello esprime l’aspetto grafico della pagina, indipendentemente dal dispositivo di output e dal linguaggio di rappresentazione, per mezzo di una sintassi XML astratta.
Le specifiche di presentazione sono, o specifiche della pagina, o generiche. Nel primo caso impongono una specifica rappresentazione di una pagina ed includono riferimenti espliciti ai contenuti della pagina stessa (es. impongono il layout grafico del titolo e della copertina di tutti gli elementi presentati nella pagina); nel secondo, sono basate su modelli predefiniti ed indipendenti dal contenuto specifico della pagina e si riferiscono ad elementi dal contenuto generico (per esempio, impongono il layout grafico di tutti gli attributi di un oggetto generico incluso nella pagina).
Abbiamo due aspetti distinti per il processo WebML presentazionale:
• disposizione delle unit nella griglia di pagina e scelta degli elementi da visualizzare;
• stili grafici da applicare alla pagina e alle Unit della pagina, sono definibili tramite modelli HTML e fogli di stile XSL.
Il primo aspetto del modello Presentazionale si effettua con la composizione delle pagine del sistema, componendole tramite l’inserimento delle Unit di Contenuto in una griglia dinamica. Questo permette di scegliere posizione e relazioni delle Unit che andranno a popolare l’interfaccia utente. Questo è un aspetto presentazionale/composizionale. Il risultato grafico effettivo si ottiene con l’applicazione degli stili ai vari elementi:
• Site view: quando si applica uno stile ad una intera site view, di default viene applicato a tutte le pagine che la compongono, se non hanno uno stile definito ad hoc;
• Pagina: stile applicato ad una singola pagina;
• Unit: stile di presentazione della singola unit. Di default tutte le unit di un tipo possono avere lo stesso risultato grafico e in casi particolari si può scegliere di renderne qualcuna visivamente distinta dalle altre.
36
Tramite il tool Web Ratio che implementa la progettazione WebML e le varie fasi di sviluppo, abbiamo, per la fase di Presentazione, la possibilità di specificare il risultato grafico dell’applicazione su più livelli:
• Page layout: Rappresenta lo stile di presentazione delle pagine che non riguarda gli elementi WebML. Si specificano due aspetti principali:
o Le varie locazioni dove gli elementi WebML possono essere posti. In pratica si definisce la sezione della pagina HTML dinamica, dove verranno posizionate le varie Unit di contenuto definite nel modello Composizionale;
o La posizione delle risorse statiche che compongono la pagina. Esempio possono essere i posti per i link, i banner, le cornici di pagina ecc;
• Unit Layout: Specifica del risultato grafico delle Content Unit. Si articola in più aspetti:
o Unit Frame: Il risultato grafico del box contenente la Unit; o Unit Core: Il risultato grafico degli elementi interni alla Unit,
come i campi dei form e le righe di una Multi-Data unit; o Unit look & feel: Una serie di regole CSS che definiscono le
regole di formattazione degli elementi definiti ai due punti precedenti.
• Attribute, field grid e link presentation: Si possono definire gli stili per sotto-elementi delle unit di contenuto. Un esempio è quello dei field dei Form che possono avere più risultati HTML a seconda del tipo. Nell’applicazione sviluppata, per esempio, i campi del form di sola lettura compaiono grigi e tridimensionali con scritta in bianco, mentre i campi in scrittura sono bidimensionali e bianchi.
37
3
Estensioni UML per il Web
3.1 Introduzione
L’UML standard non si adatta bene alla modellazione di Applicazioni Web. In particolare la parte relativa alla progettazione della comunicazione tra client e Web Server e la descrizione dei componenti più diversificati, che compongono un’applicazione di quel tipo, ne risultano esclusi.
Come vedremo nel Capitolo 4, l’UML standard risulta comunque di fondamentale importanza per la descrizione dei gruppi di utenti, dei Casi d’uso o dei Diagrammi di Sequenza. E’ comunque di basilare importanza per tutte le fasi a monte della definizione dei Class Diagram, i quali bene si prestano alla progettazione di software Object Oriented, ma non altrettanto per la progettazione di un sistema particolare e specifico come una Applicazione Web.
[16] [17] L’estensione di UML per le Applicazioni Web (WAE Web Application Extension di Jim Conallen) ci consente di rappresentare le pagine Web e altri elementi del modello, significativi dal punto di vista architetturale, insieme alle “normali” classi del modello. Soltanto usando questa estensione siamo in grado di descrivere accuratamente il sistema con un modello e di mantenere tracciabilità e integrità. Un’estensione UML è espressa in termini di stereotipi, valori etichetta (tagged value) e vincoli. Questi meccanismi, usati congiuntamente, ci permettono di creare nuovi tipi di elementi costruttivi utilizzabili nel modello.
• Stereotipo: Estensione del vocabolario del linguaggio, permette di associare un significato semantico nuovo ad un elemento del modello; si usa rappresentarlo come una stringa tra parentesi angolari << e >>. Può anche essere rappresentato tramite una nuova icona;
• Valore etichetta: E’ un’estensione di una proprietà del modello. La maggior parte degli elementi del modello ha proprietà associate. Un valore etichetta è la definizione di una nuova proprietà che può essere associata a un elemento del modello. Si rappresentano come stringhe racchiuse da parentesi tonde;
• Vincolo: Estensione della semantica del linguaggio che specifica sotto quali condizioni il modello può essere considerato ben formato, serve per specificare le modalità di assemblaggio degli
38
elementi del modello. I Vincoli si rappresentano come stringhe racchiuse tra una coppia di parentesi graffe { e }.
La modellazione avviene secondo due punti di vista diversi, ma complementari:
• Descrizione astratta, logica: Descrizione vicina a quella fornita tramite il WebML, gli elementi sono simili e anche le possibili descrizioni di interazione;
• Descrizione dei componenti: Si legano le astrazioni definite nella descrizione logica ai file fisici del sistema eseguibile. Inoltre si descrivono i moduli che costituiscono il sistema eseguibile.
Nota: Per brevità si indicherà l’UML esteso di Conallen con la sigla WAE e il processo di specifica WebML con l’acronimo WebML.
3.2 Interfaccia Utente
In una fase preliminare deve avvenire la descrizione dei casi d’uso e i vari diagrammi delle attività legate ai singoli casi d’uso. Questi aspetti non verranno dettagliati in modo particolare nella presente sezione, si può far riferimento al Capitolo 4 perché non si discostano dalle normali attività dell’ingegneria del software. Qui verranno spiegate le nuove modalità di progettazione dell’interfaccia utente e della progettazione dell’applicazione tipiche della realizzazione delle Applicazioni Web.
Una delle prime attività, risulta quindi, l’analisi del modello dei casi d’uso e l’identificazione degli oggetti che implementano il comportamento in essi descritto. Questa fase è identificabile con l’analisi dei casi d’uso, ed è la base dell’analisi dei requisiti.
Aspetto innovativo introdotto da Conallen è quello del gruppo UX, il quale si occuperà di definire il look-and-feel dell’applicazione e fornire schermate d’esempio. Questo compito risulta, in parte, di pertinenza dei grafici. Per quanto riguarda la progettazione in senso stretto, aspetto di interesse, si farà uso dell’UML per modellare i percorsi di navigazione tra le pagine. E’ un elaborato di primaria importanza dal punto di vista architetturale. I diagrammi prodotti rappresentano la struttura logica delle schermate e la mappa dei percorsi di navigazione.
39
Si identificano tutti i percorsi legali e attesi dell’applicazione. Questa mappa per piccoli siti Web viene di norma fatta a mano e senza l’uso di formalismi precisi. Nel nostro caso, per la progettazione di grandi Applicazioni Web, si richiede l’utilizzo di un formalismo basato su UML.
3.2.1 Modellazione con UML
Nel seguito vengono descritti, a titolo di esempio gli elementi base del formalismo WAE.
Una schermata è rappresentata come una classe stereotipata UML con lo stereotipo <<screen>>. Il nome della schermata è usato come nome di classe e la descrizione della schermata viene usata come descrizione della classe. Le schermate, come gli altri elementi UML possono essere organizzate in package, sulla base di confini identificati in base alle funzionalità fornite.
Figura 33: Notazione per una Schermata
Nella Figura 33 si vede un esempio di notazione per una schermata. I contenuti statici, per esempio etichette testuali e immagini, non sono significativi dal punto di vista architetturale e non sono pertanto considerati nel modello. Anche la struttura o la disposizione dei contenuti, non viene considerata nel modello, almeno in questa fase. I contenuti dinamici vengono enumerati come attributi della classe.
40
Nella Figura 34 si vede il caso di una schermata che comprende un carrello virtuale (cart). In essa compaiono gli attributi per la visualizzazione come array per indicare la possibilità che il carrello sia composto da più prodotti ordinati. Altra modalità possibile è quella che i prodotti siano elencati in una classe a parte e siano raggruppati tramite una relazione di composizione alla schermata. Questa seconda possibilità è mostrata nella Figura 35.
Figura 35: Modellazione con relazioni di composizione
I comportamenti delle schermate sono modellati come operazioni sulla schermata.
Nella maggior parte dei casi si tratta di operazioni invocate dall’utente sulla schermata per alterare lo stato della schermata o lo stato del sistema. La convenzione è di indicare queste operazioni con una semplice frase imperativa in cui il soggetto implicito è la schermata.
Le operazioni che producono come unico risultato la navigazione verso una diversa pagina non dovrebbero essere incluse nella lista delle operazioni della schermata. Tali operazioni dovrebbero essere più propriamente modellate come associazioni verso la schermata di destinazione (il risultato è simile ai link inter-pagina del WebML).
41
Figura 36: Comportamento rappresentato come operazioni
3.2.2 Flusso delle schermate
La maggior parte delle Applicazioni Web fornisce le proprie funzionalità attraverso la navigazione tra le diverse schermate e i percorsi tra le schermate che partecipano agli scenari sono un elemento architetturale chiave. I percorsi di navigazione sono modellati come delle associazioni tra schermate (si veda la Figura 37).
Figura 37: Notazione per la navigazione tra schermate
3.2.3 Input dell’utente e Mappa di navigazione
Nel presente modello è importante descrivere tutti i campi di input e opzionalmente, i tipi di controlli ad essi associati.
Le form di input sono modellate con una classe stereotipata con <<input
form>>. I campi sono modellati come attributi e può essere opzionalmente
attribuito loro un nome tipo quello del controllo di input associato. Il form può essere modellato come classe associazione o come classe inclusa (si vedano la Figura 38 e la Figura 39).
Associazione Inclusione
Figura 38: Form con associazione Figura 39: Form con inclusione
42
Altro passo da seguire, successivamente alla definizione delle schermate, è quello della scrittura dello storyboard.
Lo storyboard comprende il susseguirsi delle istanze delle schermate in un processo di navigazione. Non risulta particolarmente espressivo, alle volte è meglio modellare tale situazione come diagramma di sequenza UML. Attraverso la mappa di navigazione non si mostrano i dettagli delle singole schermate e, qualora risulti appropriato, le classi possono essere rappresentate con le icone associate agli stereotipi. Risulta un diagramma di navigazione tra le pagine del sistema, le pagine sono schematizzate come icone delle quali non si mostrano attributi o operazioni, lo stesso dicasi per i form. L’aspetto principale risulta quello delle associazioni direzionali che caratterizzano il flusso effettivo della navigazione. Si possono aggiungere informazioni come :
• Visibilità della Schermata : $ nel caso di pagina navigabile e raggiungibile da ogni altra parte del sistema, aggiunto in coda al nome;
• Pagine a scorrimento: + in coda al nome per descrivere pagine il cui contenuto verrà presentato su più schermate successive;
• Notazioni per SSL.
Questi simboli sono un possibile esempio e non sono propri dello standard UML esteso WAE.
3.3 Progettazione, descrizione Logica
Le estensioni UML per la modellazione di Applicazioni Web consentono la definizione di nuovi componenti:
• Pagine Client; • Pagine Server; • Form;
• Associazioni tra le pagine. 3.3.1 Interfaccia Utente
Si introduce il concetto di User Experience model (o modello UX), questo aspetto viene usato per descrivere il gruppo e le attività degli specialisti
43
responsabili del mantenimento della consistenza dell’interfaccia utente con i paradigmi correntemente usati e, cosa più importante, di garantire che l’interfaccia sia appropriata per il contesto nel quale il sistema dovrà operare.
Il gruppo UX è responsabile della definizione del look-and-feel dell’applicazione, della determinazione dei percorsi di navigazione dell’applicazione e della gestione/organizzazione della struttura del contenuto delle pagine.
Alcuni degli elaborati prodotti dal gruppo UX sono:
• Schermate e descrizione dei conenuti; • Storyboard associati agli scenari;
• Percorsi di navigazione tra le schermate.
Gli aspetti di presentazione grafica non sono di interesse e non verranno approfonditi. Nella sezione successiva verranno descritti gli aspetti di notazione UML per la rappresentazione di Form, Pagine Cient e Pagine Server.
3.3.2 Vista Logica
La vista logica di un diagramma UML consiste principalmente in classi, relazioni e collaborazioni. Per le classi stereotipate si userà la notazione con l’icona in alto a destra della classe. L’estensione WAE definisce tre stereotipi primari per le classi e alcuni stereotipi per le associazioni. La progettazione di questa fase è di competenza del gruppo di ingegnerizzazione.
Server page
Una pagina server rappresenta una pagina Web che ha contenuti costruiti dal server ad ogni richiesta. Tipicamente, una pagina server contiene script eseguiti dal server che interagisce con risorse lato server come basi di dati, logica di business e sistemi esterni. Le operazioni dell’oggetto rappresentano le variabili che sono visibili nella pagina (accessibili a tutte le funzioni nella pagina).
44
Figura 40: Notazione per Pagina Server
Client Page
Un’istanza di una pagina client è una pagina Web formattata in HTML ed un misto di dati, presentazione e persino logica applicativa. Le pagine client sono visualizzate dai browser client e possono contenere script che sono interpretati dal browser. Le funzioni della pagina client corrispondono a funzioni nelle etichette di script nella pagina. Gli attributi della pagina client corrispondono a variabili dichiarate nelle etichette di script della pagina e sono accessibili da qualsiasi funzione nella pagina (visibilità a livello di pagina). Le pagine client possono avere associazioni con altre pagine client o server.
Figura 41: Notazione per la Pagina Client
Form HTML
Una classe stereotipata come <<form>> è un insieme di campi di input che sono parte di una pagina client. Una classe form corrisponde direttamente al tag <<form>> di HTML. Gli attributi di questa classe rappresentano i campi di input per un modulo HTML (input box, text area, radio button, check box e hidden field).
Una <<form>> non ha operazioni, poiché non è possibile incapsulare operazioni in un modulo. Qualunque operazione che interagisce con il modulo è proprietà della pagina che contiene il modulo, nel caso in esame la pagina che contiene il form.
