EventLogEditor e il supporto all'analisi: i ltri

La classe EventLogEditor, oltre alle informazioni indicate nella Sezione 4.2.1, può registrarne altre collegate all'analisi del suo contenuto.

Oltre ad informazioni di utilità quali la memorizzazione dell'oggetto XLog, rappresentazione Java del log contenuto nell'editor e generato durante l'a- nalisi, e del codice XHTML del report di analisi relativo allo stesso log, entrambi utilizzati per facilitare l'esecuzione delle operazioni di calcolo e visualizzazione, vi sono i ltri.

I ltri sono una serie di impostazioni che l'utente può scegliere e che sono associate ad un dato editor e al suo contenuto.

I ltri permettono di denire determinate prospettive di analisi del log e vengono utilizzati in fase di generazione del report di analisi.

Ogni EventLogEditor ha associato un ltro, denito dalla classe Foot- printFilter. Questa classe denisce una serie di campi relativi a valori da

memorizzare e per ciascuno di essi un insieme di metodi per recuperare (get) ed impostare (set) questi valori.

I valori che vengono registrati e gestiti dalla classe FootprintFilter e che possono essere utilizzati in fase di analisi sono i seguenti:

1. Il numero di occorrenze minime per traccia: questo valore indica quale deve essere il numero minimo di occorrenze di una stessa traccia (costi- tuita quindi da una ben precisa sequenza di eventi) perché questa sia presa in considerazione durante l'analisi del log, o scartata altrimenti. 2. L'insieme dei classicatori: come abbiamo visto nella Sezione 2.1.2.5,

lo standard XES permette la denizione di classicatori di eventi, co- strutti che raggruppano gli eventi in insiemi in base al valore dei loro attributi; questo valore memorizza l'insieme dei classicatori disponibili per il log analizzato.

3. Il classicatore selezionato: La scelta di un determinato classicato- re tra quelli disponibili permette di decidere secondo quali attribu- ti due eventi debbano essere considerati uguali, e quindi cambiare di conseguenza la prospettiva di analisi.

4. Gli eventi iniziali selezionati: si possono denire quali tracce utilizzare per l'analisi e quali scartare, in base ai loro eventi iniziali; in pratica se una traccia inizia con un evento che è stato selezionato, l'analisi prenderà in considerazione quella traccia, altrimenti la scarterà. 5. Gli eventi nali selezionati: come per sopra, si possono denire quali

se una traccia termina con un evento che è stato selezionato, l'analisi prenderà in considerazione quella traccia, altrimenti la scarterà. Questi possono essere modicati dall'utente utilizzando il pulsante "Fil- ters" dell'interfaccia del menù Discovery.

Nel caso non sia ancora stata eettuata una analisi del log prima del- l'apertura del pannello dei ltri, questi ultimi avranno un valore nullo, in quanto non è possibile determinarli a priori senza eettuare una prima ana- lisi del log contenuto nell'editor: considerando che ogni log è diverso, senza analizzarlo è impossibile sapere ad esempio quali siano gli stati iniziali e nali delle tracce o quali siano i classicatori impostati.

In questo caso il sistema chiederà prima se si desidera calcolare i loro valori iniziali per avere un pannello dei ltri completo, oppure se si vuole procedere utilizzando solo il ltro sul numero minimo di occorrenze delle tracce.

Nel primo caso, quello che otterremo sarà una prima analisi del log per il calcolo dei suoi valori iniziali e la successiva apertura di un pannel- lo come quello mostrato in Figura 5.8, implementato utilizzando la classe FilterPanel.

Nel secondo caso invece, otterremo un pannello simile ma semplicato, con semplicemente il primo campo (quello sulle occorrenze).

Vedremo meglio nella Sezione 5.2.3 come viene calcolato il valore dei ltri in base al contenuto del log.

I ltri mostrati nel pannello possono ora essere modicati dall'utente, al quale poi si richiede di scegliere tra tre possibili azioni:

Figura 5.8: Il pannello dei ltri

1. Salvare i ltri impostati nell'oggetto FootprintFilter dell'editor e av- viare l'algoritmo di analisi del log, che utilizzerà i nuovi ltri impostati. 2. Salvare i ltri impostati nell'oggetto FootprintFilter dell'editor ma non avviare l'algoritmo di analisi del log, procedendo solo con l'aggior- namento del ltro associato all'editor selezionato.

3. Avviare l'algoritmo di analisi utilizzando i ltri impostati, ma senza sal- varli nell'oggetto FootprintFilter dell'editor, in modo da mantenere i ltri salvati ma al contempo eettuare analisi con ltri temporanei diversi da quelli dell'editor.

É importante notare come questo pannello dei ltri sia direttamente col- legato con l'editor a cui è associato: se un editor ha un pannello dei ltri aperto, qualsiasi operazione di selezione, minimizzazione, massimizzazione e

chiusura che avvengono sulla nestra dell'editor, hanno un eetto identico anche sul suo pannello dei ltri.

Sottolineiamo inne una importante proprietà della classe EventLogEdi- tor, per quanto concerne l'analisi dei log.

Abbiamo notato precedentemente come un editor possa memorizzare l'og- getto XLog e il report generato dall'analisi, nonché tenere traccia dei ltri impostati da un utente e deniti sul contenuto del log.

Nel caso avvenga una modica del contenuto dell'editor, non accade sola- mente quanto riportato nella Sezione 4.2.1 in merito allo stato di modicato e validato, ma vengono anche cancellati i riferimenti all'oggetto XLog e al relativo report generato e azzerati i valori dei ltri calcolati, in quanto sono tutti valori collegati al vecchio contenuto dell'editor e non più validi adesso (dovranno essere rigenerati dal sistema alla prossima analisi).

Dopo aver descritto questa importante funzionalità della classe EventLo- gEditor, possiamo ora passare a vedere come si sviluppa il processo di analisi di un log.