Progettazione di applicazioni Web

Progettazione di applicazioni Web Indice Introduzione 1 Il processo di sviluppo di un applicazione Web 2 Specifica dei requisiti 6 Raccolta dei requisiti 7 Analisi dei requisiti 11 Progettazione dei dati 14 Progettazione dell ipertesto 15 Il linguaggio di modellazione per l organizzazione dell'ipertesto 16 Progettazione generale e dettagliata 39 Web usability 42 Usabilità nella progettazione Web 43 Introduzione Lo sviluppo di applicazioni Web, così come quello di ogni altro sistema software, è un'attività complessa, che richiede la capacità, da parte di esperti con conoscenze ed esperienze diverse, di eseguire in modo cooperativo un largo spettro di compiti. Al fine di affrontare adeguatamente la complessità intrinseca di un tale sviluppo, può essere utile adottare un processo di sviluppo fondato su concetti, di modellazione adeguati. In questa dispensa verrà presentato il classico processo incrementale e interativo adottato dalle moderne metodologie dell'ingegneria del software, adattato alla specificità delle applicazioni Web centrate sui dati. Tale processo di sviluppo si basa su notazioni e concetti appropriati per la modellazione dei dati e dell'ipertesto e sulla separazione tra gli aspetti di struttura, navigazione e presentazione. Particolare attenzione deve essere riservata per la modellazione ipertestuale, il cui scopo è quello di specificare l'organizzazione dell'interfaccia di un'applicazione Web. Per essere efficace, tale specifica deve essere in grado di esprimere in modo semplice e intuitivo aspetti quali la suddivisione logica dell'applicazione in moduli di alto livello (ognuno dei quali racchiude un insieme di funzioni coerenti con gli obiettivi di una specifica classe di utenti), la partizione dei moduli di alto livello in sotto-moduli (per una migliore organizzazione delle applicazioni complesse), e la topologia dell'ipertesto di ogni modulo (pagine, costituite da elementi di contenuto, e link, che supportano la navigazione e l'interazione dell'utente). Il modello ipertestuale dovrebbe essere specificato al giusto livello di astrazione; la specifica dell'ipertesto dovrebbe essere mantenuta a livello concettuale, non dovrebbe cioè far riferimento ai dettagli di progettazione e implementazione, come la distribuzione effettiva delle funzionalità tra i vari strati dell'applicazione. A differenza della modellazione di basi di dati, che è un'attività ben consolidata, la modellazione ipertestuale è una disciplina molto più giovane, a cui manca ancora una base solida di concetti, notazioni e metodi di progettazione. WebML, linguaggio a cui si fa riferimento in questa dispensa, fornisce le primitive per la modellazione ipertestuale, ereditando dal modello Entità-Relazione l'idea di utilizzare concetti semplici ed espressivi e di essere supportato da una notazione grafica intuitiva. 1/52

Infine, verranno presentati alcuni principi di Web Usability. Creare un'ipermedia vuol dire organizzare il testo in funzione di diversi possibili percorsi di lettura che raramente sono lineari. L'ordine lineare del testo si dissolve ed è sostituito da un deposito di elementi disponibile sotto forma di un continuum di linguistici, grafici, visivi e sonori che si intersecano in una struttura a rete. L'introduzione di questi nuovi oggetti informativi comporta non solo un nuovo modo di costruzione o scrittura dei testi condizionato dal medium utilizzato, ma anche dal nuovo modo di lettura. Il WWW non ha lettori nel senso tradizionale del termine, in quanto la maggioranza dei navigatori del Web non legge riga per riga, ma "scorre" la pagina, cercando rapidamente, come su una mappa visiva, quello che più gli interessa. I lettori-utenti del Web si caratterizzano per la ricerca frenetica di informazioni passando senza sosta da una pagina all'altra. Questa ricerca è, comunque, consapevole e attiva e segue un percorso che non è mai casuale. Per poter catturare l'attenzione di questa tipologia di lettore bisogna, dunque, creare ipermedia disseminati di segnali che indichino immediatamente di cosa si parla e che rendano subito chiaro il contenuto della pagina. Il web è un medium giovane e dalle grandi potenzialità, e offre molte possibilità di sperimentazione comunicativa. L interattività, la multimedialità, la possibilità di mutuare forme comunicative proprie di altri media (stampa, audiovisivi, radio ) spesso, però, finiscono semplicemente col disorientare l utente. Molti siti web, per quanto tecnicamente perfetti, non hanno successo perchè non riescono ad attenersi alle regole fondamentali che aiutano l utente nel raggiungimento del proprio obiettivo, che dovrebbe coincidere, dall altra parte, con quello del sito stesso. Diventa, quindi, fondamentale conoscere i principali criteri di web usability sia a livello progettuale che a livello implementativo. Chi produce pagine web deve non solo conoscere il linguaggio di programmazione HTML e i linguaggi di programmazione che possono essere utilizzati nel web, ma deve anche adottare un modello di progettazione di applicazioni Web e conoscere le regole di web usability. Processo di sviluppo di un applicazione Web Le fasi di un possibile processo di sviluppo di applicazioni centrate sui dati sono mostrate nella Figura 1. In conformità con il classico modello a spirale di Boehm e con i moderni metodi dell'ingegneria del software e dell'ingegneria del Web, le fasi di sviluppo sono applicate in modalità incrementale e iterativa: le varie attività sono cioé ripetute e raffinate fino a quando i risultati ottenuti soddisfano i requisiti di business inizialmente raccolti. Lo sviluppo dell'applicazione consta quindi di diversi cicli di "scoperta dei problemi-raffinamento del progetto-implementazione", in cui ogni ciclo produce un prototipo oppure una versione parziale del sistema. A ogni iterazione, la versione corrente del sistema è testata e valutata e quindi estesa o modificata a seconda dei problemi riscontrati. Un tale approccio incrementale e iterativo non è esclusivo dello sviluppo di applicazioni Web, ma tuttavia appare particolarmente appropriato per questa classe di sistemi. Le applicazioni Web devono infatti essere realizzate e rilasciate velocemente (nei tempi brevi che caratterizzano Internet) e i loro requisiti sono spesso soggetti a cambiamenti. Gli input di tale processo di sviluppo sono l'insieme dei requisiti di business che guidano lo sviluppo dell'applicazione. Questi requisiti sono in molti casi non tecnici ed esprimono gli obiettivi a lungo termine che lo sviluppo dell'applicazione deve permettere di giungere, definendo il valore aggiunto che l'applicazione deve produrre per gli utenti e per l'organizzazione che ne richiede lo sviluppo. I requisiti di business identificano inoltre gli attori (sia agenti umani, sia agenti software) che possono trarre profitto dallo sviluppo dell'applicazione, i processi influenzati dall'applicazione, il confine tra la nuova applicazione e i sistemi preesistenti e i fattori di qualità a cui l'applicazione deve aderire, quali per esempio quelli relativi alla qualità dei contenuti, dei servizi e delle interfacce, ai tempi di risposta, alla continuità di servizio, alla sicurezza, alla privatezza, ecc. 2/52

Figura 1 - Le fasi nel processo di sviluppo di applicazioni Web centrate sui dati. Ulteriori fattori di input che influenzano il processo di sviluppo sono i vincoli derivanti dal contesto d'uso. Tali vincoli sono limitazioni che il contesto d'uso reale impone sul raggiungimento degli obiettivi dell'applicazione. Possono derivare da particolari configurazioni architetturali, dalla compatibilità con i sistemi e le applicazioni preesistenti, dalla disponibilità di personale tecnico esperto e dalla disponibilità di tempo e di risorse. L'applicazione finale è il risultato di un accurato compromesso tra questi vincoli e i requisiti di business. L'output di un processo di sviluppo è l'implementazione del sistema, che consiste nella definizione e preparazione dell architettura hardware/software e dei moduli software dell'applicazione installati su tale architettura e nella documentazione di sistema: L'architettura rilasciata è l'infrastruttura hardware, software e di rete in grado di assicurare il livello di servizio richiesto e il rispetto dei vincoli tecnici di progetto. Su tale architettura si definiscono i moduli dell'applicazione, cioè le parti di software sviluppate, cioè le sorgenti di dati, i template delle pagine dinamiche e i componenti che gestiscono la logica dell'applicazione e che forniscono le funzionalità richieste dai requisiti di business. La documentazione di sistema è l'insieme di prodotti non software sviluppati per documentare le scelte fondamentali intraprese durante lo sviluppo dell'applicazione. La documentazione più rilevante riguarda le specifiche dei requisiti e le specifiche di progettazione. Le specifiche dei requisiti esprimono in particolare i requisiti funzionali, che derivano dai requisiti di business e che rispetto a questi introducono concretezza e operazionalità per descrivere con maggior rigore le funzionalità che l'applicazione deve supportare. Le specifiche di progettazione descrivono invece il modo in cui l'applicazione è stata progettata per rispondere ai requisiti; i componenti fondamentali sono le specifiche derivanti dalla progettazione dei dati, dell'ipertesto e dell'architettura. Lo sviluppo di applicazioni Web coinvolge diverse figure, aventi competenze e ruoli diversi ma obiettivi complementari: L'analista dell'applicazione raccoglie i requisiti di business e li trasforma nella specifica dei requisiti dell'applicazione. In questa attività, l'analista interpreta gli obiettivi di business strategici e a lungo termine ed eventuali vincoli di contesto e li trasforma in requisiti dell'applicazione concreti e a breve termine. Il progettista dei dati si concentra sui requisiti che riguardano i dati e produce lo schema concettuale dei dati. Il progettista dell'applicazione si concentra sui requisiti che riguardano i servizi che applicazione deve fornire e progettare l'ipertesto, attraverso la specifica di site view (viste del sito web) costruite al di sopra dello schema dei dati prodotto dal progettista dei dati. 3/52

