progettazione di applicazioni web - isdigital.it · analisi dei requisiti 11 progettazione dei dati...

Dispensa del corso di Tecnologie e applicazioni Internet – Progettazione di applicazioni Web

1/52

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.


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


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


4/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à


5/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


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


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


8/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


9/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


10/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


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


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


13/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,


14/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à-


15/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 Definendo una categorizzazione sugli oggetti core, che può essere utilizzata per costruire gerarchie di indici, che progressivamente conducono l'utente agli oggetti core desiderati.

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

o 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 sotto-entità 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


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


17/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


18/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à.


19/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,


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


21/52

• 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à. • Blockfactor (numero di elementi di un blocco): numero di oggetti visualizzati all'interno di

una schermata. Di default, il block factor vale 1, che indica che a ogni schermata si mostra un oggetto per volta.

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

La Figura 9 mostra la notazione grafica per rappresentare una scroller unit e la sua possibile presentazione in un'implementazione basata su HTML. La unit NavigazioneAlbum è definita sull'entità Album e non presenta selettori; pertanto essere utilizzata per scorrere l'insieme di tutti gli album. In particolare, è possibile spostarsi sul primo, sull'ultimo, sull'album precedente oppure su quello successivo, in base alla clausola di ordinamento specificata.

Figura 9 Notazione grafica di una scroller unit e presentazione in HTML.

Nell'esempio di Figura 10 il block factor è impostato a 1 e lo scroller è posizionato sul 35-esimo elemento di una lista di 150 album.

e) Entry unit: L'entry unit supporta l'inserimento di dati tramite form. Viene utilizzata per ricevere tre l'input dall'utente, che viene tipicamente impiegato per: effettuare ricerche all'interno di un insieme di oggetti di un'entità, per esempio per individuare le istanze di un'entità i cui attributi contengono una determinata parola chiave; fomire i parametri a operazioni che aggiornano i contenuti della base di dati, per effettuare login, ecc. Le entry unit sono caratterizzate dalle seguenti proprietà:

• Nome nome definito dall'utente per la scroller unit. • Campi insieme di campi per inserire i valori.

Figura 10 Notazione grafica di una entry unit e presentazione in HTML.

La Figura 10 mostra la notazione grafica per un'entry unit (ImmissioneArtista). Come mostrato in quest'esempio, l'entry unit ha quattro campi, per inserire il nome, il cognome, la data di nascita e del decesso di un artista.

I campi delle entry unit corrispondono ai campi di input che si trovano normalmente nei costrutti delle form dei linguaggi di mark-up. I campi possiedono diverse proprietà:

• Nome: nome del campo. • Tipo: tipo dei dati del valore immesso nel campo (per esempio string, text, date ecc.).


22/52

• Valore iniziale: valore di default proposto all'utente. • Modificabilità: valore booleano che specifica se l'utente può modificare il valore iniziale del

campo; di default tutti i campi sono modificabili. • Predicato di validità: condizione booleana applicabile al valore immesso dall'utente che

permette di verificame la validità. Il predicato di validità può essere una qualsiasi espressione logica costruita utilizzando il nome del campo, un operatore applicabile al tipo di dato del campo e un termine costante oppure variabile. Il termine variabile può essere il nome di un altro campo; in questo modo è possibile per effettuare il confronto tra i valori inseriti dall'utente in campi diversi, per esempio per assicurare che la data di morte di un artista sia successiva a quella di nascita. Si può utilizzare la parola chiave not null per specificare che l'utente deve inserire un valore per il campo.

Pagine e link

Le pagine costituiscono gli elementi di interfaccia forniti all'utente. Tipicamente una pagina contiene diverse unit, raggruppate per comunicare dei concetti ben definiti.

La Figura 11 mostra la notazione grafica per le pagine, che consiste semplicemente in un rettangolo etichettato che racchiude le unit che appartengono alla pagina Nell'esempio, la pagina di nome Album contiene due index unit, una per visualizzare la lista di tutti gli artisti e una per mostrare la lista di tutti gli album. L'esempio mostra anche una possibile visualizzazione della pagina in HTML, che aggrega la presentazione delle due index unit.

Figura 11 Notazione grafica di una pagina.

Le pagine e le unit non vivono isolate: gli ipertesti reali sono costituiti da pagine connesse, che contengono diverse parti di contenuto collegate tra loro e comandi che permettono all'utente di interagire con l'applicazione. Per esprimere queste caratteristiche, le pagine e le unit possono essere collegate tramite link, per specificare i possibili percorsi navigazionali tra le pagine, le possibili selezioni offerte all'utente e l'effetto dell'interazione dell'utente sul contenuto delle unit visualizzate nella pagina.

Il modello navigazionale fa parte del modello ipertestuale e specifica i link tra le unit e le pagine e le proprietà dei link. Le nozioni principali del modello navigazionale sono i concetti di link, parametri dei link e selettori parametrici.

• Un link è un collegamento orientato tra due unit o pagine.

• Un parametro di un link è la specifica di un'informazione che viene trasportata dalla sorgente alla destinazione del link.

• Un selettore parametrico è il selettore di una unit i cui predicati contengono riferimenti a dei parametri di link.

I link astraggono e generalizzano la nozione fondamentale degli ipertesti: il concetto di ancora. Un'ancora è uno strumento attivo, per mezzo del quale l'utente può interagire con l'ipertesto.


23/52

La nozione di ancora deve essere considerata in senso ampio. I casi pratici che seguono, che si riferiscono a un ipertesto basato su HTML, sono tutti esempi di cosa può essere considerato un'ancora:

• Un tag di ancora HTML con un attributo href che si riferisce a un'altrapagina. Selezionando il link la pagina visualizzata viene sostituita con la pagina a cui si riferisce l'ancora.

• Un tag di ancora HTML con un attributo href che si riferisce alla stessapagina. Selezionando il link la pagina corrente viene rivisualizzata, eventualmente con del nuovo contenuto; per esempio, dopo aver selezionato una voce da un indice vengono mostrati i dettagli di un nuovo oggetto.

• Il tasto di conferma di una form HTML utilizzato per effettuare una ricerca. L'immissione dell'input nella form e la pressione del tasto di invio fanno in modo che venga visualizzata una nuova pagina o la pagina stessa con i risultati della ricerca.

• Il tasto di conferma di una form HTML utilizzato per inviare l'input a un'operazione, per esempio per accedere tramite password a un sito.

Come suggeriscono questi esempi, l'essenza di un link è duplice:

• Permette la navigazione dell'ipertesto: l'utente può muoversi da una pagina sorgente a una pagina di destinazione.

• Trasporta informazioni da una unit a 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.

Nella terminologia WebML, i link che attraversano i confini delle pagine vengono detti link inter-pagina, 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. Graficamente, i link vengono rappresentati come archi orientati, che collegano la unit o la pagina sorgente con la unit o la pagina di destinazione.

L'esempio di Figura 12 mostra un link inter-pagina non contestuale. Il link collega una pagina sorgente (ArtistiPop), che include una multidata unit che mostra gli artisti pop, a una pagina di destinazione (ArtistiJazz), che include una multidata unit che elenca gli artisti jazz. Il contenuto della pagina ArtistiJazz ndipendente dal contenuto della pagina ArtistiPop, per cui la navigazione del link non richiede di trasportare alcuna informazione dalla pagina sorgente a quella di destinazione.

Figura 12 Link non contestuali.

Figura 13 mostra invece un esempio di link inter-pagina contestuale. La pagina Artisti contiene un'index unit, di nome IndiceArtisti, definita sull'entità Artista; l’index unit è collegata a una data unit di nome DettaglioArtista, definita sull'entità Artista e posizionata in una pagina distinta. Il significato di quest'ipertesto è che la unit IndiceArtisti viene visualizzata come una lista di voci cliccabili; quando l'utente seleziona una voce dell'indice, viene visualizzata la pagina Artista in cui la data unit mostra i dettagli dell'artista selezionato. In questo caso, il contenuto della unit di


24/52

destinazione dipende dall'informazione fornita dalla unit sorgente e il trasferimento di questa informazione di contesto è associata alla navigazione del link.

Figura 13 Link contestuali inter-pagina con parametri.

L'accoppiamento tra la unit sorgente e la unit di destinazione di un link viene rappresentato formalmente da un parametro del link definito sul link 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. Un selettore parametrico è un selettore di una unit le cui condizioni si riferiscono a uno o più parametri. Un esempio di questi concetti è visibile in Figura 13, dove il link include un parametro (ArtistaCorr) che rappresenta l'identificatore dell'artista selezionato dall'indice e la data unit ha un selettore [OID=ArtistaCorr] che utilizza il parametro ArtistaCorr per estrarre e visualizzare i dettagli dell'artista corrispondente.

Dal punto di vista sintattico un parametro di un link ha un nome e un'etichetta, separati dal simbolo di due punti. Il nome è una stringa definita dall'utente (ArtistaCorr in Figura 13), che può essere utilizzata all'interno del selettore della unit di destinazione per far riferimento al parametro. L'etichetta indica il contenuto del parametro, che può essere o un attributo oppure un campo della unit sorgente del link; quando l'etichetta si riferisce a un attributo viene definita come la concatenazione del nome di un'entità con il nome di un attributo, separati da un punto. Il nome dell'entità può essere omesso se è chiaro dal contesto, come nel caso dell'etichetta OID in Figura 14, che sta per Artista.OID).

Figura 14 Link contestuale intra-pagina con parametri.

La Figura 14 mostra un link contestuale intra-pagina. In quest'esempio, index unit e la data unit si trovano nella stessa pagina e sono connesse da un link contestuale. Questo link permette all'utente di selezionare un oggetto e di visualizzare la stessa pagina cambiando il contenuto dei dettagli dell'artista di volta in volta selezionato. Anche in questo caso il link abilita il trasporto di informazione di contesto dalla index unit alla data unit e l'accoppiamento tra queste unit è rappresentato dal parametro del link ArtistaCorr e dal selettore parametrico della data unit [OID=ArtistaCorr] che utilizza tale parametro.

Anche il caso di link non contestuale intra-pagina è possibile, sebbene sia usato poco frequentemente per collegare due sotto-pagine in OR annidate all'interno della stessa pagina.


25/52

Un parametro di un link può avere un singolo valore, come il parametro ArtistaCorr in Figura 13 e in Figura 14, che memorizza l'OID di una singola istanza selezionata dalla index unit, oppure può essere multi-valore; per esempio, può contenere l'insieme degli OID degli oggetti selezionati da una multi-choice index unit.

Figura 15 Multi-choice index e parametro multi-valore.

Sintatticamente i parametri multi-valore vengono racchiusi tra parentesi graffe. La Figura 15 mostra un esempio di parametro multi-valore; la unit SceltaArtisti permette di selezionare un insieme di artisti, i cui dettagli vengono visualizzati dalla unit ArtistiSelezionati. Il passaggio di parametri dalla unit sorgente a quella di destinazione è rappresentato dal parametro multi-valore ArtistiSelez:{OID} associato al link, che viene utilizzato nella condizione del selettore della unit di destinazione [OID IN ArtistiSelez] per verificare che gli oggetti da visualizzare con la multidata unit appartengano all'insieme di OID rappresentati dal parametro ArtistiSelez.

Le unit possono avere più link uscenti, associati a parametri diversi. La Figura 16 mostra una hierarchical index unit (IndiceArtisti) in cui il livello più alto della gerarchia visualizza le istanze dell'entità Artista e il secondo livello della gerarchia elenca gli album collegati a ciascun artista tramite il ruolo della relazione Artista_Album.

