Analisi comparativa di metodologie per la progettazione di applicazioni Web: WAE e WebML

Transcript

1 UNIVERSITÀ DEGLI STUDI DI TRENTO Facoltà di Scienze Matematiche, Fisiche e Naturali Corso di Laurea triennale in Informatica Elaborato finale Analisi comparativa di metodologie per la progettazione di applicazioni Web: WAE e WebML Relatori: Proff. Marchese Maurizio Dott. Ricca Filippo Laureando: Stedile Luana Anno Accademico

2 Indice 1. Introduzione 7 2. La modellazione con WAE Introduzione Progettazione interfaccia utente (UX Model) Progettazione e descrizione dei componenti Stereotipi per le classi Stereotipi per le associazioni Esempi di utilizzo Modellazione della sessione La modellazione con WebML Introduzione Modello dei dati Modello di derivazione Modello di ipertesto Elementi chiave del modello di ipertesto Composizione del modello Gestione dei contenuti Modellazione di utenti e gruppi Modello di presentazione Tools Tools per la modellazione con WAE Rational Rose VisualUML Tool per la modellazione con WebML WebRatio 50 2

3 5. WAE e WebML, alcuni esempi a confronto Esempi di modellazione dei contenuti di un applicazione Web con entrambe le metodologie Esempio di modellazione di pagina AND Esempio di modellazione di pagina OR Esempio di modellazione di un percorso fra pagine Esempio di modellazione di pagine con Form Esempio di modellazione di pagine con Scroll Soluzioni per completare le due metodologie Utilizzo del modello UX Utilizzo del tool WebRatio Case study: Pubblicare Facile Web Scopo del progetto Descrizione del progetto originale Pubblicare Facile Descrizione del progetto Pubblicare Facile Web Modellazione con la metodologia WAE Il modello UX L implementazione dell applicazione Modellazione con la metodologia WebML WebML solo a livello di modellazione Manutenzione/Evoluzione dell applicazione Gestione degli utenti con WAE Gestione degli utenti con WebML Confronto fra le due metodologie Studio della nuova metodologia Metodo di modellazione dei contenuti Metodo di approccio ai costrutti più complessi Capacità di manutenzione ed estensione Soluzioni per gli sviluppatori Conclusioni e sviluppi futuri 104 Riferimenti 107 3

4 Indice delle Figure: Figura 2.1: Rappresentazione stereotipo <<screen>> 13 Figura 2.2: Rappresentazione stereotipo <<input form>> 13 Figura 2.3: Esempio di modellazione UX 14 Figura 2.4: Esempio di modellazione UX (Gioielleria Web) 15 Figura 2.5: Rappresentazione stereotipo <<client page>> 16 Figura 2.6: Rappresentazione stereotipo <<server page>> 17 Figura 2.7: Rappresentazione stereotipo <<form>> 17 Figura 2.8: Rappresentazione stereotipo <<frameset>> 17 Figura 2.9: Rappresentazione stereotipo <<target>> 18 Figura 2.10: Esempio applicazione Studente 20 Figura 2.11: Esempio applicazione Ricerca Album 21 Figura 2.12: Esempio applicazione Visualizza Album 21 Figura 2.13: Esempio applicazione Album 22 Figura 2.14: Esempio di modellazione stereotipo <<session>> 23 Figura 3.1: Rappresentazione Entità Attributi 25 Figura 3.2: Rappresentazione Relazione 25 Figura 3.3: Rappresentazione data unit 28 Figura 3.4: Rappresentazione multidata unit 28 Figura 3.5: Rappresentazione index unit 28 Figura 3.6: Rappresentazione Hierarchical index unit 29 Figura 3.7: Rappresentazione Multi-choice index unit 29 Figura 3.8: Rappresentazione scroller unit 30 Figura 3.9: Rappresentazione entry unit 30 Figura 3.10: Esempio di pagina 31 Figura 3.11: Esempio di area con pagine landmark, default e home 32 Figura 3.12: Esempio di pagina END 32 Figura 3.13: Esempio di pagina OR 33 Figura 3.14: Esempio di link inter-pagina non contestuale 34 Figura 3.15: Esempio di link intra-pagina contestuale 35 Figura 3.16: Rappresentazione set unit 36 Figura 3.17: Rappresentazione get unit 36 Figura 3.18: Esempio di site view 37 Figura 3.19: Rappresentazione create unit 39 Figura 3.20: Rappresentazione delete unit 40 Figura 3.21: Rappresentazione modify unit 40 Figura 3.22: Rappresentazione connect unit 41 Figura 3.23: Rappresentazione disconnect unit 41 Figura 3.24: Rappresentazione operation unit 42 Figura 3.25: Rappresentazione login unit 42 Figura 3.26: Rappresentazione logout unit 43 Figura 3.27: Rappresentazione change group unit 43 4

5 Figura 4.1: Stereotipi WAE del tool Rational Rose 45 Figura 4.2: Visuale del tool Rational Rose 46 Figura 4.3: Pannello delle specifiche del tool Rational Rose 46 Figura 4.4: Stereotipi WAE del tool VisualUML 47 Figura 4.5: Visuale del tool VisualUML 48 Figura 4.6: Pannello delle specifiche del tool VisualUML 48 Figura 4.7: Organizzazione delle viste del tool VisualUML 49 Figura 4.8: Visuale del tool WebRatio: modello dei dati 51 Figura 4.9: Visuale del tool WebRatio: modello di ipertesto 52 Figura 4.10: Pannello per la connessione del database del tool WebRatio 52 Figura 4.11: Visuale del tool WebRatio: modello di presentazione 53 Figura 5.1: Schema E-R del database per gli esempi Album 54 Figura 5.2: Schermata esempio pagina AND 55 Figura 5.3: Modello WebML per l esempio di pagina AND 56 Figura 5.4: Modello WAE per l esempio di pagina AND 57 Figura 5.5: Schermata esempio pagina OR 58 Figura 5.6: Modello WebML per l esempio di pagina OR 59 Figura 5.7: Modello WAE per l esempio di pagina OR 60 Figura 5.8: Schermata esempio di sequenza di tre pagine 61 Figura 5.9: Modello WebML per l esempio di sequenza di tre pagine 62 Figura 5.10: Modello WAE per l esempio di sequenza di tre pagine 63 Figura 5.11: Schermata esempio pagina con form 64 Figura 5.12: Modello WebML per l esempio di pagina con form 64 Figura 5.13: Modello WAE per l esempio di pagina con form 65 Figura 5.14: Schermata esempio pagina con scroll 67 Figura 5.15: Modello WebML per l esempio di pagina con scroll 67 Figura 5.16: Modello WAE per l esempio di pagina con scroll 68 Figura 5.17: Modello UX per l esempio di pagina con form 70 Figura 5.18: Assegnazione di attributi con il tool WebRatio 71 Figura 6.1: Visuale generica di Pubblicare Facile Web 74 Figura 6.2: Modello WAE per l applicazione Pubblicare Facile Web 75 Figura 6.3: Modello UX per l applicazione Pubblicare Facile Web 77 Figura 6.4: Videate in esecuzione dell applicazione Pubblicare Facile Web 79 Figura 6.5: Modello WebML per l applicazione Pubblicare Facile Web 80 Figura 6.6: Modello WAE con modifica per l applicazione Pubblicare Facile Web 84 Figura 6.7: Modello UX con modifica per l applicazione Pubblicare Facile Web 86 Figura 6.8: Videate della modifica in esecuzione dell applicazione Pubblicare Facile Web 87 Figura 6.9: Schema E-R per la gestione degli utenti di WebML 87 Figura 6.10: Modello WebML della site view Pubblicare Facile 88 Figura 6.11: Modello WebML della site view Login 88 Figura 6.12: Tabelle per la gestione degli utenti con WebML 91 Figura 6.13: Pannello Deployment configuration dialog del tool WebRatio 92 Figura 6.14: Barra degli strumenti del tool WebRatio 92 Figura 6.15: Videate della modifica in esecuzione dell applicazione generata da WebRatio 93 Figura 6.16: Videata della pagina di logout generata da WebRatio 94 5

6 Indice delle Tabelle: Tabella 2.1: Stereotipi per le associazioni WAE 19 Tabella 5.1: Punti deboli e di forza di WAE e WebML 69 Tabella 6.1: Composizione del codice dell applicazione Pubblicare Facile Web 78 Tabella 6.2: Composizione del codice dell applicazione Pubblicare Facile Web dopo l aggiunta della login 86 Tabella 7.1: Caratteristiche e differenze delle metodologie WAE e WebML riguardanti lo studio e l introduzione delle due metodologie 96 Tabella 7.2: Caratteristiche e differenze delle metodologie WAE e WebML riguardanti il metodo di modellazione dei contenuti 97 Tabella 7.3: Caratteristiche e differenze delle metodologie WAE e WebML riguardanti il metodo di approccio ai costrutti più complessi 99 Tabella 7.4: Caratteristiche e differenze delle metodologie WAE e WebML riguardanti il metodo di manutenzione/estensione 101 Tabella 7.5: Soluzioni per gli sviluppatori 103 6

7 1. Introduzione La crescita e la capillare diffusione del Web hanno fatto nascere una nuova generazione di applicazioni caratterizzate da una relazione diretta tra il business e il cliente. In questi ultimi anni, le applicazioni Web sono divenute un ingrediente fondamentale per le nostre attività lavorative, sociali e relazionali. Le nuove aree di applicazione interessano domini che variano dai siti Web per organizzazioni private e pubbliche, al commercio elettronico, alle librerie digitali, ai corsi a distanza, ai portali, fino ad arrivare alle comunità virtuali. Le interfacce Web sono considerate da molti, se non da tutti, come lo strumento più potente per un efficace presentazione e diffusione dell informazione, in quanto il suo utilizzo determina una serie di vantaggi: o La diffusione delle informazioni avviene in modo naturale grazie ai Web Browser senza bisogno di particolari (e costose) installazioni hardware e software. o L utilizzo dei siti Web è diventato di uso popolare in quanto l utente non trova difficoltà ad interagire con il computer grazie alle nuove interfacce Web userfriendly. o La combinazione di testi, immagini, suoni e video permette una semplice rappresentazione dei concetti o L uso degli hyperlinks rende naturale e flessibile l accesso alle informazioni. Le applicazioni Web sono utili in vari ambiti, economici, sociali, di ricerca, ecc., ma al tempo stesso sono molto complesse da realizzare e difficili da mantenere sempre aggiornate e funzionanti. Le principali cause che rendono difficile la realizzazione e la manutenzione delle applicazioni Web sono da ricercare in molteplici cause: o nelle tante soluzioni tecnologiche disponibili (HTML, linguaggi di scripting, linguaggi server side, Content management system, e-learning, Common Gateway Interface, ecc.); o nel fatto che le applicazioni devono essere aggiornate frequentemente per soddisfare i bisogni sempre crescenti dei clienti; o nel fatto che le applicazioni dovrebbero, per questioni di business, essere sempre funzionanti (24 ore, 7 giorni su 7 e 365 giorni all anno). Una corretta modellazione nell ambito del ciclo di vita delle applicazioni Web risulta fondamentale per cercare di contrastare almeno in parte le tante difficoltà di progettazione e manutenzione. Alcuni studi recenti [19] indicano che la qualità delle applicazioni disponibili in Internet non è soddisfacente sotto diversi punti di vista. Molte applicazioni Web di pubblico dominio sono state create non tenendo presente le differenze tra software tradizionale ed applicazioni Web introducendo così alcuni problemi di grado di controllo e di contenuti [26]. Il differente grado di controllo riguarda le azioni, i servizi e l esplorazione rese possibili all utente. Mentre nei software tradizionali il progettista decide quali azioni rendere disponibili, ad esempio disattivando alcune voci dal menu, nel Web questo non è possibile. Nel Web le informazioni sono esplorabili a partire da qualsiasi pagina e qualsiasi azione è possibile in ogni momento. Mentre i software hanno a che fare soprattutto con funzionalità, il Web è un mezzo basato essenzialmente sul contenuto. Questo fatto pone 7

8 problemi di design nuovi e del tutto assenti nel software. Inoltre, a rendere la fase di design ancora più complessa, i contenuti spesso sono prodotti da fornitori esterni indipendentemente dai graphic designer e dagli interaction designer. [25] è un interessante esempio di come le informazioni spesso vengano fornite in maniera del tutto generica, con dati poco intuitivi e codici incomprensibili. Spesso i progettisti modellano le applicazioni Web sulla base della loro conoscenza individuale, applicando metodologie standard utilizzate nella modellazione delle applicazioni tradizionali. Tali metodologie risultano spesso inadeguate per modellare: o la visualizzazione dei contenuti; o la capacità di mettere a disposizione servizi utilizzando un front-end ipertestuale [15]. Attualmente è forte l'esigenza di trovare una notazione chiara ed efficace per rappresentare le funzionalità dei componenti front-end e la loro iterazione, allo scopo di generare diagrammi e documenti di specifica/design. Negli ultimi anni, proprio per colmare questa lacuna, sono state proposte, da alcuni ricercatori, nuove tecniche di design specifiche per il Web. Tra queste metodologie forse le più importanti sono WAE [3] e WebML [7]. Lo scopo di questa tesi è proprio quello di analizzare e confrontare le metodologie WAE e WebML. In particolare, l obbiettivo della tesi è quello di: o studiare in modo approfondito le due metodologie; o descrivere le varie viste/diagrammi e gli elementi costituenti; o analizzare i pattern più usati nella costruzione di applicazioni Web; o far emergere i punti di forza e i punti deboli delle due metodologie esaminate; o progettare un case-study ( Pubblicare Facile Web ) con entrambe le metodologie in modo da comprenderle meglio e valutare eventuali ipotesi sperimentali; o studiare, usare e valutare i tools disponibili; o dare alcuni consigli di utilizzo ad eventuali sviluppatori (in particolare capire quando usare l una o l altra a seconda dei casi e delle varie tipologie di applicazioni). Il lavoro svolto nella tesi ha messo in evidenza le potenzialità espressive ma anche le lacune dei due linguaggi WAE e WebML. Esso ha inoltre permesso di identificare gli strumenti possibili per l implementazione delle applicazioni Web mettendo in risalto due punti di vista diametralmente opposti. WAE permette una modellazione specifica e dettagliata della parte server, aiutando il programmatore ad implementare e a mantenere, in maniera manuale, l applicazione Web. WebML permette una modellazione intuitiva ed espressiva della parte client rendendo possibile una visione astratta dell applicazione Web. Inoltre l associazione della metodologia WAE con il tool WebRatio permette la generazione automatica del codice. Con le informazioni raccolte e con gli esempi studiati è stato possibile delineare una serie di consigli che aziende e sviluppatori potranno utilizzare per creare le loro applicazioni Web. 8

9 La tesi è strutturata nel seguente modo: Il primo capitolo introduce la metodologia WAE. Verranno presentati la descrizione del linguaggio, le modalità di progettazione e le fasi di sviluppo. In particolare ci soffermeremo sulla progettazione dell interfaccia utente e sulla progettazione e descrizione dei componenti. Il secondo capitolo introduce la metodologia WebML. Verranno presentati la descrizione del linguaggio, le modalità di progettazione e le fasi di sviluppo. In particolare ci soffermeremo sul modello relazionale, quello di ipertesto e quello di presentazione. Inoltre verranno introdotti i principali pattern utilizzati dal linguaggio in modo standard, le operazioni sui dati e la gestione dei gruppi. Il terzo capitolo presenta alcuni CASE tool che supportano il processo di progettazione delle due metodologie. In particolare verranno presentati Rational Rose e VisualUML per la progettazione con WAE e WebRatio per la progettazione con WebML. Il quarto capitolo mostra, utilizzando entrambe le metodologie, i pattern tipici delle applicazioni Web. I pattern si possono riassumono in quattro tipi principali: pagine AND, pagine OR, pagine con form e pagine con scroll. Per ognuno di questi sono descritti i modelli WAE e WebML prendendo in considerazione: o il livello di organizzazione delle pagine; o il lato client (specifica del contenuto e della composizione della pagina visualizzata); o il lato server (specifica del codice, degli attributi e dei metodi utilizzati); o la specifica di navigazione; o il livello di astrazione. Infine in base alle osservazioni raccolte verranno proposte alcune soluzioni per completare le due metodologie aggiungendo alle stesse elementi e viste nuove. Nel quinto capitolo viene descritto il case-study Pubblicare Facile Web anch esso progettato utilizzando entrambe le metodologie. Verranno descritti i due modelli prendendo in considerazione, oltre i punti proposti nel capitolo precedente, anche i seguenti: o migrazione di un applicazione già esistente verso il Web; o utilizzo di un pattern MVC [12] (Model View Controller) per l implementazione della nuova applicazione Web; o utilizzo di una base di dati per la gestione e la creazione di nuove informazioni. o gestione dell upload di un file; o creazione di un oggetto di tipo sessione. Successivamente verrà proposta anche una modifica da effettuare al nostro caso di studio Pubblicare Facile Web anch essa modellata con entrambe le metodologie. In particolare, verranno mostrati i due modelli considerando: o la capacità delle due metodologie di estendere un applicazione Web già esistente; o la capacità delle due metodologie di aiutare il programmatore nelle fasi di manutenzione/evoluzione; o come si comportano le due metodologie con la gestione degli utenti. Alla fine di questo capitolo ci soffermeremo sull utilizzo di WebRatio e sulla sua capacità di generare automaticamente il codice. 9

10 Nel sesto capitolo, tenendo in considerazione le pubblicazioni lette e considerando gli esempi fatti nei capitoli precedenti, i pattern modellati e il nostro caso di studio, verrà condotta un analisi comparativa delle due metodologie. Nello specifico WAE e WebML verranno confrontate sui seguenti punti: o studio della nuova metodologia o metodo di modellazione dei contenuti o metodo di approccio a costrutti complessi o capacità di manutenzione ed estensione I risultati ottenuti dopo il lavoro di analisi e confronto verranno presentati alla fine del capitolo in forma riassuntiva come tabella. 10