Il progettista grafico definisce lo stile di presentazione delle pagine, basandosi sui requisiti di business che si riferiscono all'identità visuale dall'organizzazione e agli standard di comunicazione prescelti. Lo sviluppatore e amministratore dell'applicazione è responsabile della progettazione dell'architettura, dell'implementazione, della messa a punto e installazione e dell'evoluzione dell'applicazione. In particolare, tale figura si concentra sui requisiti non funzionali che riguardano le prestazioni, la continuità di servizio. la sicurezza, la scalabilità e la manutenibilità ed è inoltre responsabile affinché l'applicazione assicuri un livello di servizio appropriato. Oltre a queste figure, nel processo di sviluppo intervengono anche altri specialisti che eseguono in modo ortogonale attività relative al testing e alla valutazione loro ruolo consiste nel verificare che l'applicazione rispetti i requisiti funzionali e non funzionali. E importante notare come i diversi ruoli non devono essere necessariamente attribuiti a figure diverse; al contrario, nel contesto di semplici applicazioni spesso accade che diversi ruoli convergano in una stessa persona. Vediamo, ora, più nel dettaglio le diverse fasi del processo di sviluppo preso in considerazione. Specifica dei requisiti La specifica dei requisiti è l'attività in cui l'analista dell'applicazione raccoglie e formalizza le informazioni essenziali riguardo il dominio applicativo e le funzionalità che l'applicazione deve supportare. L'input per questa attività è l'insieme dei requisiti di business che motivano lo sviluppo dell'applicazione e tutte le informazioni disponibili riguardo il contesto tecnico, organizzativo e decisionale in cui l' applicazione deve operare. L output è una specifica precisa e tuttavia facile comprendere anche da parte del personale non tecnico. Si rivolge quindi ai progettisti, che la utilizzano per individuare le funzionalità dell'applicazione che devono essere progettate e realizzate, così come ai committenti, che prima di dare il via allo sviluppo possono verificare che quanto specificato sia conforme ai requisiti di business. Progettazione dei dati La progettazione dei dati è la fase in cui l'esperto dei dati organizza gli oggetti informativi principali, individuati durante la specifica dei requisiti, in uno schema dei dati completo e coerente, definito in base a un modello prescelto. La progettazione dei dati è una disciplina ben affermata: il modello maggiormente utilizzato, il modello Entità-Relazione, è stato definito nel 1976 e, sin da allora, sono state proposte diverse pratiche di modellazione dei dati e linee guida, che sono ormai ben consolidate. Tuttavia, la modellazione dei dati per le applicazioni Web presenta alcune specificità, dovute al ruolo che gli oggetti informativi assumono in tali applicazioni. Un aspetto fondamentale nella progettazione dei dati per applicazioni Web riguarda la relazione con le precedenti scelte progettuali che caratterizzano le sorgenti di dati preesistenti. In molti casi, un'applicazione Web pubblica contenuti già disponibili nelle basi di dati aziendali, eventualmente arricchiti tramite contenuti meno strutturati, come per esempio oggetti multimediali necessari per migliorare gli aspetti comunicativi dell'applicazione. In tale scenario, la progettazione dei dati devono bilanciare due obiettivi a volte in opposizione: soddisfare i requisiti della nuova applicazione e non violare i vincoli derivanti dalle precedenti progettazioni e implementazioni. Anche nella situazione in cui il contenuto gestito dall'applicazione Web sia già disponibile in una base di dati o in un sistema preesistente, la modellazione concettuale continua a rivestire un ruolo fondamentale e, al fine di definire lo schema dei dati che meglio soddisfi i requisiti della nuova applicazione, deve essere eseguita indipendentemente dall'organizzazione dei dati preesistenti. Sarà 4/52

poi la fase di implementazione a concentrarsi sull'associazione (mapping) tra lo schema concettuale così definito e le sorgenti dei dati esistenti. Tale associazione è un'attività tecnica, per la quale sono stati proposti molteplici metodi, tecnologie e strumenti. Progettazione dell'ipertesto La progettazione dell'ipertesto trasforma i requisiti funzionali, individuati durante la specifica dei requisiti in una o più site view che pubblicano i contenuti e offrono le funzionalità per manipolare i dati. La progettazione dell'ipertesto opera a livello concettuale e può utilizzare un linguaggio di modellazione concettuale (come WebML) per specificare la composizione in pagine di unit di contenuto, definite su entità dello schema dei dati, e la connessione di unit e pagine mediante link per dar forma a un ipertesto. Diversamente dalla progettazione dei dati, la progettazione dell'ipertesto è una nuova disciplina, con scarso supporto metodologico. La progettazione dell'ipertesto è la fase che nell'ambito del ciclo di sviluppo trae maggiore vantaggio dall'adozione di un modello concettuale. Operare a livello concettuale, utilizzando un modello visuale, invece che a livello di implementazione, direttamente sul codice, rende più semplice l'individuazione delle funzionalità che devono essere offerte dall'applicazione e la loro organizzazione all'interno delle site view. Inoltre, l'utilizzo di design pattern, eventualmente messi a disposizione dal modello concettuale adottato, incrementa la regolarità del progetto, soprattutto quando le applicazioni hanno grandi dimensioni, rinforzando quindi la coerenza e l'usabilità dell'ipertesto. In aggiunta, le specifiche delle site view prodotte durante la modellazione documentano la struttura dell ipertesto in modo formale e indipendente dall'implementazione e risultano essere fondamentali per gestire le successive modifiche eventualmente richieste dopo il rilascio dell'applicazione. Progettazione dell architettura La progettazione dell'architettura riguarda la definizione dei componenti hardware, software e di rete tramite cui l'applicazione è in grado di fornire servizi ai suoi utenti. Lo scopo della progettazione dell'architettura è trovare la giusta mescolanza dei vari componenti, cioé quella che meglio risponde ai requisiti dell'applicazione in termini di prestazioni, sicurezza, continuità di servizio e scalabilità e che allo stesso tempo rispetti i vincoli tecnici ed economici dettati dal progetto di applicazione. L'input per la progettazione dell'architettura sono i requisiti non funzionali e i vincoli individuati e formalizzati nelle specifiche dei requisiti. L output è ogni specifica che riguardi l'organizzazione dell'architettura in termini di processori, processi e mutue connessioni. Implementazione L'implementazione è l'attività di produzione dei moduli software, necessaria a trasformare il progetto dei dati e dell'ipertesto in un'applicazione funzionante in un architettura selezionata. L'implementazione dei dati si concentra sulla definizione del mapping tra schema Entità-Relazione e una o più sorgenti di dati. Lo scopo di questa attività è associare le entità, gli attributi e le relazioni, definite a livello concettuale, ad alcune strutture fisiche nelle sorgenti dei dati. Come già evidenziato per la progettazione, l'implementazione dei dati può dover essere espletata in due scenari di versi. In un caso, cioé, la sorgente dei dati deve essere progettata e implementata ex-novo, parallelamente all'applicazione Web; nell'altro, è invece necessario interfacciare la nuova applicazione a una sorgente dati preesistente. Nel primo caso, il mapping dei dati consiste nella classica attività di trasformazione dello schema concettuale in una base di dati, in cui memorizzare e gestire i contenuti dell'applicazione. Nel secondo caso, è necessario affrontare il problema più complesso dell integrazione con i dati e i sistemi preesistenti, per il quale è possibile adottare diverse soluzioni. L'implementazione dell'ipertesto riguarda la produzione di template di pagine dinamiche e programmi in linguaggi di script, che traducono le pagine e unit di contenuto specificate tramite il linguaggio concettuale, in un certo linguaggio di mark-up e in script a lato server. I template di pagina possono operare sia con oggetti applicativi che gestiscono la presentazione, sia con quelli che 5/52