Figura 16 Hierarchical index con due link uscenti con parametri di tipo diverso.

Due link collegano la hierarchical index unit con due data unit che si trovano in pagine separate: il link che punta alla data unit DettaglioArtista è associato a un parametro di tipo Artista.OID, che contiene l'OID di un artista selezionato dal livello più alto della gerarchia; il link che punta alla data unit DettaglioAlbum è associato a un parametro di tipo Album.OID che contiene l’OID di un album selezionato dal secondo livello della gerarchia. Quando l'utente seleziona un artista oppure un album viene visualizzata la pagina appropriata.

Le multidata unit, le index unit, le hiearchical index e le multi-choice index unit differiscono per i parametri associati ai loro link uscenti: nel caso di index e hierarchical index unit il link uscente


26/52

permette la selezione di un singolo oggetto, nel caso di multi-choice index unit possibile selezionare un sotto-insieme di oggetti, mentre per le multidata unit è possibile passare solamente l'intero insieme di oggetti visualizzati.

Per rendere lo schema ipertestuale più leggibile, la specifica dei parametri dei link può essere omessa quando i parametri associati al link si possono dedurre dal contesto. Per favorire questa semplificazione vengono definiti dei parametri di output di default per ogni unit, in modo che, quando un link è associato a un output di default, la specifica del parametro del link possa essere omessa senza perdita di informazione. Una semplificazione analoga può essere applicata anche alle condizioni del selettore.

Come conseguenza di questi default, la specifica grafica della pagina di Figura 13 può essere semplificata come mostrato in Figura 17. Grazie al parametro di output di default della index unit e al selettore di default della data unit, lo schema di Figura 17 è equivalente a quello di Figura 13: il suo significato intuitivo è che la index unit fornisce l'OID dell'artista selezionato alla data unit.

Figura 17 Notazione semplificata che sfrutta parametri e selettori impliciti.

Un altro esempio d'uso dei default è illustrato in Figura 18, che mostra uno schema WebML equivalente a quello di Figura 14. In questo caso i default permettono di evitare il riferimento esplicito al parametro del link multi-valore (ArtistaSelez) e alla condizione del selettore della multidata unit [OID IN ArtistaSelez]. In seguito ometteremo la specifica dei parametri e delle condizioni dei selettori che possono essere derivati dai default, tranne nei casi in cui vorremo enfatizzarne la presenza.

Figura 18 Esempio d'uso di parametri e selettori impliciti.

I parametri dei link possono essere usati anche per trasmettere i valori inseriti in un'entry form. La Figura 19 mostra un esempio di link avente come parametro il valore di un campo. La unit ImmissioneParola deve includere un singolo campo di nome Condizione per inserire una parola chiave, non mostrato nella notazione grafica.

Il valore di questo campo viene assegnato come parametro, di nome Parola, al uscente dall'entry unit e usato nella condizione del selettore della multidata per mostrare solamente gli album che contengono la parola chiave inserita dall' utente.


27/52

Figura 19 Link contestuale con parametri associati ai campi di una entry.

Link automatici e di trasporto

Oltre a supportare la navigazione dell'utente, i link possono essere utilizzati anche per specificare particolari tipi di flussi di informazione tra unit, che avvengo senza l'intervento dell'utente.

Per illustrare questa necessità si consideri la pagina in Figura 20. Quando si accede alla pagina, viene visualizzata solamente l'index unit: successivamente se l'utente seleziona una voce dell'indice, la pagina viene rivisualizzata e la unit mostra i dettagli dell'oggetto selezionato. Prima della selezione da parte dell' utente dall'indice, la data unit non viene mostrata, poiché l'OID dell'oggetto selezionato necessario per calcolare la data unit non è disponibile.

In alcune applicazioni può essere necessario specificare comportamenti differenti ti, in cui il contenuto di alcune unit viene visualizzato non appena si accede alla pagina, anche se l'utente non ha ancora navigato i suoi link in ingresso. Quest'effetto può essere ottenuto utilizzando i link automatici. Un link automatico è un link che viene "navigato" senza l'intervento dell'utente, quando si accede alla pagina che contiene la unit sorgente del link.

Figura 20 Esempio di pagina con unit collegate da link e sua presentazione in HTML quando si accede alla pagina.

La Figura 21 mostra lo stesso esempio della Figura 20, specificando il link come automatico. Il significato di quest'ipertesto è che, quando la pagina Album. viene caricata, non viene visualizzata solo l'index unit, ma anche la data unit. che mostra i dettagli di uno degli oggetti selezionati dall'indice. La selezione dell'oggetto dall'indice si può basare su qualche criterio euristico, per esempio, può scegliere il primo oggetto in base alla clausola di ordinamento dell'index. In altre parole, l'accesso alla pagina Album causa la navigazione "simulata” del link automatico, che propaga l'informazione contestuale scelta in modo automatico dalla unit sorgente alla unit di destinazione.

Si noti che la capacità di selezionare in maniera euristica l'informazione contestuale da propagare lungo il link automatico è necessaria solamente per le index unit, le hierarchical index unit, le multi-choice index unit e le scroller unit, che permettono all'utente di selezionare uno o più oggetti all'interno di un insieme. Le data unit e le multidata unit non consentono la selezione di oggetti e quindi non richiedono scelte euristiche.


28/52

Figura 21 Esempio di link automatico e sua presentazione in HTML quando si accede alla pagina.

Come mostra la Figura 21, la notazione grafica per i link automatici è una 'A' maiuscola che etichetta l'arco del link. Lo stesso risultato può essere ottenuto nella specifica testuale, aggiungendo la parola chiave automatic alla dichiarazione del link.

Tutti i link visti finora vengono presentati per mezzo di ancore o bottoni di conferma. Tuttavia, esistono dei casi in cui il link viene utilizzato solamente per passare informazione contestuale da una unit a un'altra e quindi non deve essere reso come un'ancora. Questo tipo di link viene detto link di trasporto, per evidenziare il fatto che abilita solamente il passaggio di parametri e non la navigazione dell'utente.

La Figura 22 mostra un esempio di link di trasporto: la pagina AlbumDiCelineDion contiene la data unit DettaglioArtista con i dati dell'artista di nome Celine Dion e l'index unit AlbuniPubblicati, che elenca gli album da lei pubblicati. Poichè il link è definito come link di trasporto, quando si accede alla pagina sia la data unit che l'index unit mostrano il loro contenuto, ma per il link non viene visualizzata nessuna ancora.

Come mostrato nella Figura 22, un link di trasporto nella specifica grafica viene rappresentato tramite un arco tratteggiato; lo stesso significato può essere espresso nella specifica testuale aggiungendo la parola chiave transport alla dichiarazione del link.

Figura 22 Esempio di link di trasporto.

Pagine annidate Le pagine degli ipertesti viste finora sono organizzate come collezioni di una o più unit. Questa struttura di pagina copre i requisiti della maggior 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 annidata al progettista di dare una struttura gerarchica anche alle pagine, suddividendole idendole in sotto-pagine.

Le pagine annidate possono essere in forma congiuntiva oppure in forma disgiuntiva. Nel primo caso vengono visualizzate insieme, nel secondo la visualizione di una sotto-pagina rimpiazza la visualizzazione di un'altra sotto-pagina.

Le pagine annidate in forma congiuntiva (dette anche sotto-pagine in AND) sono utilizzate per dividere la pagina contenuta in una schermata in porzioni, in modo tale che una porzione venga tenuta fissa e le altre mostrino informazioni variabili in base ai comandi degli utenti, come con i frame in HTML, in


29/52

cui l'informazione in alcuni frame variabili viene sostituita con dati diversi dopo che l'utente seleziona un'ancora dal frame fisso.

Figura 23 Notazione WebML per pagine AND annidate e possibile presentazione in HTML.

La pagina di Figura 23 contiene due sotto-pagine in AND: la sotto-pagina di nome Sinistra contiene due indici relativi ad album recenti e in archivio, mentre la sotto-pagina di nome Destra mostra le informazioni di un album. La sotto-pagina Destra viene ricaricata in seguito a ogni selezione di un link nella sotto-pagina Sinistra, che viene tenuta fissa.

Le pagine annidate in forma disgiuntiva (dette anche sotto-pagine in OR) vengono usate per specificare che certe porzioni dello schermo possono contenere configurazioni di unit alternative, ognuna modellata come una pagina distinta. A tempo di esecuzione, una delle pagine viene selezionata e presentata in base alle scelte dell'utente. La Figura 24 mostra una pagina che include l'indice degli album e degli artisti, assieme all'informazione o dell'album o dell'artista.

Figura 24 Notazione WebML per pagine OR annidate e loro possibile rapprentazione in HTML.

La composizione della pagina, e non solamente l'oggetto da visualizzare, cambia se l'utente seleziona un artista oppure un album dagli indici, il che richiede l'utilizzo di due sotto-pagine in OR, una per mostrare i dettagli dell'artista e una per le informazioni sull'album. Una delle sotto-pagine in OR può essere marcata come sotto-pagina OR di default per specificare che è quella da mostrare prima che l'utente effettui una scelta, quando si accede alla pagina che la racchiude.

In Figura 24 la pagina più esterna contiene due sotto-pagine in AND, di nome Sinistra e Destra. Quest'ultima racchiude due sotto-pagine in OR, una delle quali viene marcata come la sotto-pagina


30/52

di default. Graficamente, le pagine che racchiudono sotto-pagine in OR, come la pagina Destra, hanno un colore di riempimento diverso.

Operazioni