11 2. La modellazione con WAE 2.1. Introduzione UML (Unified Modelling Language) [1] è un linguaggio utilizzato nella fase di design diventato standard nella realizzazione di modelli per la rappresentazione astratta dei sistemi software. L enorme successo di questo linguaggio è dovuto soprattutto alla sua capacità di estensione e quindi di adattamento verso nuove tecnologie. Questo suo aspetto ci aiuta anche nella modellazione delle applicazioni Web. Esse, infatti, introducono il concetto di comunicazione tra client e server al quale UML non fornisce un immediata rappresentazione. Jim Conallen presenta un estensione del linguaggio UML, chiamato WAE, per la modellazione delle applicazioni Web. In questo capitolo introduciamo il lavoro di Jim Conallen per modellare le applicazioni Web tramite l estensione del linguaggio UML [3]. Il linguaggio WAE (Web Application Extension) [2], introduce nuovi stereotipi, constraints e tagged values per rappresentare le pagine Web in termini di classi e oggetti. Supponiamo di usare come esempio una semplice applicazione Web composta unicamente da una pagina JSP. Una pagina JSP tipicamente è composta da codice eseguibile sul lato server e da HTML che specifica la formattazione della pagina visibile sul lato client. UML non fornisce nessun modo immediato per rappresentare una pagina JSP così composta. Se vogliamo rappresentare questa pagina con UML otteniamo un unica classe che non rappresenta la relazione tra pagina JSP generatrice e pagina JSP generata. Oltre all ambiguità del ruolo abbiamo anche un problema connesso allo sviluppo della pagina. Visto che di solito la persona che si occupa del codice è diversa da quella che si occupa della grafica del sito con una rappresentazione in UML è difficile capire qual è la parte che spetta al programmatore e quale al designer. Proprio per ovviare a questo problema Conallen ha introdotto nuovi stereotipi. Grazie all estensione proposta da Conallen è possibile dividere le due componenti fin dalla fase di modellazione dell applicazione ottenendo due o più stereotipi per una sola pagina. In sostanza il modello WAE espande il linguaggio UML introducendo nuovi elementi utilizzabili nella modellazione del progetto dell applicazione Web. I nuovi elementi sono: o Stereotipo: è un estensione al vocabolario del linguaggio; associa un significato semantico nuovo ad un elemento. Si può rappresentare nel seguente modo: <<stereotipo>>. Vedremo più avanti che sono state introdotte nuove icone per poter rappresentare alcuni elementi specifici delle applicazioni Web; o Tagged Value: detti anche valori etichetta; Un valore etichetta è la definizione di una nuova proprietà che può essere associata ad un elemento del modello. Si rappresentano con una stringa racchiusa da parentesi tonde; o Constraint: vincolo in italiano; specifica sotto quali condizioni il modello può essere considerato ben formato, serve per specificare le modalità di assemblaggio degli elementi del modello. I vincoli si rappresentano come stringhe racchiuse tra una coppia di parentesi graffe. 11

12 Nella sua prima versione la modellazione WAE era basata unicamente sulla descrizione dei componenti, modellando i componenti fisici che completano l applicazione Web. In seguito è stata introdotta una descrizione per specificare in maniera più precisa l interfaccia utente. In definitiva, oltre ai classici diagrammi UML (Use Cases, Class diagrams, Activity diagrams, ecc), sono state aggiunte due nuove viste: o Progettazione interfaccia utente: detto UX model; rappresenta ad alto livello come l applicazione dovrà essere vista dall utente; o Progettazione e descrizione dei componenti: modella l applicazione Web in base agli elementi che la compongono, sia dal punto di vista client che dal punto di vista server (corrisponde al Class diagram nella modellazione UML di applicazioni tradizionali). Di seguito vedremo nel dettaglio i due tipi di modelli che estendono il linguaggio UML Progettazione interfaccia utente (UX Model) L UX model (user experience) [3] o modello della navigazione consiste nel rappresentare ad alto livello come l applicazione dovrà essere vista dall utente. Si rappresentano le schermate, le maschere e i percorsi di navigazione. Tale modello si disegna con un diagramma delle classi che rappresenta le schermate e le associazioni tra queste. L insieme del modello rappresenta il percorso di navigazione. A questo scopo, si introducono tre nuovi stereotipi di classe: o Schermata (<<screen>>) o Parti di schermo (<< screencompartment >>) o Input form (<<input form>>) Screen È l astrazione della pagina così come viene vista dall utente. Gli attributi sono i dati dinamici che vengono visualizzati dall utente. I dati statici non vengono mostrati. I metodi sono le operazioni necessarie a cambiare lo stato dell applicazione. Vi sono alcune convenzioni: o Nomi classi: si scrivono con la lettera maiuscola e devono indicare lo scopo della pagina; o $: pagina a cui si può accedere da qualsiasi altra pagina (per esempio la Homepage). Sono le pagine che saranno sempre raggiungibili da una barra di navigazione generale; o +: indica una sequenza di pagine con la stessa struttura ( scrollable ). Per loro natura queste pagine devono avere tra i loro metodi la funzionalità di next e di previous che permettono la navigazione all interno delle informazioni che sono state divise in più pagine. Nella Figura 2.1 vengono mostrati due esempi. Una pagina Album che mostra un elenco di titoli di album, i titoli possono variare ad esempio in base a una ricerca effettuata in precedenza, quindi l attributo array che contiene i titoli viene inserito. Il risultato della ricerca potrebbe essere di molti titoli e quindi viene inserito il simbolo +. Una pagina Home con la convenzione $ non ha al suo interno attributi in quanto è una pagina iniziale statica. 12

13 Screencompartment Figura 2.1 Una schermata può essere composta da più parti di schermo; ad esempio banner o parti comuni a più pagine che si scorporano in classi a parte. Più comunemente queste parti di schermata sono conosciute come frames e vengono usate ad esempio per creare menù comuni a tutte le pagine, header dell applicazione Web, ecc. Input form È la pagina che permette l iterazione con l utente. Gli attributi rappresentano i dati inseriti dall utente che possono cambiare lo stato dell applicazione. Rappresentano i campi della form e sono utilizzati dall applicazione nei metodi per le operazioni richieste dall utente. La input form però non ha al suo interno definizioni di metodi: è lo screen associato che ha i metodi che utilizzano le informazioni della form, tra questi è necessario un Submit che permette l invio dei dati. Nella Figura 2.2 viene mostrata la rappresentazione dello stereotipo input form. Una form RicercaAlbum con tre campi compilabili dall utente per effettuare una ricerca. Figura 2.2 La costruzione dello UX Model parte dalle schermate e dalle input form che sono state individuate e introduce i cammini di navigazione tra di esse in termini di associazioni tra schermate o input form. In particolare, si individuano due tipi di cammini: statici e dinamici. o Un cammino statico è composto da semplici links, senza nome, tra pagine che non modificano lo stato dell applicazione. Va ricordato che la notazione $ consente di non mostrare tutti i link; o I cammini dinamici, al contrario, sono percorsi che avvengono ogniqualvolta l utente invoca uno dei metodi definiti in una schermata. L UX Model è molto utile associato alla normale progettazione di applicazioni medio-grandi in quanto specifica i possibili percorsi di navigazione. Infatti, sopratutto in presenza di particolari pattern (come l MVC, Model View Controller [12] ), questo aspetto nella progettazione dei componenti, viene spesso perso di vista. 13

14 Nella Figura 2.3 viene mostrato un esempio di modellazione UX. Dalla pagina statica Home si può accedere tramite ad un link ad una pagina di ricerca album che contiene un input form. Se la ricerca ha successo si visualizza una terza pagina Album con la lista degli album trovati, altrimenti si ritorna alla pagina di ricerca RicercaAlbum. Figura 2.3 Nella Figura 2.4 viene mostrato un secondo esempio di modellazione UX. L esempio mostra la modellazione di una piccola gioielleria Web. La pagina statica Home è composta da due parti di schermo che rappresentano due frame. Il primo frame contiene una input form che permette di effettuare una ricerca rapida sui prodotti solo con una parola chiave. Il secondo frame si presenta come una pagina statica e mostra una presentazione della gioielleria. Dalla seconda <<Screen Compartment>> PresentazioneGioielleria possiamo accedere ad una pagina che permette all utente di effettuare una ricerca dettagliata. La screen RicercaDettagliata ingloba una form con diversi campi; questi possono essere compilati dal cliente in svariati modi e permettono di cercare il prodotto desiderato in modo mirato. Entrambe le ricerche mostrano il risultato nella screen RisultatoRicerca che a seconda del numero degli elementi trovati può essere suddivisa in più pagine poste in sequenza (rappresentato con il simbolo + ). Da quest ultima pagina è possibile scegliere un prodotto e visualizzarne i dettagli. L utente potrà vedere i dettagli del gioiello nella schermata DescrizioneGioiello e potrà decidere se aggiungerlo al carrello. Aggiungendo il prodotto al carrello, l utente visualizzerà quest ultimo in una screen chiamato Carrello da cui può successivamente acquistarlo. L ultima fase serve per acquistare il prodotto, la schermata DatiAcquirente contiene una form per l inserimento dei dati dell utente che vuole effettuare l acquisto. I dati vengono controllati e se l operazione va a buon fine verrà effettuata la notificata (screen AcquistoTerminato ). 14

15 Figura

16 2.3. Progettazione e descrizione dei componenti La progettazione dei componenti consiste principalmente nel rappresentare le classi, le associazioni e le collaborazioni. L estensione WAE definisce nuovi stereotipi per le classi e per le associazioni, introducendo nuove icone per i componenti. I principali componenti sono: o Pagine Client o Pagine Server o Form o Associazioni tra pagine Come vedremo in seguito questi non sono gli unici componenti proposti da Conallen, ma solo i più usati e utili Stereotipi per le classi Stereotipi principali Gli stereotipi principali introdotti dalla metodologia WAE per la modellazione delle applicazioni Web sono tre. I primi due sono la pagina client e la pagina server, il terzo stereotipo invece, è il form. Pagina Client La pagina client ha il compito di rappresentare nel modello la pagina HTML che viene interpretata dal browser. Questa pagina può essere statica oppure generata dinamicamente da un programma eseguito su lato server. Una pagina può inoltre contenere script che vengono interpretati dal browser. Se nella rappresentazione della pagina client vi sono variabili e/o metodi, questi possono essere soltanto variabili e metodi dichiarati nell etichetta dello script in quanto la pagina client non contiene codice. Nella Figura 2.5 viene mostrato lo stereotipo usato per rappresentare la pagina client. Pagina Server Figura 2.5 La pagina server rappresenta nel modello il codice che viene eseguito su lato server. L esecuzione di una pagina server solitamente produce una pagina client. La pagina server tipicamente interagisce con alcune risorse quali ad esempio basi di dati, programmi che implementano la logica di business e sistemi esterni. 16

17 Nella Figura 2.6 viene mostrato lo stereotipo per rappresentare la pagina server. Form Figura 2.6 Lo stereotipo form è utilizzato nel modello WAE per trasmettere i dati inseriti dall utente tra client e server. Questo stereotipo rappresenta la form nel linguaggio HTML. Tipicamente una form è un insieme di campi di input che fanno parte di una pagina client. Gli attributi per questa classe rappresentano i campi di un modulo HTML (input box, text area, radio button, ecc.). La form non ha operazioni, e qualunque operazione che interagisce con il modulo deve stare nella pagina che lo contiene. Nella Figura 2.7 viene mostrato lo stereotipo per rappresentare la form. Altri stereotipi Figura 2.7 Altri stereotipi utili per la modellazione delle applicazioni Web sono il frameset e il target. Grazie al meccanismo dei frames, è possibile visualizzare contemporaneamente più pagine Web nella stessa schermata del browser. Frameset Il frameset rappresenta un contenitore di pagine Web. Ogni frame può essere associato ad un target. Nella Figura 2.8 viene mostrato lo stereotipo per rappresentare il frameset. Figura

18 Target Il target rappresenta la posizione (in pratica il Frame) nella quale la pagina Web deve essere visualizzata. Nella Figura 2.9 viene mostrato lo stereotipo per rappresentare il target. Figura 2.9 Un esempio tipico di un applicazione Web che contiene frame è rappresentato da una videata che contiene due pagine. La prima pagina posizionata a sinistra costituisce un menù con una serie di link che l utente può clikkare. La seconda pagina viene posizionata a destra e muta il suo contenuto in base alle informazioni che l utente desidera ricevere e che sceglie dal menù di sinistra. Si può vedere un esempio guardando la Figura

19 Stereotipi per le associazioni Client pages, server pages e forms, possono essere collegate tra loro tramite associazioni. Anche per le associazioni Conallen ha introdotto nuovi stereotipi. Gli stereotipi delle associazioni e il relativo utilizzo sono i seguenti: Stereotipo <<build>> Descrizione Il programma server genera una pagina client HTML. L associazione, identifica l output HTML di una pagina server. <<submit>> I valori contenuti nella form sono trasmessi al programma server. Quando la risorsa viene richiesta al server, tutti i valori degli attributi associati ai campi del modulo sono inviati assieme alla richiesta per essere successivamente elaborati. <<redirect>> La pagina ridireziona il controllo verso un altra pagina. Un esempio concreto di redirect è il comando HTML refresh. <<forward>> Una pagina delega il lavoro ad un altra pagina. Un esempio è il controller servlet che delega il lavoro ad una pagina JSP. <<include>> Una pagina server include dinamicamente un altra pagina nel corpo del risultato. Questa associazione indica che la pagina inclusa, se è di tipo dinamico, viene elaborata e che i suoi contenuti o risultati vengono utilizzati dalla classe contenitore o classe padre. <<link>> La pagina client contiene dei collegamenti ad altre pagine. Per questo tipo di associazione stereotipata è definito un importante valore etichetta: parameters. Questo valore contiene i parametri passati con la richiesta HTTP; è formattato come stringa e può utilizzare una codifica legata alla specifica implementazione. Tabella

20 Esempi di utilizzo Dopo aver introdotto i principali stereotipi definiti da Conallen vedremo alcuni semplici esempi che serviranno a chiarirne la semantica. Introduciamo brevemente alcuni pattern: o Utilizzo di form per effettuare ricerche, inserimenti, login, ecc; o Rappresentazione delle pagine scroll; o Rappresentazione di pagine con frame. Utilizzo di form per effettuare il login Nella Figura 2.10 è stata modellata una semplice applicazione Studente. Con questo modello, si vuole rappresentare una pagina (Login) che prende in ingresso tramite un form, user e password per la registrazione di uno studente. L applicazione restituisce in una nuova pagina client (PianoStudi) il piano di studio dello studente che si è appena collegato. Da questa pagina è possibile fare il logout tramite un link con parametro. Il parametro passato è assegnato al valore true e il programma server della index esegue il logout. Nel caso di errore viene generata la pagina Login_Fallita. E interessante notare nel modello che la pagina server Login.jsp usa un database (Studenti) per controllare se l utente è registrato o no. Figura

21 Utilizzo di form per effettuare una ricerca Nella Figura 2.11 viene modellata una semplice applicazione RicercaAlbum. Con questo modello rappresentiamo un esempio di ricerca fatta tramite form. La form (RicercaAlbumForm) prende in ingresso o il titolo o l anno o l autore da passare alla pagina server (RicercaAlbum.jsp) per l elaborazione. In base al parametro passato la pagina server effettua la ricerca e restituisce il risultato in una nuova pagina client. La pagina client potrà essere o un elenco dei risultati (in questo caso di titoli di album) o una notifica di Album non trovato. Rappresentazione di pagine scroll Figura 2.11 Nella Figura 2.12 è stata modellata una semplice applicazione VisualizzaAlbum che utilizza una pagina client, una pagina server e una tabella di database esterna. Con questo modello si vuole evidenziare come è possibile modellare lo scrolling tra pagine tramite le associazioni <<link>> denominate prev e next, per accedere alla pagina precedente e a quella successiva. La pagina server si serve di un database esterno per ottenere i dati dell album da visualizzare. Figura

22 Rappresentazione di pagine con frame Nella Figura 2.13 è stata modellata una semplice applicazione Album che utilizza gli stereotipi frameset e target. Con questo modello si vuole illustrare la modellazione di pagine con frame. Il frameset è composto da due pagine, una contenente il menù di tutti gli album e l altra che visualizza l album scelto. Le specifiche [col = 1] [col = 2] determinano la posizione delle pagine all interno del frameset. La prima significa che la pagina verrà visualizzata nella prima colonna (tipicamente quella a sinistra), la seconda che la pagina verrà visualizzata della seconda colonna (tipicamente quella a destra). Possiamo quindi specificare le posizioni delle pagine all interno del frameset come specifichiamo le righe e le colonne per una tabella. I titoli degli album vengono scritti come una lista nel menù di sinistra e sotto forma di link. Ognuno di questi una volta clikkato manda le informazioni di un particolare album alla pagina successiva che ricerca tutte le specifiche da visualizzare all utente nella pagina di destra. Figura 2.13 Abbiamo introdotto questi esempi per chiarire la semantica degli stereotipi introdotti da Conallen e per far vedere come è possibile modellare un applicazione Web tramite WAE. Questi esempi ci serviranno anche in seguito per effettuare il confronto tra WAE e WebML. Vedremo nel Capitolo 3 che WebML utilizza una notazione diversa per rappresentare questi esempi. 22

23 Modellazione della sessione Un concetto importante da tenere presente è quello di sessione. Ogni utente deve avere la possibilità di identificarsi univocamente con l applicazione; quest ultima dovrà essere in grado di tenere traccia delle visite di un singolo utente. La modellazione WAE introduce degli stereotipi per poter modellare questo importante aspetto. La sessione è creata su un oggetto che rappresenta la connessione di un particolare utente. La pagina server così può creare una sessione su un istanza della classe (che implementa l oggetto su cui vogliamo effettuare una sessione), rappresentato con lo stereotipo <<new>>. Per rappresentare il concetto di sessione Conallen ha introdotto anche lo stereotipo di classe <<session>>. Per fare un esempio concreto pensiamo ad un applicazione Web di e-commerce che ha bisogno del concetto di sessione per poter mantenere univocamente il carrello per ognuno dei clienti. Inoltre il carrello dovrà mantenere al suo interno gli oggetti desiderati per tutta la durata della sessione [3]. Nella Figura 2.14 vediamo com è possibile modellare il concetto di sessione con gli stereotipi WAE. L esempio modella una porzione d applicazione di e-commerce; la parte principale è quella che serve per aggiungere prodotti al carrello. Da una form di ricerca (FormDiRicerca), contenuta nella pagina Home, otteniamo una lista di prodotti, ad ogni prodotto è associato un link con parametro che permette l inserimento dello stesso nel carrello. La pagina server che aggiunge il prodotto utilizza (associazione <<use>>) una classe supporto che implementa il concetto di sessione. La sessione viene creata dalla pagina server ElaboraRicerca.jsp. Direttamente nel modello è possibile notare due nuovi stereotipi di associazione utili per creare la sessione (<<new>>) e per aggiungere prodotti al carrello (<<add>>). Figura