gestiscono la logica procedurale richiesta per computare le pagine e per soddisfare le richieste dei client. Rilascio e installazione dell'applicazione Web Le attività di testing e valutazione hanno lo scopo di verificare l'aderenza dell'applicazione sviluppata ai requisiti funzionali e non funzionali. Le attività principali sono: Test-funzionale: il comportamento dell'applicazione è verificato rispetto ai requisiti funzionali. Il testing funzionale può essere scomposto nelle classiche attività di test dei singoli moduli, test dell'integrazione e test di sistema. Test di usabilità: le site view prodotte devono essere valutate rispetto ai requisiti di facilità d'uso, efficacia della comunicazione e aderenza ai comuni standard d'interazione. I criteri di valutazione possono cambiare a seconda della site view considerata, in quanto site view diverse possono essere dirette a gruppi di utenti con requisiti di usabilità diversi (per esempio a clienti e a personale interno all'azienda). Test delle prestazioni: i risultati prodotti dall'applicazione e i tempi di risposta devono essere valutati, sia in situazioni di carico medio, sia in situazioni di picco. Nel caso in cui il livello di servizio sia inadeguato, l'architettura dell'applicazione deve essere monitorata e analizzata per individuare e rimuovere eventuali colli di bottiglia. Il rilascio dell'applicazione Web consiste nell'installazione dei moduli software sviluppati sull'architettura selezionata. Il rilascio coinvolge sia lo strato dei dati, dove si può verificare che una nuova base di dati debba essere resa operativa o che i software di collegamento a sorgenti dati e applicazioni preesistenti debbano essere attivati, sia gli strati di business e di presentazione, in cui i template di pagina e gli oggetti di business devono essere installati. Il rilascio è un'attività tecnica. che richiede conoscenze e abilità proprie dell'amministratore dell'applicazione. La manutenzione e l'evoluzione riguardano tutte le modifiche effettuate dopo che l'applicazione è stata rilasciata. A differenza delle altre fasi di sviluppo, la manutenzione e l'evoluzione sono applicate a un sistema già prodotto, quindi a un'applicazione funzionante e alla documentazione corrispondente. In un processo basato su un modello, la gestione dei cambiamenti trae vantaggio dell'esistenza dello schema concettuale dell'applicazione, in quanto le richieste di modifica sono analizzate e trasformate in cambiamenti a livello di progetto e sono apportate allo schema concettuale dei dati o dell'ipertesto; i cambiamenti operati a livello concettuale sono poi propagati all'implementazione. Vediamo ora le fasi "alte" di analisi e progettazione che nell'intero processo sono quelle maggiormente influenzate dall'adozione di un modello concettuale. Specifica dei requisiti La specifica dei requisiti è l'attività in cui l'analista dell'applicazione elabora i requisiti di business che motivano lo sviluppo dell'applicazione e tutte le informazioni disponibili riguardo il contesto tecnico, organizzativo e direzionale in cui l applicazione deve operare e traduce questi input nella specifica delle funzionalità che l applicazione deve realizzare. La specifica dei requisiti si compone di due fasi: la raccolta dei requisiti e la successiva analisi. La raccolta dei requisiti ha l'obiettivo di definire un'immagine globale del dominio applicativo e della soluzione che deve essere sviluppata, attraverso interviste rivolte agli attori principali del dominio applicativo e revisioni della documentazione disponibile. Alla fine di tale attività devono essere noti gli utenti principali che utilizzeranno l'applicazione, le funzionalità che dovranno essere supportate e i principali requisiti non funzionali. 6/52

L'analisi dei requisiti si concentra sulla revisione e la formalizzazione dei requisiti elicitati e produce come risultato un insieme di specifiche semi-formali che includono: L'elenco dei gruppi di utenti che accederanno all'applicazione Web, insieme alla specifica dei loro diritti di accesso sul contenuto informativo. I casi d'uso più significativi, il cui scopo è illustrare l'interazione tra i gruppi di utenti individuati e l'applicazione. Un dizionario dei dati, che raccoglie le descrizioni degli oggetti informativi più rilevanti nel dominio dell'applicazione. La specifica informale delle site view tramite cui gli utenti eseguiranno le funzioni espresse nei casi d'uso. I requisiti non funzionali a cui l'applicazione deve aderire. Un insieme di linee guida di presentazione, che illustrano lo stile grafico delle interfacce utente che devono essere sviluppate. Raccolta dei requisiti L'attività di raccolta dei requisiti consiste nel revisionare i requisiti di business che guidano lo sviluppo dell'applicazione, individuando e intervistando gli attori principali ed esaminando tutta la documentazione che può far luce sulle funzionalità che devono essere sviluppate. La raccolta dei requisiti è un'attività alquanto destrutturata, in cui risultano essere fondamentali l'esperienza e la recettività dell'analista. Ogni analista con una certa esperienza ha sicuramente la propria lista di linee guida, che egli aggiorna ogni qual volta affronta lo sviluppo di una nuova applicazione. Per queste ragioni, gli esempi di requisiti presentati possono essere interpretati come semplici suggerimenti riguardo una possibile modalità di analisi e specifica. a) Individuazione degli utenti Il primo obiettivo della raccolta dei requisiti è stabilire quali sono gli utenti dell'applicazione e i loro possibili raggruppamenti in base a obiettivi e comportamenti omogenei. Tipicamente, ogni gruppo è associato a una site view diversa che incorpora i contenuti e le funzioni necessarie per rispondere ai requisiti degli utenti del gruppo. Come primo criterio, gli utenti possono essere classificati come interni ed esterni. Gli utenti interni sono i membri dell'organizzazione che forniscono servizi e contenuti, mentre gli utenti esterni sono i clienti o i membri dell'organizzazione che fruiscono dei servizi e dei contenuti. Un'altra utile distinzione può essere quella esistente (soprattutto per applicazioni commerciali) tra utenti business (per esempio utenti registrati, clienti, partner) e utenti non-business (per esempio visitatori, membri di gruppi di interesse, ecc.). Tipicamente, gli utenti business possono accedere a servizi diversi da quelli degli utenti non-business. Per esempio gli utenti registrati accedono a maggiori informazioni rispetto ai visitatori casuali. Per gli utenti business, alcuni criteri di raggruppamento più raffinati possono essere dedotti dal loro ruolo aziendale, oppure dalla funzione organizzativa che essi espletano. Al contrario, il raggruppamento di utenti non-business è principalmente basato sui loro requisiti di accesso a servizi e contenuti. Una volta che una prima lista di gruppi di utenti è stata definita, è possibile analizzare l'esistenza di relazioni gerarchiche tra i gruppi individuati. Per esempio, il gruppo dei direttori commerciali di un'azienda può specializzarsi nei gruppi "direttori commerciali nazionali" e "direttori commerciali europei". Infine, può essere necessario definire un ruolo amministrativo, per rappresentare gli amministratori delle applicazioni, i cui requisiti sono molto diversi rispetto agli utenti "regolari". Essi hanno per esempio diritti speciali per creare e registrare nuovi utenti dell'applicazione, o anche per aggiornare contenuti ad accesso ristretto. Per tali ragioni, gli amministratori dell'applicazione meritano l'introduzione e la specifica di un ulteriore gruppo di utenti. 7/52

