Interfaccia Utente

In una fase preliminare deve avvenire la descrizione dei casi d’uso e i vari diagrammi delle attività legate ai singoli casi d’uso. Questi aspetti non verranno dettagliati in modo particolare nella presente sezione, si può far riferimento al Capitolo 4 perché non si discostano dalle normali attività dell’ingegneria del software. Qui verranno spiegate le nuove modalità di progettazione dell’interfaccia utente e della progettazione dell’applicazione tipiche della realizzazione delle Applicazioni Web.

Una delle prime attività, risulta quindi, l’analisi del modello dei casi d’uso e l’identificazione degli oggetti che implementano il comportamento in essi descritto. Questa fase è identificabile con l’analisi dei casi d’uso, ed è la base dell’analisi dei requisiti.

Aspetto innovativo introdotto da Conallen è quello del gruppo UX, il quale si occuperà di definire il look-and-feel dell’applicazione e fornire schermate d’esempio. Questo compito risulta, in parte, di pertinenza dei grafici. Per quanto riguarda la progettazione in senso stretto, aspetto di interesse, si farà uso dell’UML per modellare i percorsi di navigazione tra le pagine. E’ un elaborato di primaria importanza dal punto di vista architetturale. I diagrammi prodotti rappresentano la struttura logica delle schermate e la mappa dei percorsi di navigazione.

39

Si identificano tutti i percorsi legali e attesi dell’applicazione. Questa mappa per piccoli siti Web viene di norma fatta a mano e senza l’uso di formalismi precisi. Nel nostro caso, per la progettazione di grandi Applicazioni Web, si richiede l’utilizzo di un formalismo basato su UML.

3.2.1 Modellazione con UML

Nel seguito vengono descritti, a titolo di esempio gli elementi base del formalismo WAE.

Una schermata è rappresentata come una classe stereotipata UML con lo stereotipo <<screen>>. Il nome della schermata è usato come nome di classe e la descrizione della schermata viene usata come descrizione della classe. Le schermate, come gli altri elementi UML possono essere organizzate in package, sulla base di confini identificati in base alle funzionalità fornite.

Figura 33: Notazione per una Schermata

Nella Figura 33 si vede un esempio di notazione per una schermata. I contenuti statici, per esempio etichette testuali e immagini, non sono significativi dal punto di vista architetturale e non sono pertanto considerati nel modello. Anche la struttura o la disposizione dei contenuti, non viene considerata nel modello, almeno in questa fase. I contenuti dinamici vengono enumerati come attributi della classe.

40

Nella Figura 34 si vede il caso di una schermata che comprende un carrello virtuale (cart). In essa compaiono gli attributi per la visualizzazione come array per indicare la possibilità che il carrello sia composto da più prodotti ordinati. Altra modalità possibile è quella che i prodotti siano elencati in una classe a parte e siano raggruppati tramite una relazione di composizione alla schermata. Questa seconda possibilità è mostrata nella Figura 35.

Figura 35: Modellazione con relazioni di composizione

I comportamenti delle schermate sono modellati come operazioni sulla schermata.

Nella maggior parte dei casi si tratta di operazioni invocate dall’utente sulla schermata per alterare lo stato della schermata o lo stato del sistema. La convenzione è di indicare queste operazioni con una semplice frase imperativa in cui il soggetto implicito è la schermata.

Le operazioni che producono come unico risultato la navigazione verso una diversa pagina non dovrebbero essere incluse nella lista delle operazioni della schermata. Tali operazioni dovrebbero essere più propriamente modellate come associazioni verso la schermata di destinazione (il risultato è simile ai link inter-pagina del WebML).

41

Figura 36: Comportamento rappresentato come operazioni

3.2.2 Flusso delle schermate

La maggior parte delle Applicazioni Web fornisce le proprie funzionalità attraverso la navigazione tra le diverse schermate e i percorsi tra le schermate che partecipano agli scenari sono un elemento architetturale chiave. I percorsi di navigazione sono modellati come delle associazioni tra schermate (si veda la Figura 37).

Figura 37: Notazione per la navigazione tra schermate

3.2.3 Input dell’utente e Mappa di navigazione

Nel presente modello è importante descrivere tutti i campi di input e opzionalmente, i tipi di controlli ad essi associati.

Le form di input sono modellate con una classe stereotipata con <<input

form>>. I campi sono modellati come attributi e può essere opzionalmente

attribuito loro un nome tipo quello del controllo di input associato. Il form può essere modellato come classe associazione o come classe inclusa (si vedano la Figura 38 e la Figura 39).

Associazione Inclusione

Figura 38: Form con associazione Figura 39: Form con inclusione

42

Altro passo da seguire, successivamente alla definizione delle schermate, è quello della scrittura dello storyboard.

Lo storyboard comprende il susseguirsi delle istanze delle schermate in un processo di navigazione. Non risulta particolarmente espressivo, alle volte è meglio modellare tale situazione come diagramma di sequenza UML. Attraverso la mappa di navigazione non si mostrano i dettagli delle singole schermate e, qualora risulti appropriato, le classi possono essere rappresentate con le icone associate agli stereotipi. Risulta un diagramma di navigazione tra le pagine del sistema, le pagine sono schematizzate come icone delle quali non si mostrano attributi o operazioni, lo stesso dicasi per i form. L’aspetto principale risulta quello delle associazioni direzionali che caratterizzano il flusso effettivo della navigazione. Si possono aggiungere informazioni come :

• Visibilità della Schermata : $ nel caso di pagina navigabile e raggiungibile da ogni altra parte del sistema, aggiunto in coda al nome;

• Pagine a scorrimento: + in coda al nome per descrivere pagine il cui contenuto verrà presentato su più schermate successive;

• Notazioni per SSL.

Questi simboli sono un possibile esempio e non sono propri dello standard UML esteso WAE.