24 3. La modellazione con WebML 3.1. Introduzione WebML (Web Modelling Language) [6] [7] [16] è un linguaggio nato specificatamente per la modellazione di Applicazioni Web. Il linguaggio è stato proposto, dopo una lunga sperimentazione condotta sul campo, da un gruppo di ricercatori che opera nel Dipartimento di Elettronica e Informazione del Politecnico di Milano. WebML [8] è un linguaggio ad alto livello che permette la progettazione di Applicazioni Web basate sull uso di dati strutturati; tipicamente di database. In particolare permette di modellare applicazioni medio-grandi in grado di: o Utilizzare una struttura dati per memorizzare, cancellare o modificare contenuti; o Interagire con funzioni interne o esterne per la gestione e la navigazione delle informazioni; o Utilizzare le informazioni della struttura dati per generare dinamicamente pagine Web. Questo tipo di linguaggio si può utilizzare con una base di dati collegata all'applicazione che viene creata appositamente per essa, ma anche con una struttura dati già esistente. In quest ultimo caso è possibile che le primitive di accesso ai dati (che possono essere di vario genere) pongano dei vincoli o delle limitazioni all uso di WebML. In generale la progettazione di Applicazioni Web basata sui dati, viene rappresentata su più modelli che permettono di tenere separata la parte dei contenuti informativi da quella della struttura e navigazione della pagina ed infine da quella di presentazione a livello di stile. Scendendo più in particolare, WebML introduce tre principali modelli estendibili: o Il modello dei dati che esprime l organizzazione e la gerarchia dei dati ed è compatibile con i diagrammi E-R. Può essere esteso con il modello di derivazione (vedi paragrafo 3.2.1) che permette di calcolare nuovi dati; o Il modello di ipertesto che consente di specificare l organizzazione della GUI (utilizzando site view e aree) e la tipologia dell ipertesto (utilizzando pagine, unit e link). È estendibile con il modello di gestione dei contenuti (vedi paragrafo 3.3.3) che permette tramite costrutti di specificare le modifiche dei dati e le integrazioni con altri servizi. Inoltre è possibile definire con la modellazione di utenti e gruppi (vedi paragrafo 3.3.4) molteplici ipertesti sugli stessi dati. Ad esempio, è possibile differenziare l accesso dei visitatori da quello degli utenti registrati oppure da quello degli amministratori. Questi tre tipi di utenti possono interagire con l applicazione in maniera differente tra loro; o Il modello di presentazione che permette di esprimere il layout e i requisiti grafici per il disegno delle pagine Web. Di seguito vedremo i tre modelli nel dettaglio, soffermandoci maggiormente sul modello di ipertesto, interessante per effettuare la comparazione con WAE. 24

25 3.2. Modello dei dati Il modello dei dati esprime in termini di entità, attributi e relazioni la struttura dei dati necessari all applicazione. Per rappresentare i dati WebML non introduce nessuna notazione specifica, ma sfrutta i diagrammi E-R [5] in quanto già consolidati, noti e diffusi. Entità e Attributi Un entità rappresenta un contenitore di dati caratterizzati da una descrizione comune. Spesso sono organizzati in gerarchie. I dati contenuti si dicono attributi, questi sono associati ad un tipo e possono essere definiti come chiave primaria. Le chiavi primarie associate a uno o più attributi identificano univocamente l entità. Alcuni esempi di entità sono album e artista. Le entità vengono rappresentate con un rettangolo contenente nella parte superiore il nome. Alcuni esempi di attributi possono essere nome, cognome, titolo e album, questi nomi vengono inseriti nella parte inferiore della tabella delle entità. Nella Figura 3.1 sono rappresentate due entità con i propri attributi. Relazioni Figura 3.1 Le relazioni rappresentano le associazioni tra le entità. E il progettista che le definisce e ne sceglie il nome. Ad esempio pubblicazione è la relazione che c è tra un artista e un album. Ogni relazione è caratterizzata da ruoli, ognuno dei quali esprime la funzione che ha una delle entità. Un ruolo della relazione può essere visto come un associazione orientata che collega un entità sorgente ad una di destinazione. Inoltre i ruoli delle relazioni possono essere annotati con la cardinalità, che indica il minimo e il massimo numero di oggetti dell entità di destinazione a cui un entità sorgente può essere collegata. Nella Figura 3.2 è rappresentata una relazione (chiamata Pubblica ) fra le entità Album e Artista. Figura

26 Modello di derivazione Il modello di derivazione estende il modello dei dati con lo scopo di ottenere dati calcolati o ridondanti. In particolare WebML adotta un linguaggio di interrogazione basato su OQL (Object Query Language) [4] che permette al progettista di effettuare operazioni di derivazione quali: o Importazione di attributi da un entità ad un altra; o Definizione di attributi calcolati; o Creazione di relazioni derivate concatenando e derivando le relazioni già esistenti. Esempi Introduciamo brevemente alcuni esempi di utilizzo del linguaggio OQL [6]. Entità derivate Un autore italiano è un autore con luogo di nascita pari a Italia. WebML OQL: Value = Autore as A where A.LuogoNascita contains Italia Attributi calcolati o aggregati - prezzototale in Dettaglio come attributo calcolato. WebML OQL: Self.prezzo * Self.qta - prezzototale in Ordine come attributo aggregato. WebML OQL: Sum(Self.Ordine_Dettaglio.prezzoTotale) Relazioni derivate Gli autori che hanno pubblicato libri recentemente WebML OQL: Value = Self.Autore_Libro as L where L.date > 01/01/

27 3.3. Modello di ipertesto La modellazione ipertestuale specifica l organizzazione dell interfaccia di un applicazione Web. WebML vuole rendere tale specifica il più semplice e intuitiva possibile. Per far ciò utilizza moduli ad alto livello per la suddivisione logica che a loro volta vengono suddivisi in sotto-moduli. Inoltre stabilisce una topologia dell ipertesto di ogni modulo in termini di pagine costituite da elementi di contenuto e link che supportano navigazione e iterazione dell utente. La modellazione ipertestuale è una disciplina giovane che manca ancora di alcuni aspetti, WebML cerca di introdurre delle primitive che in un certo senso ereditano dagli schemi E-R la semplicità e l intuizione. In particolare è vista come l estensione del modello Entità-Relazioni che permette al progettista di specificare la modellazione dell ipertesto per la pubblicazione dei dati e la manipolazione Elementi chiave del modello di ipertesto Gli ingredienti chiave di WebML sono le pagine, le unit e i link, organizzati in costrutti modulari detti aree e site view. Gli ultimi due fanno parte di un ulteriore vista detta Composizione del modello. Le unit rappresentano la parte atomica del contenuto delle pagine da pubblicare; offrono vari moduli per la rappresentazione di diversi contenuti e tra questi vi è anche quello che permette la specifica dell inserimento dei dati da parte dell utente. Le pagine vengono modellate combinando unit di vario tipo per ottenere l effetto visivo desiderato. I link servono per collegare pagine e unit creando un effetto ipertestuale. I link permettono di navigare da un punto ad un altro all interno dell ipertesto e abilitano il passaggio di parametri da una unit ad un altra (utili per la generazione delle successive pagine). Le site view sono il raggruppamento di un insieme di pagine e rappresentano un ipertesto coerente per soddisfare un insieme di requisiti. In applicazioni complesse vi possono essere diverse site view. Le aree permettono di decomporre site view complesse in gerarchie, ovvero gruppi di pagine con uno scopo omogeneo. Unit Le unit sono gli elementi che specificano il contenuto di un pagina Web, esse possono essere combinate per rappresentare pagine di complessità arbitraria. WebML supporta sette diversi tipi di unit: o Data unit: mostra i dati di un singolo oggetto; o Multidata unit: mostra i dati di un insieme di oggetti; o Index unit: mostra una lista di dati di alcuni oggetti senza andare nello specifico; o Hierarchical index unit: mostra un indice di elementi organizzati secondo un albero gerarchico; o Multi-choice index unit: mostra una lista di oggetti e ne permette la selezione multipla; o Scroller unit: permette la navigazione di un insieme di dati ordinato accedendo al precedente, al successivo, al primo e all ultimo elemento; o Entry unit: è la unit che modella i form per l inserimento dei dati da parte degli utenti per effettuare ricerche, modifiche e aggiornamenti. 27

28 Data Unit Pubblica i dati di un singolo oggetto di una determinata entità. Alla data unit è possibile associare un selettore che è un predicato che identifica un unico oggetto ed è possibile specificare quali attributi dell oggetto mostrare a video. Nella Figura 3.3 vengono mostrati alcuni esempi di data unit. Le due figure di destra mostrano come è possibile associare un selettore ad una data unit. La figura centrale associa un selettore su di un attributo che ha lo scopo di selezionare l album dal titolo Footlose. La figura a destra associa un selettore di relazione che ha lo scopo di selezionare gli album in base alla relazione che esiste con l artista. Multidata Unit Figura 3.3 Presenta un insieme di oggetti di un entità (ripetizione di data unit). Per la multidata unit è possibile definire un ordinamento che permette la visualizzazione degli oggetti, ad esempio, in ordine alfabetico. Nella Figura 3.4 viene mostrata la rappresentazione WebML della multidata unit. Index Unit Figura 3.4 Presenta un insieme di oggetti di un entità come una lista. La differenza con la multidata unit è che la index è tipicamente usata per selezionare un oggetto da una lista mentre la multidata per la visualizzazione di un insieme di oggetti. Nella Figura 3.5 viene mostrata la rappresentazione della index unit. Figura