b) Requisiti funzionali I requisiti funzionali si riferiscono alle funzioni essenziali che l'applicazione deve offrire ai suoi utenti. L obiettivo dell'attività di raccolta di tali requisiti è indicare i processi che devono essere supportati dall'applicazione. Un processo è un insieme coeso di attività eseguite dagli utenti che interagiscono con l'applicazione. Per esempio, un processo ricorrente nelle applicazioni Web dinamiche di medie dimensioni è la gestione dei contenuti, che riguarda la creazione, modifica verifica dei contenuti che devono essere pubblicati dall'applicazione. Un modo per raccogliere i requisiti funzionali consiste nell'identificare ed determinare un certo numero di casi d'uso. Un caso d uso è una "unità di interazione" tra l'applicazione e uno o più utenti, descrive l'esecuzione di uno specifico processo finalizzato al raggiungimento di un certo obiettivo. L'identificazione dei gruppi è preliminare allo studio dei requisiti funzionali, perché è più naturale esaminare i casi d'uso considerando separatamente i requisiti di ogni gruppo. Per ogni processo individuato nei requisiti di business, è possibile definire un caso d'uso. In caso di processi complessi, può essere conveniente una suddivisione in sotto-processi e la definizione di un caso d'uso per ognuno di essi. Il caso d'uso individuato può inoltre avere varianti o casi speciali, che possono essere descritti da ulteriori casi d'uso. Per esempio, in un'applicazione destinata all'uso mediante dispositivi diversi, la stessa attività per un certo gruppo di utenti può essere supportata in modi diversi, ognuno specializzato per le caratteristiche di un particolare dispositivo di accesso. c) Requisiti dei dati I requisiti dei dati descrivono gli oggetti informativi principali che l'applicazione deve gestire al fine di raggiungere i propri obiettivi. Lo scopo della raccolta di tali requisiti è individuare i dati gestiti dall'applicazione. Il punto di partenza è investigare "dove, quando e da chi" i contenuti dell'applicazione sono prodotti e consumati. L'oggetto di tale analisi sono le organizzazioni e gli utenti business che forniscono i dati all'applicazione e le organizzazioni o gli utenti non-business che li utilizzano. I processi di business alla base dell'applicazione rappresentano un'ulteriore e fondamentale fonte di conoscenza, in quanto la loro analisi permette di scoprire i dati scambiati dagli attori principali e quelli prodotti e consumati da le loro attività. Durante la raccolta dei requisiti, l'analista deve concentrarsi sulla definizione degli elementi dei dati principali, che diventeranno poi i concetti centrali dello schema definito durante la progettazione dei dati. d) Requisiti di personalizzazione I requisiti di personalizzazione si riferiscono alla necessità di fornire contenuti e servizi in diverse modalità, a seconda delle preferenze e dei diritti di accesso degli utenti dell'applicazione. La personalizzazione delle applicazioni Web prevede tre diverse attività: La raccolta e la memorizzazione dei dati relativi agli utenti. L analisi dei dati degli utenti, per poter inferire alcune caratteristiche in base alle quali personalizzare servizi e contenuti. L'effettiva costruzione di un ipertesto in grado di offrire servizi e contenuti personalizzati rispetto alle caratteristiche degli utenti individuate. La raccolta dei dati degli utenti si concentra sulla definizione, sulla popolazione e sul mantenimento dei profili utente. I dati nei profili utente possono essere ottenuti esplicitamente o implicitamente. Nel primo caso, è l'utente a fornire le proprie informazioni personali, registrandosi presso l'applicazione Web e compilando durante la registrazione il proprio profilo personale. Nel secondo caso, l'utente non fornisce alcun dato, ma il profilo richiesto ai fini della personalizzazione è inferito a partire da alcune sorgenti di dati, per esempio dai log che registrano il comportamento dell'utente 8/52

nell'interazione con l'applicazione. Questa inferenza può essere eseguita online, monitorando la navigazione effettuata dall'utente durante la sessione di interazione corrente, oppure off-line, attraverso l'elaborazione di dati di log relativi a interazioni passate. L'analisi dei dati comporta l'elaborazione di dati grezzi circa gli utenti, che permettono di inferire ulteriori proprietà relative ai loro profili. Un esempio di risultato dell'analisi dei dati è la classificazione degli utenti in gruppi omogenei a cui fornire contenuti o servizi speciali. L'analisi dei dati si applica tipicamente a utenti esterni, i cui obiettivi e comportamenti sono sconosciuti. Gli utenti interni sono generalmente raggruppati a priori, durante la progettazione, sulla base dei loro requisiti, che possono essere stimati precisamente prima del rilascio dell'applicazione. La costruzione di un'applicazione personalizzata sfrutta quindi la conoscenza disponibile riguardo gli utenti per poter adattare il contenuto, la navigazione e la presentazione. L'obiettivo della personalizzazione può consistere nell'offrire all'utente un'esperienza d'uso di maggiore attrattiva, o rinforzare il controllo dei diritti di accesso sugli oggetti informativi, laddove all'utente sia consentito di accedere solo a porzioni dei dati e delle pagine di ipertesto. I requisiti di personalizzazione possono variare dal caso più semplice, in cui un'applicazione Web fornisce gli stessi contenuti nella stessa modalità a tutti gli utenti, e quindi non è richiesto alcun profilo utente o alcuna politica di personalizzazione, al caso in cui l'applicazione sia progettata per diverse categorie di utenti interni ed esterni, con sofisticate politiche di personalizzazione per ogni utente, in base ai dati del profilo personale e al gruppo di appartenenza. In questo caso, la raccolta dei requisiti deve individuare i gruppi di utenti rilevanti, i dati che caratterizzano il loro profilo e le porzioni di ipertesto che devono essere personalizzate. e) Requisiti dei dispositivi di accesso Un caso speciale di personalizzazione ricorre nel caso di applicazioni multi-dispositivo o mobili, in cui il contesto di interazione dell'utente può influenzare i requisiti dell'applicazione. In questo scenario, è importante individuare i dispositivi che possono essere usati per l'accesso all'applicazione, raggrupparli in famiglie con capacità di presentazione omogenee e stabilire i vincoli di presentazione che le interfacce dell'applicazione devono rispettare per ogni classe di dispositivi individuata. L'analisi dei dispositivi di accesso può essere ulteriormente raffinata, individuando, per una certa classe, le famiglie di browser che possono essere utilizzati per accedere all'applicazione. Per esempio, è possibile classificare le versioni dei browser Web utilizzati dagli utenti in base al supporto offerto per i vari standard Web (HTML, linguaggi di script a lato client, CSS, XML e XSL, ecc.). Una tale classificazione può essere utilizzata per esprimere con maggiore precisione i vincoli di presentazione. Altri fattori ambientali possono essere rilevanti per fornire contenuti e servizi agli utenti, per esempio la velocità della rete disponibile, la posizione geografica dell'utente, il momento della giornata in cui l'utente accede all'applicazione, ecc. Ognuno di tali fattori può determinare la definizione di politiche appropriate per fornire contenuti e servizi. f) Requisiti non funzionali I requisiti non funzionali riguardano alcuni aspetti che sono rilevanti per il raggiungimento degli obiettivi di business, ma non correlati in modo specifico alle funzionalità del sistema. I requisiti non funzionali coprono un vasto numero di problematiche e di aspetti tecnici e di comunicazione, tra cui alcuni sono particolarmente rilevanti per le applicazioni Web: Usabilità: si riferisce alla facilità d'uso dell'applicazione, che può essere determinata da molteplici fattori, quali la facilità per l'utente nell'imparare a usare le interfacce dell'applicazione, l'aderenza degli oggetti di interazione (menu, link. pulsanti) a standard affermati, l'uso coerente degli oggetti di interazione ne le interfacce dell'applicazione, la 9/52

