5.2 Analisi dell’interfaccia utente
6.1.3 UML: Unified Modeling Language
Nella fase di progettazione del software abbiamo sottolineato l’importanza della crea- zione di modelli astratti, ognuno dei quali rappresenta un aspetto diverso di un sistema. In particolare un modello è una rappresentazione astratta del sistema, ovvero una de- scrizione che lascia da parte i dettagli a favore dell’identificazione delle caratteristiche salienti. Per rappresentare il software da diversi punti di vista è necessario sviluppare modelli differenti. Possiamo per esempio individuare un modello a partire da una pro- spettiva esterna, nella quale vengono individuati il contesto e l’ambiente nel quale si in- serisce il sistema; da una prospettiva strutturale, nella quale viene presentata la struttura del sistema e dei suoi dati; da una prospettiva di interazione, nella quale si modellano le interazioni tra un sistema e il suo ambiente; da una prospettiva comportamentale, nella quale si analizza il modo in cui il sistema risponde agli eventi.
Per creare queste rappresentazioni sono stati utilizzati i diagrammi e i costrutti messi a disposizione dall’Unified Modeling Language (UML), un linguaggio per la modellazione basato sul paradigma orientato agli oggetti, diventato standard con la sua prima versio- ne nel 1997 grazie all’Object Management Group (OMG).13 La versione attuale è la 2.5,
pubblicata nel 2017.
Consultando le specifiche dell’ultima versione,14 i diagrammi si dividono in due
grandi categorie:
• diagrammi di struttura (structure diagrams), che mostrano la struttura statica del sistema e dei diversi livelli di astrazione e implementazione delle sue parti, evi- denziando la relazione tra i vari elementi.
• diagrammi di comportamento (behavior diagrams), che mostrano il comportamen- to dinamico degli elementi nel sistema. La dinamica di un sistema può essere de- finita come l’insieme dei cambiamenti che si registrano in un determinato lasso di tempo.
13OMG:https://www.omg.org/.
Figura 6.2: UML 2.5: classificazione dei diagrammi.
Osservando la figura 6.2 possiamo vedere che da ogni categoria si ramificano vari ulteriori tipi di diagrammi.
Per la progettazione del motore di ricerca di EVT 2, sono stati realizzati due tipologie di diagrammi di struttura (Component diagram e Class diagram) e due tipologie di dia- grammi di comportamento (Sequence diagram e Activity diagram), ritenendoli modelli basilari per una completa visione delle funzionalità da implementare.
Diagramma dei componenti (Component diagram)
Il diagramma dei componenti è una rappresentazione del sistema ad alto livello e ha lo scopo di descrivere le componenti e le interfacce15dell’applicazione e le relazioni che
intercorrono tra di loro. Un componente rappresenta un modulo all’interno del sistema e ha una sua specifica tipologia, la cui conformità è definita dall’interfaccia richiesta, che risponde in ultima analisi alle specifiche funzionali del sistema. I vari elementi sono col- legati tra loro da connettori, che hanno il compito di specificare il tipo di relazione che vi 15Nella programmazione orientata agli oggetti un’interfaccia ha il compito di offrire servizi a un com- ponente. Essa definisce la modalità di interazione tra il componente e il mondo esterno. Possiamo semplicemente definirla come «il pannello di controllo dell’oggetto» (Sintes 2002, p. 19).
intercorre. Questo metodo di sviluppo fonda la propria esistenza sull’elevata riusabilità dei componenti creati.16
La figura 6.3 rappresenta il diagramma dei componenti del motore di ricerca di EVT 2. Come mostrato dalla figura, la struttura del motore di ricerca segue una logica object oriented, astraendo il più possibile il modello dai dettagli implementativi in modo che possa essere utilizzato a prescindere dal linguaggio con il quale viene sviluppato.
Figura 6.3: EVT 2 Search: il diagramma dei componenti.
Il diagramma segue l’architettura MVC e si divide, di conseguenza, in tre gruppi principali, all’interno dei quali sono definiti i componenti e le interfacce appartenenti a ogni categoria.
All’interno della macro componente del model troviamo gli elementi che si occupano della gestione e dell’elaborazione dei dati. Qua vengono definite due interfacce. La prima (Search Interface) ha il compito di creare un’interfaccia per la ricerca, mentre la seconda è l’interfaccia dedicata ai parser XML (XML Parser Interface). Come mostrato in figura, quest’ultima è richiesta dal componente Object Builder, che avrà il compito di creare oggetti di tipo Parser, in questo caso LineBeginning Parser e ParagraphLine Parser, che si occuperanno di analizzare ed estrarre i dati necessari dalle varie tipologie di documenti XML. I due componenti si serviranno dei metodi forniti da XML Document.
Nella progettazione di questa prima parte è stato utilizzato un modello specifico chia- mato factory design pattern. Lo scopo del pattern è quello di creare oggetti. È solitamente implementato in una classe o in un metodo statico17di una classe e ha lo scopo di ese-
16The Unified Modeling Language 2018.
guire le stesse operazioni in presenza di oggetti simili, permettendo la loro creazione a “tempo di esecuzione” senza conoscerne il tipo specifico.18
Un altro componente che farà parte del motore di ricerca è l’Index, il quale è responsa- bile della fase di indicizzazione, nella quale utilizzerà i dati restituiti dal parser. L’indice creato verrà utilizzato dal componente Search Query, che avrà il compito di occuparsi dell’elaborazione della keyword inserita dall’utente con lo scopo di restituire i risultati della ricerca, gestiti dal componente Search Results. Il Provider recupererà i risultati e li renderà disponibili al Controller, componente che gestirà il flusso di dati dall’elabora- zione alla presentazione, inviandoli alla view. All’interno di essa avremo il componente Directive, che farà da intermediario tra il componente Controller e il componente HTML Template inviando i dati a quest’ultimo, permettendo così la loro visualizzazione sullo schermo dell’utente.
Diagramma delle classi (Class diagram)
Il diagramma delle classi descrive i modelli degli oggetti che fanno parte del sistema e le varie tipologie di relazioni che intercorrono tra di loro. Le due principali relazioni che possiamo trovare in questo tipo di diagrammi sono l’associazione (association) e la generalizzazione (generalization).19 Il primo specifica una relazione di dipendenza tra le
istanze delle classi coinvolte, mentre nel secondo caso esiste una relazione diretta, col- legata al tipo della classe, tra un classificatore generale (superclasse) e uno più specifico (sottoclasse).
Vi sono varie prospettive impiegabili per la creazione dei diagrammi di classe. In particolare vengono messi in evidenza tre modelli.20Il primo modello è concettuale (con-
ceptual), disegnato con poca o nessuna considerazione per il linguaggio che si andrà a utilizzare in fase di implementazione. Il secondo è basato sulle specifiche (specification), e andrà a prediligere la descrizione delle interfacce del software, ma non dell’implemen- tazione. La differenza tra interfaccia e implementazione è spesso trascurata nella pratica, in quanto la nozione di classe in un linguaggio object oriented combina sia l’interfaccia che l’implementazione.
18Stefanov 2010, p. 146. 19Fowler e Scott 2000. 20Fowler e Scott 2000.
Figura 6.4: EVT 2 Search: il diagramma delle classi.
Infine il terzo modello è quello basato sull’implementazione (implementation) ed è il più usato. In questo caso vengono definite le classi con i loro metodi e attributi, descrivendo anche gli aspetti implementativi.
Il diagramma delle classi per il motore di ricerca di EVT 2 (figura 6.4) è stato costruito seguendo il terzo modello e in esso possiamo individuare varie tipologie di relazioni, in particolare relazioni di dipendenza e di generalizzazione. La relazione di dipendenza in- dica che alcuni elementi richiedono o dipendono da altri elementi. Nel caso del diagram- ma in figura abbiamo la relazione di dipendenza “use”, la quale indica che un elemento utilizza i dati restituiti da un altro elemento, e la relazione di dipendenza “create”, che indica la creazione di un elemento da parte di un altro. La relazione di generalizzazione è invece indicata utilizzando la parola chiave “extend” e viene utilizzata nel caso in cui un elemento estenda un altro.
Analizzando il diagramma, tenendo in considerazione che l’applicazione è stata im- plementata utilizzando AngularJS, possiamo individuare due interfacce, in particola- re EvtSearchParser. Essa viene estesa da oggetti di tipo Parser, creati dinamicamen- te dal servizio evtSearchBuilder, che hanno il compito di estrarre i dati necessari dal documento XML in modo da permettere al servizio che si occupa dell’indicizzazione,
evtSearchIndex, di utilizzarli. Per elaborare i dati, i parser si serviranno dei metodi pre- senti nel servizio evtSearchDocument, che gestisce le operazioni generali relative al do- cumento XML. evtSearchDocument ed evtSearchBuilderverranno poi utilizzati dal ser- vizio evtSearch, che inizializzerà la funzionalità di ricerca. Una volta creato, l’indice verrà usato dal servizio evtSearchQuery che si occuperà di estrarre da esso i risultati della ricerca effettuata dall’utente. Come possiamo vedere, la parte di indicizzazione e query fa uso del package esterno lunr.js.21 I risultati verranno poi utilizzati dal servi-
zioevtSearchResults, che si occuperà di organizzarli in modo da permettere successiva- mente al controller SearchBoxCtrldi inviarli al template evtSearchBoxTemplatemedian- te la direttivaevtSearchBoxDirective. Lo scopedella direttiva verrà esteso dal provider
evtSearchBox. In questo modo i componenti esterni saranno in grado, tramite il provi- der, di accedere ai valori delloscope, come ad esempio il valore che assumerà il campo di input. In AngularJS il provider è un servizio che viene adottato se c’è la necessità di eseguire operazioni prima dell’avvio dell’applicazione. In questo caso, esso ha il compi- to di creare gli elementi che andranno a far parte dell’interfaccia utente. In particolare
evtSearchBox, tramite il metodobuild(), creerà il box per la ricerca, composto dal campo di input, nel quale l’utente andrà a inserire la query, e da vari bottoni che permetteranno 21LUNR:https://lunrjs.com/.
di avviare la ricerca, visualizzare i risultati e attivare o disattivare le opzioni disponi- bili. Il servizio si occupa inoltre di monitorare lo stato dei vari elementi, in modo che il controller possa aggiornare i dati nel template, che si visualizzeranno sullo schermo dell’utente. La stessa logica vale per la tastiera virtuale, che verrà inserita all’interno del box di ricerca. Essa dipende daevtSearchBox, che ne gestisce lo stato.
Diagramma di sequenza (Sequence diagram)
Il diagramma di sequenza è il tipo più comune di diagramma UML di comportamen- to e si concentra sullo scambio di messaggi tra un certo numero di linee di vita, dette lifelines. Una lifeline, rappresentata da una linea tratteggiata, descrive la durata della vita dell’oggetto, posizionato all’interno di un rettangolo. I rettangoli sottili posizionati in verticale sono le caselle di attivazione, chiamate anche caselle di richiamo del meto- do, e indicano il tempo impiegato dall’oggetto per eseguire l’elaborazione con lo scopo di soddisfare un messaggio proveniente da un’altro elemento. Esso è rappresentato da una freccia che collega le lifelines di due oggetti, etichettata con il tipo di messaggio trasmesso. L’ordine di trasmissione dei messaggi parte dall’alto e si sviluppa verso il basso.
Nonostante i diagrammi di sequenza non abbiano il compito di mostrare una logica procedurale complessa, esistono un certo numero di meccanismi in grado di esprimere un basilare flusso di controllo, che rientrano nella categoria dei frammenti combinati (combined fragments). Un frammento combinato è rappresentato da una o più sequenze di elaborazione racchiuse in un frame. I frammenti posso essere di varie tipologie, in particolare è molto diffuso il frammento loop, che descrive una serie di messaggi che vengono ripetuti, o i frammenti multipli alternativi (alt), che gestiscono le condizioni ed eseguono solo il frammento la cui condizione è vera.22
La figura 6.5 rappresenta il diagramma di sequenza del parser utilizzato per estrarre i dati da un documento XML, in modo che questi siano pronti quando l’utente utilizza il motore di ricerca.
Figura 6.5: EVT 2 Search: il diagramma di sequenza del parser XML.
L’applicazione invia un messaggio con lo scopo di creare un parser adatto allo spe- cifico documento XML. Una volta creato, queto invierà uno o più messaggi, a seconda della quantità di documenti XML da analizzare, tramite un’iterazione rappresentata gra- ficamente dal frame loop. Lo scopo è quello di analizzare gli elementi in modo da identi- ficarli e associarli ad altre eventuali informazioni utili. Ogni invio di messaggio ha come risultato un oggetto contenente gli elementi parsati di uno specifico documento. Questi elementi saranno successivamente restituiti all’applicazione che, utilizzandoli, invia un altro messaggio all’oggetto incaricato alla creazione e gestione dell’indice. L’indice crea- to verrà poi restituito dall’applicazione, che tiene pronti i dati necessari in previsione di una query da parte dell’utente.
La figura 6.6 rappresenta invece il diagramma di sequenza del motore di ricerca, che ha il compito di accogliere la richiesta dell’utente sotto forma di query e restituire uno o più risultati nel caso esistano.
Figura 6.6: EVT 2 Search: il diagramma di sequenza del motore di ricerca.
L’utente invia un messaggio al box di ricerca e ne richiede l’apertura premendo un pulsante. Una volta aperto il box, l’utente invia un altro messaggio, tramite l’inseri- mento di una query. Ricevuto il messaggio, il search engine lo elabora, inviando a sua volta un ulteriore messaggio all’indice, interrogandolo. Quest’ultimo invierà i risultati al componente che si occupa di elaborarli per poi restituirli in un formato adatto alla visua- lizzazione. I risultati ottenuti possono essere maggiori di zero o uguali a zero: nel primo caso il componente restituirà una lista di risultati, mentre nel secondo una lista vuota. La lista sarà poi visualizzata dal componente di interazione dell’interfaccia utente. Diagramma delle attività (Activity diagram)
Il diagramma delle attività è un diagramma di comportamento che viene utilizzato per descrivere la logica o il flusso che sta alla base di uno scenario d’uso. Uno dei concetti principali è quello di activity (attività), che indica uno specifico compito che deve essere svolto e viene rappresentato tramite un rettangolo smussato all’interno del quale viene descritta l’attività. Le attività sono collegate tra di loro tramite delle frecce orientate, che indicano la sequenza temporale con la quale devono essere svolte. L’inizio del flusso viene indicato con un cerchio nero, mentre la fine, che può essere più di una,23 viene
indicata con un cerchio nero circondato da una linea. Un nodo molto utilizzato è quello rappresentato da un rombo con due frecce uscenti e descrive una o più condizioni, che possono verificarsi o meno. Importante nominare anche il separatore di attività (activity partion), che raggruppa le azioni che hanno qualcosa in comune, per esempio quelle che fanno parte di un’unica attività oppure quelle eseguite da particolari componenti. Il separatore viene visualizzato come una “corsia” orizzontale o verticale delimitata da due linee.24
Figura 6.7: EVT 2 Search: il diagramma delle attività del motore di ricerca.
La figura 6.7 rappresenta il diagramma delle attività del motore di ricerca, che è com- posto da quattro attività principali, ognuna della quali ne racchiude altre più specifiche. Partendo dall’attività create parser il sistema fa un controllo sui tag XML per capire la tipologia di documento e successivamente creare il parser adatto. Nel nostro caso vie- ne controllato se il documento contiene o meno il tag <lb/> da un lato, e i tag <l> o
<p>dall’altro. Si procede poi all’analisi dell’XML recuperando alcuni nodi utili, dai qua- li verranno estratte le informazioni contestuali con l’obiettivo di ottenere una struttura contenente gli elementi analizzati. L’attività successiva sarà la creazione dell’indice a partire dai dati ottenuti, per poi procedere con l’attività di query, nella quale l’utente 24Pressman 2010.
che effettua una ricerca apre il box dedicato, inserisce una keyword e preme il bottone di avvio. A questo punto si possono verificare due condizioni: la prima prevede che non ci siano risultati, e in questo caso verrà restituito un messaggio che comunica all’utente l’assenza dei risultati; la seconda prevede la restituzione e la visualizzazione dei risultati all’utente insieme alle informazioni contestuali estratte in precedenza. In entrambi i casi il flusso termina.