29 Hierarchical index unit Presenta un indice le cui voci 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. Nella Figura 3.6 viene mostrata la rappresentazione della hierarchical unit. Ad esempio la lista degli album con indentati per ognuna la lista delle proprie canzoni. Multi-choice index unit Figura 3.6 Presenta una lista di elementi; ognuno è associato ad una casella di scelta che permette all utente di selezionare un insieme di oggetti anziché un singolo oggetto. Si utilizza tipicamente per selezionare un insieme di oggetti e visualizzarne successivamente la scheda completa con la multidata unit. Nella Figura 3.7 viene mostrata la rappresentazione della multi-choice index unit. Ad esempio si possono selezionare più album a cui si è interessati per la visione. Scroller unit Figura 3.7 Visualizza i comandi per poter navigare in una sequenza di oggetti (precedente - successivo). Ad esempio mostra in ogni videata N tra tutte le istanze di un entità rendendo la visualizzazione più fruibile. Questa unit ha due proprietà: o 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 viene visualizzato un oggetto per volta; o Il Block window: che specifica l ampiezza della finestra dei blocchi. Quando é specificata indica il numero massimo di blocchi precedenti e successivi al blocco corrente a cui `e possibile saltare direttamente. 29

30 Nella Figura 3.8 viene mostrata la rappresentazione della scroller unit. Nell esempio si possono visualizzare le specifiche di ogni album disponibile all acquisto. Ogni album occupa una pagina e tutti gli album si possono visualizzare in sequenza uno dopo l altro. Entry unit Figura 3.8 Visualizza e gestisce la form che permette l inserimento dei dati da parte dell utente. L input inserito viene usualmente impiegato per: o Effettuare ricerche all interno di un insieme di oggetti di un entità (ad esempio utilizzando parole chiavi); o Fornire parametri alle operazioni di aggiornamento. Ad esempio per effettuare il login, per generare la successiva pagina, ecc. E possibile aggiungere i predicati di validità associati ai campi della form, questo permette di verificarne l ammissibilità. All interno della form i campi possono essere text area di dimensione settabile oppure combo box con valori inseriti manualmente o precaricati dal database. Nella Figura 3.9 viene mostrato come WebML rappresenta le entry unit. L esempio si riferisce ad un operazione di ricerca di un album attraverso titolo e/o anno e/o nome dell artista (attributi non rappresentati nella parte visuale del modello). Figura 3.9 Ogni unit può essere associata ad una specifica testuale. WebML mette a disposizione un linguaggio testuale che permette di specificare proprietà e campi delle unit associate. Ad esempio la entry unit grafica non mostra la notazione dei nomi dei campi. Grazie all introduzione di questo linguaggio testuale questo è invece possibile. Di seguito un esempio di specifica testuale per la notazione grafica della Figura 3.9. EntryUnit Ricerca Album (fields titolo String; nome_artista String; data Date) 30

31 Pagine Le pagine forniscono gli elementi di interfaccia per la navigazione. Gli utenti possono navigare tra le pagine nella sequenza desiderata. La notazione grafica per le pagine, consiste semplicemente in un rettangolo etichettato che racchiude le unit che appartengono alla pagina stessa. Anche alle pagine è possibile associare una specifica testuale e la sintassi è data dal nome della pagina e dalla lista delle unit che la compone. Nella Figura 3.10 viene mostrato un esempio grafico di pagina e la sua specifica testuale. Page Album (units IndiceAlbum, SpecificaAlbum) Figura 3.10 Le pagine sono caratterizzate da alcune proprietà che mettono in evidenza la loro funzione all interno dell applicazione Web. In particolare si possono avere le seguenti tre proprietà: o La Pagina Home: è la pagina all indirizzo di default del sito, che solitamente viene presentata quando l utente si collega all applicazione per la prima volta tramite il login. La pagina Home deve essere unica all interno della site view. Nella specifica grafica la proprietà della pagina Home viene denotata con una H all interno dell icona della pagina; o La Pagina di Default: è la pagina presentata di default quando si accede all area che la racchiude. La pagina di default all interno di un area deve essere unica. Nella specifica grafica la proprietà di default di una pagina viene denotata con una D all interno dell icona della pagina; nella specifica testuale viene aggiunta la parola chiave default; o La Pagina Landmark: è la pagina raggiungibile da tutte le altre pagine o aree all interno del modulo che la racchiude (la site view oppure una super-area). Nella specifica grafica la proprietà landmark viene denotata con una L all interno dell icona della pagina; nella dichiarazione testuale viene aggiunta la parola chiave landmark. Nella Figura 3.11 viene mostrato un esempio di pagina Home, di pagina Default e pagina Landmark. 31

32 Figura 3.11 Con le notazioni appena descritte possiamo modellare gran parte delle applicazioni Web, ma non tutte. Per modellare l organizzazione 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 sotto-pagine. Le pagine annidate possono essere di due tipi: o Le pagine annidate in forma congiuntiva (sotto-pagine AND, Figura 3.12): vengono usate in modo analogo al concetto di frame; dividono la pagina in porzioni, una delle quali rimane fissa e l altra mostra le informazioni variabili in base ai comandi dell utente; o Le pagine annidate in forma disgiuntiva ( sotto-pagine OR, Figura 3.13): vengono usate per specificare che certe porzioni dello schermo possono contenere insieme di unit alternative, ognuna modellata come una pagina alternativa. Nella Figura 3.12 viene mostrata una rappresentazione di pagina AND. Dal menù di sinistra è possibile scegliere l album da visualizzare attraverso due indici; quello delle novità e quello dell archivio. Figura

33 La specifica testuale per l esempio della Figura 3.12 è la seguente: page Esterna (and-pages Sinistra, Destra) page Sinistra (units IndiceAlbumNovita, IndiceVecchiAlbum) page Destra (units SpecificaAlbum) Nella Figura 3.13 viene mostrata una rappresentazione di pagina OR. Dal menù di sinistra è possibile scegliere se visualizzare un album oppure un artista. A seconda della scelta, nel frame di destra verrà visualizzata una pagina differente. Figura 3.13 La specifica testuale per l esempio della Figura 3.13 è la seguente: page Destra (or-pages Destra1 default, Destra2) page Destra1 (units DettagliArtista) page Destra2 (units DettagliAlbum) 33

34 Link All interno del modello ipertestuale, WebML fornisce gli elementi per specificare i percorsi navigazionali e le possibili selezioni da parte dell utente. Unit e pagine sono collegate tra loro con link (è un collegamento orientato tra due pagine o due unit). I link possono avere: o un parametro: specifica dell informazione che viene passata dalla sorgente alla destinazione (equivalente al passaggio di attributi tra oggetti); o un selettore parametrico: è un selettore associato ad una unit i cui predicati contengono riferimenti a dei parametri di link. L idea di link proposta da WebML è quindi duplice, in quanto: o Permette la navigazione nell ipertesto; l utente può muoversi da una pagina sorgente ad una destinazione; o Trasporta informazioni da una unit ad un altra, per esempio l identificatore dell oggetto selezionato da un index unit a una data unit che ne mostra i dettagli, oppure l input inserito in una form a un index unit che mostra i risultati della ricerca, o all operazione che effettua la verifica della password. La rappresentazione dei link avviene tramite archi orientati che possono collegare unit e pagine. Anche i link possono essere rappresentati con la sintassi testuale. La sintassi testuale per rappresentare un link include il nome del link definito dall utente e la sua sorgente e destinazione. link PopVersoJazz (from ArtistiPop to ArtistiJazz) Nella terminologia WebML, i link che attraversano i confini delle pagine vengono detti link interpagina, mentre i link la cui sorgente e la cui destinazione appartengono alla stessa pagina vengono detti link intra-pagina; i link che trasportano informazione sono detti contestuali; se non trasportano informazione sono detti non contestuali. Nella Figura 3.14 viene mostrato un esempio di link inter-pagina non contestuale. Figura

35 Nella Figura 3.15 viene mostrato un esempio di link intra-pagina contestuale. La unit Lista Album contiene un elenco di album con ad esempio il titolo. Il link trasporta l informazione dell album assieme al suo identificativo che permette di trovare le informazioni di un specifico album da mostrare nella unit Specifica Album Figura 3.15 L accoppiamento tra la unit sorgente e la unit di destinazione di un link viene rappresentato formalmente da un parametro del link definito sull arco orientato e da un selettore parametrico definito nella unit di destinazione. Un parametro del link è un valore associato a un link tra unit, che viene trasportato, per effetto della navigazione del link, dalla unit sorgente alla unit di destinazione. Un link può essere associato a tanti parametri quanti sono quelli richiesti dalla unit di destinazione. Sintatticamente i parametri multi-valore vengono racchiusi tra parentesi graffe. Oltre a supportare la navigazione dell utente, i link possono essere utilizzati anche per specificare particolari tipi di flussi di informazione tra unit, che avvengono senza l intervento dell utente. Per far ciò WebML introduce due nuovi tipi di link: o Link automatico: link che viene attraversato 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 un qualche criterio euristico, per esempio si può scegliere il primo oggetto di una lista ordinata. La rappresentazione del link automatico è fatta con l aggiunta di una A sopra l arco orientato; o Link di trasporto: sono link usati per trasportare informazioni senza che vengano visualizzati bottoni o ancore clikkabili. E un link che abilita solamente il passaggio di parametri e non la navigazione da parte dell utente. La rappresentazione del link di trasporto è fatta tratteggiando l arco orientato. Parametri globali Come abbiamo visto in precedenza, le informazioni contestuali necessarie all applicazioni Web sono sempre associate ai link. Per questo il concetto di sessione, viene rappresentato tramite parametri globali associate a link di trasporto. L utilizzo di un parametro globale richiede tre passi: la sua dichiarazione, l assegnamento di un valore e l estrazione del suo valore. La dichiarazione di un parametro globale richiede la definizione di un nome, un tipo e un valore di default. La definizione testuale di un parametro globale è data da: 35

36 globalparameter Dati Album (type string; initialvalue "vuoto") Il valore di un parametro viene assegnato tramite una unit specifica, chiamata set unit. Una set unit ha solamente un link in ingresso, a cui viene associato un parametro che contiene il valore da assegnare al parametro globale. Poiché l assegnamento ha effetti globali e diventa visibile a tutte le pagine della site view, graficamente la set unit nello schema ipertestuale viene posizionata al di fuori delle pagine. Normalmente, i link in ingresso di una set unit sono link di trasporto, poichè l assegnamento del valore avviene in modo trasparente per l utente e non sono necessarie ancore. Nella Figura 3.16 viene mostrato un esempio di set unit per creare una variabile globale di sessione che corrisponde all album nel carrello. L album rimarrà all interno del carrello fino alla fine della sessione. Figura 3.16 Il valore di un parametro globale può essere estratto per mezzo della get unit, che può essere considerata l operazione duale della set unit. La get unit non ha link entranti e ha solo un link uscente, che trasporta il valore del parametro; la unit viene posizionata all interno della pagina in cui viene usato il parametro globale, per indicare che il parametro viene estratto per permettere il calcolo di alcune unit locali alla pagina. Nella Figura 3.17 viene mostrato un esempio di get unit. Al momento dell acquisto è necessario richiedere (get) i dati degli album memorizzati nel carrello. Figura

37 Composizione del modello Nel caso di ipertesti complessi WebML introduce un ulteriore gerarchia, utilizzando costrutti come le site view e le aree. Site view Le site view racchiudono un insieme di unit, pagine e/o aree collegate tra loro con dei link. Le site view sono caratterizzate da un nome definito dall utente e sono disegnate come grandi cartelle che contengono il resto della modellazione. La rappresentazione testuale contiene il nome della site view e l elenco delle pagine e/o aree ivi contenute. Nella Figura 3.18 viene mostrato un esempio di site view (Album). La casetta rappresenta la pagina Home e il simbolo L è la pagina Landmark, ovvero la pagina che è raggiungibile da tutte le altre. Figura 3.18 La rappresentazione testuale per l esempio in Figura 3.17 è la seguente: siteview Album (pages Artisti, Artista, Indice Album, Album) 37

38 Aree 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. Alle aree possono essere associate le proprietà landmark e default: o L area di default è la sotto-area a cui si accede di default quando si accede alla super-area che la racchiude. Se l utente naviga un link che punta a una super-area viene trasferito alla pagina oppure alla sotto-area di default; o Un area landmark è un area implicitamente raggiungibile da tutte le altre pagine o aree della site view o della super-area in cui è racchiusa. Le proprietà di essere default e landmark vengono aggiunte alle definizioni testuali e grafiche delle aree, usando la stessa notazione illustrata per le pagine Gestione dei contenuti Per gestione dei contenuti si intende quella parte di elaborazione dati effettuata da particolari operazioni eseguite dall applicazione. Le applicazioni Web spesso effettuano operazioni sui dati (modifica del database), ma non solo, le operazioni possono anche invocare programmi definiti esternamente. L introduzione delle operazioni in WebML è vista come un estensione del modello ipertestuale. In particolare l estensione avviene su due piani: o A livello di Unit: apposite unit permettono di rappresentare le operazioni che sono o manipolazioni di dati oppure l esecuzione di un servizio esterno generico; o A livello di Link: i link uscenti dalle unit che rappresentano operazioni si distinguono in link OK e link KO. I link OK e KO catturano rispettivamente gli eventi di successo e di fallimento e permettono al progettista di scegliere risultati alternativi a seconda del risultato ottenuto. È possibile anche eseguire delle transizioni che sono una sequenza di operazioni atomiche. Una sequenza di operazioni è detta atomica quando, o tutte le operazioni vengono eseguite correttamente, o l intera sequenza viene annullata. Graficamente, una transazione viene rappresentata racchiudendo la sequenza di operazioni in un rettangolo tratteggiato; se un operazione non viene racchiusa all interno di un rettangolo tratteggiato, la singola operazione viene considerata come una transazione. Operazioni predefinite WebML definisce cinque operazioni predefinite che sono le operazioni basilari per la gestione dei dati contenuti nel database. 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. Il risultato della create unit è un nuovo oggetto nel database con i dati passati tramite il link. 38

39 Nella Figura 3.19 viene mostrata la notazione della create unit e un esempio di utilizzo. Figura 3.19 La descrizione testuale completa dell esempio di Figura 3.19 è mostrata di seguito. In particolare vengono esemplificate la create unit e i suoi link OK e KO. EntryUnit DatiArtista (Nome: String, Cognome: String) link versocreateunit (from DatiArtista to CreazioniArtista; parameters PNome:CNome, PCognome:CCognome) CreateUnit CreazioniArtista (source Artista; Nome:=PNome, Cognome:=PCognome) OKLink creaoklink (from CreazioniArtista to OggettoCreato;) KOLink creakolink (from CreazioniArtista to CreazioneArtista;) DataUnit DatiArtista (source Artista; attribute Nome, Cognome) Delete Unit Permette di cancellare uno o più oggetti di una determinata entità. Tramite un link in ingresso, che trasporta l informazione per identificare l oggetto da rimuovere, si specifica l entità su cui operare e gli oggetti dell entità che andranno rimossi. 39

40 Nella Figura 3.20 viene mostrata la notazione della delete unit e un esempio di utilizzo. Modify Unit Figura 3.20 Permette di aggiornare uno o più oggetti di una determinata entità. Tramite un link in ingresso si specificano le informazioni dell entità e dell oggetto da modificare. Utilizzando un secondo link (associato alla entry unit) si specificano i nuovi valori degli attributi da sostituire per la modifica. Nella Figura 3.21 viene mostrata la notazione della modify unit e un esempio di utilizzo. Figura 3.21 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. La connect unit imposta sul database la relazione tra gli oggetti, in particolare mette in relazione le chiavi. 40

41 Nella Figura 3.22 viene mostrata la notazione per la connect unit e un esempio di utilizzo. Disconnect Unit Figura 3.22 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. Se l oggetto non viene rimosso con una delete unit si rimuove solo la relazione. Quindi in seguito si potrebbe ugualmente accedere all oggetto e riassegnarlo con una connect unit. Nella Figura 3.23 viene mostrata la notazione per la disconnect unit e un esempio di utilizzo. Figura

42 Operazioni generiche In WebML le operazione generiche vengono rappresentate con un operation unit. Un operazione è detta generica quando viene eseguita al di fuori del contesto WebML; gli utenti possono interagire con essa fornendo gli input tramite i link in ingresso e dopo la sua esecuzione potrebbero rientrare nell applicazione modellata o generata con WebML ma anche terminare e quindi non ritornarci. Per questo motivo l operazione generica potrebbe non avere alcun link in uscita. In altri casi l operazione può avere i link OK e KO come nelle operazioni predefinite. Nella Figura 3.24 viene mostrato il simbolo utilizzato per le operazioni generiche Modellazione di utenti e gruppi Figura 3.24 WebML introduce la possibilità di modellare una comunità di utenti (visitatori, clienti, partner, amministratori, ecc). Per far ciò, distingue due classi di utenti: utenti registrati e utenti non registrati. I primi hanno un identità nota all applicazione, che persiste oltre la durata della singola sessione di navigazione (ad esempio con un processo di registrazione esplicito). I secondi non hanno invece un identità al di fuori della singola durata di una sessione. In modo simile, WebML distingue due classi di site view: pubbliche e protette. Le prime sono accessibili a tutti gli utenti, senza controllo. Le altre richiedono che l utente fornisca le proprie credenziali per potervi accedere. Login Unit Permette di implementare il controllo degli accessi e verificare l identità di un utente che accede al sito. Questa operazione ha due parametri fissi (nome utente e password), i cui valori devono essere forniti in input tramite un link. L operazione di login controlla la validità dell identità di un utente e, se ha successo, lo porta nella home page della sua site view di default. Se le credenziali non sono valide, l operazione di login porta l utente a una pagina di errore tramite il link KO. Nella Figura 3.25 viene mostrata la rappresentazione della login unit. Figura

43 La descrizione testuale dell operazione di login di Figura 3.24 è la seguente: login OperazioneLogin (parameters Username:=PUser, Password:=PPassword;) Logout Unit Permette di eseguire l operazione di logout, che viene utilizzata per invalidare la sessione di un utente. L utente una volta che ha eseguito l operazione di logout viene portato ad una pagina di default accessibile alla sola visitazione e non protetta. L operazione di logout non ha input e output, e può essere invocata tramite un semplice link non contestuale. Nella Figura 3.26 viene mostrata la rappresentazione per la logout unit. Change group Unit Figura 3.26 Si tratta di un operazione che riceve in ingresso un singolo parametro ( l ID di un gruppo, che è il suo identificatore) e trasferisce l utente alla pagina home della site view di tale gruppo. Se l utente corrente non è un membro del gruppo passato in input all operazione di change group si verifica un errore. Quindi viene ceduto il controllo a una pagina predefinita che include una maschera di input in cui l utente ha la possibilità di autenticarsi con delle credenziali differenti. Nella Figura 3.27 viene mostrata la rappresentazione per il change group unit. Per questo tipo di unit è necessario il pattern specificato nella figura. Figura

44 3.4. Modello di presentazione Per esprimere la grafica delle pagine dell applicazione Web, WebML utilizza una sintassi XML astratta. Il modello di presentazione, che si trova al terzo livello nella modellazione con WebML, è indipendente dal dispositivo di output e dal linguaggio di rappresentazione. Abbiamo due aspetti distinti per il modello di presentazione in WebML: o Disposizione Unit: si scelgono gli elementi della pagina da visualizzare e la loro posizione. Le unit che compongono la pagina vengono inserite in una griglia che permette di settare la composizione della pagina che sarà vista dall utente; o Stili grafici: si possono applicare degli stili grafici alle site view, alle pagine e alle unit. Gli stili sono definibili tramite modelli HTML e fogli di stile XSL [17]. In particolare valgono le regole: o 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 un proprio stile definito; o Pagina: stile applicato ad una singola pagina; o 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. 44

45 4. Tools 4.1. Tools per la modellazione con WAE Dato che WAE estende UML, molti tool che permettono la modellazione di applicazioni tradizionali si sono evoluti permettendo anche la modellazione orientata alle applicazioni Web. Solitamente questi tool che estendono UML utilizzano il concetto di stereotipo [18] che permette al progettista di utilizzare durante la progettazione alcune componenti specifiche del Web. In molti casi le icone dei principali stereotipi introdotte da Conallen sono aggiunte ai tools e sono già disponibili all uso. I tools utilizzati durante la tesi sono: Rational Rose [10] e VisualUML [11] Rational Rose Rational Rose Enterprise Edition è un tool sviluppato dall IBM Corporation che supporta i costrutti per la modellazione di diversi diagrammi nello studio delle applicazioni nell ingegneria del software. La versione del Web Modeler del 2003 utilizzata nella tesi è la 3.3. Tra i tanti diagrammi UML modellabili con questo tool noi ci soffermeremo unicamente sui Class Diagram. Il Web modeler permette di inserire nella toolbox gli stereotipi WAE. Grazie a questa barra è semplicissimo disegnare il modello Web desiderato. Basta scegliere il tipo di elemento da aggiungere dalla barra e clikkarci sopra. Successivamente con un secondo click è possibile disegnare lo stereotipo nella parte bianca della schermata. La stessa cosa vale per le associazioni e aggregazioni, queste però vanno trascinate dalla classe mittente a quella destinataria. È possibile inoltre scegliere come far apparire lo stereotipo tra: una decorazione aggiunta alla classe o un icona. Nella Figura 5.1 vengono mostrati i principali stereotipi WAE utilizzati nel tool Rational Rose nelle due varianti possibili. Figura

46 Nella Figura 4.2 viene mostrata una visuale del tool Rational Rose. Nella toolbox sono stati cerchiati di rosso gli elementi che compongono gli stereotipi WAE. Nel foglio destinato alla modellazione è stato disegnato un modello (riferimento Figura 2.9). Figura 4.2 Nella Figura 4.3 viene mostrato il pannello delle specifiche associato ad ogni classe. È possibile notare i principali campi che richiedono il nome, il tipo e lo stereotipo. Tra i pannelli vi è anche una parte riservata alle operazioni e una agli attributi. Figura

47 La versione di Rose utilizzata e descritta permette la modellazione di applicazioni Web grazie agli stereotipi WAE. Quella utilizzata è però ancora una versione in fase di sviluppo, infatti, non tutti gli stereotipi sono presenti in forma di decorazione o icona, ma solo i principali. Questo tool permette di aggiungere nuovi tipi di stereotipi il cui riferimento viene inserito sopra il nome della classe con la sintassi <<nome stereotipo>>. La stessa cosa vale per le associazioni che mostrano lo stereotipo nelle vicinanze della linea che le rappresenta. Un esempio è mostrato in Figura 4.4; lo schema è stato modellato con il tool Rose e gli stereotipi di frameset e target sono stati inseriti dalla schermata delle specifiche in quanto non erano presenti tra quelli predefiniti VisualUML VisualUML è un tool sviluppato da Visual Object Modelers che supporta i costrutti per la modellazione di diversi diagrammi UML nello studio delle applicazioni nell ingegneria del software. La versione utilizzata nella tesi è la 5.23 del Con questo tool è possibile scegliere gli stereotipi degli elementi che costituiscono il modello dal pannello delle proprietà associato. Sono presenti tutti gli stereotipi della modellazione WAE. Per disegnare il modello di un applicazione Web è sufficiente scegliere dalle barre degli strumenti il tipo di elemento da introdurre nel modello (ad esempio classi e associazioni). Clikkando sullo stereotipo mostrato nel pannello laterale, il corrispondente elemento verrà riportato nel modello. Nella Figura 4.4 vengono mostrati i principali stereotipi WAE utilizzati nel tool VisualUML. Figura 4.4 Nella Figura 4.5 viene mostrata una vista del tool VisualUML. Sono visibili le barre degli strumenti (in alto e a lato a sinistra) con i vari elementi che si possono inserire per creare la modellazione desiderata. Nel foglio di lavoro è presente il modello di Figura

48 Figura 4.5 Nella Figura 4.6 viene mostrato il pannello delle specifiche associato ad ogni classe. Ogni volta che si vuole introdurre un nuovo elemento nel modello viene mostrato questo pannello dal quale è possibile scegliere lo stereotipo desiderato. Figura

49 Il modello con gli stereotipi WAE viene modellato nel tool VisualUML nella parte dedicata alla Logical View della progettazione. Ma questa non è l unica vista modellabile con questo tool, infatti VisualUML permette di modellare anche le viste Use Case, Component, Deployment e Dynamic. Tutte queste viste possono essere modellate (con UML) e associate al linguaggio WAE. Selezionando la vista che si desidera modellare le barre degli strumenti cambiano mostrando gli elementi disponibili all utilizzo (quando selezioniamo la Logical View ad esempio ci appaiono nella barra degli strumenti gli stereotipi e le associazioni per creare la vista logica delle classi). Nella Figura 4.7 mostriamo l organizzazione delle viste del tool VisualUML. In rosso la vista Logica dove vengono inseriti i modelli con gli stereotipi WAE. Figura 4.7 L utilizzo di VisualUML è stato intuitivo e semplice, le numerose barre degli strumenti permettono di trovare con semplicità la classe e l associazione desiderata. Il tool possiede inoltre due viste generiche dei modelli; la prima è a pakage (vedi Figura 4.7), ogni cartella contiene gli elementi del modello che possono essere selezionati ed editati, la seconda è un diagramma di navigazione che permette di muoversi velocemente all interno di diagrammi complessi. Entrambe le viste permettono di trovare con facilità i punti e gli elementi da modellare anche se il modello è di grandi dimensioni. L idea su cui si basano Rational Rose e VisualUML è molto simile tra loro, la differenza principale riscontrata nel modellare il diagramma WAE fra i due tool è rappresentata dagli stereotipi. Rational Rose (la versione utilizzata nella tesi 3.3) non possiede ancora tutti gli stereotipi proposti da Conallen mentre VisualUML ha tenuta aggiornata la lista degli stereotipi WAE. Questa differenza si riferisce alla rappresentazione degli stereotipi con l icona poiché entrambi i tool permettono di specificare nuovi tipi di stereotipi (inserendo il <<nome_stereotipo>> sopra il nome della classe). 49

50 4.2. Tool per la modellazione con WebML Associato a WebML c è il tool WebRatio. WebRatio [9] è l unico tool che permette di modellare un applicazione Web usando la metodologia WebML. Metodologia e tool sono nati assieme e si sono evoluti congiuntamente WebRatio Il tool WebRatio è stato sviluppato da un team di ricercatori del politecnico di Milano. Esso è un ambiente di sviluppo che permette la rappresentazione di applicazioni Web utilizzando la metodologia WebML. Il tool permette anche la generazione automatica del codice a partire dal modello. La versione utilizzata nella tesi è la 4.2. WebRatio è concentrato sulla modellazione delle applicazioni Web e in particolar modo sull utilizzo di WebML. A differenza dei tool visti in precedenza questo è specifico per le applicazioni Web. Essendo il tool nato e cresciuto con WebML esso permette di sviluppare i tre modelli della metodologia (dati, ipertesto e presentazione) con tre differenti visuali. Da ogni visuale è possibile passare ad un altra in qualsiasi istante. o Il primo pannello permette di modellare la base di dati e il front-end dell applicazione. Si definiscono entità e relazioni disegnando lo schema E-R e si definiscono aree, pagine e unit utilizzando la metodologia WebML. Ulteriori pannelli dividono il modello dei dati da quello dell ipertesto. I modelli di ipertesto possono essere suddivisi a loro volta in più site view (nel tool rappresentati con ulteriori pannelli); o Il secondo pannello permette di fare il mapping della sorgente dati; o Il terzo pannello permette di definire la presentazione e generare il codice. Viene mostrata la pagina come una griglia dove è possibile posizionare le varie unit definite nelle fasi precedenti. In particolare individuiamo quattro fasi per la progettazione dell applicazione Web con il tool WebRatio. Prima fase: creazione del modello dei dati Nella Figura 4.8 viene mostrata una schermata del tool WebRatio. In particolare la visuale dove è possibile modellare la base dei dati. Il pannello che permette di accedere a questa parte di modellazione è cerchiato in rosso. Da qui è possibile spostarsi tra il pannello (cerchiato di blu) che permette di modellare gli schemi E-R e quelli per la modellazione delle site-view. Cerchiati in verde vi sono i comandi per creare le entità e le relazioni. La parte sinistra del tool mostra la gerarchia degli elementi che costituiscono la modellazione. La parte bassa (sempre a sinistra) permette di inserire le specifiche dell elemento su cui stiamo operando (esempio: il nome cerchiato di viola). Clikkando con il tasto destro del mouse sopra l elemento che si vuole modificare appare una tendina dalla quale è possibile, ad esempio, aggiungere degli attributi. 50

51 Seconda fase: creazione del modello di ipertesto Figura 4.8 Nella Figura 4.9 viene mostrata la visuale dove è possibile modellare l ipertesto dell applicazione Web. I pannelli delle site-view sono cerchiati di blu: è sufficiente spostarsi tra questi per poter modellare le varie viste del sito. Subito sotto a questi pannelli si possono vedere i comandi necessari a disegnare il modello di ipertesto (aree, pagine, unit, ecc). Nella parte sinistra c è la specifica degli elementi inseriti nel modello in forma gerarchica. La parte cerchiata in rosso mostra la cartella Web Model che racchiude gli elementi per la creazione del modello di ipertesto. Nella parte inferiore c è il pannello con le specifiche dell elemento selezionato. Sono cerchiati in verde alcuni esempi di specifiche della entry unit selezionata (nome e campi). Clikkando con il tasto destro del mouse sull elemento desiderato appare una tendina che permette l aggiunta di descrizioni, variabile a seconda dell elemento stesso. Nell esempio si seleziona una entry unit e la tendina mostra le operazioni che si possono fare su questo tipo di elemento (ad esempio aggiungere dei campi alla form). 51

52 Terza fase: aggiunta di un database Figura 4.9 Nella Figura 4.10 viene mostrato il pannello dal quale è possibile connettersi con il database (cerchiato di rosso nella figura di sinistra). Dalla cartella Data Sources è possibile aggiungere il database. Una volta aggiunto si può gestire nel pannello che nel tool si trova in basso a sinistra (vedi la figura a destra) inserendo i parametri necessari per trovare la fonte di dati (nome, tipo di database, driver, ecc). È possibile infine connettersi al database semplicemente clikkando con il tasto destro del mouse sull icona che lo rappresenta nella cartella Data Sources, scegliendo tra le operazioni della tendina il refresh. Figura

53 Quarta fase: creazione del modello di presentazione Nella Figura 4.11 viene mostrato il pannello che permette di modellare la presentazione dell applicazione Web (cerchiato di rosso). Ogni pagina viene mostrata come una griglia dove è possibile posizionare le varie unit. Nel pannello in basso a sinistra è possibile scegliere tutti gli stili di layout (come l impaginazione e la posizione delle unit, i colori, le dimensioni, ecc...). Per ogni possibile personalizzazione, o quasi, ci sono degli ulteriori pannelli dove scegliere i vari stili. Ad esempio nella figura si vede la personalizzazione della index unit: è possibile scegliere lo stile dell elenco da visualizzare. Figura

54 5. WAE e WebML: alcuni esempi a confronto 5.1. Esempi di modellazione dei contenuti di un applicazione Web con entrambe le metodologie Nel presente capitolo verranno modellati alcuni esempi di applicazioni Web con entrambe le metodologie WAE e WebML. Lo scopo è quello di mostrare, affiancando i modelli ottenuti, le principali differenze che vi sono tra le due metodologie. Il confronto fra le due metodologie verrà eseguito su alcuni esempi scelti tenendo in considerazione: o Il livello di organizzazione delle pagine; o Il lato client (specifica del contenuto e della composizione della pagina visualizzata); o Il lato server (specifica del codice; degli attributi e dei metodi utilizzati); o La specifica della navigazione; o Il livello di astrazione. Tutti gli esempi mostrati nel presente capitolo si riferiscono alla gestione e visualizzazione di album e relativi autori. È necessario affiancare all applicazione Web una base di dati che contiene gli attributi utili alla gestione e al prelievo delle informazioni desiderate. In questo caso la soluzione più semplice è utilizzare un database composto da due entità (Album e Autori) con la relazione pubblicare. Il database viene modellato con uno schema E-R e può essere utilizzato sia per la modellazione con WAE che per quella con WebML. Nella Figura 5.1 si mostra lo schema E-R del database utilizzato per gli esempi. Figura 5.1 Gli esempi introdotti e che meglio riassumono i pattern più usati sono cinque e si suddividono in: o Modellazione di pagina AND o Modellazione di pagina OR o Modellazione di un percorso tra più pagine o Modellazione di pagine con form o Modellazione di pagine con scroll 54

55 Esempio di modellazione di pagina AND Il primo esempio vuole rappresentare la modellazione di una pagina AND. Le pagine AND hanno come caratteristica la suddivisione in frames; ogni frame rappresenta una pagina con specifici contenuti. L insieme dei frames compone la schermata visualizzata. In precedenza abbiamo visto che WebML ha un particolare pattern che prevede questo tipo di modellazione, mentre con WAE è necessario utilizzare gli stereotipi di frameset e di target. Descrizione dell esempio 1 Si vuole visualizzare una schermata unica che al suo interno presenta due frame. Il primo frame mostra un elenco di album musicali scanditi in base alla data di pubblicazione. L elenco è suddiviso a sua volta in due: album dell anno corrente e album degli anni passati. Ogni parola dell elenco è un link che una volta clikkato modifica il contenuto del secondo frame. Nel secondo frame vengono visualizzate le specifiche dell album scelto con il menu di sinistra. Nella Figura 5.2 viene mostrato come l utente visualizza la schermata a video dell esempio descritto sopra. Modellazione con WebML Figura 5.2 Nella Figura 5.3 viene mostrata la modellazione di questo primo esempio utilizzando la metodologia WebML. La pagina outermost contiene al suo interno altre due pagine: leftmost e rightmost. La pagina leftmost è composta da due index unit che rappresentano i due tipi di elenco, quello costruito mettendo in relazione l anno corrente e quello con gli album degli anni passati. La pagina rightmost ha una sola data unit che mostra gli attributi estratti dall entità album. I link sono due, ognuno dei quali parte dalla unit che compone la pagina di sinistra. L arrivo dei link è uguale per entrambi; la pagina di destra. Il risultato dell azione di click dei due menu è la stessa nonostante i menù siano differenti, in entrambi i casi si ottengono informazioni su un album. 55

56 Figura 5.3 Con questo modello possiamo rappresentare la composizione delle pagine utilizzando le unit. Queste specificano che il risultato dovrà essere un elenco per quanto riguarda la prima pagina (index unit) e di un insieme di dati (data unit) per quanto riguarda la seconda. In questo caso, l organizzazione è definita solo dal nome della pagina, ma non sempre questa può essere ricondotta alla posizione della stessa sulla schermata. In WebML il posizionamento di pagine e delle rispettive unit avviene a livello di modellazione della presentazione. Per quanto riguarda la parte server, in questo esempio si può notare che non vengono visualizzati i nomi degli attributi che si vogliamo mostrare. Nella index unit non viene specificato qual è l elemento che compone la lista (es. il titolo dell album). Invece per la data unit non viene specificato quale tipo di informazione sull album visualizzare (es. foto, titolo, autore, ecc.). Questo tipo di informazione si può ottenere solamente consultando la specifica di testo prevista da WebML. La specifica di navigazione è piuttosto chiara: viene rappresentata una sola schermata e l unica possibile navigazione è quella di modificare la pagina di destra navigando con il menù di sinistra. Modellazione con WAE Nella Figura 5.4 viene mostrata la modellazione dell esempio utilizzando la metodologia WAE. La schermata è modellata con la classe stereotipata frameset FrameSetAlbum che è generata (<<builds>>) dalla pagina server Anni_Album. Il frameset è composto da due pagine client, una Anni_Album_Menù che rappresenta il menù di sinistra e l altra RisultatoAlbum che rappresenta la pagina con le specifiche dell album di destra. Il link è unico e trasporta il parametro nome_album che servirà alla pagina server per effettuare la ricerca. All interno di tale pagina ci sono i metodi necessari per ottenere le informazioni richieste da visualizzare nella pagina di destra. La classe Anni_Album.jsp è l unica che interagisce con il database e in particolare con l entità Album che viene utilizzata per l estrazione dei dati. 56

57 Figura 5.4 La composizione delle pagine con la modellazione WAE è rappresentata dalle pagine client e dal frameset che specifica il contenuto e il posizionamento delle stesse all interno della schermata. Grazie alla specifica [col = 1] e [col = 2] siamo in grado di gestire le posizioni; la prima significa che la pagina Anni_Album_Menu verrà visualizzata nella colonna di sinistra (la prima colonna), la seconda che la pagina RisultatoAlbum verrà visualizzata nella colonna di destra (la seconda colonna). La specifica della posizione della pagina che si modifica viene fatta sul target. La pagina client RisultatoAlbum ingloba al suo interno il contenuto del target. Con questa rappresentazione però, non riusciamo a rappresentare la composizione del menù. Esso contiene due tipi di elenco, quello con gli album dell anno corrente e quello con gli album degli anni passati, ma nel modello questo non è precisato. La parte server è evidenziata nella pagina Anni_Album.jsp. Essa contiene gli attributi e le variabili necessarie per la ricerca dell album. Gli attributi rappresentano anche gli elementi che verranno visualizzati a video. In realtà, non si specifica che nella pagina Anni_Album_Menu verrà visualizzato un elenco di titoli e che nella pagina RisultatoAlbum verranno visualizzate le informazioni dell album. Queste scelte (quali attributi mostrare, la modalità di visualizzazione, ecc.) sono lasciate all implementazione. Un idea dei potenziali dati da poter utilizzare però ci viene fornita già nel modello ed è data dall elenco degli attributi che la classe utilizza. La specifica di navigazione è più complessa, in quanto le associazioni possono avere più stereotipi che le rappresentano (builds, link, target e inclusione). Non tutte le associazioni però, rappresentano un percorso che l utente può navigare. L unico collegamento visibile e utilizzabile dall utente in fase di navigazione è il link con parametro. Quest ultimo permette di modificare il contenuto della pagina di destra con le informazioni desiderate. 57

58 Esempio di modellazione di pagina OR Il seguente esempio vuole rappresentare la modellazione di una pagina OR. Le pagine OR, come le pagine AND devono essere suddivise da frames. Differentemente dalle pagine AND però, il frame che modifica il suo contenuto modifica anche la pagina, poiché i risultati riguardano due aspetti diversi. In precedenza abbiamo visto che WebML ha un particolare pattern che prevede questo tipo di modellazione, mentre con WAE è necessario utilizzare ancora una volta gli stereotipi di frameset e di target. Descrizione dell esempio 2 Si vuole visualizzare una schermata unica che al suo interno presenta due frame. Il primo frame mostra due elenchi: uno con i titoli degli album e l altro con i nomi degli artisti. Ogni elemento dell elenco è un link che modifica il contenuto del secondo frame. Nel secondo frame vengono visualizzate le specifiche di un particolare album (l album dal nome equivalente al link clikkato) se viene ciccato un elemento del primo elenco, altrimenti vengono visualizzate le specifiche di un artista (l artista dal nome equivalente al link clikkato) se si sceglie un elemento del secondo elenco. Si vuole inoltre, che il frame contenente il menù sia visualizzato a sinistra e quello che mostra le informazioni dell album a destra. Nella Figura 4.5 viene mostrata la schermata video dell esempio 2. Figura

59 Modellazione con WebML Nella Figura 5.6 viene mostrata la modellazione dell esempio 2 utilizzando la metodologia WebML. La pagina outermost contiene al suo interno altre due pagine, leftmost e rightmost. La pagina leftmost è composta da due index unit che rappresentano i due tipi di elenco, quello degli album e quello degli artisti. La pagina rightmost ha a sua volta all interno altre due pagine; la rightmost1 e la rightmost2. Ognuna delle due pagine contiene una data unit: la prima prende le informazioni dalla tabella degli album e la seconda dalla tabella degli artisti. I link sono due, ognuno dei quali ha partenza da una unit che compone la pagina di sinistra. Il punto di arrivo dei link è rispettivamente alla pagina che visualizza le informazioni desiderate, ovvero alla data unit della pagina rightmost1 se si è scelto un link dalla lista degli artisti oppure alla rightmost2 se la scelta è avvenuta dalla lista degli album. Il risultato dell azione di click dai due menu modifica la scelta della pagina da inserire nel frame, poiché ha contenuti differenti. Con il modello WebML possiamo rappresentare la composizione delle pagine utilizzando le unit. Queste specificano che il risultato dovrà essere di un elenco (index unit) per quanto riguarda la prima pagina e di un insieme di dati (data unit) per quanto riguarda le seconde. Anche in questo caso, come per il precedente, l organizzazione e il posizionamento sono definiti solo dal nome delle pagine. Sarà possibile scegliere le posizioni solamente quando verrà definita la presentazione. Anche in questo modello l assenza di attributi non specifica il contenuto delle unit. È sempre possibile però associare la specifica testuale WebML. Se consideriamo la parte server dell applicazione, possiamo notare che i metodi che permettono la ricerca dei dati non vengono specificati. Associati alle unit vi sono le tabelle del database da cui si ricavano i dati ma le operazioni che servono per effettuare l estrazione e l elaborazione non sono rappresentate. La specifica di navigazione dell esempio è chiara. Viene rappresentata un unica schermata e l unica navigazione possibile è quella che permette la modifica della pagina di destra navigando con menù di sinistra. Il doppio link specifica che la pagina di destra verrà cambiata. Figura

60 Modellazione con WAE Nella Figura 5.7 viene mostrata il modello dell esempio 2 utilizzando la metodologia WAE. La schermata è modellata con la classe stereotipata frameset FrameSetAlbumArtisti che è generata (<<builds>>) dalla pagina server Artisti_Album. Il frameset è composto da tre pagine client: una Artisti_Album_Menù che rappresenta il menù di sinistra e le altre RisultatoAlbum e RisultatoArtista che rappresentano la pagina di destra con le specifiche dell album e dell artista rispettivamente. I link sono due ed ognuno trasporta il parametro necessario alla server per effettuare la ricerca. I parametri sono nome_album per effettuare la ricerca sugli album e nome_artista per effettuare la ricerca sull artista. All interno della pagina server ci sono i metodi necessari per ottenere le informazioni richieste da visualizzare nella pagina di destra. La classe Artisti_Album.jsp è l unica che interagisce con il database e in particolare con le entità Album e Artista che sono utilizzate per l estrazione dei dati. Figura 5.7 La composizione delle pagine con la modellazione WAE è rappresentata dalle pagine client e dal frameset che specifica il contenuto e il posizionamento delle stesse all interno della schermata. Grazie alla specifica [col = 1] e [col = 2] siamo in grado di gestire le posizioni; la prima significa che la pagina Artisti_Album_Menu verrà visualizzata nella colonna di sinistra (ovvero la prima colonna), la seconda che la pagina RisultatoAlbum o RisultatoArtista verrà visualizzata nella colonna di destra (la seconda colonna). La specifica della posizione della pagina che si modifica viene fatta sul target. La pagina client RisultatoAlbum o RisultatoArtista ingloba al suo interno il contenuto del target. Con questa rappresentazione però, non riusciamo a rappresentare la composizione del menù. Esso contiene due tipi di elenco, quello con gli album dell anno corrente e quello con gli album degli anni passati, ma nel modello questo non è precisato. La parte server del progetto è evidenziata nella pagina server Artisti_Album.jsp. Essa contiene gli attributi e le variabili necessarie per la ricerca dell album o degli artisti. Gli attributi rappresentano 60

61 anche gli elementi che verranno visualizzati a video. Anche per questo esempio, le specifiche di composizione delle pagine vengono lasciate al programmatore che ha a disposizione l elenco degli attributi. La specifica di navigazione, come nel caso precedente è composta da i due link che cambiano il tipo di pagina e il suo contenuto da visualizzare a destra Esempio di modellazione di un percorso fra pagine Il seguente esempio vuole mostrare una semplice rappresentazione di iterazione tra più pagine. Con gli esempi precedenti ci siamo limitati ad avere più pagine in un unica schermata. Ora vogliamo che l insieme delle pagine costituisca un vero e proprio percorso che l utente può navigare. Descrizione dell esempio 3 Vogliamo rappresentare un applicazione un po più complessa delle precedenti, composta da tre finestre. Ogni finestra è collegata ad un altra ed interagisce con essa per la visualizzazione di nuovi dati. La prima videata mostra le informazioni di un artista, quali nome, cognome, foto, ecc. Da questa finestra è possibile, tramite un link, accedere ad una nuova videata che mostra l elenco dei titoli degli album che l artista ha prodotto. L elenco a sua volta è composto da link; ogni link trasporta il titolo dell album e trasferisce le informazioni in una nuova finestra. La terza e ultima finestra mostra le informazioni dell album scelto (es. titolo, anno, copertina, ecc.). Nella Figura 5.8 vengono mostrate le schermate video dell esempio 3. Modellazione con WebML Figura 5.8 Nella Figura 4.9 viene mostrata la modellazione dell esempio 3 utilizzando la metodologia WebML. La rappresentazione è molto semplice e lineare in quanto composta da solo tre pagine. La prima pagina è composta da una data unit che prende le informazioni dalla tabella Artista del database. La seconda pagina contiene una index unit che prende le informazioni mettendo in relazione l artista con i relativi album (questo è un esempio di unit con selettore). Il risultato è l elenco degli album dell artista selezionato (l identificativo dell artista verrà utilizzato per trovare i corrispettivi album). La terza pagina è composta da una data unit che prende le informazioni dal database Album. 61

62 Figura 5.9 La composizione delle pagine è, ancora una volta, rappresentata dalle unit. Ed essendo le pagine lineari e semplici le unit sono singole in ognuna di esse. La prima e la terza pagina devono mostrare all utente dei dati (data unit), mentre la seconda un elenco (index unit). Gli attributi da visualizzare sono descritti nella specifica testuale prevista da WebML. Ad ogni unit è associata la tabella da cui ricavare i dati; la index unit diversamente dalla data unit ha un selettore. Il selettore specifica il rapporto tra artista e album che ogni elemento della lista risultante deve avere (lista di tutti gli album di un particolare artista). Non vengono però, specificati gli attributi dell album da visualizzare (ad esempio una lista di soli titoli). I metodi per ottenere le informazioni (in questo caso la lista degli album) non sono specificati, ma il selettore sulla index unit fa capire al programmatore che la lista dovrà essere composta da album che hanno una particolare relazione con gli artisti. Nel dettaglio il selettore Artisti2Album identifica gli album appartenenti ad un artista. Introduciamo un nuovo aspetto del lato server. Con questo tipo di modello il programmatore che deve implementare l applicazione Web non ha abbastanza informazioni per decidere come implementare le pagine. In particolare il modello non da nessuna informazioni sul tipo di pagina (statica o dinamica) e sulla tecnologia da usare (Servlet, JSP, o HTML). La specifica di navigazione è semplice, le pagine sono disposte in modo consecutivo e ognuna di esse ha un link uscente verso la pagina di destinazione. Questo modello rende la visualizzazione della navigazione molto realistica e vicina alla sequenza reale che l utente eseguirebbe durante la navigazione. Modellazione con WAE Nella Figura 5.10 viene mostrata la modellazione dell esempio 3 utilizzando la metodologia WAE. La pagina server Artista.jsp genera la pagina client Artista. Dalla pagina Artista parte un link con parametro che porta alla pagina server AlbumXArtista.jsp che genera a sua volta la pagina ListaAlbum. Il parametro del link (nomeartista) è utilizzato dalla pagina jsp per fare la ricerca nel database e trovare gli album collegati all artista selezionato. Dalla pagina client ListaAlbum parte un secondo link con parametro che rappresenta i link di ogni nome dell elenco. Il parametro è il nome dell album che verrà utilizzato dalla pagina server Album.jsp per visualizzare le informazioni dell album scelto nella nuova pagina DettagliAlbum. 62

63 Figura 5.10 Ogni pagina è rappresentata da una pagina server che genera una pagina client. Il problema è che non vi è specificata la modalità in cui le informazioni vengono mostrate. Ma il modo in cui vengono mostrati gli attributi aiuta il programmatore ad effettuare una scelta implementativa. Ad esempio l attributo ListaAlbum della pagina AlbumXArtista.jsp verrà visualizzato proprio come una lista di elementi scanditi dall array. La parte lato server dell applicazione è rappresentata nel modello da tutte le pagine jsp che generano le pagine client. Ognuna di esse contiene gli attributi e i metodi necessari per le operazioni di ricerca nel database e visualizzazione. I link con parametro chiariscono le informazioni trasmesse tra le pagine. Con questo tipo di modello il programmatore che deve implementare l applicazione Web ha abbastanza informazioni per decidere come implementare le pagine Web dell applicazione. Le pagine server infatti possono essere implementate sia come Servlet che JSP mentre le pagine statiche solo in HTML (eventualmente con parti in Javascript). La navigazione è determinata dai link. In questo semplice caso la navigazione nel modello è vicina alla navigazione che l utente effettuerebbe durante la navigazione nel sito. Per prima cosa sono visualizzati i dettagli dell artista, poi l elaborazione passa alla pagina server che genera la lista degli album, che a sua volta fa lo stesso per la visualizzazione dei dettagli dell album Esempio di modellazione di pagine con Form Il seguente esempio (numero 4) mostra una semplice ricerca eseguita tramite form. Come per l esempio 3 ogni pagina costituisce una schermata. La prima contiene un modulo (la form) con cui l utente può 63

64 interagire. È possibile compilare la form per effettuare operazioni, in particolar modo di ricerca, sui dati. La navigazione dunque prende il via in base alla ricerca effettuata. Descrizione dell esempio 4 Vogliamo rappresentare un applicazione composto da tre finestre. Ogni finestra è collegata ad un altra ed interagisce con essa visualizzando nuove informazioni. La prima videata mostra una form composto da tre campi nel quale è possibile inserire del testo e un bottone per sottomettere i dati. L utente può inserire il titolo dell album, il nome dell artista, l anno dell album o una combinazione di questi campi. Da questa finestra è possibile effettuare una ricerca con i parametri inseriti nella form. Il risultato della ricerca è una nuova schermata che mostra l elenco degli album trovati che rispettano i vincoli inseriti dall utente. L elenco a sua volta è composto da link; ogni link trasferisce il titolo dell album alla pagina collegata. La terza e ultima finestra mostra le informazioni dell album scelto (es. titolo, anno, copertina, ecc.). Nella Figura 4.11 sono mostrate le schermate video dell esempio 4. Modellazione con WebML Figura 5.11 Nella Figura 5.12 viene mostrata la modellazione dell esempio 4 utilizzando la metodologia WebML. La rappresentazione è molto semplice e lineare. Il modello è composto da tre pagine ognuna delle quali ha un tipo di unit che la descrive in modo differente. La prima pagina è composta da una entry unit che attende delle informazioni riguardanti gli album. La seconda pagina contiene una index unit che ricerca le proprie informazioni dall entità album. Il risultato sarà l elenco degli album che rispettano i vincoli di ricerca. La terza pagina è nuovamente composta da una data unit che prende le proprie informazioni dalla tabella del database Album. Figura

65 E importante notare che le entry unit rappresentano le form in HTML. Gli attributi da visualizzare devono essere specificati con una specifica testuale prevista da WebML. Gli attributi su cui è possibile effettuare una ricerca non sono specificati nella entry unit. Guardando solo il modello, i metodi per ottenere la ricerca non sono specificati ed inoltre la mancanza dei selettori di ricerca non aiuta il programmatore a capire come implementare la ricerca. Inoltre il designer può capire il tipo e il numero di elementi da inserire nella pagina client (ad esempio, box per il testo, bottoni, ecc). La specifica di navigazione è semplice: le pagine sono posizionate in modo consecutivo ed ognuna di esse ha un link uscente verso la pagina di destinazione. Questo metodo rende la visualizzazione della navigazione molto vicina alla sequenza reale che l utente eseguirebbe durante la navigazione. Modellazione con WAE Nella Figura 5.13 viene mostrata la modellazione dell esempio 4 utilizzando la metodologia WAE. La pagina server CercaAlbum.jsp genera la pagina client CercaAlbum. La pagina CercaAlbum contiene al suo interno una form che viene rappresentato con lo stereotipo form Form_CercaAlbum. La prima schermata mostra la form (su cui l utente può interagire) che trasmette i dati alla pagina server CercaAlbum.jsp tramite una relazione di tipo <<submit>>. La relazione indica che tutti gli attributi della form vengono trasportati alla server. La pagina server utilizza i parametri passati per effettuare la ricerca e modifica la pagina client di uscita CercaAlbum con la lista di album trovati. Dalla pagina client CercaAlbum (che ora contiene la lista degli album trovati) parte un link con parametro che rappresenta i link di ogni nome dell elenco. Il parametro è il nome dell album che verrà utilizzato dalla pagina server AlbumDettaglio.jsp per visualizzare le informazioni dell album scelto nella nuova pagina AlbumDettaglio generata. Entrambe le pagine server utilizzano l entità Album del database per effettuare la ricerca dei dati da mostrare. Figura

66 La prima pagina server, quella a cui si accede per effettuare la ricerca, genera nella stessa pagina client contenuti differenti. Prima genera la form da completare e poi l elenco di album che corrispondono ai requisiti di ricerca. E possibile quindi rappresentare più contenuti in un unica pagina. In questo modo le pagine visualizzate dall utente possono sembrare all occhio del programmatore solamente due. Un attenta lettura del modello però fa capire che la pagina CercaAlbum viene generata due volte: una con la form, l altra dopo l operazione di submit. La parte server dell applicazione è rappresentata da tutte le pagine jsp che generano le pagine client. Ognuna di esse contiene gli attributi e i metodi necessari per le ricerche nel database e le visualizzazioni. Il link con parametro permette di capire il tipo di informazione che viene trasferita tra la pagina mittente a quella di destinazione. L introduzione del nuovo stereotipo per la form introduce anche la possibilità di inserire già nel modello le componenti del modulo di ricerca. Gli attributi della form sono infatti gli elementi con cui l utente può interagire, gli stessi che il designer dovrà predisporre nella pagina client. La navigazione è determinata dai link e dalla submit. In questo modello è possibile perdere traccia del percorso che l utente effettua tra una pagina all altra. La pagina unica CercaAlbum viene visualizzata due volte ed è necessario (se la ricerca non fallisce) fare esattamente questo percorso per ottenere le informazioni volute. La rappresentazione poteva essere fatta anche utilizzando due pagine client, (una per la form e una per il risultato della ricerca) ma anche in questo caso il percorso non era del tutto lineare, poiché la submit si sarebbe riferita sempre ad una pagina server. La stessa pagina server quindi avrebbe generato due pagine client con la relazione <<Builds>> senza segnalare quale delle due si genera per prima Esempio di modellazione di pagine con Scroll Il seguente esempio (numero 5) mostra la rappresentazione di una pagina che contiene elementi la cui visualizzazione è consecutiva. Ogni pagina mostra in dettaglio un argomento. Gli argomenti sono messi in un ordine preciso e ci si può accedere dalla pagina corrente. Questo tipo di navigazione è detta scroll poiché permette la visualizzazione dei dati sfogliando le informazioni desiderate (come ad esempio un album di immagini). Descrizione dell esempio 5 Vogliamo rappresentare una semplice applicazione composto da due finestre: la prima finestra permette di scegliere il primo argomento da visualizzare e su cui in seguito verrà effettuato lo scroll. La prima pagina visualizza un elenco di nomi di artisti. Scegliendo un artista è possibile accedere ad un altra schermata. La seconda schermata mostra i dettagli dell artista scelto, ma allo stesso tempo permette la navigazione verso gli altri artisti. È possibile quindi visualizzare anche il precedente o il successivo artista nell ordine definito dall elenco. Questo tipo di navigazione può essere ripetuto per ogni artista presente nell elenco. 66

67 Nella Figura 5.14 vengono mostrate le schermate video dell esempio 5. Modellazione con WebML Figura 5.14 Nella Figura 5.15 viene mostrata la modellazione dell esempio 5 utilizzando la metodologia WebML. Il modello è composto da due pagine. La prima contiene una semplice index unit che rappresenta la lista degli artisti. La seconda è composta da due unit; una data unit che mostra le informazioni di un artista e una scroll unit che modella la possibilità di passare da un artista all altro. Figura 5.15 La composizione delle pagine è rappresentata dalle unit. Per rappresentare lo scroll, si introduce la nuova unit (scroll unit) che è associata alla data unit (la data unit che contiene le informazioni da visualizzare nelle pagine che compongono l elenco). La seconda pagina contiene due tipi di unit differenti, la scroll unit deve essere associata ad un altra unit che specifica il tipo di informazione da visualizzare. Gli attributi da visualizzare devono essere descritti a parte con la specifica testuale. Per quanto riguarda la navigazione a scroll, è abbastanza intuitivo per il programmatore capire la sua realizzazione. In questo particolare caso non sono necessari particolari attributi e nemmeno particolari metodi poiché sono standard. Lo scroll infatti deve sempre dare la possibilità di muoversi tra le pagine (precedente, successiva, prima ed ultima) Anche la rappresentazione da parte del designer è standard. La specifica di navigazione è semplice: le pagine sono disposte in modo consecutivo ed esiste un unico link che esce dalla prima pagina e arriva alla seconda. Un link interno alla pagina specifica che la navigazione è possibile utilizzando la scroll unit. Questo metodo rende la visualizzazione della navigazione molto vicina alla sequenza reale che l utente eseguirebbe durante la navigazione. 67

68 Modellazione con WAE Nella Figura 5.16 viene mostrata la modellazione dell esempio 5 utilizzando la metodologia WAE. La pagina server VisualizzaArtista.jsp genera la pagina client Lista_Artisti che mostra una lista di nomi di artisti. Dalla pagina Lista_Artisti tramite un link con parametro è possibile accedere alla seconda pagina server Visualizza_Info_Artista.jsp. Questa genera la pagina client InfoArtista che ha dei link uscenti verso la pagina server Visualizza_Info_Artista.jsp. Questi link hanno uno stereotipo particolare associato al <<link>> (next e prev) per indicare lo scroll. Entrambe le pagine server utilizzano il database Artista per estrapolare i dati da visualizzare. Figura 5.16 Ogni pagina visualizzata ha una pagina server che la genera. La seconda in particolare viene generata più volte; una volta per ogni click effettuato dall utente. La composizione della pagina di scroll è definita dalla presenza dei link uscenti dalla pagina client verso la pagina server. La parte server dell applicazione è rappresentata da tutte le pagine jsp che generano le pagine client. Ognuna di esse contiene gli attributi e i metodi necessari per le ricerche e le visualizzazioni. Sono queste ultime ad utilizzare le tabelle del database. Il link con parametro permette di capire quale informazioni sono trasferite tra mittente e destinatario. Nella pagina server Visualizza_Info_Artista.jsp è presente il metodo che permette di implementare lo scroll. La navigazione è determinata in modo naturale dai link. La pagina non cambia, quello che viene modificato è il contenuto interno alla stessa. 68

69 5.2. Soluzioni per completare le due metodologie Dagli esempi proposti sembra emergere che entrambe le metodologie hanno punti di forza e punti deboli. Prima di confrontare le metodologie (vedi Capitolo 7) analizzeremo in dettaglio i punti deboli ed alcune soluzioni possibili. WAE La modellazione con WAE spesso rende difficile la specifica di navigazione. Se vi sono più pagine client generate da una stessa pagina server si perde traccia delle operazioni che l utente può effettuare. Quello che non è chiaro è come ricostruire la sequenza corretta. Quale pagina client viene generata prima?, quale pagina può navigare l utente e in che ordine? è possibile che l utente ritorni sulla stessa pagina?. WebML La modellazione con WebML rende chiara la specifica di navigazione. Le pagine sono posizionate in modo consecutivo e da ognuna di esse partono solo (ad eccezione dei link automatici) possibili percorsi che l utente può fare. Il modello rappresenta esattamente i possibili percorsi che il navigatore potrebbe seguire eseguendo l applicazione. La modellazione con WAE permette di inserire già nel modello attributi e metodi necessari al programmatore e al designer per effettuare le scelte durante l implementazione. Inoltre permette di posizionare i frames all interno di una schermata. La modellazione con WebML non prevede l inserimento di attributi e metodi nelle unit. Questi elementi sono importanti per il programmatore durante l implementazione. Inoltre questa metodologia non permette di posizionare i frames all interno di una schermata. Tabella 5.1 Entrambe le metodologie hanno una soluzione a questi problemi: estendere il modello con viste/specifiche ulteriori. WAE ha introdotto la modellazione dello schema UX [3] che permette di modellare i percorsi di navigazione. WebML associa alla propria modellazione una specifica testuale (di cui abbiamo già parlato nel Capitolo 3). Anche il tool WebRatio [9] (vedi Capitolo 4 ) può essere usato per questo scopo. Tramite il tool è possibile sopperire ad alcune mancanze del modello: WebRatio permette l inserimento degli attributi, le specifiche per i form ed inoltre abilita l utente ad assegnare le posizioni delle unit all interno della pagina. 69

70 Utilizzo del modello UX Il modello UX di WAE permette al designer di specificare la navigazione. In questo modo il programmatore potrà intuire i percorsi di navigazione che l applicazione Web potrà permettere all utente. Il modello UX modella la parte client dell applicazione. Il risultato è quello di avere una visione globale dell applicazione in modo lineare e intuitivo, come se, in un certo senso, stessimo guardando la mappa del sito. Il modello contiene solamente gli elementi visualizzabili dall utente. Per capire meglio il contributo del modello UX, prendiamo l esempio numero 4 e lo completiamo con il nuovo modello. L esempio che meglio si presta al nostro scopo è quello di Figura In questo modo vedremo come il modello UX elimina l ambiguità, dovuta alla presenza di un unica pagina client per contenere due tipi di informazione. Nella Figura 5.17 è rappresentato il modello UX dell esempio numero 4 presentato nel Paragrafo Figura 5.17 Le tre pagine vengono rappresentate con lo stereotipo <<Screen>>. La prima in particolare, contiene al suo interno un <<input form>>. Ognuna delle pagine è collegata con delle associazioni che rappresentano il percorso di navigazione. CercaAlbum è contrassegnata con il simbolo $ per indicare che è raggiungibile da tutte le altre pagine. Inoltre è possibile specificare il percorso da effettuare in caso di successo/insuccesso dell operazione, marcando i collegamenti con il nominativo incomplete per indicare il fallimento dell operazione e successful per indicare il successo. Guardiamo il modello ottenuto utilizzando WebML nella Figura Possiamo notare che le tre Unit in WebML e le tre pagine con lo stereotipo <<Screen>> in WAE sono molto simili. InfoAlbum è comparabile con AlbumUnit, Albums a AlbumIndex e CercaAlbum a AlbumSerch, con la differenza che quest ultima pagina nel modello UX contiene uno stereotipo a parte che è quello dell <<input form>>; mentre nel modello WebML si rappresenta con l apposita Unit di ricerca (entry unit). Si nota che nel modello UX vengono introdotte le parti che devono comporre il form e quindi le variabili su cui viene effettuata la ricerca. Anche le <<Screen>> contengono (solo ed esclusivamente) gli attributi che vengono visualizzati dall utente, cosa che nel modello WebML non è presente. Nel modello delle classi in WAE possono essere presenti anche attributi che servono solo per le operazioni e non vengono successivamente visualizzate dall utente. 70

71 Utilizzo del tool WebRatio WebML è associato in modo molto stretto al tool di sviluppo WebRatio (vedi Capitolo 4). L utilizzo di questo tool permette di associare attributi e selettori tralasciando la specifica testuale. Inoltre è possibile posizionare le unit all interno della pagina. Queste due operazioni, effettuabili grazie al tool, aiutano a risolvere i problemi visti in precedenza. Nella Figura 5.18 vediamo un esempio di assegnazione di alcuni attributi utilizzando il tool WebRatio. La pagina Invoices contiene una index unit Invoices. Nella parte bassa a sinistra del tool è possibile inserire gli attributi che si vogliono mostrare. Clikkando nell apposito spazio Shown Attributes compare una schermata Select Elements da cui è possibile selezionare gli attributi da mostrare (vedi le parti evidenziate in giallo). Figura 5.18 Per quanto riguarda il posizionamento delle unit all interno della pagina ci riconduciamo al Capitolo 4 all esempio in Figura 4.3. WebRatio fornisce la possibilità di generare il codice in modo automatico partendo dalla modellazione. Questo aspetto gestisce l ambiguità della tipologia della pagina. Allo stesso tempo però non elimina del tutto il problema, infatti è possibile che alcuni problemi permangano al momento della manutenzione o nella revisione dell applicazione Web. 71

72 6. Case study: Pubblicare Facile Web 6.1. Scopo del progetto Lo scopo del case study Pubblicare Facile Web è quello di confrontare le due metodologie non solo su esempi semplici ma anche su un applicazione completa. L applicazione presa in esame è di medie dimensioni (vedi Tabella 6.1), ma nonostante questo è composta da molti nuovi punti di studio e di confronto. Grazie alle sue dimensioni è possibile fare un confronto diretto, eliminando le ulteriori complicazioni che comporterebbe un applicazione più complessa. In particolare è possibile inserire gran parte degli elementi che compongono una tipica applicazione Web ed è possibile esaminare vari aspetti, come: o Far migrare un applicazione già esistente verso il Web. Convertire un semplice progetto in un applicazione Web. Punto utile per verificare la capacità di interagire con applicazioni esistenti ed esterne alle due metodologie; o Utilizzare il pattern MVC [12] (Model View Controller) per l implementazione della nuova applicazione Web. Problematica utile per verificare come si comportano le due metodologie se si vuole utilizzare un pattern specifico; o Far affidamento su una fonte dati per la gestione e la creazione di nuove informazioni. Punto fondamentale per vedere come le due metodologie affrontano la questione. o Gestire l upload di un file. Confronto tra le due metodologie sull utilizzo di operazioni esterne ai dati; o Creare un oggetto di tipo sessione. Vedere come le due metodologie affrontano il problema della sessione. Di seguito affrontiamo una descrizione del progetto. Dapprima ci concentriamo sul vecchio progetto Pubblicare Facile esaminandone i requisiti per dare un idea dell applicazione che vogliamo estendere. Successivamente mostriamo i cambiamenti che vogliamo affrontare per eseguire la migrazione, descriviamo i requisiti del nuovo progetto Pubblicare Facile Web. Introduciamo quindi la visuale che vogliamo ottenere e passiamo a modellare l applicazione Web con le due metodologie. Associati ai due modelli vi saranno le descrizioni e le considerazioni osservate Descrizione del progetto originale Pubblicare Facile Chiamiamo con il nome Pubblicare Facile il primo progetto creato durante il corso di Laboratorio di Ingegneria del Software. Lo scopo del progetto era di creare un tool in grado di eseguire delle revisioni stilistiche confrontando alcuni documenti Latex con modelli stilistici assunti dalle case editrici. Queste ultime rappresentano i potenziali clienti del prodotto che viene utilizzato dallo stylereviewer (addetto alla revisione stilistica dei documenti sottoposti alla casa editrice). Il progetto deve dare la possibilità di inserire un documento in formato Latex ed in base ad un secondo file contenente le caratteristiche di stile determinarne la conformità. Il secondo file contiene i requisiti di stile che ogni casa editrice determina, e sono ad esempio per un libro: o Nei titoli, la prima lettera deve essere maiuscola; o Un titolo può avere un numero massimo di caratteri (ad es. 20); 72

73 o Il libro deve contenere un numero minimo di capitoli (ad es. 2), ed un numero massimi di capitoli; o L uso di Itemize prevede di non superare un numero massimo di item (ad es. 15) e di non mettere figure all interno dell itemize; o In una sottosezione c è un numero massimo di figure che si possono includere; o Non vanno inserite citazione all inizio di una frase; o Il libro deve contenere un numero minimo di citazioni (ad es. 5). Il progetto analizza il dominio applicativo considerando diverse tipologie di documenti (libro, technical report, ) ed inoltre è stata progettata un architettura flessibile, che consente di considerare in futuro diversi tipi di documenti. Per queste motivazioni si è utilizzato un file per contenere tutti i vincoli, in modo da poter essere modificato e configurato a piacere facilmente anche dalla stessa casa editrice. Analisi dei requisiti In particolare il tool dovrà permettere di effettuare le seguenti operazioni: o Controllo automatico della conformità di un documento rispetto ai vincoli di stile prendendo in input un file Latex e un file contenente una lista di requisiti di stile configurabile; o Restituire in caso di non conformità la lista degli errori trovati nel documento Latex in un nuovo file; o Eseguire la conversione in formato HTML dei documenti che hanno superato con successo la revisione. Composizione del progetto Per consentire facili sviluppi futuri e per realizzare un sistema di verifica dei vincoli di stile su documenti generici è stato utilizzato il design pattern Visitor [13]. Il codice risultante è composto da una ventina di classi Java: la classe che inizializza il controllo automatico della conformità prende in ingresso come argomento i nomi dei due file da aprire, leggere e confrontare Descrizione del progetto Pubblicare Facile Web Chiamiamo con il nome Pubblicare Facile Web il progetto che estende Pubblicare Facile (paragrafo precedente). Lo scopo del progetto è quello di far migrare il programma esistente verso il Web, trasformandolo in un applicazione Web. Con la nuova applicazione, il cliente (style reviewer) può accedere al servizio offerto da Pubblicare Facile via Web inserendo il path del documento da analizzare. L applicazione procederà all analisi del documento preso in ingresso, controllando e confrontando gli stili utilizzando l applicazione Pubblicare Facile. Dovrà successivamente visualizzare all utente la pagina con il risultato. L utente potrà vedere l esito positivo o negativo tramite la diversa pagina che verrà visualizzata; la lista degli errori nel caso in cui il documento non rispetti i criteri o la notifica della buona riuscita dell operazione in caso contrario. 73

74 Analisi dei requisiti In particolare l applicazione Web dovrà permettere di effettuare le seguenti operazioni in aggiunta al vecchio progetto: o Permettere l inserimento del path del file Latex da controllare attraverso una Form e fare l upload del file; o Visualizzare in una nuova pagina la lista di errori nel caso in cui il file Latex non sia conforme ai vincoli di stile; o Visualizzare in una nuova pagina il file Latex convertito in HTML nel caso in cui il documento sia conforme ai vincoli di stile; o Controllare altri eventuali errori e notificarli al cliente con una nuova pagina; o A partire da tutte le pagine dare la possibilità di ritornare alla pagina di upload. Composizione del progetto L idea è quella di implementare l applicazione Web utilizzando le classi di Pubblicare Facile e facendo in modo che queste interagiscano con l interfaccia Web. Un pattern utile a questo scopo si è rivelato essere il MVC (Model View Controller) [12], che permette di usare l applicazione Pubblicare Facile già esistente come Model della nuova applicazione Web. Il lavoro sarà quello di realizzare il Controller con una Servlet e implementare le pagine che vanno ad interagire con l utente con delle JSP (View). o Pagina di Upload: l utente inserisce il path del file latex da controllare, permettendo l upload del documento e quindi il controllo dello stesso; o Pagina degli Errori: l utente visualizza la lista degli errori riscontrati nel file preso in ingresso e puo tornare alla pagina di upload; o Pagina dell Esito positivo: il documento è conforme e quindi l utente puo accedere alla conversione del proprio file in HTML; o Pagine di Errore: notificano eventuali errori che possono avvenire nelle letture di file o nelle ricerche di pagine. Da ognuna di queste è possibile ritornare alla pagina di upload. Nella Figura 6.1 viene visualizzato in finestre la visuale del client che vorremmo ottenere dopo l implementazione di Pubblicare Facile Web. Figura

75 6.4. Modellazione con la metodologia WAE In questo paragrafo modelliamo l applicazione con la metodologia WAE cercando di rispettare i punti proposti nel Paragrafo 6.1. Vediamo come la metodologia affronta i vari punti. Il lavoro di modellazione con la metodologia WAE è stato eseguito usando il tool VisualUML [11]. In Figura 6.2 vediamo il modello risultato. «Link» «Client Page» +ErroreTrovato Model Name: PubblicareFacileConallen Package Name: Logical View Diagram Name: Main Diagram Type: Class «Builds» «Server Page» +paginadeglierrori.jsp «Forward» «Server Page» +index.jsp «Builds» «Client Page» +index «Form» +uploadform Submit Reset path: text «New» «Use» «Submit» «Forward» «Server Page» +Controller.java page: String path: String dopost( ) doget( ) «Use» «Forward» «Class» +Inizializzazione filel: File filer: File LeggiItemize( ) LetturaLibro( ) LetturaArticolo( ) PrendiCR( ) TOHTML( ) «Class» +FileDiIngresso nomefile: StringBuffer FileIngresso: File getnomefile( ) getfileingresso( ) «Use» «Server Page» +conversione.jsp nomefile: String «Use» «Server Page» +errori.jsp ListaErrori: ArrayList «Builds» «Builds» «Session» +HttpSession «Client Page» +conversionepossibile «Client Page» +Errori «Link» «Link» «Link» «Client Page» +documentoconvertitohtml «Link» Figura

76 Descrizione del modello Il progetto originale è composto dalle classi Inizializzazione, Controllo, Verifica, Conversione, NodoVisitor e altre necessarie all implementazione del pattern Visitor (queste classi non sono rappresentate nella Figura 6.2, poiché non interagiscono direttamente con l applicazione Web). Inizializzazione, unica classe business rappresentata nella figura, è la classe che contiene il main e dalla quale inizia l esecuzione del programma; essa richiama tutte le altre classi. Possiamo vedere dal modello che la classe Controller.java è quella che interagisce con la vecchia parte del progetto. Con lo stereotipo <<use>> specifichiamo che l applicazione Web agisce sulla classe Inizializzazione richiamandone una nuova istanza. La classe index.jsp è rappresentata con tre stereotipi di classe. Essa contiene del codice java, dei tag HTML e una form per l inserimento del file. La pagina server genera una pagina client che a sua volta contiene una form. La form invia i dati, tramite una submit, alla classe Controller, essa gestisce il controllo ed esegue il forward adeguato in base alla risposta che riceve. Ogni pagina di risposta è a sua volta creata tramite una JSP e quindi viene rappresentata con due stereotipi: server e client. Un altro stereotipo utilizzato in questo modello è il <<link>>: ogni pagina nel modello contiene un link che permette di ritornare alla pagina iniziale. Un concetto importante da tenere presente è quello di sessione. Ogni utente deve avere la possibilità di identificarsi univocamente con l applicazione; quest ultima deve essere in grado di tenere traccia delle visite di un singolo utente. Ogni persona può inserire, anche contemporaneamente, un documento da far controllare al programma. La sessione è creata su un oggetto che rappresenta la connessione di un particolare utente. Per far ciò si è costruita una classe di supporto FileDiIngresso sulla quale viene creata una sessione univoca. A questo punto, il controller può creare una sessione su un istanza della classe, rappresentato con lo stereotipo <<new>>. Per rappresentare il concetto di sessione abbiamo introdotto lo stereotipo di classe <<session>>. Considerazioni Con la metodologia WAE i punti del Paragrafo 6.1 sono stati rispettati e modellati tutti. La metodologia permette di tener in considerazione gli aspetti che abbiamo preso a modello e ha una soluzione per ognuno di essi. Inoltre provando ad implementare il codice, il modello di Conallen, è stato particolarmente utile ed il risultato appropriato alle aspettative. Il lavoro di implementazione è stato affrontato senza l uso di tool per lo sviluppo automatico del codice. La metodologia interagisce bene con un applicazione già esistente. È bastato isolare la classe che conteneva il main (ovvero la classe da cui partiva il programma) e modificarne solamente due righe di codice: esattamente quelle che si utilizzano per la lettura dei due file. Con il nuovo progetto i file vengono letti a livello di applicazione Web e vengono passati alla vecchia classe solamente una volta richiamata dalla pagina Server che implementa il controller. L utilizzo di pattern specifici non ha introdotto problematiche nella modellazione. Grazie a WAE, che permette di specificare il tipo di pagina, è stato possibile descrivere il pattern MVC che ci eravamo prefissati di utilizzare. Un problema che comporta l uso di un pattern come questo è quello della specifica di navigabilità dell applicazione Web. Tutte le richieste provenienti da tutte le pagine fanno 76

77 riferimento al controller (in questo caso ad un unica classe) che genera più pagine client, in questo modo è possibile perdere il flusso della navigazione. Questo è un problema visto anche in precedenza con gli esempi più semplici e che abbiamo risolto affiancando al classico diagramma delle classi il diagramma UX. Nel Paragrafo vedremo il modello UX per il progetto Pubblicare Facile Web. Con questo tipo di modellazione non è necessario modificare il metodo di memorizzazione dei dati. Il progetto iniziale prevedeva di usare un file per il salvataggio delle informazioni quali vincoli ed eventuali errori rilevati. WAE permette di mantenere questo meccanismo senza la necessità di cambiare nulla da questo punto di vista. Essendo il nuovo progetto un applicazione Web si basa su una tecnologia di tipo client-server è quindi necessario che il server abbia in memoria una copia del file Latex da controllare inserito da parte del client. Questo meccanismo detto upload permette di copiare e memorizzare un file dalla macchina client a quella server. Quando vogliamo implementare una funzionalità di questo tipo è necessario creare un operazione esterna in grado di gestire l upload. La metodologia WAE è piuttosto elastica e permette di unire operazioni esterne, utilizzando semplici classi che le implementano usando lo stereotipo <<use>>. L idea è la stessa che abbiamo esposto per poter utilizzare il progetto Pubblicare Facile, anche esso era in un operazione esterna che l interfaccia Web ha utilizzato per il controllo del file. Infine consideriamo il concetto di sessione. La metodologia WAE ha permesso di creare facilmente la sessione sull oggetto FileDiIngresso utilizzando gli stereotipi previsti Il modello UX Per completare la modellazione del progetto Pubblicare Facile Web affianchiamo il modello UX dell applicazione. Questo permette di specificare i possibili percorsi di navigazione che l utente potrà effettuare, specificando le pagine che è possibile visualizzare e il loro ordine. Nella Figura 6.3 viene mostrato il modello UX per Pubblicare Facile Web. Figura

78 La home del sito è rappresentata dalla <<Screen>> index che contiene al suo interno un attributo path ; ovvero l unico attributo che viene modificato all interno della pagina. È lo stesso attributo contenuto nella form associata alla pagina. La home è costituita da una <<input form>> UploadForm composta da una casella di testo nella quale è possibile inserire il path del file da controllare. Il simbolo $ presente nella pagina index ha il significato di pagina raggiungibile da qualsiasi altra pagina. Questo simbolo permette di non tracciare i link uscenti da tutte le altre pagine verso quella che lo contiene, permettendo così maggior linearità nella lettura dei percorsi. Il percorso prosegue mostrando una seconda pagina che cambia a seconda del risultato dell inserimento della path del documento Latex. Se l inserimento ha avuto successo si passa al controllo della conformità, altrimenti viene visualizzata una schermata con la notifica di errore. Nel modello UX nel caso in cui abbiamo a che fare con una form è necessario avere due link uscenti: il link successfull (che determina il successo dell operazione di submit) e il link incomplete (che determina l avvenimento di errori durante la submit). Nella Figura 6.3 si associa il link incomplete alla schermata di errore, mentre il link successfull viene suddiviso tra due casi ben distinti e sullo stesso livello. Se il documento è non conforme la successiva <<Screen>> è la pagina Errori che contiene al suo interno la variabile ListaErrori che si modifica per ogni documento inserito. Se il documento invece è conforme la successiva <<Screen>> è la pagina ConversionePossibile che notifica il successo della conformità e mostra un link che permette di accedere al documento convertito in HTML. L ultima pagina visualizzata è quindi la <<Screen>> DocumentoConvertito L implementazione dell applicazione L applicazione Pubblicare Facile Web è stata implementata facilmente mantenendo le pagine previste dal modello WAE. L applicazione ottenuta è composta come mostrato in Tabella 6.1. Numero di file: Classi Java Servlet JSP HTML CSS Java Script DB: no Pattern MVC: si Numero LOC: 1775 circa Tabella 6.1 Nella Figura 6.4 sono rappresentate alcune videate dell applicazione. Il risultato di come vogliamo la visuale da parte dell utente. Nella figura in alto è riportata la pagina iniziale dell applicazione. In questa pagina l utente può scegliere il file latex da analizzare. Nella figura in basso viene riportato un esempio di fallimento di conversione; il file latex inserito non rispetta alcuni vincoli. La lista degli errori trovati viene visualizzata con la specifica dei requisiti non soddisfatti. 78

79 Figura

80 6.5. Modellazione con la metodologia WebML In questo paragrafo modelliamo l applicazione Pubblicare facile Web usando la metodologia WebML e cercando di rispettare i punti proposti nel Paragrafo 6.1. Il lavoro di modellazione con la metodologia WAE è stato effettuato usando il tool WebRatio [9]. Prima di procedere nella fase di modellazione soffermiamoci su alcune considerazioni: o La modellazione WebML permette di utilizzare una struttura dati, ma l applicazione originaria memorizza i dati in file facendo così in modo che gli utenti possano modificarli facilmente; o Se vogliamo utilizzare WebRatio per la generazione del codice abbiamo bisogno di un metodo per collegare l applicazione originaria ( Pubblicare Facile ) alla nuova applicazione Web modellata e generata con WebML. Queste considerazioni portano il programmatore ad effettuare una scelta di tipo organizzativo e implementativo. Se il programmatore decide di non modificare il metodo di memorizzazione dei dati può utilizzare la metodologia WebML solo a livello di modellazione. Altrimenti, se vuole generare il codice con il tool WebRatio ha bisogno di modificare il modo in cui sono memorizzati i dati (cioè occorre eseguire un operazione di re-engineering trasformando il file-system in database). Vediamo nel dettaglio la prima scelta, utilizzando quindi solo la metodologia WebML WebML solo a livello di modellazione Se il programmatore vuole rispettare la gestione a files, come era previsto nelle specifiche di Pubblicare Facile, può decidere di utilizzare la sola metodologia WebML per modellare la nuova applicazione. La modellazione può essere eseguita ugualmente con il tool WebRatio lasciando però al programmatore l implementazione effettiva. In Figura 6.5 vediamo il modello prodotto con WebRatio. Figura

81 Descrizione del modello La pagina Upload contiene una index unit che si occuperà di mostrare la form dove l utente potrà inserire il file per l upload. Inoltre la pagina di upload si deve anche occupare dell upload vero e proprio del file. Questa pagina è contrassegnata dalla Home e dal simbolo di Lendmark, poiché dovrà essere la prima pagina ad essere visualizzata e quella raggiungibile da tutte le altre. Una volta effettuato l upload del file l applicazione originaria potrà essere eseguita. Per rappresentare l esecuzione, si utilizza una operation unit che chiameremo con il nome dell applicazione esistente, ovvero Pubblicare Facile. Questa unit deve essere messa all esterno delle pagine, poiché non fa parte dell applicazione modellata con WebML. L operation unit ha a sua disposizione due link, il link KO e il link OK. A seconda del risultato dell applicazione Pubblicare Facile i link mostrano una nuova pagina. L applicazione originale restituisce a seconda del controllo o gli errori (link KO) o la conformità del documento (link OK). A questo punto ci troviamo nella situazione in cui dobbiamo usare una pagine OR. Con la metodologia WebML è possibile modellare questo particolare tipo di pattern con la pagina Alternative (nel modello si vede questa pagina in grigio ed è chiamata Responso ). La pagina Alternative permette di contenere e di identificare le due possibili pagine di risposta. La prima pagina Lista errori contiene una index unit che indica che nella pagina ci sarà una lista, nel nostro caso di errori (vedi scritta verde in basso). La seconda pagina Possibile Conversione contiene una data unit che indica che un particolare documento, quello il cui identificativo è appena stato controllato, può essere convertito e permette di accedervi tramite un link. Per creare la sessione univoca sul file viene utilizzata una set unit Set File che crea un parametro globale sul file Latex inserito dall utente. La set unit viene inserita nel modello esternamente alle pagine perché è creata per tutta la site view. Inoltre è collegata alla pagina che la crea con un link di trasporto che parte dalla data unit che contiene le informazioni sul file Latex inserito. Il link è di tipo trasporto perché la data unit Dati File Latex non verrà mostrata a video, ma è solo di supporto. Specifica testuale SiteView PubblicareFacileWeb (pages Upload, Controllo File, Documento Convertito) Page Upload (unit Upload Form, Dati File Latex) DataUnit Dati File Latex (source Documento) EntryUnit Upload Form (fields Path BLOB Content type File Latex) Link addfile transport (from upload Form to Dati File Latex) 81

82 GlobalParameter FileLatexInserito (type OID Entity Documento Initial value vuoto ) SetUnit Set File (parameter FileLatexInserito) Link setfile transport (from Dati File Latex to Set File) OperationUnit Pubblicare Facile Link Upload (from Upload to Pubblicare Facile) OKLink Ok_link (from Pubblicare Facile to Conversione) KOLink Ko_link (from Pubblicare Facile to Lista Errori) Page Responso (or-pages Conversione default, Lista Errori) Page Conversione (unit Conversione) DataUnit Conversione (source Documento attribute path) Page Lista Errori (unit Errori) IndexUnit Errori (source Errori attribute errore orderby errore) GetUnit Get File (parameter FileLatexInserito) Page Documento Convertito Link MostraDocumento (from Conversione to Documento Convertito) 82

83 Considerazioni Con la metodologia WebML è possibile modellare la nuova applicazione rispettando i punti del Paragrafo 6.1. Usando WebML l implementazione risulta più difficile che con WAE. Dal modello non si possono scorgere alcuni dettagli implementativi importanti: ad esempio non si può vedere come è costruita la form. È quindi necessario associare alla modellazione la specifica testuale. È possibile inserire nel modello l applicazione esistente Pubblicare Facile utilizzando l operation unit messa a disposizione dal linguaggio WebML. Il modello mostra che l applicazione si serve di un operazione personalizzata chiamata Pubblicare Facile ma non ne specifica l identità e tanto meno il metodo per collegare l interfaccia Web all operazione di verifica di conformità. Dal modello non si riescono ad ottenere informazioni sufficienti, in quanto non vengono nominate le classi, per cui il programmatore dovrà cercare la classe da modificare senza fare affidamento sulla metodologia. Con questo tipo di modellazione il programmatore è libero di usare il pattern più adatto: il MVC proposto in fase di analisi è implementabile considerando le pagine WebML inserite nel modello, la parte View del progetto e la operation unit Pubblicare Facile il Model. Per quanto riguarda il Controller è il programmatore che deve decidere come implementarlo, in quanto, ancora una volta, le classi non sono modellate. In conclusione possiamo affermare che dalla modellazione il programmatore non riesce ad intuire il pattern scelto dal progettista e rimane a sua scelta trovare quello più adatto. La sessione è modellata attraverso la set unit e il parametro globale FileLatexInserito che rimane per tutta la durata della sessione di un utente Manutenzione/Evoluzione dell applicazione In questo paragrafo vogliamo verificare come le due metodologie si comportano con le operazioni di manutenzione/evoluzione. In particolare supponiamo di dover implementare il seguente task di evoluzione: l applicazione così come era progettata inizialmente prevedeva che il cliente dell applicazione Web fosse lo style reviewer. Modificando il codice e aggiungendo una pagina di identificazione vogliamo che i clienti dell applicazione diventino gli autori del documento da controllare. Gli autori dei documenti iscritti al sito Pubblicare Facile Web potranno identificarsi e controllare la conformità del proprio documento in automatico utilizzando la rete. È necessario quindi, creare una gestione utenti, che riconosce gli utenti registrati (gli autori) e che mantenga in una sessione apposita le loro operazioni. Con questo semplice cambiamento vogliamo determinare: o La capacità delle due metodologie di estendere un applicazione Web già esistente; o Capire come le metodologie aiutano il programmatore a localizzare le porzioni di codice dove effettuare i cambiamenti; o Verificare come si comportano WAE e WebML con la gestione degli utenti. I nuovi requisiti (Requisiti di cambio) per la modifica dell applicazione sono: o CR1: permettere all utente (autore del documento) di accedere a Pubblicare Facile Web eseguendo una login; o CR2: controllare se la login avviene con successo altrimenti notificare l errore all utente; o CR3: far diventare l applicazione Web precedente protetta dagli utenti non registrati. 83

84 Gestione degli utenti con WAE La prima cosa che dobbiamo fare per implementare un requisito di cambio è capire dal modello precedente dove e come inserire le nuove classi. Inoltre dobbiamo riuscire a capire come fare interagire le nuove classi con il resto dell applicazione Web. Dato che l applicazione è stata costruita con il pattern MVC e il Controller è rappresentato dalla classe Controller.java la nuova pagina di login dovrà fare riferimento a quest ultima in modo da effettuare il controllo sugli utenti. Inoltre sarà necessario verificare dove creare la sessione, gestire gle errori (utente non valido) e l operazione di logout. Nella Figura 6.6 vediamo il modello WAE con la modifica apportata. In rosso si possono vedere le classi e le associazioni aggiunte al modello precedente. «Server Page» +Login.jsp -nome_utente: String -Passwd: String «Build» «Link» «Client Page» +Login «Client Page» +ErroreTrovato «Builds» «Server Page» +paginadeglierrori.jsp Model Name: PubblicareFacileConallen Package Name: Logical View Diagram Name: Main Diagram Type: Class Pubblicare Facile Conallen Login «Server Page» +index.jsp «Use» «Link» «Client Page» «Builds» +index «Forward» «Class» +FileDiIngresso «Use» nomefile: StringBuffer FileIngresso: File getnomefile( ) getfileingresso( ) «Form» +LoginForm -Nome: String «Submit» -Passwd: Password «Class» «Forward» -Submit +Inizializzazione filel: File filer: File «Server Page» «Use» «Form» +Controller.java LeggiItemize( ) +uploadform LetturaLibro( ) «Submit» page: String Submit LetturaArticolo( ) path: String Reset PrendiCR( ) -nome_utente: String path: text TOHTML( ) -passwd: String dopost( ) doget( ) «New» «New» «Class» «Use» «Forward» +Utenti «Forward» -nome_utente[]: String -passwd[]: String «Server Page» +conversione.jsp «Server Page» «Use» +errori.jsp nomefile: String ListaErrori: ArrayList «Use» «Table» Utenti db «Builds» «Builds» «Session» +Http Session «Session» +HttpSession «Client Page» +conversionepossibile «Client Page» +Errori «Link» «Link» «Link» «Link» «Link» «Client Page» +documentoconvertitohtml «Link» Figura

85 Descrizione del modello Al modello precedente è stata aggiunta una nuova pagina con form per permettere l inserimento dello user name e password da parte dell autore del documento. La nuova pagina è composta quindi da una server page Login.jsp, da una client page Login e da una form LoginForm che contiene le variabili nome, password e il bottone Submit. La pagina server genera (<<Build>>) la pagina client che contiene la form. La form trasmette le informazioni (<<Submit>>) al Controller (in rosso sono riportate le due variabili nome e password aggiunte alla classe). Il Controller deve quindi verificare l utente e creare la sessione su quest ultimo (la <<new>> verso la classe Utenti che ha sua volta estende la Http Session serve proprio a questo). La classe Utenti inoltre utilizza un entità Utenti.db (è il database) che contiene la lista con le generalità degli utenti registrati. Dopo che avrà eseguito il controllo la classe Controller.java esegue il forward alla index.jsp che mostra la pagina di upload. Dalla pagina di upload l utente potrà navigare e utilizzare l applicazione nello stesso modo in cui avveniva precedentemente per lo style reviewer. Se l utente non è presente, il controller si preoccupa di mandare il tipo di errore alla pagina paginadeglierrori.jsp. Quindi la modifica nel codice avverrà anche in quest ultima server page aggiungendo un caso di errore. Il logout può essere effettuato dalle pagine Errori, conversionepossibile e index tramite un link verso la pagina iniziale Login.jsp. Anche in questo caso sarà compito del Controller invalidare la sessione e ridirigere l utente alla pagina iniziale. Considerazioni La modellazione con WAE permette di aggiungere la nuova pagina sfruttando il controller creato in precedenza. Gli stereotipi <<use>>, <<new>> (per le associazione) e l inclusione della classe <<session>> permettono di creare la sessione sull utente nello stesso modo in cui abbiamo creato la sessione precedente sul file Latex. Questo tipo di modellazione permette di identificare facilmente le pagine che dovranno essere modificate, in questo caso tutte le pagine fanno riferimento al controller, quindi anche la nuova pagina dovrà trasmettere i propri dati a quest ultimo. Il problema è quello solito: identificare, una volta creato il modello, la navigazione da parte dell utente. Il controller, infatti, elabora le informazioni da entrambe le pagine con form e visualizza tre possibili pagine la index, la conversionepossibile e la Errori. La pagina index però deve essere visualizzata solamente quando si proviene dalla pagina login, mentre le altre due solamente quando si proviene dalla pagina di upload. Il modello UX si è rivelato ancora una volta utile. Nella Figura 6.7 vediamo il modello UX dell applicazione modificata con la pagina di login. La homepage del sito è rappresentata dalla <<Screen>> Login (con l aggiunta della pagina di login sostituisce la <<Screen>> index ) che contiene al suo interno gli attributi nome_utente e passwd ; ovvero gli unici attributi che sono modificati all interno della pagina (vedi Paragrafo 2.2). Sono gli stessi attributi contenuti nella form associata alla pagina. La home è costituita da una <<input form>> LoginForm composta da due caselle di testo nella quale è possibile inserire lo user name e la password dell utente che vuole connettersi. Il simbolo $ viene aggiunto anche alla pagina di Login, in quanto è raggiungibile da tutte le altre eseguendo la logout. La pagina index mantiene il simbolo $ in quanto pagina raggiungibile da qualsiasi altra pagina dopo l esecuzione della login. Questo simbolo permette di non tracciare i link contenuti nelle pagine successive (l utente può tornare nelle pagine di upload o di login da qualsiasi altra pagina), permettendo maggior linearità nella lettura dei percorsi. 85

86 Figura 6.7 Con questo tipo di modellazione ogni utente registrato al servizio può controllare e pubblicare (sempre che sia conforme) il proprio elaborato. A questo punto il lavoro dello style reviewer rimane solamente quello di gestire il file contenente i vincoli di stile. Con questa soluzione di ampliamento dell applicazione Web modellata con WAE lo style reviewer non deve preoccuparsi di nessun tipo di variazioni rispetto a prima, potrà per tanto modificare i requisiti di stile dal file che utilizzava anche precedentemente. Implementazione della modifica Dopo aver modificato il modello dell applicazione Web Pubblicare Facile Web sono state implementate le nuove classi ed eseguite le modifiche alla classi già esistenti. Il modello WAE è risultato adeguato per l implementazione della nuova applicazione Web, le modifiche apportate al modello sono state utili per l estensione, ma sopratutto hanno permesso di intuire precedentemente dove effettuarle. La nuova applicazione è composta come in Tabella 6.2. Numero di file: Classi Java Servlet JSP HTML CSS Java Script DB: Pattern MVC: Numero LOC: si, per la gestione degli utenti si 1855 circa Tabella

87 In Figura 6.8 sono riportate alcune videate dell applicazione in esecuzione. La prima mostra la nuova pagina che permette l inserimento dei dati da parte dell utente per accedere ai servizi di Pubblicare Facile. La seconda mostra la prima videata di Upload modificata in modo tale da visualizzare il nome dell utente connesso. Inoltre si vede il link per effettuare il logout Gestione degli utenti con WebML Figura 6.8 La metodologia WebML mette a disposizione dei pattern specifici per la gestione degli utenti che ci permette di creare la modifica che ci siamo prefissati. Questo tipo di gestione è gratuita, nel senso che WebRatio la mette a disposizione utilizzando uno specifico database che dovrà essere compilato adeguatamente (la compilazione del database deve essere effettuata come richiede la documentazione del tool per permettere la generazione del codice) [14]. Inoltre vi sono delle unit specifiche (login unit e logout unit) da inserire nelle site view. Nella Figura 6.9 vediamo lo schema E-R proposto dal tool WebRatio per la gestione degli utenti. Figura 6.9 Il pattern che contiene la login unit deve essere inserito in una site view apposita, per permettere alle altre di essere protette (cioè accessibili solamente dopo la login). Il pattern che contiene la logout unit invece dovrà essere posizionato nelle site view che l utente accede dopo la login. Inoltre la pagina di logout deve essere landmark per permettere al link (logout) di essere presente in tutte le pagine. Per effettuare la modifica sul modello creato in precedenza quindi dobbiamo aggiungere una site view. 87

88 Nella Figura 6.10 vediamo come è stata modellata la modifica con la metodologia WebML. In particolare vediamo che la site view Pubblicare Facile è diventata protetta (notare il simbolo della chiave). Inoltre si vede l aggiunta del pattern per la creazione della logout. Figura 6.10 Nella Figura 6.11 vediamo la seconda site view aggiunta con il pattern per la realizzazione della login. La site view diventa quella di default e la pagina Login Page la home. Figura

89 Descrizione del modello La nuova site view Login contiene il pattern per la realizzazione della login e la pagina Login Page al suo interno diventa la nuova home dell applicazione. La pagina in questione contiene la entry unit con i field per l inserimento dello user name e la password. Il link trasmette le informazioni alla login unit che esegue il controllo sull utente. La login unit riesce ad eseguire il controllo utilizzando il database di cui abbiamo già parlato in precedenza e automaticamente, se l autenticazione ha successo, trasferisce l utente alla site view elencata nell entità Module. In questo caso nella site view Pubblicare Facile. Inoltre crea il parametro globale UserCtxParam che permette di mantenere la sessione sull utente. La site view Pubblicare Facile è protetta, ciò significa che può essere raggiunta solamente effettuando la login e in particolare solamente gli utenti specificati nell entità Group-Module possono accedere a questa area del sito. Inoltre la site view pubblicare Facile è stata modificata (rispetto al modello precedente) aggiungendo il pattern per la realizzazione della logout. La pagina Logout Page è di tipo landmark per permettere di essere raggiungibile da tutte le altre pagine e quindi per permettere all utente di effettuare il logout in qualsiasi punto della navigazione. La pagina di logout contiene una data unit che prende i valori dell utente connesso, creato dalla login unit come parametro globale, e li mostra all utente. Il link verso la logout unit effettua il logout definitivo. Alla logout unit è necessario associare una site view da mostrare una volta effettuato il logout poiché la stessa è protetta. Nel nostro caso rimandiamo l utente alla site view Login. Considerazioni La metodologia WebML permette di gestire gli utenti in modo separato dal resto della modellazione. Questo rende la modifica che ci eravamo prefissati molto semplice da fare e inoltre non complica la lettura del modello precedente. L aggiunta dei due pattern è molto semplice e sempre uguale, bisogna ricordarsi però di modificare il database inserendo i campi in modo adeguato. Inoltre questo tipo di modellazione permette di identificare quali sono le aree dell applicazione Web protette. Anche per la modifica le unit avranno bisogno di una specifica testuale per la comprensione del loro contenuto. Ad esempio la entry unit per la creazione della form non contiene la definizione dei campi necessari per la login (due field e un submit). Anche se in questo caso i campi della form sono semplici da immaginare. Specifica testuale Di seguito viene presentata la specifica testuale per la nuova site view. SiteView Login (page Login Page) Page Login Page (unit Login) Entry Unit Login (fields nome String 89

90 passwd Password) Login Unit Login Unit Link Accedi (from Login Page to Login Unit) KOLink Ko_link (from Login Unit to Login Page) Di seguito la specifica testuale per la parte modificata nella site view Pubblicare Facile. Page Logout Page (unit Utente, GetUser) Data Unit Utente (source Utente) Get Unit GetUser (parameter UserCtxParam) Link getutente transport (from GetUser to User) Logout Unit Logout Unit Link Logout (from Logout Page to Logout Unit) KOLink Ko_link (from Logout Unit to Logout Page) Per questa modifica, che si basa solamente sul supporto di database, proviamo ad utilizzare WebRatio, in particolare la sua funzione di generazione automatica di codice. Generazione del codice Dopo aver modellato l applicazione (Figura 6.10 e Figura 6.11) è possibile, usando WebRatio, generare il codice dell applicazione Web in automatico. La prima cosa da fare è mappare un database completo e uguale allo schema E-R nell apposito spazio nel tool. Nel nostro caso dobbiamo completare il database della gestione utenti come segue: Nella Figura 6.12 vediamo le tabelle del database di Figura 6.9 compilate dei campi necessari per effettuare la modifica (creare la login per gli autori dei documenti da controllare). La tabella del modulo rappresenta la site view accessibile dopo l operazione di login (sv1 è l id della site view). La tabella del gruppo rappresenta il tipo di utente che può accedere a quella particolare zona dell applicazione Web (in questo caso Content owners 1 sta per gli utenti registrati semplici). Ad ogni modulo possono accedere dei gruppi; la tabella Gruppo-Modulo specifica quali. La tabella dell utente rappresenta ogni utente registrato all applicazione, esso appartiene a uno o più gruppi specificati nella tabella Utente-Gruppo. 90

91 Tabella Modulo: Tabella Gruppo: Tabella Gruppo-Modulo: Tabella Utente: Tabella Utente-Gruppo: Figura 6.12 Quando il database è stato completato possiamo connetterlo attraverso il tool con l applicazione Web, utilizzando il pannello apposito (vedi Figura 5.6). Quando la modellazione è completa, il database è connesso e i layout sono stati scelti (come visto nel Paragrafo 5.2.1) è possibile settare la cartella dove verranno create le pagine jsp utilizzando la Deployment Configuration Dialog del comando Tools. Finite le operazioni di modellazione e settaggio è possibile controllare eventuali errori utilizzando il comando Wornings. Vi è un controllo per ogni visuale della metodologia WebML. Se non ci sono errori è possibile generare il codice utilizzando il comando Build All che appartiene alla tendina Templates (sempre sulla barra degli strumenti). A questo punto il codice verrà generato. Per eseguire l applicazione è sufficiente lanciare Tomcat (piattaforma per l esecuzione di applicazioni Web sviluppate nel linguaggio Java) [20], aprire il browser e inserire l indirizzo in localhost. Per la nostra applicazione Web Pubblicare Facile l indirizzo è: Nella Figura 6.13 vediamo il pannello Deployment configuration dialog che permette di settare i parametri per identificare dove il tool dovrà posizionare il codice generato. 91

92 Figura 6.13 Nella Figura 6.14 vediamo la barra degli strumenti con la quale possiamo verificare gli errori e generare il codice. Cerchiati in rosso ci sono i comandi per la generazione del codice e in blu i comandi per il controllo degli errori. Figura 6.14 Nella Figura 6.15 sono riportate alcune videate dell applicazione creata in automatico. La prima mostra la pagina di login, con la form che permette l inserimento dello user name e della password. La seconda mostra la pagina di upload, con la form che permette la ricerca del file da controllare tramite il bottone Sfoglia e il suo upload con il bottone Upload. Entrambe le operazioni sono state generate automaticamente a partire dal modello. Ogni unit è rappresentata da una tabella che in questo esempio è rappresentata in giallo. È possibile inoltre personalizzare le pagine con proprie aggiunte una volta che sono state generate (come ad esempio il titolo Pubblicare Facile Web ). È possibile infine notare che ogni pagina dichiarata nel modello di default viene visualizzata come sequenza di link da cui si può accedervi da qualsiasi altra pagina del sito (esempio: Upload_LogoutPage). 92