disponibilità di meccanismi di orientamento e di aiuto e la completezza e la qualità della documentazione. Prestazioni: si riferisce all'efficienza con cui l'applicazione sfrutta le risorse a disposizione. Nel contesto del Web, la risorsa maggiormente critica è il tempo. Le prestazioni sono quindi misurate in termini di numero di pagine che possono essere servite per unità di tempo e di tempo impiegato per servire ogni richiesta. Le prestazioni possono essere valutate in condizioni medie e di picco. Le condizione medie si riferiscono alle situazioni d'uso normali, mentre le condizioni di picco riguardano situazioni speciali, in cui in un breve intervallo di tempo si concentrano numerose richieste. Disponibilità: si riferisce alla frequenza tollerabile di errori e fallimenti, che influenza la percentuale di tempo in cui l'applicazione è disponibile all'utente. Il raggiungimento di un alto livello di disponibilità richiede l'introduzione di risorse ridondanti nell'architettura dell'applicazione, così come l'implementazione di procedure per individuare e gestire errori e guasti e allo stesso tempo mascherare la loro occorrenza. In uno scenario ideale, l'architettura dell'applicazione deve essere progettata in modo che non esista alcun punto singolo di guasto, così da assicurare la sua totale disponibilità. Tuttavia, i vincoli architetturali ed economici sulle risorse possono ostacolare la progettazione di un'architettura ideale. In questo caso, i requisiti di disponibilità per le diverse funzionalità dell'applicazione devono essere raccolti ed esaminati con cura, per poter raggiungere un compromesso ragionevole tra il costo della ridondanza e il rischio di incorrere in guasti. Scalabilità: è l'abilità nell'incrementare le prestazioni dell'applicazione in risposta all'incremento del volume di richieste. La scalabilità si ottiene clonando elementi dell'architettura, in modo che più risorse (server, connessioni alla re, te e apparecchiature di rete) possano supportare un traffico maggiore. I fattori chiave per ottenere la scalabilità sono una topologia dell'architettura adeguata, l'accorpamento di risorse dalle caratteristiche omogenee in raggruppamenti (cluster) e la presenza di procedure di bilanciamento del carico di lavoro per condividere in modo flessibile il carico tra cluster diversi. Le architetture multistrato sono implicitamente concepite per essere scalabili, perché i diversi strati possono essere efficacemente organizzati come cluster e gestiti da sistemi fles sibili per il bilanciamento del carico. Tuttavia, le architetture basate su cluster sono più complesse da gestire rispetto alle architetture semplici. I requisiti di scalabilità devono evidenziare in modo accurato il tasso di crescita del carico di lavoro, in modo da permettere al progettista dell'applicazione di stabilire il corretto compromesso tra complessità e scalabilità. Sicurezza: è un requisito dalle molteplici sfaccettature, che copre diversi aspetti, come per esempio la protezione dell'integrità, la confidenzialità e la privatezza dell'informazione, la disponibilità dei servizi, l'autenticazione degli utenti la protezione del flusso di informazione trasferita tra utenti e applicazione. Nel caso di applicazioni Web offerte al publico di Intemet, la protezione del contenuto costituisce un problema rilevante, che è gestito suddividendo l'architettura dell'applicazione in domini separati aventi diversi livelli di sicurezza: la rete pubblica, accessibile dagli utenti esterni, la rete sicura, in cui sono memorizzati i contenuti aziendali, e un dominio intermedio, spesso denominato zona demilitarizzata (demilitarized zone, DMZ), che separa la rete sicura da,quella pubblica. L'autenticazione degli utenti e la protezione del flusso di informazioni sono particolarmente importanti nel contesto di applicazioni per il commercio elettronico, le quali richiedono un'infrastruttura di fiducia affinché gli utenti eseguano transazioni elettroniche in modo sicuro. Tecniche come la crittografia a chiave segreta o pubblica e la firma digitale devono essere adottate quando le transazioni sicure rientrano tra i requisiti dell'applicazione. Manutenibilità: riguarda la facilità con cui è possibile porre rimedio agli errori dell' applicazione e adattare l'applicazione Web a requisiti nuovi o a variazioni dei requisiti 10/52