Le operation unit (o semplicemente operazioni) sono un nuovo tipo di unit che può essere posizionato all'esterno delle pagine e collegato ad altre operazioni oppure alle unit contenute nelle pagine tramite link. A differenza delle unit di contenuto, le operazioni non hanno lo scopo di pubblicare informazioni, il che giustifica il fatto che vengono posizionate estemamente alle pagine; esse infatti eseguono semplicemente un'azione. Come le unit di contenuto, le operazioni possono avere un oggetto sorgente (un'entità oppure una relazione) e dei selettori. possono ricevere parametri dai loro link in ingresso e fornire dei valori tramite dei parametri sul link in uscita.

Le operazioni possono essere predefinite oppure generiche. Le prime modellano le funzioni per la gestione del contenuto, come la creazione, la cancellazione e la modifica di oggetti e la creazione e la cancellazione di relazioni tra oggetti. Le seconde permettono l'integrazione di procedure esteme di complessità arbitraria. Indipendentemente da questa classificazione, le operazioni WebML soddisfano i seguenti principi di progettazione:

• Un'operazione può avere più link entranti, che forniscono i suoi parametri di ingresso. • Le operazioni possono essere collegate tramite link per formare una sequenza. L'

attivazione della prima operazione della sequenza implica l'esecuzione delle successive operazioni. Uno dei link in ingresso all'operazione deve essere un link normale, mentre i rimanenti link devono essere di trasporto. L'operazione viene eseguita quando si naviga il link normale; durante la sua esecuzione, essa utilizza i parametri associati a tutti i link in ingresso.

• Ogni operazione ha un link OK ed un link KO; il primo viene seguito quando l'operazione va a buon fine; il secondo quando l'operazione fallisce. La scelta del link da seguire (OK oppure KO) dipende dal risultato dell'esecuzione dell'operazione ed è sotto la responsabilità dell'implementazione dell'operazione.

• Un'operazione può avere un qualsiasi numero di link di trasporto uscenti, utilizzati per specificare i parametri necessari ad altre operazioni oppure a unit di contenuto. La specifica dei link di trasporto non altera l'esecuzione della sequenza di operazioni, che si basa sui link OK e KO, ma permette al progettista di utilizzare i vari output delle operazioni come input per altre unit.

Le operazioni non visualizzano dei dati, ma eseguono dei processi come effetto della navigazione di un link. Il risultato di un'operazione può però essere visualizzato in una pagina, collegando tramite un link l'operazione con una conent unit, che accetta dei parametri di ingresso provenienti dall'operazione e li utilizza per estrarre e visualizzare l'informazione rilevante.

Operazioni predefinite

Il linguaggio di modellazione fornisce un certo numero di operazioni predefinite, la cui semantica è specificata dal linguaggio. Poichè WebML si occupa prevalentemente di applicazioni Web centrate sui dati, la maggior parte delle operazioni predefinite ha lo scopo di manipolare i dati applicativi; vengono fornite anche alcune altre operazioni che offrono servizi di utilità generale, usati frequentemente in applicazioni Web: le operazioni di login, logout e invio di e-mail. Le sezioni che seguono descrivono la sintassi e i pattern di utilizzo di tutte le operazioni predefinite.

Creazione di oggetti

La prima operazione predefinita è la creazione, rappresentata dalla create unit, che permette di creare una nuova istanza di un'entità. La create unit è caratterizzata da:

• un nome definito dall'utente. • un’entità sorgente su cui si applica l'operazione.


31/52

• un insieme di assegnamenti che legano gli attributi dell'oggetto da creare con i valori dei parametri che provengono dai link in ingresso, o con dei valori costanti.

L'input di una create unit è un insieme di valori, che provengono tipicamente da un link uscente da una entry unit. Questi valori vengono usati dalla create unit per costruire il nuovo oggetto, attraverso gli assegnamenti dei valori agli attributi; per un attributo non sono presenti dei valori sui link in ingresso esso viene accostato al valore nullo, a eccezione dell'OID che viene trattato in modo diverso: se non viene fornito nessun valore l'operazione genera un nuovo valore, unico all'interno delle istanze dell'entità. La create unit può esporre in output l'insieme dei valori degli attributi, incluso l'OID, del nuovo oggetto creato. Questo output è definito solo quando l'operazione va a buon fine e quindi può associare dei valori indicativi ai parametri del link OK. L'output di default per la create unit è il valore dell'attributo OID, che si assume come parametro implicito del link OK quando non si specificano esplicitamente altri parametri.

Figura. 25 - Notazione grafica per la create unit e una sua possibile visualizzazione in HTML.

L'esempio di Figura 25 mostra il pattern di utilizzo tipico dell'operazione di operazione, che consiste nello specificare una entry unit (InserimentoArtista) che fornisce l'input a una create unit (CreazArtista), che crea una nuova istanza di un'entità (Artista). Nell'esempio, la entry unit ha due campi (CNome e CCognome) per inserire il nome e il cognome di un artista. I valori inseriti dall'utente vengono associati a dei parametri espliciti del link che va dalla entry unit alla create unit e collegati agli attributi dell'oggetto di tipo artista che verrà creato tramite due assegnamenti, rappresentati sotto il nome dell'entità sorgente della create unit. Nella resa grafica di Figura 25 il link uscente dalla entry unit è rappresentato tramite il tasto OK che permette l'attivazione dell'operazione. L' operazione CreazArtista ha due link in uscita: il link OK che punta alla data unit DettagliArtista e trasporta il parametro implicito di default (l'OID del nuovo oggetto); il link KO che punta nuovamente alla pagina CreazioneArtista per permettere all'utente di ripetere l'operazione in caso di fallimento.

Cancellazione di oggetti

La delete unit permette di cancellare uno o più oggetti di una determinata entità. La delete unit è caratterizzata da:

• Un nome definito dall'utente. • L'entità sorgente e il selettore che determinarno gli oggetti su cui si applica l’operazione Gli

oggetti da cancellare sono quelli che soddisfano la condizione del selettore.


32/52

Solitamente l'utente sceglie a tempo di esecuzione o un singolo oggetto da cancellare, visualizzato da una data unit oppure selezionato da una index o da una scroller unit, o un insieme di oggetti da cancellare, visualizzati tramite una multidata unit oppure selezionati tramite una multi-choice index unit; l'OID oppure l'insieme di OID corrispondenti vengono associati ai parametri dei link entranti nella delete unit.

Il link OK viene seguito se tutti gli oggetti determinati dal selettore sono stati cancellati; esso non ha alcun parametro in quanto gli oggetti di interesse non esistono più. Il link KO viene seguito se almeno uno degli oggetti non è stato cancellato; a esso viene associato un parametro che contiene l'OID oppure l'insieme di OID degli oggetti non cancellati.

Figura. 26 - Notazione grafica per la delete unit e una sua possibile visualizzazione in HTML.

L'esempio di Figura 26 mostra la notazione grafica dell'operazione di cancellazione e rappresenta un esempio di cancellazione di un singolo oggetto. La pagina Album include l'indice degli album che si possono cancellare, collegati tramite un link alla delete unit. Il link trasporta il parametro di default, cioè l'OID dell'album selezionato, che viene utilizzato dal selettore implicito della delete unit. La navigazione del link attiva la cancellazione dell'oggetto selezionato. Se l'operazione ha successo la pagina Album viene visualizzata nuovamente, e , album cancellato non apparirà più nell'indice; in caso di fallimento la pagina l’Album viene comunque rivisualizzata, ma questa volta l'indice conterrà ancora l’album che non è stato cancellato.

L'esempio di Figura 27 mostra una multi-choice index unit utilizzata per visualizzare i titoli di diversi album: l'utente sceglie un insieme di titoli e attiva la cancellazione degli album selezionati. In questo caso il parametro implicito del link di ingresso della delete unit contiene un insieme di OID e il selettore implicito identificagli oggetti da cancellare. Se l'operazione va a buon fine e tutti gli oggetti sono stati cancellati correttamente viene seguito il link OK e viene ricaricata la pagina Album. Se l'operazione fallisce viene visualizzata una pagina di errore, che mostra i dettagli degli album che non sono stati cancellati.


33/52

Figura 27 - Notazione grafica per la selezione e la cancellazione di oggetti e possibile visualizzazione in HTML.

L'insieme di oggetti da cancellare può essere determinato anche per mezzo di un selettore basato su attributi. Un semplice esempio è rappresentato dell'ipertesto, di Figura 28: una entry unit permette all'utente di inserire il nome di un autore di una recensione per poter poi cancellare tutte le sue recensioni. Il link uscente dalla entry unit trasporta un parametro che contiene il nome dell'autore della recensione, che viene utilizzato dal selettore della delete unit per estrarre e cancellare tutte le recensioni scritte da tale autore. Il link OK punta nuovamente alla pagina Nome, per poter inserire il nome di un altro autore di recensioni, mentre il link KO punta a una pagina di errore.

Figura 28 - Notazione grafica per la cancellazione basata su attributo e sua possibile visualizzazione in HTML.

Modifica di oggetti

La modify unit permette di aggiornare uno o più oggetti di una determinata entità. La modify unit è caratterizzata da:

• Un nome definito dall'utente. • L’entità sorgente e il selettore che identifica l'oggetto o l'insieme di oggetti su cui si applica

l'operazione; gli oggetti da modificare sono dati dall'insieme di oggetti che soddisfano il selettore.

• Un insieme di assegnamenti che associano i nuovi valori agli attributi degli oggetti da modificare.


34/52

L'utente tipicamente sceglie a tempo di esecuzione il singolo oggetto oppure l'insieme di oggetti da modificare; in quest'ultimo caso la stessa modifica si applica a tutti gli oggetti. Per ottenere gli input necessari la modify unit deve essere collegata tramite dei link appropriati alle altre unit. In particolare sono necessari:

• I nuovi valori degli attributi: solitamente vengono definiti come parametri di un link in ingresso proveniente da una entry unit.

• Gli oggetti da modificare: solitamente vengono specificati come parametri di un link in ingresso, che contiene un OID oppure un insieme di OID, e vengono utilizzati dal selettore della modify unit.

• In alternativa all'uso di parametri di tipo OID, gli oggetti da modificare possono essere individuati per mezzo di selettori basati su attributi oppure su relazione all'interno della modify unit, che possono utilizzare altri parametri dei link in ingresso.

Il link OK di una modify unit viene seguito se tutti gli oggetti sono stati modificati con successo: in questo caso il link trasporta un parametro di default che contiene l'insieme degli oggetti modificati. Il link KO viene seguito quando almeno un oggetto non è stato modificato; esso ha come parametro implicito l'insieme degli OID degli oggetti non modificati.

L'esempio di Figura 29 mostra una entry unit che permette di fornire i valori a una modiTy unit. La pagina ModificaArtista comprende una data unit (DatiBiografia), che mostra il nome dell'artista da modificare, ed una entry unit (ModificaBiografia), tramite la quale l'utente può modificare la biografia esistente. Il link di trasporto dalla data unit alla modify unit porta come parametro implicito l'OID dell'artista da modificare, che viene utilizzato dal selettore di default della modify unit.

La modify unit viene attivata da un secondo link, che esce dalla entry unit; questo link ha un parametro esplicito (chiamato PBiogr) che contiene il valore del campo della entry unit e viene utilizzato nell'assegnamento. dell'operazione. Il link OK porta alla pagina Risultato, che mostra il valore corrente dell'attributo Biografia; il link KO punta alla data unit DatiBiografia.

Si noti che se l'operazione va a buon fine, il nuovo valore della biografia viene presentato dalla data unit DatiBiografia.

Figura 29 Notazione grafica per la modify unit e una sua possibile realizzazione in HTML.


35/52

Creazione di relazioni

La connect unit permette di creare nuove istanze di una relazione. Più precisamente, una connect unit si applica a uno dei due 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. Le proprietà della connect unit sono:

• Un nome definito dall'utente. • Il ruolo della relazione al quale si applica l'operazione. • Due selettori, uno per individuare gli oggetti dell'entità sorgente e uno per gli oggetti

dell'entità destinazione. Per distinguere le condizioni applicate alle entità sorgente e di destinazione, gli attributi e i ruoli delle relazioni usati nei predicati dei selettori possono essere preceduti dal nome dell'entità a cui si riferiscono.

L' operazione di connect crea un'istanza del ruolo della relazione per tutte 1 possibili combinazioni tra gli oggetti delle entità sorgente e gli oggetti dell'entità di destinazione estratte valutando i due selettori; fornisce in output due parametriche contengono rispettivamente gli OID degli oggetti delle entità sorgente e destinazione estratte dal selettore. Questi valori possono essere usati per de parametri dei link OK, KO e di trasporto dell'operazione. Il link KO viene viene to se la creazione di almeno un'istanza della relazione fallisce, mentre viene seguito se tutte le connessioni possono essere create. Se un'istanza è già presente nella base di dati l'operazione non introduce un duplicato dell'istanza, ma non viene considerata fallita. La Figura 30 mostra un esempio di connect unit per assegnare una recensione un artista.

Figura 30 Notazione grafica per la connect unit e una sua possibile realizzazione in HTML.

Operazione di login e logout

Per implementare il controllo degli accessi e per verificare l'identità di un utente che accede al sito, il linguaggio di modellazione fornisce un'operazione predefinita chiamata login. Quest'operazione ha due parametri fissi (nome utente e password), i cui valori devono essere forniti in input tramite un link, tipicamente uscente da una entry unit, come mostrato in Figura 31.


