Il pacchetto View

Il pacchetto view è costituito dalla classe EventLogManagerView, classe prin- cipale del pacchetto che rappresenta la componente della vista nel pattern MVC, e da una serie di classi che deniscono i vari componenti della vista ed il loro comportamento.

Per quanto riguarda la classe EventLogManagerView, questa fornisce tutti i metodi per permettere al Controller di "ascoltare" le azioni dell'utente (ovvero, in termini tecnici, di installare dei listener sulle componenti della vista per poter monitorare gli eventi che accadono su di essi a partire dalle

azioni dell'utente) e per informare la vista stessa delle elaborazioni eettuate e come di conseguenza questa debba modicarsi.

E' di fatto la classe che implementa la componente della View e che permette a questo pacchetto di interagire con gli altri.

Le altre classi di questo pacchetto implementano invece una serie di com- ponenti graci della vista. Si tratta di oggetti speciali utilizzati nell'inter- faccia graca con determinate speciche a seconda del loro compito, e di un insieme di componenti manager e layout per la visualizzazione dei compo- nenti graci. Queste classi vengono utilizzate dalla classe principale per la visualizzazione di una interfaccia graca specica per l'applicazione.

Nella Figura 3.5 viene mostrato il diagramma UML di questo pacchetto. Al centro vi è la classe principale che permette la comunicazione con gli altri pacchetti: EventLogManagerView.

Intorno ad essa le altre classi che forniscono a quest'ultima componenti grache speciche e componenti speciali per la gestione di questi elementi.

Andiamo adesso a descrivere brevemente le classi che sono in dipendenza con la classe principale. In questo capitolo ci limiteremo a dare una denizio- ne più astratta del loro utilizzo e comportamento, rimandando ai successivi una descrizione più dettagliata.

Le classi sono le seguenti:

1. EventLogEditor: questa classe denisce la struttura di una particolare nestra interna del sistema (tecnicamente, un frame interno al frame principale dell'applicazione, detto anche internal frame) che viene uti- lizzata per la visualizzazione dei log di eventi e per la scrittura e mo- dica del loro codice in linguaggio XES. É di fatto un editor testuale e viene utilizzato dall'applicazione anche per la modica di qualsiasi documento di testo che venga aperto in essa. Ha numerose proprietà che vedremo nei successivi capitoli di questo documento.

2. FootprintFilter: ogni EventLogEditor contenente un log ha associa- to uno specico ltro per quel log che verrà utilizzato durante la fase di analisi per ottenere risultati più accurati. Un oggetto di questa classe è associato a ciascun EventLogEditor per registrare i ltri attualmente impostati dall'utente per quello specico log di eventi.

3. FilterPanel: questa classe denisce un pannello mobile dell'applica- zione contenente i ltri del log selezionato, in modo da mostrarli all'u- tente e permettergli di modicarli e cambiare così l'esito dell'analisi. Ha una associazione sia con l'EventLogEditor alla quale appartiene, sia con i ltri deniti per il log che questo editor contiene (ltri deniti attraverso la classe FootprintFilter) per potervi accedere diretta-

mente per le operazioni di lettura e modica. Anche se non mostrato nel diagramma, esiste una associazione anche dalla classe EventLogE- ditor e questa classe, creando di fatto una associazione bidirezionale. Sia l'editor che il pannello dei ltri infatti hanno un riferimento all'al- tra componente, questo perché una azione su una delle due da parte dell'utente deve risultare in una modica all'altra componente, quindi queste due devono necessariamente essere associate tra loro. Il motivo per il quale questa associazione non è visualizzata nel diagramma è che, mentre la classe FilterPanel ha un riferimento ad un oggetto Even- tLogEditor (chiamato eventLogEditor nel diagramma in Fig. 3.5), la classe EventLogEditor ha un riferimento ad un generico oggetto graco (tecnicamente, ad un oggetto di tipo Dialog il cui riferimento è chiamato filterDialog nel diagramma in Fig.3.5) per potersi asso- ciare a qualsiasi tipo di pannello e non solo ad un FilterPanel. Ne consegue che l'associazione c'è, ma non è diretta e quindi non viene visualizzata nel diagramma.

4. FootprintMatrixInfo: questa classe denisce la struttura di una par- ticolare nestra interna del sistema (come fa EventLogEditor) uti- lizzata per la visualizzazione di codice XHTML. Il codice XHTML è utilizzato dal sistema per la visualizzazione graca dei risultati dell'a- nalisi sui log, ovvero una matrice delle dipendenze causali ed una serie di informazioni che vedremo in dettaglio nei capitoli successivi.

5. CustomDesktopManager: per la gestione all'interno della nestra prin- cipale del sistema delle nestre interne sopra citate, viene utilizzato

questo manager, che si preoccupa di disporre ogni nuova nestra che viene aperta ed inserita all'interno della principale in uno spazio li- bero (se disponibile), evitando la sovrapposizione totale delle nestre tramite uno stile di disposizione detto "a cascata".

6. MenuAreaButton: questa classe denisce la struttura e la graca dei pulsanti visualizzati nel menù principale dell'applicazione. Questi pul- santi sono statici, ovvero vengono deniti dall'applicazione al suo avvio e mostrati all'utente nel menù.

7. MenuAreaTabLayout: la disposizione dei pulsanti all'interno del menù principale è denita da questo layout. In particolare, nel momento in cui non c'è abbastanza spazio nella nestra per mostrare tutti i pulsanti disponibili, questo layout li riorganizza inserendone quanti più possibile nel menù in alto e utilizzando in fondo a destra un pulsante "More" per unire in un sotto-menù tutti quelli che non hanno spazio a disposi- zione. Nel diagramma questo layout ha una associazione con la classe MenuAreaButton, in quanto, sebbene questo layout gestisca dinamica- mente un qualsiasi numero di pulsanti, ne utilizza uno in particolare in maniera ssa (il pulsante "More" appunto, indicato dal riferimento more) in caso di necessità.

8. FooterAreaButton: questo classe denisce la struttura e la graca dei pulsanti visualizzati nel menù in fondo alla nestra principale. Questi pulsanti, a dierenza dei MenuAreaButton, sono dinamici, ovvero ne viene inserito uno per ogni nestra che viene aperta all'interno dell'ap- plicazione, riportante in esso il nome della nestra ad esso collegata,

per permetterne la gestione (operazioni classiche come la minimizza- zione o massimizzazione della nestra, la selezione e la chiusura della stessa). Questi pulsanti vengono poi dinamicamente rimossi quando la nestra alla quale sono associati viene chiusa.

9. OneRowFlowLayout: i pulsanti inseriti nella parte in fondo alla nestra principale, i FooterAreaButton, possono essere in numero variabile. Se ne viene inserito un numero maggiore rispetto allo spazio dispo- nibile per visualizzarli tutti, questo layout si preoccupa di ricalcolare la dimensione di tutti quelli presenti e diminuirla (o aumentarla, se in seguito ad un precedente ridimensionamento, nel caso qualcuno di essi venga chiuso e si renda disponibile più spazio per la visualizza- zione) proporzionalmente in modo da visualizzarli tutti nello spazio disponibile.