iniziali. Sebbene la manutenibilità sia un fattore associato soprattutto alla qualità dell'applicazione finale, esso si riferisce anche al processo di sviluppo, in quanto questo deve essere organizzato e condotto in modo da garantire la correzione degli errori e l'evoluzione dell'applicazione. La manutenibilità può essere facilitata dalla semplicità del progetto, dalla modularità del software e dalla completezza e chiarezza della documentazione. Una progettazione dell'applicazione basata su modello può fortemente incrementare la manutenibilità, in quanto aiuta a specificare, comunicare e documentare applicazione e facilita inoltre la gestione dei cambiamenti. La manutenibilità anche essere migliorata dall'adozione di un'architettura software modulare che permetta agli sviluppatori di intervenire separatamente sulle diverse componenti dell'applicazione. Analisi dei requisiti L' analisi dei requisiti ha l'obiettivo di rappresentare in documenti semi-formali la conoscenza raccolta riguardo l'applicazione. Tali documenti costituiscono l'input per la progettazione dell'applicazione. Prima dell'inizio della fase di progettazione è infatti necessario individuare le seguenti informazioni: I principali gruppi di utenti e le relazioni gerarchiche tra essi esistenti. I principali casi d'uso (use case), che risultano dalla raccolta dei requisiti funzionali, e i gruppi a cui si riferiscono. Il dizionario dei dati con la descrizione degli oggetti informativi e le associazioni semantiche tra essi esistenti. Le site view richieste e il loro assegnamento ai gruppi di utenti che dovranno utilizzarle. Le linee guida essenziali relative agli aspetti di presentazione e di usabilità dell'interfaccia. La specifica dei test di accettazione per la valutazione dei requisiti non funzionali, per esempio il test di accettazione per le prestazioni. I requisiti di personalizzazione sono trasversali, in quanto coprono tutti gli aspetti dell'analisi dei requisiti: I dati dei profili degli utenti e i diritti di accesso sono definiti nella specifica dei gruppi di utenti. Le politiche di personalizzazione dei contenuti e della navigazione sono espresse nella specifica dei casi d'uso e delle site view. Le politiche di personalizzazione della presentazione sono espresse nelle linee guida di presentazione. a) Specifica dei gruppi In diversi casi, un'applicazione Web è indirizzata a diverse categorie di utenti, che possono essere individuate durante la progettazione e quindi formalizzate primi del rilascio dell'applicazione in un insieme di gruppi di utenti. I gruppi possono essere organizzati gerarchicamente, per denotare che un certo insieme di utenti con requisiti omogenei si specializza in sotto-gruppi, caratterizzati da ulteriori proprietà rispetto al gruppo iniziale. Per ogni gruppo individuato è raccomandabile compilare un foglio di specifica con i seguenti elementi: Nome: il nome del gruppo. Descrizione: una descrizione concisa dei criteri di raggruppamento utilizzatiche caratterizzano gli utenti del gruppo. Dati di profilo: un insieme di attributi che caratterizzano i membri del gruppo e l'indicazione della modalità di raccolta (tramite richiesta esplicita all'utente o tramite computazioni a partire da altri dati). 11/52

Super-gruppo: il gruppo che generalizza le caratteristiche comuni ai vari sottogruppi (opzionale) Sotto-gruppo: la lista dei sotto-gruppi che esprimono proprietà speciali di membri selezionati del gruppo (opzionale). Casi d'uso: la lista dei casi d'uso più rilevanti a cui gli utenti del gruppo partecipano. Diritti d'accesso: i dati essenziali accessibili o gestibili dagli utenti di un gruppo. Questo elemento della specifica si divide in due sotto-campi: Oggetti accessibili in lettura e Oggetti accessibili in scrittura. b) Specifica dei casi d'uso Un caso d'uso rappresenta un'unità di interazione tra utenti di un certo gruppo e applicazione. Ogni caso d'uso può essere descritto da un foglio di specifica, che include i seguenti elementi: Nome: il nome del caso d'uso. Scopo: una breve descrizione della funzionalità rappresentata dal caso d'uso. Pre-condizione: la condizione che deve essere soddisfatta prima dell'esecuzione del caso d'uso. Post-condizione: la condizione che diventa vera a seguito dell'esecuzione del caso d'uso. Workflow: i passi elementari che devono essere eseguiti per portare a termine con successo il caso d'uso. Le interazioni tra gruppi di utenti e casi d'uso possono essere descritte per mezzo di diagrammi UML dei casi d'uso. In tali diagrammi, gli utenti sono rappresentati con un simbolo grafico e sono connessi ai casi d'uso, rappresentati da ovali a cui partecipano. c) Specifica dei dizionario dei dati La specifica del dizionario dei dati produce la lista degli oggetti informativi princpali iindividuati durante la raccolta dei requisiti dei dati. Ogni voce del dizionario dei iati può essere caratterizzata per mezzo delle seguenti proprietà: Nome: il nome principale con cui l'oggetto è identificato Sinonimi: nomi alternativi usati nel dominio applicativo per denotare lo stesso concetto Descrizione: una descrizione breve del significato dell'oggetto nel dominio applicativo. Istanze campione: una o più istanze rappresentative, che possono facilitare la comprensione del concetto. Proprietà: una lista di attributi essenziali dell'oggetto, di cui si specifica il nome e una breve descrizione. Relazioni: una lista delle relazioni più significative esistenti con altri oggetti. Componenti: una lista dei componenti interni dell'oggetto più significativi. I componenti corrispondono a proprietà complesse ed eventualmente multivalore, che possono perciò essere descritte per mezzo di ulteriori oggetti informativi. Super-concetto: il concetto che generalizza le caratteristiche dell'oggetto informativo (opzionale). Sotto-concetti: la lista dei concetti che specializzano l'oggetto informativo (opzionale). d) Specifica delle site view La specifica delle site view produce la lista delle site view che sono necessarie per soddisfare i requisiti dei gruppi di utenti individuati. L'input per tale attività è la lista dei gruppi di utenti, la lista dei casi d'uso e il dizionario dei dati: una site view supporta infatti i casi d'uso associati a uno o più gruppi e offre accesso ai dati, o funzionalità di gestione di elementi di dati selezionati.per ogni site view, è possibile compilare un foglio di specifica con i seguenti elementi: Nome della site view: il nome della site view. Descrizione: una breve spiegazione dello scopo della site view. 12/52

Gruppi di utenti: la lista di gruppi di utenti che hanno accesso alla site view. Casi d'uso: la lista dei casi d'uso coperti dalla site view. Mappa della site view: una tabella annidata che illustra le diverse aree che compongono una site view. La tabella include i seguenti elementi: o Nome dell'area: il nome dell'area. o Descrizione dell'area: una breve descrizione dei contenuti e dei servizi forniti dall'area. o Oggetti accessibili o gestibili: la lista degli oggetti informativi specificati nal dizionario dei dati, che sono accessibili o manipolabili all'interno dell'area o Livello di priorità: un valore numerico simbolico, che riflette l'importanza dell'area. Il progettista userà tale priorità per stabilire l'ordine in cui le aree devono essere considerate nelle varie iterazioni di progetto e implementazione. In principio, un'area deve avere priorità alta se riguarda requisiti "importanti", deve essere progettata e implementata indipendentemente dalle altre aree e la sua disponibilità influenza il progetto, l'implementazione o il testing altre aree nella site view. e) Specifica delle linee guida per lo stile grafico Le linee guida per lo stile grafico stabiliscono le regole per la presentazione delle pagine, che sono poi utilizzate nella produzione delle interfacce dell'applicazione. Tali linee guida coprono i seguenti aspetti: Specifica della griglia di pagina: una griglia di pagina è una tabella che contiene certa disposizione di righe, colonne e celle, che rappresentano l'organizzazione della pagina in cui sistemare contenuti statici e dinamici. La specifica della griglia di pagina può definire il numero di righe e colonne e la dimensione assoluta o relativa dei vari elementi della griglia. Griglie di pagina alternative possono essere specificate per rappresentare pagine con diverse disposizioni di contenuti. Specifica del posizionamento dei contenuti: riguarda le regole per assegnare elementi di contenuto standard, come banner, menu, sotto menu, e campi di input per la login e per la ricerca, a posizioni selezionate nella griglia di pagina. Linee guida di posizionamento adeguate aiutano a ridurre il sovraccarico cognitivo dell'utente durante la fase di apprendimento dell'applicazione, in quanto forzano il posizionamento di elementi dalla semantica simile nella stessa posizione lungo pagine diverse, con l'effetto di ridurre il disorientamento dell'utente finale. Linee guida grafiche: si riferiscono alle regole di formattazione per gli elementi grafici, come caratteri, colori, bordi e margini. Tali regole si applicano a elementi ricorrenti nella pagina, per esempio testi, titoli, intestazioni e piè pagina ancore, tabelle, liste, menu, ecc. Le regole di formattazione possono essere espresse per mezzo di fogli di stile in cascata (Cascading Style Sheet - CSS) o tramite specifiche equivalenti. Linee guida specifiche per i dispositivi e per i browser: alcune linee guida devono riguardare i dispositivi di accesso con requisiti di presentazione speciali, come per esempio dispositivi con schermi di piccole dimensioni o monocromatici. Ulteriori linee guida possono essere necessarie anche relativamente a limitazioni per versioni obsolete dei browser utilizzati dagli utenti, come per esempio i browser che non supportano la versione 4 di HTML e i CSS. Le linee guida di stile sono spesso rappresentate tramite mock-up di pagina. I mock-up sono rappresentazioni d'esempio per uno specifico dispositivo e linguaggio di presentazione di alcune pagine tipiche dell'applicazione, per esempio la home page e le pagine più importanti da essa raggiungibili. I mock-up sono particolarmente efficaci, perché forniscono indicazioni facili da interpretare circa la modalità in cui i contenuti statici e dinamici devono essere organizzati. Inoltre. essi presentano il vantaggio di essere immediatamente comprensibili anche da non esperti di grafica, 13/52

offrendo quindi la possibilià di testare l'applicazione con campioni di utenti reali sin dalle primissime fasi di sviluppo. f) Specifica dei test di accettazione I requisiti non funzionali riguardo le prestazioni, la disponibilità, la scalabilità, la sicurezza e la manutenibilità possono essere formalizzati in un piano di test di accettazione, eseguito sull'implementazione dell'applicazione per accertare se il livello di servizio richiesto è stato raggiunto. I test di accettazione si concentrano tipicamente sulle prestazioni, per le quali si definiscono tempi di risposta accettabili in diverse condizioni di carico, e sulla disponibilità, per cui si cerca di stabilire la risposta dell'applicazione a diversi tipi errori. La definizione dei test di accettazione è una questione tecnica, relativa alla progettazione dell'architettura dell'applicazione. La progettazione dei dati La progettazione è l'attività in cui la conoscenza riguardo l'applicazione, raccolta e formalizzata durante la specifica dei requisiti, è trasformata nella descrizione di componenti software. Inizialmente ci si deve concentrare sulla progettazione dei dati e attraverso il dizionario dei dati, prodotto dall'analisi dei requisiti per i principali oggetti informativi dell'applicazione, si individua la struttura della base di dati (anche utilizzando linguaggi di modellazione ben consolidati come il modello Entity-Relation). La progettazione concettuale dei dati riveste ancora un ruolo importante e non deve essere troppo influenzata dalle scelte progettuali e dall'implementazione delle sorgenti di dati eventualmente esistenti. Questo perchè la progettazione dei dati è un mezzo essenziale per chiarire i requisiti applicativi. Sviluppare un'applicazione Web senza riconsiderare la struttura dei suoi dati può portare ad ambiguità nei requisiti e a errori di progettazione. La progettazione dei dati, inoltre, produce suggerimenti utili per la progettazione dell'ipertesto. Le due attività traggono infatti benefici l'una dall'altra e la loro esecuzione in parallelo permette al progettista di eseguire diversi controlli incrociati. I dati di un applicazione Web sono spesso utilizzati per scopi abbastanza specifici, come per esempio classificare oggetti per facilitarne l'accesso, interconnettere oggetti per definire percorsi di navigazione, o supportare meccanismi di personalizzazione. Le strutture dati corrispondenti non sono normalmente presenti nello schema di una base di dati concepita per un sistema informativo tradizionale. Nel caso in cui si utilizzino sorgenti dei dati preesistenti, tali strutture dovrebbero quindi essere progettate da zero in base ai requisiti dell'applicazione. Ciò implica che, anche se il contenuto è totalmente o parzialmente riusato, è raccomandabile eseguire comunque la progettazione dei dati, così da produrre uno schema, ad esempio di Entità-Relazione, conforme ai requisiti dell'applicazione Web. Un supporto rilevante per la definizione dello schema dei dati deriva dalla comprensione dei ruoli che gli oggetti informativi assumono nell'applicazione. E' possibile distinguere tra quattro tipi diversi di oggetti: Oggetti core (o oggetti centrali): costituiscono gli oggetti più importanti che l'applicazione deve gestire, già individuati durante la fase di analisi dei requisiti. in un'applicazione Web, questi sono gli oggetti principali a cui accedono gli utenti esterni e allo stesso tempo sono quelli gestiti da utenti interni autorizzati ad amministrare i contenuti dell'applicazione. Nel caso in cui un oggetto core sia caratterizzato da proprietà complesse e da componenti interni, esso può essere rappresentato nello schema dei dati da più di un'entità. Oggetti di interconnessione: rappresentano le associazioni semantiche tra oggetti core definite nel dizionario dei dati. In un'applicazione Web, tali oggetti sono utilizzati per definire link e indici per la navigazione tra oggetti. Dal punto di vista del modello Entità- 14/52

Relazione, ad esempio, gli oggetti di interconnessione sono relazioni definite tra entità core per esprimere associazioni semantiche. Oggetti di accesso: sono oggetti ausiliari utilizzati per classificare o specializzare gli oggetti core, allo scopo di facilitarne l'accesso in diversi modi: o o o Definendo una categorizzazione sugli oggetti core, che può essere utilizzata per costruire gerarchie di indici, che progressivamente conducono l'utente agli oggetti core desiderati. Definendo meccanismi di ricerca per parole chiave, che si concentrano su categorie di oggetti core ben definite e sono quindi caratterizzati da un maggior grado di precisione. Raggruppando gli oggetti core più significativi in collezioni speciali, per esempio le collezioni dei prodotti più venduti o delle offerte del giorno, che possono essere utilizzate per accedere direttamente agli oggetti core più interessanti per gli utenti. Gli oggetti di accesso sono normalmente rappresentati da entità, connesse alle entità core tramite relazioni o associazioni di specializzazione. Anche nel caso degli oggetti di accesso, è più appropriato parlare di sotto-schemi di accesso. in quanto lo stesso oggetto core può essere classificato o specializzato in modi diversi, usando diverse entità di accesso, relazioni e sottoentità specializzate. Oggetti di personalizzazione: sono utilizzati per incorporare nel modello dei dati le proprietà rilevanti dell'utente, necessarie per poter soddisfare i requisiti di personalizzazione. Per esempio, alcune entità possono essere usate per modellare i profili degli utenti ed eventuali gruppi in cui gli utenti sono classificati. Alcune relazioni possono poi essere utilizzate per associare le entità che rappresentano gli utenti e i gruppi alle entità che rappresentano gli oggetti dell'applicazione, così da modellare sia l'appartenenza di oggetti a specifici utenti. sia preferenze di utenti e gruppi verso alcuni oggetti. Il processo della progettazione dei dati può essere strutturato come un'attività incrementale e iterativa. A partire da un nucleo iniziale, generalmente costituito dai concetti core più importanti, il progettista dei dati può progressivamente estendere lo schema, applicando operazioni di raffinamento, che comportano la specifica dettagliata degli oggetti core, aggiunta dei dati di interconnessione, di accesso e di personalizzazione. La progettazione dell ipertesto La progettazione dell'ipertesto produce la specifica delle site view che devono essere costruite al di sopra dello schema dei dati per pubblicare i contenuti e le operazioni di manipolazione dei dati individuati durante l'analisi dei requisiti. La progettazione dell'ipertesto deve essere indipendente da ogni dettaglio implementativo, ma abbastanza precisa da poter essere usata come guida per l'implementazione. Il flusso delle attività nella progettazione dell'ipertesto procede in modalità top-down, ovvero dall'alto verso il basso attraverso raffinamenti successivi, e parte dalla progettazione generale o preliminare, fino ad arrivare alla progettazione dettagliata. La progettazione generale o preliminare ha lo scopo di definire uno schema della site view ad alto livello, quindi privo di dettagli, che utilizza una notazione testuale informale per esprimere l'assegnamento degli elementi dei dati alle aree delle site view in cui questi sono utilizzati. Le aree già delineate nelle mappe delle site view prodotte durante la specifica dei requisiti vengono quindi consolidate e per esse viene definito un livello di visibilità, in base al quale sono definite come aree di default, landmark, o interne. Il progettista specifica quindi il contenuto dell'area, indicando gli 15/52

elementi dello schema dei dati che saranno utilizzati per popolare l'arca. Nel fare questo, particolare attenzione è rivolta al ruolo assunto dai vari oggetti informativi all'interno dell'applicazione. Questi possono infatti essere utilizzati per facilitare l'accesso ad altri dati, per rappresentare concetti centrali per l'applicazione, o per supportare la personalizzazione. La progettazione dettagliata rappresenta un raffinamento della progettazione preliminare, in cui gli schemi grezzi delle site view sono progressivamente revisionati fino a farli diventare collezioni di pagine conformi ai requisiti dell'applicazione. Il primo passo della progettazione dettagliata consiste nell'identificazione delle pagine e nella loro classificazione come pagine home, landmark o interne. Quindi, le unità di contenuto e le operazioni associate alle aree sono combinate secondo particolari configurazioni. La progettazione dettagliata si basa infatti sull'utilizzo di pattern ricorrenti di pagine e unità, definiti a partire dagli schemi individuati a livello dei dati. Il linguaggio di modellazione per l organizzazione dell'ipertesto La specifica di ipertesti complessi può essere organizzata gerarchicamente, utilizzando costrutti di modularizzazione, come le site view, le aree e le pagine. a) Site view: Le site view sono caratterizzate da un nome definito dall'utente e contengono un insieme di pagine e/o aree. Le specifiche grafiche elencano le aree e le pagine di alto livello che sono incluse direttamente nella site view. Una site view rappresenta un ipertesto coerente per soddisfare un insieme ben definito di requisiti, per esempio relativi a uno specifico gruppo di utenti. In applicazioni complesse, ci possono essere diverse site view definite sullo schema dei dati e site view complesse possono essere decomposte gerarchicamente in aree, ovvero gruppi di pagine con uno scopo omogeneo. b) 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. La maggior parte di siti Web reali sono partizionati in aree. Ogni area viene quindi definita separatamente, elencando le sue pagine e le sue sotto-aree. c) Pagine: Le pagine costituiscono gli elementi di interfaccia e di navigazione forniti all'utente. Tipicamente una pagina contiene diverse unità di contenuto, raggruppate per comunicare dei concetti ben definiti. La specifica di una pagina è astratta e non ha nulla a che fare con gli aspetti di presentazione, come la posizione relativa degli elementi di contenuto in HTML. Alcune proprietà di pagine e aree, come le proprietà di essere home, landmark e default, permettono al progettista di mettere a punto il livello di visibilità di questi costrutti all'interno della struttura gerarchica della site view. d) Unità di contenuto: Le unità di contenuto rappresentano le parti atomiche di contenuto da pubblicare; offrono modalità alternative per organizzare il contenuto estratto dinamicamente dallo schema dei dati e permettono anche la specifica di moduli per l'inserimento di dati da parte dell'utente. Le unit costituiscono gli elementi di base delle pagine. Tipicamente le pagine vengono costruite assemblando unità di vario tipo, per ottenere l'effetto di comunicazione desiderato. e) Link: Le pagine e le unit sono collegate tramite link per formare una struttura ipertestuale. I link rappresentano un aspetto fondamentale nella modellazione ipertestuale; esprimono la possibilità di navigare da un punto all'altro all'interno dell'ipertesto e di passare parametri da una unit all'altra, requisito necessario per il corretto calcolo del contenuto di una pagina. I link possono essere disegnati tra pagine e unità di contenuto, ma possono, anche, attraversare i bordi delle aree. Se si segue un link inter-area significa semplicemente che il focus si muove da una pagina di un'area alla pagina di un'altra area. 16/52