36/52

L'operazione di login controlla la validità dell'identità di un utente e, se la verifica 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. Un'applicazione molto utile dei parametri globali legata alla unit di login consiste nel memorizzare l'OID dell'utente che è entrato nel sistema. A questo scopo si può impostare un parametro globale predefinito, chiamato UtenteCorrente, contenente l'OID dell'utente che ha completato con successo l'operazione di login.

Figura 31 Login unit, preceduta da una entry unit per inserire le proprie credenziali.

L’operazione di logout viene utilizzata per "dimenticare" la sessione di un utente, portarlo a una pagina di default in cui non ci sia il controllo dell'accesso. L'operazione di logout non ha input e output, e può essere invocata tramite un semplice link non contestuale, come mostrato in Figura 32

Figura 32 Logout unit, invocata tramite un link non contestuale.

Parametri globali

L'informazione contestuale necessaria per calcolare le unit, in genere, è associata ai link, che vanno da un punto dell'ipertesto a un altro. Tuttavia, esistono delle situazioni in cui l'informazione contestuale non viene trasferita punto-a-punto durante la navigazione, ma deve essere disponibile "globalmente" a tutte le pagine del sito.

Si consideri, per esempio, il caso di un sito Web multilingue, in cui l'utente può selezionare la pagina home della nazione a cui è interessato e navigarne contenuto relativo, per esempio gli album e gli artisti locali, ecc. Nonostante l'ipertesto sia lo stesso per tutte le nazioni, il contenuto effettivo varia da paese a paese. Pertanto, l'identificatore della nazione selezionata dall'utente è un'informazione contestuale che viene utilizzata nel selettore di tutte le unit delle pagine della site view per estrarre la versione corretta del contenuto.

Per memorizzare l'informazione da rendere disponibile a più pagine si deve introdurre la nozione di parametro globale. Un parametro globale è un'informazione, l'OID di un oggetto oppure un valore di un altro tipo, che può essere impostato esplicitamente durante la navigazione dell'ipertesto ed estratto successivamente per calcolare il contenuto di alcune unit durante la navigazione. Il valore del parametro globale viene associato alla sessione utente, per cui utenti diversi possono ,vere valori differenti per lo stesso parametro globale; per esempio, due utenti potrebbero navigare la stessa applicazione multilingue, ma vederne il contenuto in linguaggi diversi, a seconda del valore del parametro globale che rappresenta nazione selezionata.

L'utilizzo di un parametro globale richiede tre passi: la sua dichiarazione, assegnamento di un valore e l'estrazione del suo valore. La dichiarazione di un parametro globale richiede la definizione di:

• Un nome definito dall'utente per il parametro. • Il tipo del valore memorizzato nel parametro. • Un possibile valore di default, consistente in un valore costante assegnato inizialmente al

parametro.


37/52

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.

La Figura 33 mostra un esempio di set unit, che memorizza nel parametro globale NazioneCorrente un valore ricevuto da una data unit tramite un link di trasporto. Il significato di quest'ipertesto è che, quando la pagina Nazione viene caricata e la data unit DatiNazione viene visualizzata, l'OID della nazione viene propagato alla set unit tramite il link di trasporto, e quindi salvato nel parametro globale NazioneCorrente. Poichè il link verso la set unit è un link di trasporto, non vengono visualizzate ancore cliccabili e l'impostazione del parametro globale avviene senza l'intervento dell'utente.

Figura 33 Notazione grafica per la set unit.

La configurazione della unit di Figura 33 può essere utilizzata anche per memorizzare in un parametro globale il nome di una nazione anzichè il suo OID: in questo caso è sufficiente che il link in ingresso alla set unit abbia un parametro del tipo Nome:Nazione.Nome.

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.

Nell'esempio di Figura 34, il parametro globale NazioneCorrente memorizza l'OID di una particolare nazione, precedentemente impostata dall'utente. La unit DatiNazione riceve dal suo link in ingresso questo OID e utilizza il selettore implicito [OID = <parametro del link>] per visualizzare i dati della nazione corrente.

Figura 34 Notazione grafica per la get unit

I parametri globali, la set e la get unit permettono di specificare ipertesti che mostrano una specie di "memoria navigazionale", in cui le selezioni passate dell'utente, come la scelta di una nazione nella pagina Home, sono rese disponibili in altre pagine, raggiunte successivamente durante la navigazione, per abilitare la computazione di alcune unit.


38/52

Caratteristiche comuni tra Aree e Pagine

Le pagine e le aree sono caratterizzate da alcune proprietà che evidenziano la loro importanza all'interno del sito Web. In particolare, le pagine all'interno di un'area o di una site view possono avere le seguenti tre proprietà:

• La pagina home è la pagina all'indirizzo di default del sito o che viene presentata dopo che l'utente si collega all'applicazione tramite login. La pagina home deve essere unica all'interno della site view. Nella specifica grafica la proprietà home della pagina viene denotata con una "H" all'interno dell'icona della pagina.

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

• Una pagina landmark è raggiungibile da tutte le altre pagine o aree all'interno del modulo che la racchiude (la site view oppure una 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.

Alle aree possono essere associate le proprietà landmark e default:

• 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. La pagina o la sotto-area di default vengono definite in modo ricorsivo: sono o la pagina di default definita localmente all'interno della sotto-area o la pagina di default annidata in modo ricorsivo all'interno di una sotto-sotto-area di default.

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

Per comprendere l'utilità del concetto di landmark si consideri la Figura 35, che presenta due diagrammi equivalenti. Nel diagramma di sinistra, la pagina Home è anche una pagina landmark; il suo significato è che ogni pagina racchiusa nella site view è la sorgente di un link non contestuale implicito che punta alla pagina landmark. Il diagramma sulla destra mostra questi link non contestuali in modo esplicito. Il significato del diagramma di sinistra implica quindi che la pagina Home può essere raggiunta da qualsiasi altra pagina del modulo che la racchiude. Se una site view contiene molte pagine, la proprietà landmark riduce significativamente il numero di link non contestuali da disegnare e rende il diagramma molto più leggibile.

Figura 35 Pagina home e landmark (a sinistra) e diagramma equivalente con i link esplicitati (a destra).

Lo stesso beneficio lo si ottiene con le sotto-aree contenute in una site view.


39/52

Progettazione generale e dettagliata

Nella progettazione generale o preliminare dell'ipertesto il progettista applica a ogni site view una sequenza di passi di raffinamento che permette di consolidare la mappa della site view in un insieme di aree, di cui specifica poi il contenuto e la visibilità.

La prima attività consiste nell' identificazione delle aree. Tale attività parte dal riesame dei requisiti funzionali e delle mappe delle site view, in quanto questi incorporano indicazioni preliminari riguardo la suddivisione dell'applicazione in moduli. In base a questi input, il progettista definisce la lista delle aree che devono essere sviluppate per le varie site view e produce inoltre una prima rappresentazione di ogni site view (Figura 36-a).

Figura 36(a - b) - Mappa della site view attraverso l'introduzione di aree.

Una volta che le aree sono state individuate, il passo successivo consiste nella specifica della loro visibilità. Un'area può essere definita come:

• Area di default, se a essa si accede "per default quando si entra nella site view che la include. Tipicamente, l'area di default è quella che contiene la home page della site view.

• Area landmark, se è accessibile globalmente da ogni altra area della site view. Tipicamente, la proprietà di landmark per le aree si traduce nella costruzione di barre di navigazione, contenenti link alle pagine di default delle aree landmark, che sono visualizzate in tutte le pagine della site view. In questo modo, l'utente può navigare con facilità verso le aree landmark a partire da qualsiasi pagina della site view.

• Area interna, se corrisponde a una porzione di ipertesto che può essere raggiunta solo per mezzo di link espliciti, posizionati in altre pagine.

La visibilità delle aree è espressa utilizzando le notazioni WebML per le aree landmark e di default. Nella Figura 36-b, l'area X è l'area di default; per tale ragione, questa è l'area a cui si accede quando si entra nella site view. Le aree X e Z sono landmark; ogni pagina della SiteViewl includerà quindi due link alle pagine di default delle due aree. Le aree Y e K sono invece aree interne, raggiungibili attraverso link espliciti definiti in pagine specifiche.

L'ultimo passo della progettazione preliminare è la specifica del contenuto associato a ogni area. Le mappe delle site view definite durante la specifica dei requisiti includono una descrizione testuale e informale dei servizi e dei contenuti che ogni area deve offrire. La specifica del contenuto fornisce maggiori dettagli circa l'assegnamento dei contenuti e delle funzioni alle aree, evidenziando il ruolo che gli oggetti dello schema dei dati giocano nella costruzione dell'area. Il contenuto di un'area è espresso in termini di frammenti di ipertesto, che sono classificati come segue:

• Ipertesti core: pubblicano il contenuto di entità specifiche o di gruppi di entità che rappresentano gli oggetti principali ("core") dell'applicazione.


40/52

• Ipertesti di accesso: supportano varie forme di accesso ai concetti core.

• Ipertesti di interconnessione: sono utilizzati per collegare concetti core.

• Ipertesti di personalizzazione: sono utilizzati per definire meccanismi di personalizzazione, quali per esempio l'autenticazione dell'utente, la gestione dei diritti di accesso sui dati, la fornitura di contenuti personalizzati, la gestione degli oggetti personali.

• Ipertesti per la gestione dei contenuti: specificano operazioni come la creazione, la cancellazione e la modifica di entità e la creazione e la cancellazione di relazioni.

I frammenti di ipertesto inclusi nell'area sono rappresentati utilizzando una notazione testuale. Le espressioni seguenti, riportate all'interno di un'area, specificano quali frammenti di ipertesto devono essere utilizzati:

• Core (EntitàCore, Componente1, . . . , ComponenteN) denota la pubblicazione di contenuti relativi all'entità Entità Core e le sue entità componenti Componentel, . . . , ComponenteN.

• Accesso(EntitàCore,EntitàAccessol,...,EntitàAccessoN) denota l'accesso a una o più istanze dell'entità EntitàCore, tramite una selezione per passi successivi per mezzo delle entità di categorizzazione EntitàAccessol, .... EntitàAccessoN. Quando le entità di categorizzazione non sono specificate, il frammento di ipertesto corrispondente deve permettere l'accesso diretto all'entità core per mezzo di meccanismi di ricerca.

• Interconnessione (Ruolo 1, ... , RuoloN) denota la navigazione dalle istanze di Entitàl alle istanze di EntitàN, dove Entitàl e EntitàN sono entità core connesse da una sequenza di ruoli di relazione Ruolo1 ..RuoloN.

• Crea&Connetti (Entitàl, Ruolo1, .. , RuoloN) denota la creazione di una nuova istanza di Entitàl ed eventualmente la sua connessione ad N altre entità attraverso i ruoli di relazione Ruolo1, . . . , RuoloN.

• Modifica(Entità1) denota la modifica di istanze dell'entità Entitàl.

• Elimina(Entità1) denota la cancellazione di istanze di Entità1.

• Connetti(Ruolol), Disconnetti (Ruolo1) denotano rispettivamente la creazione e la cancellazione di istanze del ruolo di relazione Ruolol.

• Set ( InformazioneContesto) denota l'inizializzazione di parametri globali, che è necessario rendere disponibili a tutte le pagine della site view. L'informazione contenuta in un parametro è tipicamente il valore di un attributo, per esempio l'OID dell'istanza di un'entità.

Figura 37 – Esempio di specifica per il contenuto di un’area.