f) Parametri globali: a livello di site view si possono specificare parametri globali, per denotare delle informazioni che devono essere memorizzate durante la navigazione dell'utente e che possono essere estratte successivamente e utilizzate nella computazione del contenuto di alcune pagine. Le primitive appena descritte stanno alla base della modellazione di ipertesti per la pubblicazione di contenuti previste dal linguaggio di modellazione WebML. Unità di contenuto Le unità sono gli elementi atomici utilizzati per specificare il contenuto di una pagina Web. WebML prevede cinque tipi di unit: Data unit: mostra i dati di un singolo oggetto. Multidata unit: mostra i dati di un insieme di oggetti. Index unit: mostra una lista di proprietà descrittive di alcuni oggetti, senza presentare i loro dati in dettaglio. Scroller unit: permette la navigazione di un insieme ordinato di oggetti, fornendo i comandi per accedere al primo, all'ultimo, all'elemento precedente e a quello successivo all'interno di una sequenza. Entry unit: modella form, i cui campi permettono di ricevere l'input necessario per effettuare ricerche oppure per alimentare operazioni di aggiornamento. I cinque tipi di unit di contenuto possono essere combinati per rappresentare pagine Web di complessità arbitraria. Le prime quattro unit modellano la pubblicazione di informazioni, mentre le entry unit esprimono l'acquisizione di informazione da parte degli utenti. Delle prime quattro unit, la data e la multidata unit presentano il contenuto degli oggetti a cui si riferiscono, mentre l'index e la scroller unit supportano la selezione di oggetti. La data unit si riferisce a un singolo oggetto, mentre la multidata, l'index e la scroller unit si riferiscono a un insieme di oggetti. La data, la multidata, l'index e la scroller unit presentano il contenuto estratto dallo schema dei dati; pertanto è necessario specificare esattamente il loro contenuto. WebML utilizza due concetti per esprimere l'origine del contenuto di una unit: la sorgente e il selettore. La sorgente è il nome dell'entità dalla quale viene estratto il contenuto della unit. Quindi l'entità sorgente indica il tipo degli oggetti utilizzati per calcolare il contenuto della unit. Una unit di contenuto può essere associata a un'entità sorgente, nel caso più comune, oppure a un insieme di entità sorgenti. Il selettore è un predicato, utilizzato per determinare gli oggetti delle entità sorgenti che contribuiscono al contenuto della unit. Viene espresso come congiunzione di condizioni elementari, costruite a partire dagli attributi delle entità e dai ruoli delle relazioni in cui l'entità è coinvolta, oppure da termini costanti o variabili. I termini variabili vengono costruiti utilizzando parametri associati ai link in ingresso alla unit. I selettori in cui le condizioni utilizzano parametri vengono detti selettori parametrici. Figura 2 Notazione grafica e testuale di una unit. Le unit di contenuto vengono rappresentate graficamente come dei rettangoli che racchiudono un'icona come illustrato in Figura 2, che mostra un esempio di index unit. Il nome della unit viene 17/52