La Figura 37 mostra un esempio di specifica dei contenuti per un'area dedicata alla creazione, cancellazione e modifica di notizie. L'entità core Notizia è accessibile tramite l'entità di categorizzazione CategoriaNotizie e le notizie in una categoria selezionata possono essere modificate o cancellate. L’area include inoltre la possibilità di creare una notizia all'interno di una categoria selezionata e impostare la categoria corrente come parametro globale, così da renderla disponibile in tutte le pagine della site view.


41/52

Una volta che lo schema preliminare della site view è stato definito, è possibile raffinarlo, trasformando le descrizioni testuali in una specifica WebML. Il processo di progettazione dettagliata consiste nell'applicare iterativamente i passi di raffinamento, cioè l'identificazione delle pagine, la specifica della loro visibilità e la specifica del loro contenuto, per ogni area di ciascuna site view.

L' identificazione delle pagine riguarda la suddivisione di un'area in pagine. A ogni pagina si associa una porzione dei contenuti e delle funzioni dell'area che la contiene. L' obiettivo è quello di ottimizzare l'usabilità e l'efficacia dell'ipertesto, mantenendo uniti elementi di contenuto e funzioni che mostrano un alto grado di coesione e lasciando invece separati i contenuti e le funzioni poco correlati.

Come esempio di specifica di pagina, si consideri l'area illustrata nella Figura 37. Il contenuto dell'area Notizie _GestioneContenuti può essere suddiviso in tre diverse pagine, come mostrato nella Figura 38: la prima pagina (Accesso&CancellazioneNotizie) permette l'accesso alle notizie per mezzo delle categorie in cui esse sono suddivise, la selezione di una categoria e la sua impostazione come categoria corrente e la cancellazione di notizie appartenenti alla categoria corrente. La seconda pagina (ModificaNotizia) permette la modifica di una singola notizia. La terza pagina (CreazioneNotizia) supporta la creazione di una nuova notizia e la sua associazione a una categoria. Questo assegnamento di contenuti e funzioni alle pagine è giustificato da ragioni di spazio e coesione logica. E' infatti impraticabile mantenere tutte le funzioni per la gestione dei contenuti delle notizie nella stessa pagina e quindi ogni operazione è assegnata a una pagina diversa.

Figura 38 – Esempio di identificazione delle pagine.

La definizione della visibilità di pagina consiste nel marcare ogni pagina come home, default, landinark o interna, sulla base della sua importanza:

• La home page, presentata all'utente quando questi accede a una site view, è la pagina che contiene i contenuti e i servizi più importanti della site view o che favoriscono l'accesso ai contenuti di altre pagine.

• La pagina di default è la pagina presentata all'utente quando questi entra in un'area. E’ la pagina più importante dell'area, che fornisce accesso ai contenuti e alle funzioni per cui l'area è stata definita.

• Una pagina landmark è raggiungibile globalmente da tutte le altre pagine del modulo in cui è contenuta (site view o area), il che implica che tutte le altre pagine del modulo contengono un link verso la pagina landmark. Per essere definita come landmark, una pagina deve fornire contenuti e servizi frequentemente richiesti dall'utente.

Infine, una pagina interna è una pagina che non rientra in uno dei tipi precedentemente elencati. Le pagine interne tipicamente includono contenuti secondari, sono presentati agli utenti solo dopo che altri contenuti sono già stati visitati, oppure rappresentano passi intermedi di navigazione.


42/52

In particolare, la pagina Accesso&CancellazioneNotizia è definita come pagina di default. Questa scelta e motivata dal fatto che l'accesso alle notizie per mezzo delle categorie è il passo iniziale del processo di gestione delle notizie. La pagina è anche marcata come landmark in modo da poter essere facilmente raggiunta da ogni altra pagina dell’area. Le pagine rimanenti sono interne e quindi raggiungibili solo per mezzo di link definiti esplicitamente nella pagina Accesso&CancellazioneNotizia. Segue il dettaglio delle pagine con l’uso di unit, operazioni, link.

Web usability

La migliore e maggiormente sintetica definizione di usabilità fa riferimento alla normativa ISO 9241 (Requisiti ergonomici per lavoro di ufficio con terminali) e afferma che "l’usabilità è la misura in cui un prodotto può essere usato da specifici utenti per raggiungere specifici obiettivi con efficacia, efficienza e soddisfazione in uno specifico contesto di uso". In questa definizione, il termine efficacia indica l'accuratezza e la completezza con cui gli utenti raggiungono i loro obiettivi, l'efficienza fa riferimento alle risorse spese mentre la soddisfazione al comfort e all'accettabilità dei sistema per gli utenti stessi.

Già da questa prima succinta definizione risulta evidente come l'usabilità sia una disciplina dalle molte sfaccettature, un concetto polivalente, il cui impiego trova luogo in numerosissimi contesti, non solo nei sistemi software. Sebbene l'usabilità nasca negli anni '60 nel settore dell'ergonomia, il suo approccio (fortunato) all'informatica avviene non prima degli anni '80. A partire da quel periodo, infatti, le produzioni software iniziano ad investire la grande massa, grazie al progressivo abbattimento dei prezzi dell'hardware: il progettista non è più l'utente di un'applicazione, né l'utente è più il progettista e tali figure possiedono conoscenze ed attitudini differenti. Questo nuovo contesto porta all'esigenza di minimizzare le differenze tra design model e user model: tanto più i due modelli saranno vicini, tanto minori saranno i problemi di usabilità.

Definita anche come HCI (Human-Computer Interaction), l'usabilità è dunque una disciplina pratica, di supporto alla progettazione, che tenta di risolvere dei problemi di natura pratica, incentrati sulla figura dell'utente: quanto più un utente riesce ad interagire con un prodotto con efficacia, efficienza e soddisfazione, tanto maggiore sarà il successo di quel prodotto. Nel settore dell'informatica, l'usabilità riguarda prevalentemente il design e la progettazione delle interfacce grafiche, poiché l'interfaccia rappresenta lo strumento principe attraverso il quale l'utente utilizza il software sottostante.

Fondamentale nell’usabilità è considerare gli human factors, ossia, l’insieme delle caratteristiche fisiologiche e psicologiche dell’essere umano inteso come soggetto che elabora informazioni. Un corretto design dell’informazione presuppone la consapevolezza dei meccanismi che avvengono a livello di:

a) percezione sensoriale. L’attenzione è selettiva, quindi gli stimoli contemporanei non devono essere troppi e non devono essere troppo intensi. L’utente deve potersi concentrare attorno al contenuto fondamentale che si vuole trasmettere.

b) memorizzazione. La memoria è limitata, quindi l’informazione deve essere suddivisa in blocchi e le convenzioni non devono essere messe in discussione. L’utente deve poter acquisire un certo automatismo operativo, per lo meno attorno alle funzionalità principali

c) costruzione e impiego di modelli mentali. L’uomo agisce con la realtà adattando regole di comportamento, quindi gli schemi devono essere facilmente riconoscibili e devono essere il più possibile generali e consolidati. L’utente deve poter applicare gli schemi a lui abituali della vita quotidiana


43/52

Sebbene i principi forniti dall'usabilità ben si adattino ad ogni contesto, un discorso a parte merita il Web. In questo ambito, infatti, vi sono alcune importanti distinzioni da sottolineare rispetto alle comuni interfacce grafiche.

In primo luogo, il Web è riuscito a spostare il paradigma dell'interazione utente-prodotto su un altro livello: il prodotto viene usato prima di essere acquistato e non il viceversa. Questa semplice osservazione aumenta il grado di importanza dell'usabilità di un sito Web: se un utente non è soddisfatto dei sito, difficilmente tornerà a visitarlo in futuro.

Come ulteriore aggravante al problema, qualsiasi sito Web ha una spada di Damocle sulla testa: la velocità di connessione dell'utente. Anche se le nuove tecnologie (come ADSL, HFC, ..) tendono diventare sempre più diffuse e quindi la capacità media di download dell'utente aumenta, è un dato provato che un lento download (quindi un tempo di feedback molto elevato) abbassa l'usabilità di un sito, poiché non soddisfa, anzi innervosisce o annoia l'utente. Per questo motivo, realizzare dei siti Web "pesanti" altamente controproducente e non a caso, i portali più famosi risultano particolarmente leggeri da visitare.

Da citare infine le varie tecnologie software utilizzate per sviluppare siti Web (come Java o Flash): numerose sono divenute ormai comuni ed accessibili anche agli utenti meno esperti. risultato è stato il proliferare di siti Web in cui elementi multimediali come grafica, suoni ed animazioni abbondano in maniera incontrollata, a tutto discapito dei contenuto reale. Molti "puristi dell'usabilità professano la dottrina di minimizzare il più possibile l'uso di grafica e sonoro (scatenando, così, infiniti dibattiti sul contrasto tra usabilità e creatività).

Nel Web bisogna, inoltre considerare l'accessibilità. Questa branca, anche se spesso viene confusa con l'usabilità, ne è una parente stretta, dal momento che entrambe le discipline presentano numerosi punti di contatto. L'accessibilità si occupa di eliminare quei problemi che limitano l'accesso ad Internet alle persone virtualmente disabili (non esperti informatici o con strumenti insufficienti) oppure veri disabili. Purtroppo, molti siti Web sembrano non preoccuparsi di questa problematica quale, oltre che per motivi economici, dovrebbe essere affrontata anche per motivi di civiltà. Spesso sono sufficienti piccoli accorgimenti in fase di progettazione per rimuovere quegli ostacoli che rappresentano delle vere e proprie barriere architettoniche che per gli utenti disabili: ad esempio, includere il tag ALT per facilitare l'impiego di screen reader per non vedenti, usare combinazioni di colori visibili anche dai daltonici, evitare l'impiego feedback sonori a favore dei non udenti.

Usabilità nella progettazione del web

Da pochissimi anni si è cominciato a parlare compiutamente di usabilità di Internet. Quando il Web era ancor più intricato di adesso e quando il singolo sito non riusciva a fornire un'interfaccia intuitiva a chi vi approdasse, qualcuno ha cominciato a volgere l'attenzione a un punto di vista tanto scontato quanto ignorato: l'utente!

Una possibile definizione di Web Usability è la seguente: l'usabilità di un sito Web è l'insieme delle proprietà del sito stesso che favoriscono l'utente nel raggiungimento dei proprio obiettivo. Secondo questa definizione risulta che tutto quello che si interpone tra l'utente e ciò che egli si aspetta di poter fare sul sito rappresenta una frontiera critica di usabilità, vale a dire un potenziale ostacolo a proseguire. Tutti i fattori critici di usabilità devono essere affrontati in fase di progetto in modo tale da trasformali da ostacoli a porte di accesso, inviti all'utilizzo, segni di confidenza per l'utente.

Per valutare l'usabilità di un prodotto Web ma anche di un qualsiasi prodotto, è possibile sfruttare molti approcci, sviluppati grazie alle ricerche effettuate negli ultimi anni. Possiamo distinguere due differenti tipologie di valutazione, che racchiudono diverse tecniche: una analitica e una empirica.

Alcune delle tecniche più note di valutazione analitica sono il cognitive walkthrough e la valutazione euristica. Un elemento comune che lega tali tecniche consiste nel fatto che non è richiesto l'intervento


44/52

dell'utente ed il loro costo di applicazione è abbastanza ridotto. E’ quindi compito di un esperto analizzare un progetto sfruttando una delle precedenti tecniche, al fine di prevedere possibili problemi di usabilità. Ad esempio, attraverso il cognitive walkthrough, il valutatore si pone quattro domande, rispetto alle sequenze di azioni necessarie a svolgere uno specifico compito attraverso l'interfaccia utilizzata:

• Cercherà l'utente di produrre gli effetti associati all'azione? • Noterà che l'azione corretta è disponibile? • Trovata l'azione, capirà che è quella giusta per produrre l'effetto desiderato? • Una volta eseguita l'azione, sarà in grado di interpretare il feedback ricevuto?

La valutazione euristica si basa sull'impiego di regole empiriche (frutto di precedenti analisi) che guidano a priori la progettazione. Vi sono diverse "regole d'oro" da poter seguire, tra cui quelle definite dal celeberrimo Jakob Nielsen. Ad esempio, troviamo i seguenti consigli:

• Lo stato del sistema deve essere sempre visibile • I dialoghi devono essere sempre formulati secondo il linguaggio naturale • Deve essere sempre possibile cancellare azioni sbagliate e uscire dal sistema • Occorre essere consistenti e privilegiare le soluzioni standard sulle proprietarie • Occorre prevenire gli errori • L’utente deve ritrovare dei segnali di rinforzo che gli ricordino e confermino le proprie

possibilità/competenze d’uso • Il sistema deve essere flessibile a seconda del grado di expertise dell’utente • L’utente deve riceve sempre informazioni sintetiche e perspicue • Il sistema deve sempre segnalare gli errori in modo intuitivo • Il sistema deve offrire delle funzionalità di aiuto e documentazione in linea

Si può notare come questi 10 principi si riferiscano in buona parte a 3 grandi aree di problematicità:

1. Orientamento e Navigazione: Rendere cioè disponibili e comprensibili tutti quegli strumenti che consentono all'utente di capire immediatamente dove si trova, da dove è venuto e dove può andare all'interno del sito web. E' necessario presentare in maniera chiara e con nomi comprensibili le sezioni del sito, l'indicazione del percorso delle pagine interne, usando nomi significativi ed evitando di usare metafore poco chiare per l'utente. Bisognerebbe inoltre strutturare l'informazione seguendo il tipo di conoscenza dell'utente, più che il proprio, e assegnare la massima libertà di esplorazione e movimento all'utente, con chiare indicazioni di come tornare indietro e alla pagina principale.

2. Prevenzione e gestione di errori, senza allarmismi e con linguaggio comune. Gli errori dovrebbero prima di tutto essere prevenuti, ma se ciò non fosse possibile, sarebbe necessario offrire all'utente la possibilità di tornare sempre indietro, e dovremmo sempre spiegare cosa sta succedendo, con un linguaggio semplice e chiaro, evitando i messaggi tecnici del server. Ciò diventa particolarmente cruciale in caso di link mancanti, di inserimento di dati nei form, di procedure d'acquisto e di registrazione a servizi online, e coinvolge in prima istanza lo staff tecnico che si occupa del sito, ma anche il progettista: le gestioni degli errori vanno comunicate con un linguaggio il più possibile vicino all'utente finale.

3. Coerenza interna, aderenza agli standard e ai vincoli del web. E’ importante definire uno stile omogenero per l'intero sito, non disorientare il lettore con cambi di carattere tipografico, dimensioni, colori e layout senza un motivo che sia prima di tutto semantico. I cambiamenti di forma dovrebbero sempre corrispondere a cambiamenti logici, di contenuto. Per quanto riguarda l'aderenza agli standard, è importante che si conoscano gli elementi da inserire. I vincoli sono soprattutto quelli legati alla dimensione e al formato della grafica e delle


45/52

pagine html, della loro compatibilità all'indietro e dalla possibilità di essere fruite senza grossi problemi dal maggior numero possibile di dispositivi.

Ogni guideline tende poi a focalizzarsi su specifici aspetti dell'interfaccia. Cercare di seguirli il più fedelmente possibile (seguirli tutti è impossibile!) previene l'insorgenza di comuni problemi d'usabilità.

La valutazione empirica, invece, prevede l'uso attivo degli utenti e si basa su una qualche forma di osservazione delle azioni eseguite dall'utente stesso durante l'uso dei software. Ha il difetto di essere abbastanza costosa, poiché spesso è necessario disporre di un laboratorio d'usabilità attrezzato con specifici strumenti (come le telecamere) e di essere spesso intrusiva. Tuttavia permette di rilevare una notevole gamma di problemi. Tra le tecniche più importanti in quest'area vi sono l’osservazione, i questionari e le interviste.

L'osservazione diretta o indiretta consiste in un gruppo di valutatori che esaminano l'attività degli utenti: raccogliendo dati statistici, si cerca di analizzare il modo ed i tempi in cui i task vengono affrontati. Una tecnica meno intrusiva è quella dei questionari, in quanto permette di raccogliere informazioni sulle impressioni soggettive degli utenti. Un'altra tecnica è quella delle interviste, spesso condotte in modo informale e naturale: in questo modo è possibile per il gruppo di valutatori comprendere meglio il background ed anche il modo di pensare ed affrontare i problemi dell'utente.

Il massimo risultato dell'usabilità è consentire all'utente di raggiungere il proprio obiettivo quando questo coincida con l'obiettivo di vita del sito (per esempio fare acquisti su un sito di' commercio elettronico, consultare gli articoli su un sito di informazione, avere assistenza su un sito di customer care, ecc.). Il concetto è molto semplice: il committente (un'azienda, per esempio) decide di creare un sito Web per raggiungere un obiettivo definito da uno studio di fattibilità che ha condotto (ad esempio, fornire servizi di assistenza on line). Il sito deve essere progettato con i criteri di usabilità che consentiranno all'utente di arrivare effettivamente ad usufruire dei servizi sui quali il sito stesso si fonda. Come si vede, dunque, l'usabilità manifesta il suo massimo effetto quando l'utente raggiunge il proprio obiettivo (quello di ricevere assistenza per esempio) che coincide proprio con quello dei sito (dare assistenza).

E' chiaro che l'usabilità deve essere misurata sul 'bacino di utenti appartenenti al target di riferimento dei progetto (per esempio, i clienti dell'azienda). Visto, infatti, che il comportamento degli utenti verso un sito dipende in prima analisi dalle loro aspettative di questi stessi, è molto importante focalizzare l'attenzione su coloro che possono essere realmente interessati ai servizi offerti. Il problema di far conoscere tali servizi agli utenti "giusti" non rientra nell'usabilità ma nelle azioni di marketing (on line e off fine) e nel CRM (Customer Relationship Management: la gestione dei rapporti con i clienti). I criteri di usabilità presuppongono che l'utente sia quello desiderato e concorrono a far sì che questo raggiunga il massimo livello di interazione e di soddisfazione.

Come si vede, quindi, è molto importante affrontare la questione non solo in termini di strutture di navigazione, colori, ecc. ma anche di linguaggio, del messaggio che dovrà trasparire: cioè, in termini di comunicazione.

Nella fase di produzione dell’usabilità rientrano tutte le fasi di studio, progettazione e sviluppo (comprese le fasi di test). Andiamo adesso a vedere più in dettaglio quali sono le fasi nelle quali si sviluppa un modello di progettazione che tiene conto dei criteri di usabilità.

Fase 1: progettare la comunicazione

Il progetto di usabilità inizia dallo studio dei messaggio che deve essere dato e che dovrà apparire evidente. Molti siti non hanno successo o, addirittura, hanno fallito per non aver focalizzato l'attenzione sugli aspetti comunicativi. In un sito di commercio elettronico, per esempio, deve essere trasparente il fatto che l'obiettivo è vendere. E’ necessario anzi valorizzare tale obiettivo, specializzare il sito sui processi di acquisto e depurarlo di tutto ciò che può essere forviante e


46/52

ambiguo. La tendenza attuale ci aiuta in questo. L'utente infatti preferisce sempre più i siti specializzati: poche attività, molto definite e servizi ottimizzati allo scopo.

Comunque è fondamentale dare priorità a quelle domande che l'utente presumibilmente si pone per prime e che nel caso dei commercio elettronico possono essere: cosa fa questo sito? Mi interessano gli articoli in vendita? Chi c'è dietro? E’ destinato all'ingrosso o al dettaglio? Ci sono quantitativi minimi da acquistare? Come pagherò? Come riceverò il materiale? Quali sono le garanzie e le condizioni di recesso? Mi posso, dunque, fidare? Raggiungere questo livello di usabilità non è assolutamente facile. Parlando di comunicazione è necessario avere una conoscenza profonda dell'interlocutore (gruppo di utenti o singolo utente), di cosa si vuoi trasmettere e di come lo si può fare. Le regole da seguire ci vengono offerte dai risultati degli studi sul linguaggio e dalla semiotica.

E’ di vitale importanza dunque che la homepage sia focalizzata a far capire immediatamente l'obiettivo del sito. Visti i tempi medi di permanenza sulle pagine, in genere molto brevi, se l'utente non intuisce subito le finalità del sito, lo abbandonerà senza pensarci troppo (sarebbe un errore di usabilità della comunicazione). Per questo i contenuti più importanti dovranno essere subito visibili e intercettabili a colpo d'occhio senza obbligare l'utente all'uso delle scrollbar verticali.

In questo senso sarebbe un grave errore progettare un'interfaccia adatta solo per la risoluzione monitor 1024x768, non troppo diffusa tra gli utenti: attualmente lo standard è 800x600 e a volte è necessario pensare anche a risoluzioni minori.

Fase 2: progettare l'architettura usabile

Il lavoro del progettista inizia con la progettazione dei contenuti, dei servizi offerti, della piattaforma hardware e software lato server. Definiti questi aspetti si procede con la progettazione dell'architettura di navigazione dei sito e, infine, della grafica, Il concetto di usabilità è alla base di molte decisioni. Vediamone alcune.

Fase 2.1: progettare i contenuti

Quando si parla di contenuti non si intendono solo i testi bensì l'insieme di tutti gli elementi che concorrono a formare, appunto, il contenuto informativo del sito (testi, foto, filmati, ecc.).

La progettazione dei contenuti è uno degli aspetti più critici Rappresenta infatti il legame tra gli obiettivi dei sito e la sua reale organizzazione. E in questa fase infatti che si definisce la suddivisione in sezioni, l'organizzazione di un catalogo, la realizzazione di elementi, ecc.

E’ comprensibile dunque come l'usabilità ricopra l’intera fase di progettazione, perché è da questa che dipenderà la fruibilità dei contenuti stessi.

Fase 2.2. progettare i servizi

La capacità di offrire servizi e la loro reale usabilità può fare la differenza. In un ipotetico sito di commercio elettronico, infatti, una volta conquistata la fiducia dell'utente e datagli la possibilità di accedere ai contenuti (nella fattispecie il catalogo), l'ultimo "scoglio" si trova nell'utilizzo dei servizi.

Riempimento e salvataggio dei carrello gestione degli acquisti effettuati, cache personale, preferiti, aggiornamento del catalogo e/o dei prezzi, assistenza on line, comunicazioni personali, interscambi, sono servizi alcuni necessari, altri progettati esclusivamente per aiutare l'utente o consentirgli di velocizzare alcune procedure (quindi aumentare l'usabilità). Tutti devono essere facilmente intuibili.

Fase 2.3: progettare la navigazione

Vi sono alcuni canoni fondamentali che devono essere rispettati a priori nella fase di progettazione della navigazione di un sito. Il rispetto di questi parametri garantirà livelli di accessibilità e di usabilità basilari, senza i quali il progetto rischia fortemente di perdere efficienza e credibilità.

Primo fra tutti: l'utente dovrà essere in grado di raggiungere il proprio scopo nel minor tempo possibile. A tale fine è necessario ridurre al minimo la dimensione in KB delle pagine, evitare


47/52

introduzioni animate, bloccanti e non, ridurre in genere il numero di click necessari a raggiungere l'obiettivo organizzando flussi di utilizzo facilmente individuabili.

In questo senso ci vengono in aiuto le barre di navigazione, in primis la pulsantiera principale dei sito che le regole fondamentali dell'usabilità delle interfacce vogliono orizzontale e in alto, come le barre dei menu presenti nei programmi desktop. Queste devono mantenere sempre la stessa posizione nelle diverse pagine dei sito in maniera tale che l'utente possa sentirsi a suo agio ritrovando nelle varie sezioni punti fissi di riferimento. La ripetizione delle voci principali nella parte inferiore della pagina garantirà, inoltre, una maggiore navigabilità.

Voci accessorie possono trovare collocamento in barre verticali, che la tendenza attuale sta spostando sulla destra dello schermo così che i contenuti della parte sinistra risultino sempre completamente stampabili e siano la prima cosa che l'utente legge.

Circa la stampabilità dei contenuti è penalizzante l'utilizzo dei frame (che hanno peraltro controindicazioni per l'indicizzazione. Molto importante è evidenziare differentemente le diverse aree tematiche dei sito, con l'uso di colori o icone dedicate come pure usare link "esplicativi" contenenti parole chiave focalizzate all'argomento trattato nella relativa pagina e raccolti in menu laterali. Importante è inoltre non affidarsi alle animazioni come unici link ad una pagina dando invece un metodo alternativo: sempre più spesso le animazioni sono associate a pubblicità e quindi tendenzialmente ignorate.

L'obbiettivo è quello di dare il massimo controllo all'utente:

• non obbligandolo a scaricare grossi file grafici (come pesanti foto, ma fornendo delle miniature da ingrandire on demand, su richiesta)

• rendendo chiaro dove si trovi ad ogni istante, sia che stia navigando sia, a maggior ragione, nel caso approdi ad una pagina a seguito di una ricerca su un motore senza passare dalla homepage.

Fase 2.4: progettare la grafica

Compito dei Web designer è anche quello di progettare il lavoro per il grafico. La grafica ha lo scopo di dare credibilità al sito attraverso lo studio di elementi che manifestino all'utente cura e attenzione verso l'argomento trattato.

Immagini, icone, banner, sfondi e colori hanno la funzione di accompagnare l'utente attraverso percorsi di fruizione dei contenuti e dei servizi progettati precedentemente.

Al contrario di quanto avviene sviluppando grafica per supporti cartacei, sul Web c'è un "nemico" in più: le dimensioni in KB delle creazioni. Nella fase di definizione del layout delle pagine si dovrà pensare sempre a come il lavoro dovrà essere "tradotto" in HTML, così da evitare scelte difficilmente compatibili con l'usabilità. I colori dovranno essere studiati per dar risalto alle diverse aree tematiche e permettere all'utente di individuare a colpo d'occhio contenuti di suo interesse, così come lo studio delle icone avrà lo scopo di semplificare la navigazione.

La creatività dei grafico può essere esaltata inoltre dal possibile uso di standard vettoriali, come Macromedia Flash, che contribuiscono a rendere emozionale l'esperienza dell'utente, sempre a patto che questo non infici l'usabilità dell'insieme.

Fase 3: garantire l'accessibilità

L'accessibilità rappresenta una frontiera critica. Si tratta infatti di quelle proprietà dell'intero sistema che consentono o impediscono all'utente di accedere al contenuto.

Qui non si parla dunque di facilità di navigazione o di comunicazione, bensì di essere arrivati o meno a poter navigare o a poter interpretare. In prima battuta è legata alla possibilità di arrivare sul sito, in seconda di poter accedere alle informazioni in esso contenute e ai servizi da esso offerti.


48/52

Le varie problematiche dell'accessibilità vengono trattate in maniera esauriente dal W3C, che stabilisce delle linee guida da rispettare al fine di garantire a tutti gli utenti la fruizione delle varie tipologie di contenuto.

Ignorando queste linee, alcune categorie di utenti potrebbero risultare molto penalizzate: utenti che usano dispositivi di navigazione testuali o con funzionalità disattivate, connessioni lente, differenze di browser, plug in, sistemi operativi, ecc.

Tutte le linee guida dei W3C sono dotate di "punti di controllo", con diverse priorità, che hanno lo scopo di permettere la revisione della pagina al fine di validarla (garantirla, quindi, come accessibile) o meno. l principi guida generici dei l'accessibilità sono:

1) Assicurare una "trasformazione elegante" delle pagine: con il termine trasformazione si fa riferimento a quella che la pagina subisce cambiando l'interprete dei codice (browser diversi, solo testuali, disposítivi di sintesi vocale, display braille ecc.); per elegante si intende la salvaguardia della fruibilità dei contenuto.

2) Rendere il contenuto sempre comprensibile e navigabile.

Fondamentale è garantire l'accessibilità di base alle informazioni cercando di slegare la fruizione dei contenuti e dei servizi dallo strumento utilizzato per la navigazione e dalla piattaforma hardware e software lato client (Indipendenza dal dispositivo"). Il principio base è quello di separare la struttura di un documento (organizzazione logica: capitoli, paragrafi ecc.) dalla sua presentazione (come il documento viene reso: testo, sintesi vocale ecc.). Usare i corretti elementi HTML per separare i due aspetti permette agli "interpreti" di distinguere in maniera ottimale quelli legati al contenuto da quelli legati alla sua organizzazione logica.

Particolare attenzione deve essere dedicata agli utenti che hanno deficit di vario tipo (visivi, uditivi, motori o di comprensione lessicale). Sviluppare siti fruibilí anche da queste categorie di utenti porta notevoli benefici all'intera comunità Web. E’ necessario fornire, in genere, forme alternative di fruizione delle informazioni, sia grafiche che testuali, in modo da non penalizzare utenti con handicap: progettando equivalenti testuali per le immagini, non affidandosi soltanto al colore per l'evidenziazione di aree tematiche ma utilizzando "marcatori HTML" interpretabili da dispositivi di sintesi vocale utilizzati dai non vedenti, oppure realizzando una descrizione sonora o iconografica dei contenuto. Dobbiamo, inoltre, permettere la navigazione attraverso la tastiera, ottimizzando la tabulazione.

Fase 4: implementazione usabile

Progettata l'architettura dei sito, compresi i vincoli di accessibilità, agli sviluppatori spetta il compito di realizzare e ottimizzare la grafica, il codice e i contenuti. Chi realizza un sito Web si augura che possa essere consultato dal maggior numero possibile di visitatori. Quanti di noi, tuttavia, navigando su un sito si sono imbattuti in problemi di visualizzazione, di lentezza nel downIoad delle pagine, di scomodità nell'accesso alle informazioni, di mancanza di un plug-in, in errori veri e propri o altre situazioni analoghe? Situazioni di questo tipo si verificano non solo su siti amatoriali o non molto frequentati, ma anche su siti ad alto traffico. Spesso, infatti, si pone maggiore attenzione all'aspetto estetico di un sito Web a scapito della sua effettiva usabilità da parte di tutti i navigatori.

Uno dei principali ostacoli alla effettiva usabilità dei siti Web è, paradossalmente, lo strumento di visualizzazione principale: il Web browser. Nonostante le raccomandazioni dei W3C (World Wide Web Consortium), i vari browser implementano determinate caratteristiche in maniera diversa o aggiungono estensioni proprietarie all'HTML standard. A peggiorare la situazione, spesso, c'è scarsa la compatibilità tra versioni differenti dello stesso browser.

Spesso la "soluzione" usata per aggirare questo problema si limita all'indicazione, nella home page dei sito, che le pagine sono ottimizzate per uno specifico browser. Naturalmente questa soluzione non si pone nemmeno il problema dell'usabilità. Una soluzione completamente opposta si basa su


49/52

tecniche di individuazione dei tipo di browser che accede al sito (browser sniffing) e alla personalizzazione dei codice HTML. Nella maggior parte dei casi questo vuoi dire creare più versioni delle pagine Web duplicando o triplicando il lavoro di creazione e di manutenzione dei sito.

Un buon compromesso consiste nel considerare un determinato browser come target dei sito e prevedere codice HTML utilizzabile da qualsiasi browser, anche se meno ricco esteticamente. In questo modo viene salvaguardata l'usabilità dei sito senza rinunciare a fornire un buon impatto visivo agli utenti dotati di uno specifico browser.

E’ fondamentale comunque che venga sempre indicato il browser di riferimento per ottenere la migliore qualità di visualizzazione.

Un altro aspetto molto importante è la gestione corretta della risoluzione video. Anche se ormai lo standard di riferimento per la risoluzione video è 800x600 pixel, non possiamo fare completo affidamento su questa assunzione. Un utente potrebbe avere impostato una risoluzione più bassa o più alta e gli elementi della pagina Web potrebbero non risultare così accessibili come li avevamo pensati. Immaginate una tabella a dimensioni fisse con ampiezza impostata a 800 pixel: su uno schermo con risoluzione 640x480 non verrebbe visualizzata per intero e occorrerebbe scorrere orizzontalmente la pagina (cosa da evitare per quanto è possibile). Se poi la tabella viene visualizzata all'interno di un frame su cui è stata inibita la presenza di barre di scorrimento mettiamo l'utente nell'impossibilità di utilizzare la nostra pagina.

Per evitare queste situazioni sarebbe opportuno usare il dimensionamento in pixel di tabelle ed altri elementi (come, ad esempio, i frame) soltanto quando le dimensioni risultano inferiori alla risoluzione minima 640x480. Negli altri casi potrebbe convenire l'assegnamento di dimensioni proporzionali, anche se in certe situazioni viene sacrificato l'aspetto estetico.

Se invece l'utente utilizza una risoluzione troppo alta corriamo il rischio che il testo della nostra pagina risulti troppo piccolo e difficilmente leggibile.

E’ possibile intercettare la risoluzione video corrente e personalizzare la pagina in base a tale informazione. Possiamo catturare però queste informazioni e passarli al server all'inizio della navigazione dell'utente, mantenendola per tutta la durata della sessione in modo da poter produrre codice HTML adeguato alla risoluzione corrente direttamente tramite l'elaborazione server-side.

Un altro fattore che influisce sull'usabilità di un sito Web è la velocità di caricamento delle pagine. Questo aspetto è larga parte dipendente dalla velocità di connessione disponibile per il navigatore, ma non possiamo fare assunzioni generali in quanto la velocità è spesso soggetta a diverse variazioni dovute al traffico.

Tuttavia, una particolare attenzione nella composizione di pagine consente di renderle leggere e rapidamente caricabili. Come regola generale sarebbe opportuno mantenere dimensioni di una pagina Web e dei suoi componenti (immagini, script, ecc.) al di sotto della soglia dei 30 KB. In quest'ottica possono tornare utili i seguenti suggerimenti :

• Evitare codice inutile Alcuni editor di pagine Web aggiungono dei codice HTML in maniera automatica che spesso risulta dei tutto inutile; numerosi spazi codificati come usati per posizionare elementi, di tabelle o paragrafi vuoti presenti in fondo alla pagina, ecc.