posto all'interno del rettangolo, sopra l'icona. la sorgente e il selettore sono posti sotto il rettangolo: nell'esempio, la index unit ha come entità sorgente Album e include un selettore [Anno=2000], costituito dall attributo Anno, da un predicato di uguaglianza e dal termine costante 2000. a) Data unit: La data unit pubblica i dati di un singolo oggetto di una determinata entità. data unit è caratterizzata dalle seguenti proprietà: Nome: nome definito dall'utente per la data unit. Sorgente: entità che fornisce il contenuto alla unit. Selettore (opzionale): predicato che identifica un unico oggetto, che verrà sualizzato dalla unit. Il selettore di una data unit è opzionale, ma può essere omesso solamente nel caso in cui l'entità sorgente abbia una sola istanza altrimenti l'oggetto da visualizzare risulta essere indefinito. Attributi da visualizzare: insieme di attributi dell'entità sorgente da visualizzare. La Figura 3 mostra la notazione grafica WebML per rappresentare una dataunit di nome Artista. L'entità sorgente e il selettore della unit sono evidenziati sotto l'icona. La unit è definita sull'entità Artista e mostra l'oggetto specifico determinato valutando il suo selettore, che è dato dalla congiunzione di due predicati, sugli attributi Nome e Cognome. Poichè Nome e Cognome sono stati definiti come chiave per l'entità Artista, la valutazione del selettore produce un singolo oggetto che viene mostrato dalla data unit. La Figura 2 mostra anche una possibile presentazione della data unit in un'implementazione basata su HTML. Figura 3 Notazione grafica di una data unit e presentazione in HTML. Il selettore di Figura 3 contiene una congiunzione di due predicati semplici. Oltre alla congiunzione è possibile specificare forme di disgiunzione come la disgiunzione di valori o disgiunzione di attributi. Nel primo caso un singolo attributo viene confrontato con un insieme di valori utilizzando l'espressione [attributo operatore valorel valore2... valoren]. Quest'espressione corrisponde al predicato (attributo operatore valorel) OR (attributo operatore valore2) OR... OR (attributo operatore valoren). Un esempio di condizione che utilizza la disgiunzione di valori è: LuogoNascita contains "Italia" or "Francia". Nel secondo caso un insieme di attributi viene confrontato con un singolo valore utilizzando l'espressione [attributo1 attributo2... attributon operatore valore]. Questa notazione corrisponde al predicato (attributo1 operatore valore) OR (attributo2 operatore valore) OR... OR (attributon operatore valore). Un esempio di disgiunzione di attributi è: DataNascita Biografia contains "Italia". b) Multidata unit: La multidata unit presenta un insieme di oggetti di un'entità, ripetendo la presentazione di molte data unit. Pertanto, una multidata unit è caratterizzata dalle seguenti proprietà: Nome: nome definito dall'utente per la multidata unit. Sorgente: entità che fornisce il contenuto alla unit. Selettore (opzionale): predicato che determina gli oggetti che la unit deve visualzzare. Se il selettore non viene definito, vengono considerate tutte le istanze dell'entità. 18/52

Attributi da visualizzare: insieme di attributi dell'entità sorgente da visualizzare per ogni oggetto mostrato dalla multidata unit. Clausola di ordinamento (opzionale): insieme di attributi utilizzati per ordinare gli oggetti della multidata unit e criterio di ordinamento da applicare, che può essere crescente oppure decrescente. Se non viene esplicitato, si assume che l'ordinamento sia crescente. La Figura 4 mostra la notazione grafica WebML per rappresentare le multiunit, con la loro sorgente e nessun selettore. La unit Artisti è definita sull'entità Artista e, poiché non è stato specificato il selettore, mostra tutti gli oggetti esistenti. Gli artisti sono ordinati in base al cognome e al nome e visualizzati utilizzando gli attributi cognome, nome e foto Figura 4 Notazione grafica di una multidata unit e sua presentazione in HTML. Gli attributi utilizzati per l'ordinamento vengono considerati in sequenza: gli artisti vengono ordinati dapprima in base al cognome e, se più artisti hanno lo stesso cognome, in base al nome. c) Index unit: L'index unit presenta un insieme di oggetti di un'entità come una lista. La specifica di una index unit include le seguenti proprietà: Nome: nome definito dall'utente per la index unit. Sorgente: entità che fornisce il contenuto alla unit. Selettore (opzionale): predicato che determina gli oggetti che la unit deve visualizzare. Se il selettore non viene definito, vengono considerate tutte le istanze dell'entità. Attributi da visualizzare: insieme di attributi dell'entità sorgente utilizzati per visualizzare gli elementi dell'indice. Clausola di ordinamento (opzionale): insieme di attributi utilizzati per ordinare gli oggetti della index unit e criterio di ordinamento da applicare, che può essere crescente oppure decrescente. Se non viene esplicitato si assume che l'ordinamento sia crescente. Per capire meglio la differenza tra multidata e index unit, bisogna dire che l'index unit tipicamente viene utilizzata per selezionare un particolare oggetto. Al contrario, le multidata unit possono essere utilizzate per elaborare tutti gli oggetti mostrati dalla unit. Figura 5 Notazione grafica di una index unit e presentazione in HTML. La Figura 5 mostra la notazione grafica WebML per rappresentare un index unit, con la sua sorgente e nessun selettore. La unit IndiceAlbum è definita sull'entità Album e mostra tutte le istanze. Gli album vengono visualizzati utilizzando solamente l'attributo titolo in ordine alfabetico crescente. Le index unit ammettono due varianti per scegliere oggetti multipli e per organizzare la lista delle voci dell'indice in modo gerarchico. Laprima variante è rappresentata dalla multi-choice index unit, 19/52

in cui ogni elemento della lista è associato a una casella di scelta che permette all'utente di selezionare un insieme di oggetti anzichè un singolo oggetto. La notazione grafica per rappresentare una multi-choice index unit e una sua possibile presentazione HTML sono mostrate in Figura 6. La unit SelezioneAlbum definita sull'entità Album e mostra tutte le istanze. Le istanze di Album sono rappresentate dal loro titolo ed elencate in ordine alfabetico. Figura 6 Notazione grafica di una multi-choice index unit e possibile presentazione in HTML. La seconda variante di index unit è rappresentata dal concetto di hierarchical index (indice gerarchico), in cui le voci dell'indice sono organizzate secondo un albero a più livelli. La gerarchia è rappresentata da una sequenza di N entità sorgenti, connesse da N-1 ruoli di relazione. La prima entità sorgente rappresenta le istanze al livello più alto della 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 nella gerarchia. Figura 7 Notazione grafica di una hierarchical index unit e possibile presentazione in HTML. La Figura 7 mostra la notazione grafica WebML per una hierarchical index unit. L'indice mostra una gerarchia a due livelli di album e brani. Le voci al livello più esterno sono tutte le istanze dell'entità Album e, per ogni istanza di album, vengono elencati tutti i brani a essa associati in base al ruolo di relazione Album-Brano. Figura 8 Hierarchical index unit con selettori su tutte le entità sorgenti. La Figura 8 mostra una hierarchical index unit che include gli album pubblicati nell'anno 2000 e, per ogni album, mostra solo i brani la cui durata è inferiore a 2 minuti. d) Scroller unit: La scroller unit fornisce i comandi per navigare una sequenza di oggetti, per esempio tutte le istanze di un'entità. La specifica di una scroller unit è caratterizzata dalle seguenti proprietà: Nome: nome definito dall'utente per la scroller unit. 20/52