• Utilizzare i CSS (Cascading Style Sheets) esterni In questo modo si estraggono le informazioni di formattazione dall'interno della pagina e viene sfruttata cache per i successivi riferimenti. Si ha inoltre il vantaggio di facilitare la manutenzione delle pagine, momento che le informazioni di formattazione sono concentrate in un unico punto.

• Utilizzare script esterni Nel caso in cui blocchi di script client-side vengano usati più volte nelle diverse pagine dei sito è opportuno memorizzarli in file esterni e includere un riferimentc ciascuna pagina sfruttando l'attributo src dei <script>; i vantaggi sono analoghi a quelli visti per CSS.


50/52

• Utilizzare formati di immagine adeguati Le immagini costituiscono il peso maggiore nella esposizione delle pagine Web; per questo motivo è opportuno limitare al massimo le loro dimensioni in byte. Fra i due principali formati per il Web è opportuno sceglire quello più adeguato al tipo di immagine da inserire nella pagina. Come regola generale, per immagini di tipo fotografico viene usato il formato JPG, mentre per altre immagini si usa il formato GIF. Forzare l'invio al browser Quando le pagine Web coinvolgono delle elaborazioni lato server abbastanza impegnative, per cui la velocità di caricamento della pagina è influenzata dalla velocità di elaborazione dei server, è opportuno dare all’utente un feedback di quello che sta succedendo. Un meccanismo può essere quello di inviare i dati al browser man mano che questi vengono prodotti.

L'utilizzo dei frame in un sito Web è un argomento molto controverso. Molti sviluppatori usano i frame nei loro progetti per via della possibilità di strutturare il layout della pagina in maniera che sia di facile manutenzione: la modifica ad un'intestazione contenuta in un frame coinvolge una sola pagina. Tuttavia i problemi che creano i frame all'usabilità sono diversi:

• Non sempre è chiaro all'utente inesperto come muoversi all'interno di una pagina strutturata in frame;

• L'utilizzo del pulsante back non sempre dà i risultati che l'utente si aspetta;

• La memorizzazione della pagina tra i bookmark dell'utente riporta l'indirizzo della pagina che descrive la struttura in frame e non la pagina correntemente visualizzata;

• L'indicizzazione da parte dei motori di ricerca è relativa alla singola pagina, per cui si possono avere dei collegamenti diretti a pagine che dovrebbero essere visualizzate in un frame e che, senza il contesto opportuno, possono risultare inutilizzabili.

E’ possibile rinunciare all'uso dei frame in un sito Web, senza perdere la facilità di manutenzione usando tecniche di inclusione server-side, ossia in istruzioni in linguaggi di programmazione che permettono di includere file contenenti l’intestazione o il piè di pagina. In questo modo si mantiene la semplicità di manutenzione e si evitano i lati negativi dell'uso dei frame.

Infine, la presenza di elementi multimediali come audio, video o animazioni può essere spesso un elemento che limita l'usabilità delle pagine Web. Un esempio è dato dal rapido diffondersi della tecnologia Flash che ha indotto molti sviluppatori di pagine Web ad inserire animazioni interattive nei propri siti. Spesso questi sviluppatori dimenticano che non tutti hanno installato l'apposito plug-in e che è buona norma fornire un'alternativa HTML al contenuto multimediale. Tra l'altro, dal momento che in genere i contenuti multimediali hanno un certo peso sulla velocità di caricamento della pagina, sarebbe opportuno verificare l'effettiva fruibilità dell'elemento multimediale da parte dei browser prima di inviarglielo.

Quelle che abbiamo visto sono soltanto alcune delle tecniche applicabili per rendere i nostri siti Web maggiormente accessibili. Numerosi altri aspetti sono da prendere in considerazione per creare siti universalmente fruibili: versioni stampabili delle pagine, intercettazione della lingua dell'utente, ecc.

A complicare la situazione si aggiunge il fatto che si stanno sempre più diffondendo altri dispositivi di navigazione con caratteristiche molto particolari: WebTV, palmari, telefonini WAP ecc.

Questo dovrebbe indurre a pensare alle problematiche di usabilità non più come accessorie ma di fondamentale importanza per la sopravvivenza di un sito Web.

Fase 4.1: scrivere testi usabili

Dopo la progettazione dei contenuti effettuata dal content designer, i Web writer hanno il compito di scrivere i testi in modo che risultino usabili per il navigatore. Sul Web la lettura. è molto più faticosa che su carta, quindi l'obiettivo primario è quello di sintetizzare quanto più possibile i concetti, facendo in modo che le informazioni più importanti siano riassunte nella parte iniziale della pagina,


51/52

allo scopo di veicolare il messaggio in maniera veloce minimizzando la probabilità che l'utente abbandoni la lettura senza aver trovato quello che cerca.

Ogni documento web comunica attraverso due componenti fondamentali: una iconica ed una linguistica. La componente iconica è composta dagli elementi grafici o sonori presenti in pagina. Quella linguistica invece è costituita dai testi, dai titoli, dagli slogan, dai links.

Queste due componenti sono fondamentali perché in grado di determinare il successo o il fallimento di un pagina web, ossia la sua possibilità di essere "letta". Mentre la componente iconica influisce principalmente sull'attrattività e sulla riconoscibilità dell'emittente, la componente linguistica determina la corretta comprensione dei significati e delle informazioni contenute nelle pagine.

Spesso la comunicazione linguistica delle pagine e dei siti web risulta difficilmente interpretabile perché i codici linguistici utilizzati non sono condivisi dall'emittente e dal ricevente. Per questo motivo, nella fase di redazione dei contenuti di un documento web, per comunicare senza pregiudicare la qualità dello scambio di significati tra emittente e ricevente, è necessario valutare attentamente il destinatario della comunicazione e soprattutto il suo livello di competenza linguistica. Più ampio è il pubblico a cui ci si rivolge, più semplice e chiara dovrà essere la comunicazione.

Scrivere testo per il web diventa così diverso dallo scrivere su carta, anche se è basato sulle stesse qualità di fondo. Nella scrittura di un testo per web si deve fare riferimento alle questi principi basilari:

• Quantità: scrivere solo informazione testuale assolutamente necessaria; • Qualità: scrivere informazioni testuali di qualità, cioè, non è possibile prescindere da una

buona sintassi e una corretta grammatica; • Relazione: scrivere informazioni rilevanti e coerenti con l'argomento; • Modo: scrivere in modo chiaro e sostanziale.

Il web vuole una scrittura pratica, concisa. Il linguaggio del web deve esprimere in maniera diretta i contenuti, senza perifrasi o espressioni vaghe, eliminando tutte le parole superflue e le frasi lunghe e i periodi con troppe coordinate e subordinate.

Nel testo devono essere aboliti i gerghi e tutti i termini incomprensibili ed evitare i giochi di parole che potrebbero non essere compresi da parte di eventuali utenti internazionali. Il ritmo deve essere sincopato: per esempio, evitare frasi che abbiano tutte la stessa cadenza. Ad un periodo più lungo anteporre e posporre sequenze di frasi più brevi.

Tra le modalità di scrittura introdotte dal web c'è la scrittura "a piramide rovesciata", dove i concetti più importanti vanno evidenziati sin dall'inizio. Non viene richiesto di arrivare a delle conclusioni attraverso un ragionamento, come avviene nei romanzi. L'utente vuole sapere subito se troverà nel testo ciò che lo potrà interessare. Questo comporta una scrittura di tipo giornalistica con l'esposizione della conclusione o della notizia. I dettagli vanno aggiunti in seguito. Titoli e le prime frasi sono, quindi, le parti più importanti che devono essere curate attraverso l'introduzione di frasi chiave.

I link, o collegamenti ipertestuali, sono una parte importante dell'interfaccia di un ipermedia perché permettono all'utente di prendere delle decisioni sul suo percorso di lettura, spostandosi all'interno della pagina o da una pagina all'altra, in un sito o nel Web. La parte testuale del link è fondamentale per garantire che l'utente possa comprendere rapidamente quale tipo di informazioni troverà nel momento in cui decide di seguire il link.

I link ipertestuali sono fondamentalmente di due tipi: link strutturali, che permettono all'utente di muoversi all'interno delle informazioni contenute in un sito, facilitando la navigazione; link associativi, solitamente parole sottolineate che portano a pagine di approfondimento del testo utilizzato per il link o a pagine dal contenuto simile o correlato.


52/52

Una scrittura corretta dei testi presenti nei link strutturali e associativi, ossia la descrizione dei link, permette di facilitare le scelte che l'utente compie, migliorando in questo modo l'usabilità del sito. Si devono scegliere descrizioni brevi o label (etichette verbali), scegliendo poche parole (possibilmente un massimo di quattro) che comunichino la maggior quantità di informazioni all'utente, aiutandolo a decidere se seguire o meno il link. Fornire più vie d'accesso ai contenuti è normalmente un aiuto per l'utente, a patto che i criteri delle diverse categorizzazioni siano ben distinti e non si possano confondere.

La lettura si fonda su due processi: il primo consiste nel riconoscimento visivo, il secondo nell'estrazione del significato. Il secondo processo (l'estrazione del significato) viene ostacolato da una cattiva percezione. Per migliorare la percezione visiva bisogna usare alcuni espedienti pratici:

• Spezzare i periodi andando frequentemente a capo. Un unico blocco di testo viene visto come un ostacolo insormontabile. Ogni periodo deve concentrarsi su un solo concetto. Questo facilita visivamente, ma anche concettualmente, il processo di comprensione del lettore.

• Evidenziare le parole chiave: per farlo è meglio utilizzare il grassetto o usare un colore saturo e non troppo luminoso, come il rosso, per evidenziare il testo.

• Usare i link con parsimonia, e solo per informazioni secondarie e non determinanti per la comprensione del discorso, perché sono dei distrattori, dato che danno all'utente la tentazione di seguirli.

• Non utilizzare una colonna di testo troppo larga.

• Utilizzare dove possibile elenchi numerati o con puntatore. Le voci risultano chiaramente divise e spaziate. E' meglio naturalmente mettere le voci più importanti in alto.

• Scegliere colori che assicurino un buon contrasto, valutando anche l'impatto emotivo, il calore, la sensazione che la pagina trasmette. Caratteri neri su sfondo bianco offrono il contrasto migliore.

• Utilizzare un carattere tipografico standard. I caratteri più diffusi sono: il times, usato molto in stampa, con le grazie che aiutano la lettura; l'arial e il verdana, senza grazie, più leggibili su monitor specialmente con caratteri di dimensioni piccole; il courier, carattere con grazie monospaziato, che ricorda la macchina da scrivere.

Completate le fasi di sviluppo e i test di usabilità, il sito può essere pubblicato e attraverso il Web diventa accessibile all'utente. Il consumo di un sito parte ovviamente dall'accessibilità, segue con la navigazione e arriva all'effettivo utilizzo dei servizi, quindi al raggiungimento dell'obiettivo.

Riferimenti

S. Ceri, P. Fraternali, A. Bongio, M. Brambilla, S. Comai, M. Matera, Progettazione di dati e applicazioni per il Web, McGrawHill 2003,

L. Toselli, Il progettista multimediale, Bollati Boringhieri, 2001

A. Spila, Scrivere per il web: guida alla scrittura on-line, 2002, http://www.html.it/webwriting

J. Nielsen, "Designing Web Usability", New Riders Publishing

www.w3.org/WAI, W3C Web Accessibility Initiative, 1997-2002

www.uplink.it/usabilita, Uplink Web Agency, 2001-2002

progettazione di applicazioni web - isdigital.it · analisi dei requisiti 11 progettazione dei dati...

Documents