Progettazione e sviluppo di un sistema per la gestione di log di eventi

(1)

Corso di Laurea Magistrale in Informatica per l'economia e per l'azienda (Business Informatics)

TESI DI LAUREA

PROGETTAZIONE E SVILUPPO DI UN SISTEMA PER LA GESTIONE DI LOG DI EVENTI

RELATORE

Prof. Roberto BRUNI

Candidato Francesco SANTERAMO

(2)

I processi di business ricoprono nel mondo di oggi una parte fondamentale, guidando i servizi e le funzioni delle aziende e delle organizzazioni di tutto il mondo. Mentre la maggior parte degli attuali sistemi informativi aziendali dispone già di funzioni per l'esecuzione di tali processi e la loro registrazione tramite log di eventi, ancora molto deve essere fatto per quanto riguarda il monitoraggio e l'analisi di queste esecuzioni. In questo ambito si inserisce la disciplina del Process Mining, capace per mezzo di innovative tecniche di analisi e monitoraggio dei processi di entrare con successo in questa area di ricerca. Il lavoro svolto si inserisce nel contesto di questa disciplina e nasce dalla necessità di avere un sistema che permetta di creare facilmente, ma-nipolare ed esaminare log di eventi, anche a ni didattici, utilizzando come tecnologia XES, dal 2010 lo standard XML uciale per la memorizzazione di log di eventi per quanto riguarda il Process Mining. L'obiettivo di questa tesi è quindi la progettazione e lo sviluppo di una applicazione basata sullo standard XES per la creazione, modica ed analisi di log di eventi memo-rizzati utilizzando questo formato. Molte delle funzionalità che sono state pensate per questo nuovo sistema non sono presenti negli altri programmi disponibili per la gestione ed analisi dei log. L'obiettivo del progetto è stato quello di fornire nuove funzionalità a questa area di ricerca, complementan-do ed integrancomplementan-dosi allo stesso tempo con le altre applicazioni già presenti in questo settore.

(3)

1 INTRODUZIONE 7

1.1 Ambito del lavoro di tesi . . . 7

1.2 Obiettivo della tesi . . . 12

1.3 Contenuto della tesi . . . 13

2 TECNOLOGIE UTILIZZATE 15 2.1 Standard XES . . . 16 2.1.1 La terminologia utilizzata . . . 18 2.1.2 Il meta-modello di XES . . . 19 2.1.3 Serializzazione XML di XES . . . 36 2.1.4 Estensioni standard . . . 38 2.2 Sviluppo dell'applicazione . . . 49 2.2.1 Il linguaggio di programmazione . . . 50 2.2.2 L'ambiente di sviluppo . . . 52

(4)

2.2.3 Il pattern Modied Model-View-Controller . . . 53

2.2.4 Le librerie esterne . . . 53

3 PROGETTAZIONE DELL'APPLICAZIONE 65 3.1 Pattern architetturale . . . 65

3.1.1 Il pattern Model-View-Controller tradizionale . . . 66

3.1.2 Il Modied Model-View-Controller . . . 68

3.2 Struttura dei pacchetti Java . . . 71

3.3 Diagrammi UML delle classi . . . 73

3.3.1 Il pacchetto Starter . . . 74

3.3.2 Il pacchetto Model . . . 74

3.3.3 Il pacchetto View . . . 75

3.3.4 Il pacchetto Controller . . . 80

3.3.5 Vista sulle interazioni tra le classi principali del sistema 90 3.3.6 Le directory del progetto . . . 92

4 SVILUPPO: LA GESTIONE DEI DOCUMENTI 95 4.1 L'interfaccia dell'applicazione . . . 96

4.2 Gestione dei documenti . . . 102

4.2.1 La classe EventLogEditor . . . 103

4.2.2 Apertura dei documenti: Open e Recent . . . 108

4.2.3 Salvataggio dei documenti: Save e Save As . . . 114

4.2.4 Chiusura di una nestra: Close . . . 121

4.2.5 Stampa di un documento: Print . . . 128

4.2.6 Funzioni di utilità per l'editing dei contenuti . . . 130

(5)

5 SVILUPPO: GENERAZIONE, ANALISI DEI LOG 134

5.1 Generazione dei log di eventi . . . 134

5.1.1 Le funzioni Template e Completion dell'editor . . . 136

5.1.2 Denizione di una sintassi per la generazione dei log . . 142

5.1.3 Generazione di log a partire da espressioni . . . 150

5.2 Analisi dei log di eventi . . . 167

5.2.1 EventLogEditor e il supporto all'analisi: i ltri . . . 167

5.2.2 Validazione di un log XES . . . 171

5.2.3 Analisi di un log XES . . . 174

5.3 Import, export e stampa dei documenti . . . 186

5.3.1 La funzione di import . . . 187

5.3.2 La funzione di export . . . 191

5.4 Errori riscontrati sullo XES XSD 2.0 e sulla libreria OpenXES 2.0 . . . 200

5.4.1 Errore sullo XES Schema 2.0 . . . 200

5.4.2 Errori sulla liberia OpenXES 2.0 . . . 202

6 SVILUPPO: GESTIONE DELL'APPLICAZIONE 205 6.1 Interazione con l'interfaccia utente . . . 205

6.1.1 La modica delle dimensioni della nestra principale . 206 6.1.2 La chiusura della nestra principale . . . 212

6.2 Disposizione di una nuova nestra all'interno dell'applicazione 215 6.3 Gestione di molteplici nestre: i FooterAreaButton . . . 219

6.4 Gestione delle congurazioni . . . 222

(6)

7 CASI D'USO 226 7.1 La generazione di un log . . . 226 7.2 L'analisi di un log . . . 232

8 CONCLUSIONI 237

(7)

INTRODUZIONE

1.1 Ambito del lavoro di tesi

I processi ricoprono nel mondo di oggi una parte fondamentale, guidando i servizi e le funzioni delle aziende, degli enti governativi e delle organizzazioni di tutto il mondo.

Si denisce processo aziendale un insieme di attività collegate tra loro, svolte all'interno dell'azienda, che creano valore trasformando delle risorse, che costituiscono l'input del processo, in un prodotto, che costituisce l'output del processo, quest'ultimo destinato a sua volta ad un soggetto che può essere l'azienda stessa o un soggetto esterno, ad esempio un cliente.

Sia le risorse in input che il prodotto in output possono essere beni, servizi o informazioni, oppure anche una combinazione di questi elementi.

La trasformazione dell'input del processo in output può essere svolta sia utilizzando manodopera, sia impiegando delle macchine, oppure entrambi.

(8)

Mentre la maggior parte degli attuali sistemi informativi aziendali dispone già di funzioni per l'esecuzione di tali processi, ancora molto deve essere fatto per quanto riguarda il monitoraggio e l'analisi di queste esecuzioni.

In questo ambito si inserisce la disciplina del Process Mining, capace per mezzo di innovative tecniche di analisi e monitoraggio dei processi di entrare con successo in questa area ancora da esplorare.

Il Process Mining è un'area di ricerca relativamente giovane che si posi-ziona tra la Computational Intelligence e il Data Mining, da un lato, e tra la modellazione e l'analisi dei processi, dall'altro.

Il processo di analisi parte da un log di eventi, che altro non è che una registrazione sequenziale di attività, ciascuna che identica un passaggio ben preciso di un processo in esecuzione, raggruppate per istanze di esecuzione del processo, ovvero sequenze di attività che elencano i passaggi eettuati dall'inizio alla ne del processo durante una sua singola esecuzione.

L'insieme di queste istanze rappresenta le possibili esecuzioni del processo e costituisce il log di eventi oggetto di analisi del Process Mining.

L'obiettivo del Process Mining è quello di dedurre, monitorare e miglio-rare processi reali attraverso tecniche di discovery, estraendo un modello di processo a partire da un log di eventi senza utilizzare alcuna informazio-ne a priori, di conformance checking, monitorando eventuali dierenze tra il modello di processo generato mediante discovery e il log in analisi (che rappresenta le esecuzioni eettive del processo) per scoprire e capire even-tuali deviazioni e misurarle, e di enhancement, migliorando o estendendo il modello esistente per mezzo di ulteriori informazioni riguardanti il processo, estratte sempre dal log di eventi.

(9)

Figura 1.1: I tre tipi base di Process Mining in termini di input ed output: (a) discovery, (b) conformance checking, ed (c) enhancement [2]

In Figura 1.1 vengono mostrate le tre tecniche di Process Mining appe-na citate, in termini di input/output. Si può notare come le tecniche di discovery producano, a partire da un log di eventi, un modello che lo rap-presenti. Gli standard utilizzati per la denizione del modello possono essere molteplici, ad esempio una rete di Petri, un modello BPMN1_{, un modello}

EPC2 _{o un diagramma UML delle attività. Questo modello, insieme al log}

di eventi, può essere testato attraverso tecniche di conformance checking, ottenendo informazioni diagnostiche che mostrano eventuali diormità tra i due input, oppure, grazie alle tecniche di enhancement, si può generare una versione migliorata ed estesa del modello stesso utilizzando il log di eventi come rappresentazione della realtà al quale il modello deve essere rapportato. Il motivo per il quale questa disciplina suscita sempre più interesse

nel-1_{Business Process Model and Notation.} 2_{Event-driven Process Chain.}

(10)

l'ambito dell'analisi dei dati è dovuto da un lato alla grande quantità di dati disponibili che contengono informazioni dettagliate sulle passate esecuzioni dei processi, dall'altro alla necessità di migliorare e supportare i processi aziendali in ambienti competitivi e in rapida evoluzione.

I modelli di processi che vengono generati sono inoltre più ecaci dei semplici log per la comprensione delle dinamiche del processo. I modelli infatti sono più facili da interpretare rispetto ai singoli log, in quanto ne forniscono una rappresentazione sulla quale si possono utilizzare tecniche di analisi e simulazione, ottenendo risultati più indicativi sul processo in analisi. Grazie alla veloce crescita tecnologica della società moderna e alla sem-pre più ricorrente digitalizzazione dei dati (sia per quanto concerne la loro registrazione, sia per quanto riguarda il loro scambio elettronico), le azien-de hanno aazien-desso la possibilità di registrare e successivamente analizzare gli eventi che caratterizzano il loro business. Questo diventa di fondamentale importanza nel momento in cui i dati dei log possono essere sfruttati per creare conoscenza, elemento determinante per qualsiasi azienda moderna per avere un business di successo ed essere leader del proprio settore.

I log di eventi possono avere forme e strutture dierenti, in quanto ogni sistema informativo che abbia al suo interno un sistema di registrazione di log, ha da sempre sviluppato il suo standard interno per questo compito, di fatto rendendo i suoi log non analizzabili da sistemi esterni, ma solo da eventuali programmi sviluppati appositamente per quel sistema informativo o per quella struttura di log.

Questa disomogeneità complica lo sviluppo di strumenti di analisi univer-sali, in grado di gestire qualsiasi log di eventi.

(11)

Per risolvere questo problema è stato creato un formato per la registrazio-ne di log di eventi, standardizzato dalla IEEE3_{Task Force on Process Mining}4

nel 2010 ed adottato come formato di default per codicare e scambiare log di eventi, chiamato XES5_.

XES è uno standard6 _{XML per la memorizzazione di log di eventi: il suo}

scopo è quello di denire un formato generalmente riconosciuto per permet-tere lo scambio di dati (riguardanti log di eventi) tra i sistemi informativi che li registrano e gli strumenti che li gestiscono e analizzano, soprattutto nel caso di sistemi eterogenei sviluppati da società diverse. Rimandiamo un maggiore approfondimento di questo standard alla Sezione 2.1, quando par-leremo delle tecnologie utilizzate per lo sviluppo dell'applicazione oggetto di questo documento.

Il lavoro svolto si inserisce nel contesto di questo standard e nella neces-sità di avere un sistema che permetta di creare facilmente, manipolare ed esaminare log di eventi a ni didattici per i quali lo standard XES non è adatto, in quanto dicilmente interpretabile da un essere umano.

I contenuti di questa sezione riprendono i concetti espressi in [1, 2].

3_{Institute of Electrical and Electronic Engineers.}

4_{Gruppo creato dalla IEEE per promuovere la ricerca, lo sviluppo, l'educazione e la}

conoscenza del Process Mining. Nel contesto di questa Task Force, un gruppo di più di 75 persone che coinvolgono più di 50 organizzazioni diverse ha creato il Manifesto sul Process Mining: un insieme di principi fondamentali ed importanti sde che devono servire da guida per tutti i professionisti del settore, nell'intento di migliorare la conoscenza del Process Mining come nuovo metodo per la (ri)modellazione, il monitoraggio ed il supporto dei processi di business.

5_{eXtensible Event Stream.} 6_{www.xes-standard.org.}

(12)

1.2 Obiettivo della tesi

L'obiettivo di questa tesi è la progettazione e lo sviluppo di una applicazione per la creazione, modica ed analisi di log di eventi.

Il sistema sviluppato è basato sullo standard XES e permette la gestione di log di eventi memorizzati utilizzando questo formato.

L'applicazione dà la possibilità di aprire, modicare e validare log di eventi reali utilizzando un editor versatile e di generarne di nuovi, denendo, attraverso un linguaggio di espressioni, possibili sequenze di eventi che iden-ticano l'esecuzione di un processo. La generazione di nuovi log può essere fatta anche attraverso una specica sintassi che è stata introdotta all'interno del sistema.

Questa applicazione permette inoltre di analizzare ogni log aperto e di generare una footprint matrix dello stesso, ovvero una matrice che mostra le dipendenze causali tra gli eventi che compongono il log e che può esse-re sfruttata da tecniche di discovery per cesse-reaesse-re modelli di processi [1, 3]. L'analisi può essere ulteriormente anata attraverso l'utilizzo di vari ltri messi a disposizione, in modo da ottenere più "conoscenza" possibile dal log analizzato, scartando ad esempio tracce infrequenti o incomplete.

Sono disponibili inoltre vari formati per il salvataggio dei log su le ester-ni, nonché il loro export in formato CSV e l'export delle footprint matrix generate in formato HTML, PDF, PNG e LaTeX7_{. Insieme alla funzione di}

export, ne viene fornita una di import per la generazione di log di eventi a

7_{Linguaggio di markup utilizzato per la preparazione di testi basato sul programma di}

(13)

partire da documenti esterni in formato CSV e per il caricamento nel sistema di footprint matrix precedentemente esportate.

Molte delle funzionalità elencate sono state pensate ed implementate al-l'interno di questo sistema perché attualmente non sono disponibili negli altri programmi presenti online per la gestione ed analisi dei log, ad esempio nel framework ProM (un noto sistema di Process Mining), nell'intento di for-nire nuove funzionalità a questa area di ricerca e di integrarsi con le altre applicazioni già presenti in questo ambito.

L'applicazione è stata sviluppata in Java e verrà rilasciata con licenza Open Source con il nome di Event Log Manager.

1.3 Contenuto della tesi

Di seguito viene descritta la struttura della relazione di tesi e l'organizzazione dei contenuti.

Nel Capitolo 2 vengono brevemente introdotte e discusse le tecnologie utilizzate che costituiscono le fondamenta per lo sviluppo di questa applica-zione.

Nel Capitolo 3 mostreremo la struttura dell'applicazione e come questa sia stata progettata, quali pattern sono stati utilizzati e come le varie componenti che caratterizzano il sistema interagiscano tra loro.

Nel Capitolo 4 approfondiremo la descrizione dell'applicazione, presen-tando tutte le funzioni sviluppate e disponibili per la gestione dei documenti, con una analisi sulla loro interconnessione e robustezza.

(14)

Nel Capitolo 5 approfondiremo le funzioni dell'applicazione destinate al-la generazione assistita di log, che includono un linguaggio di espressioni per denire insiemi di tracce e una sintassi compatta in formato CSV per la manipolazione di log, all'analisi dei processi e non ultimo alla gestione e trasformazione dei documenti in altri formati disponibili. In questo capito-lo parleremo anche delle problematiche rilevate sulcapito-lo standard XES e delle soluzioni adottate.

Nel Capitolo 6 mostreremo le funzioni per la gestione dell'interfaccia gra-ca dell'applicazione e quelle rese disponibili all'utente per una interazione diretta con quest'ultima.

Nel Capitolo 7 mostreremo alcuni casi d'uso riguardanti le operazioni tipiche che un utente può svolgere con questo sistema di gestione ed analisi. Inne, nel Capitolo 8 ricapitoleremo brevemente i risultati conseguiti e descriveremo i possibili sviluppi futuri.

(15)

TECNOLOGIE UTILIZZATE

Il progetto di tesi si basa su di una serie di tecnologie che sono state fonda-mentali per lo sviluppo dell'intera applicazione.

In questo capitolo presenteremo per prima cosa lo standard XES, uno standard XML per la memorizzazione di log di eventi, che rappresenta uno degli elementi portanti dell'applicazione, in quanto è lo standard che de-nisce la struttura dei log che questa applicazione può creare, modicare ed analizzare ed è lo stesso standard utilizzato anche da altre applicazioni, note nel campo del Process Mining, come ad esempio ProM.

Per la stesura di questa sezione riguardante lo standard XES abbiamo fatto riferimento a [7].

Successivamente deniremo le tecnologie utilizzate per creare il nostro Event Log Manager: il linguaggio di programmazione Java, l'ambiente di sviluppo Eclipse ed inne le librerie Open Source che sono state incluse nel progetto per l'implementazione di alcune delle sue funzionalità, motivandone

(16)

la scelta.

2.1 Standard XES

I log di eventi possono avere strutture molto diverse tra loro, in base al sistema informativo che li registra e all'uso che ne viene fatto. Spesso ven-gono utilizzati infatti formati proprietari o ad hoc per determinati sistemi informativi o di analisi.

L'obiettivo dello standard XES1_{è quello di denire una struttura comune}

per la denizione e memorizzazione di log di eventi, in modo che ci possa essere una interazione tra i sistemi informativi che li registrano e i sistemi che li processano e analizzano, attraverso l'utilizzo comune di questo standard.

XES è uno standard XML ed è stato standardizzato dalla IEEE2 _Task

Force on Process Mining nel 2010 e adottato come formato di default per codicare e scambiare log di eventi.

Si basa su quattro principi fondamentali, utilizzati durante la sua crea-zione come linee guida:

1. Semplicità (Simplicity): utilizzare la soluzione più semplice possibile per rappresentare le informazioni. Un log XES dovrebbe essere faci-le da decodicare (parse) e generare, e allo stesso tempo facilmente leggibile da un essere umano (human-readable). Nella progettazione di questo standard, è stato ricercato il metodo migliore per rendere

1_{eXtensible Event Stream.}

(17)

la struttura del log più signicativa possibile ed al contempo di facile implementazione.

2. Flessibilità (Flexibility): lo standard XES dovrebbe essere capace di catturare log di eventi a partire da qualsiasi tipo di dominio di appli-cazione, non importa quale sia il settore di appartenenza dei processi osservati o il sistema informativo che li registra. XES infatti si propo-ne di essere uno standard non solo per il Process Mining e i processi aziendali (business processes), ma anche più in generale per tutti i tipi di log di eventi, anche quelli che non riguardano i processi aziendali (event log data).

3. Estensibilità (Extensibility): in futuro dovrà essere facile estendere lo standard. L'estensione di quest'ultimo dovrà essere la più trasparente possibile, mantenendo allo stesso tempo la compatibilità con le ver-sioni precedenti e successive. Allo stesso modo dovrà essere possibile estendere lo standard per casi speciali, come ad esempio per particolari settori di applicazione dei log di eventi o speciche implementazioni di sistemi informativi che lavorano con i log XES.

4. Espressività (Expressivity): Nello sforzo di costruire un formato gene-rico valido per qualsiasi situazione, si dovrà sempre e comunque far sì che i log di eventi che verranno memorizzati in XES abbiano la minor perdita di informazioni possibile: ricercare quindi da un lato un forma-to generico valido per più situazioni possibili, dall'altro permettere ad ogni sistema informativo che memorizza log utilizzando XES di avere a disposizione tutti gli elementi possibili per registrare tutte le

(18)

infor-mazioni del log di eventi. In conseguenza di questo, tutti gli elementi XES per la registrazione delle informazioni devono essere fortemente tipizzati (strongly typed) e deve esistere un metodo generico per appen-dere ad essi una semantica facile da interpretare (human-interpretable semantics).

Per cercare di mantenere lo standard XES un formato generico di inter-scambio di informazioni, soltanto gli elementi che possono essere ritrovati in qualsiasi tipo di log sono esplicitamente deniti.

Per la registrazione di ulteriori informazioni proprie di specici sistemi, lo standard demanda infatti tale compito all'implementazione di opportune estensioni aggiuntive, tali da denire la semantica delle informazioni da re-gistrare, in modo da poter standardizzare gli elementi che le registreranno e permettere così di scambiare con altri sistemi anche questi ulteriori dati.

2.1.1 La terminologia utilizzata

Nelle successive sezioni faremo largo uso di alcuni termini e concetti che deniremo in questa sezione in modo da non doverne dare spiegazione in seguito.

Un processo è un insieme di casi, o istanze.

Un caso consiste in una serie di eventi, che a loro volta appartengono ad un unico specico caso.

Gli eventi all'interno di una caso sono ordinati e possono avere attributi. Tipici esempi di attributi possono essere il nome dell'evento, il tempo di esecuzione, il costo, la risorsa che l'ha generato e così via.

(19)

Assumiamo che sia possibile registrare sequenzialmente gli eventi tali che ogni evento si riferisca ad una specica attività, ovvero ad un preciso passaggio del processo, e che questa attività sia collegata ad un particolare caso.

Quello che otteniamo è un log di eventi, che da ora in poi chiameremo per semplicità log, ovvero un insieme di casi o istanze di processo, chiamati tracce, contenenti ciascuna a loro volta un insieme ordinato di attività, chiamate eventi, che sono state eseguite durante quell'istanza di processo.

2.1.2 Il meta-modello di XES

Verrà adesso analizzato nel dettaglio il meta-modello per lo standard XES, di cui viene mostrato in Figura 2.1 il diagramma UML 2.0 delle classi.

2.1.2.1 Struttura di base

La gerarchia di base di un documento XES segue la struttura universalmente utilizzata per la registrazione di informazioni su log di eventi.

Qui di seguito riportiamo il codice semplicato di un log che utilizzeremo come esempio durante questa parte del capitolo, andando a completarne il codice man mano che la descrizione degli elementi dello standard prosegue.

1 <?xml version="1.0" encoding="UTF-8" ?>

2 <log xes.version="2.0" xes.features="arbitrary-depth" xmlns="http://www.xes-standard. org/"> 3 <trace> 4 <event> 5 ... 6 </event> 7 <event>

(20)

8 ... 9 </event> 10 </trace> 11 </log>

Log

Al primo livello della gerarchia si trova il Log, un oggetto che conterrà tutte le informazioni sugli eventi che sono relativi ad uno specico processo.

Più nel dettaglio, il log rappresenta la registrazione delle attività di un processo che stiamo analizzando, del quale procederemo a registrare ogni esecuzione, memorizzando per ciascuna di esse le attività che sono state ese-guite, e a inserirla all'interno del log stesso, che quindi conterrà tutte le attività compiute durante le varie esecuzioni del processo, divise per istanza di esecuzione.

Il tag utilizzato per questo oggetto nella rappresentazione XML di XES è <log>.

Nella Tabella 2.1 sono mostrati i possibili attributi di questo tag.

Un esempio di intestazione di un documento XES in formato XML è il seguente:

1 <log xes.version="2.0" xes.features="nested-attributes">

Trace

Un log può contenere un numero arbitrario di tracce (rappresentate da un oggetto Trace), oppure anche essere vuoto.

(21)

Chiave Tipo R* Descrizione

xes.version xs:decimal Si La versione dello standard XES a cui il documento è conformato (ad es. "2.0"). xes.features xs:token Si Una lista di proprietà opzionali,

separa-te da uno spazio bianco, che il documento utilizzerà (ad es. "nested-attributes"). Se nessuna proprietà viene denita, questo attributo deve avere un valore vuoto.

* Richiesto

Tabella 2.1: Gli attributi del tag XML <log>

Ogni traccia rappresenta l'esecuzione di una specica istanza, o caso, del processo che stiamo registrando. Essa racchiude tutte le attività che sono sta-te eettuasta-te duransta-te una precisa esecuzione del processo e che costituiscono i passaggi di quella specica istanza.

Il tag utilizzato per questo oggetto nella rappresentazione XML di XES è <trace>. Non ci sono attributi XML per questo tipo di tag.

Event

Ogni traccia può contenere un numero arbitrario di eventi (rappresentati da un oggetto Event), oppure anche essere vuota.

Gli eventi rappresentano singole attività che sono state osservate durante l'esecuzione del processo e che vengono registrate nel momento della loro attuazione.

Gli eventi di per sé non hanno un valore che identica la durata dell'atti-vità, questo perché un evento rappresenta una attività di granularità atomica

(22)

di cui si può quindi registrare solo il momento della attuazione (quindi un timestamp di quando l'attività è stato registrato).

Tipicamente però molte attività hanno una durata signicativa e non possono essere rappresentate solo dal momento della loro attuazione, ma deve esserne registrato il tempo di durata.

In questo caso si utilizzano due eventi, uno di inizio (start) e uno di ne (end), entrambi con granularità atomica in modo da registrare l'inizio e la ne dell'attività rappresentata.

Analogamente, attività che hanno un ciclo di vita più complesso (con possibilità di essere sospese e riattivate o ripetute) avranno un evento per ciascuna fase signicativa.

Il tag utilizzato per questo oggetto nella rappresentazione XML di XES è <event>. Non ci sono attributi XML per questo tipo di tag.

2.1.2.2 Gli attributi

Gli oggetti deniti nora (Log, Trace ed Event) deniscono la struttura del documento ma non contengono direttamente informazioni.

Tutte le informazioni riguardanti il processo in esecuzione e le attività che lo compongono sono infatti memorizzate in oggetti Attribute, che descrivono di fatto gli elementi che li contengono (oggetti quali Log, Trace ed Event appunto).

Tutti gli attributi hanno una chiave (key) di valore testuale, denita come segue:

(23)

ini-Figura 2.1: Il diagramma UML 2.0 delle classi del meta-modello per lo standard XES [7]

(tabs), ritorno a capo (carriage returns) o righe vuote (line feeds). 2. Lo standard XES richiede che queste chiavi siano uniche all'interno

degli oggetti che le contengono (ad es. per ogni blocco <trace> un solo attributo con chiave "id" può esistere, ma ogni blocco traccia può

(24)

avere al suo interno un attributo con quella chiave). L'unica eccezione ammessa sono le chiavi contenute all'interno di liste (che vedremo in seguito): in questi costrutti gli attributi sono riportati in un ordine ben preciso e possono non essere unici in quanto la chiave viene ripetuta più volte all'interno della lista (ad es. una lista di oggetti Attribute con chiave "version" e valore il numero della versione, mantenuti in una lista sequenziale per registrare tutte le versioni create di un determinato software).

Log, tracce ed eventi possono contenere un qualsiasi numero di attributi. Lo standard denisce sei tipi di attributi elementari, ciascuno di essi ca-ratterizzato del tipo di dato che rappresenta: String, Date, Int, Float, Boolean e ID.

Insieme a questi, lo standard denisce due tipi di attributi che deniscono liste e collezioni di attributi: List e Container.

String

L'attributo String contiene informazioni letterali che hanno una connotazione e una lunghezza non denite.

Nella rappresentazione XML di XES, i valori di questo attributo sono memorizzati come tipo di dato xs:string.

Il seguente esempio mostra un possibile attributo String che denisce il nome di un elemento:

(25)

Date

L'attributo Date contiene informazioni riguardanti un momento preciso nel tempo (con una precisione di millisecondi). Registra in altre parole un valore temporale che indica non solo la data, ma anche l'ora con una precisione al millisecondo e il fuso orario.

Nella rappresentazione XML di XES, i valori di questo attributo sono memorizzati come tipo di dato xs:dateTime.

Il seguente esempio mostra un possibile attributo Date che denisce il timestamp di un attività:

1 <date key="timestamp" value="2015-04-25T19:45:32.345+02:00" />

Int

L'attributo Int registra un numero intero discreto con una precisione di tipo long a 64bit.

Nella rappresentazione XML di XES, i valori di questo attributo sono memorizzati come tipo di dato xs:long.

Il seguente esempio mostra un possibile attributo Int che registra il valore di un contatore:

1 <int key="counter" value="236366" />

Float

L'attributo Float registra un numero continuo a virgola mobile (oating-point) con una precisione di tipo double a 64bit.

(26)

Nella rappresentazione XML di XES, i valori di questo attributo sono memorizzati come tipo di dato xs:double.

Il seguente esempio mostra un possibile attributo Float che registra un valore percentuale:

1 <float key="percentage" value="75.68" />

Boolean

L'attributo Boolean contiene un valore booleano che può essere "true" oppure "false".

Nella rappresentazione XML di XES, i valori di questo attributo sono memorizzati come tipo di dato xs:boolean.

Il seguente esempio mostra un possibile attributo Boolean che memorizza il completamento o meno di una operazione:

1 <boolean key="completed" value="true" />

ID

L'attributo ID contiene un valore che rappresenta un identicatore, di solito un UUID3_.

Nella rappresentazione XML di XES, i valori di questo attributo sono memorizzati come tipo di dato xs:string.

Il seguente esempio mostra un possibile attributo ID che memorizza l'i-denticatore univoco associato ad un determinato cliente:

1 <id key="customer" value="f81d4fae-7dec-11d0-a765-00a0c91e6bf6" />

(27)

List

L'attributo List può contenere un qualsiasi numero di sotto-attributi (child attributes).

Questi sotto-attributi sono ordinati e le loro chiavi non sono univoche (si può ripetere la stessa chiave più volte all'interno dell'attributo List).

Il valore di questo attributo è dato dai valori degli attributi che a sua volta contiene.

Il seguente esempio mostra un possibile attributo List contenente una lista di revisioni eettuate ad un documento:

1 <list key="revisions">

2 <string key="name" value="XES standard" /> 3 <boolean key="stable" value="true" /> 4 <string key="revision" value="2.0" /> 5 <string key="revision" value="1.4" /> 6 <string key="revision" value="1.3" /> 7 <string key="revision" value="1.2" /> 8 <string key="revision" value="1.1" /> 9 <string key="revision" value="1.0" /> 10 </list>

Container

L'attributo Container può contenere un qualsiasi numero di sotto-attributi (child attributes).

La dierenza con l'attributo List è che in questo caso i sotto-attributi non sono ordinati e le chiavi sono univoche.

Il valore di questo attributo è dato dai valori degli attributi che a sua volta contiene.

(28)

Il seguente esempio mostra un possibile attributo Container contenente una serie di valori per la denizione di un indirizzo:

1 <container key="location">

2 <string key="street" value="Largo Bruno Pontecorvo" /> 3 <int key="number" value="3" />

4 <string key="zip" value="56127" /> 5 <string key="province" value="PI" /> 6 <string key="city" value="Pisa" /> 7 <string key="country" value="Italy" /> 8 </container>

2.1.2.3 Attributi annidati

Lo standard XES permette, per fornire la massima essibilità per quanto riguarda la memorizzazione dei dati, l'utilizzo di attributi annidati (nested attributes), ovvero ciascun attributo può a sua volta avere sotto-attributi.

Abbiamo visto come questa specica sia necessaria per poter avere co-strutti come gli attributi List e Container, ma la possibilità non è limitata solo a questi due.

Ad esempio, nel caso di un attributo String, la possibilità di inserire degli attributi annidati viene implementata nel modo seguente:

1 <string key="city" value="Piisa">

2 <boolean key="spell checked" value="false" /> 3 </string>

In questo caso abbiamo unito all'informazione registrata dall'attributo String (il nome di una città, quella di Pisa, ma scritto in maniera non cor-retta), un valore booleano che ci dice se il nome è stato o meno scritto correttamente.

(29)

In maniera del tutto simile si possono creare attributi annidati per i restanti cinque tipi di attributo di base.

Se un documento utilizza attributi annidati, questo va specicato nell'at-tributo xes.features del tag <log>, utilizzando il valore "nested-attributes", in modo da comunicare questa informazione al sistema che analizzerà il log.

La funzionalità degli attributi annidati è opzionale per i sistemi che ela-borano documenti in formato XES: non è cioè necessario che questi sistemi siano in grado di creare e gestire attributi annidati per essere conformi allo standard XES.

Se un sistema non supporta gli attributi annidati, basterà che sia in grado di leggere il documento (e quindi gli attributi annidati presenti in esso) e riconoscerne la corretta forma (quindi ritenendo eventualmente corretti anche gli attributi annidati); successivamente potrà in maniera trasparente ignorare e scartare questi attributi, eventualmente informando l'utente che alcune informazioni non possono essere elaborate.

2.1.2.4 Attributi globali

Ciascun log può contenere nella sua parte iniziale, prima dell'inizio delle tracce, due liste speciali di attributi, una per le tracce e una per gli eventi.

Queste liste contengono una serie di attributi che vengono deniti globali (global attributes): sono attributi che, elencati in questo modo, dovranno essere deniti per ciascun elemento presente nel documento del rispettivo livello (per le tracce o per gli eventi).

Questo signica che, denendo un attributo come globale all'inizio del documento, ad esempio per gli eventi, questo dovrà essere presente in ogni

(30)

oggetto Event di ogni traccia. Lo stesso discorso vale per le tracce, dove un attributo globale dovrà essere presente in ogni oggetto Trace del log.

Gli attributi globali sono deniti dal tag XML <global>, sotto-elemento del tag <log> del documento.

Un esempio di attributo globale per gli eventi è il seguente:

1 <global scope="event">

2 <string key="name" value="" /> 3 </global>

Questo blocco dichiara che ogni evento del log dovrà avere un attributo String con chiave il valore "name".

Nella denizione dell'attributo, il campo value indica il valore di default dell'attributo nel caso un evento venga creato senza questo abbia una deni-zione per questo valore. Può essere utilizzato nel caso in cui questo attributo debba sempre avere un valore signicativo, per un qualche tipo di analisi che vogliamo eettuare, in modo che in ogni caso questo valore esista sempre. Nel caso contrario, può essere lasciato vuoto.

Gli attributi globali sono una funzionalità necessaria per il rispetto dello standard XES e le applicazioni che gestiscono log in formato XES devono saper gestire la presenza di questi attributi durante la fase di validazione del documento nel rispetto dello standard.

Qui di seguito riportiamo il nostro esempio iniziale, ulteriormente com-pletato adesso con gli elementi visti nora.

2 <log xes.version="2.0" xes.features="arbitrary-depth" xmlns="http://www.xes-standard. org/">

(31)

5 <string key="concept:name" value="" /> 6 </global>

8 <string key="concept:name" value="" />

9 <date key="time:timestamp" value="1970-01-01T00:00:00.000+00:00" /> 10 <string key="system" value="" />

11 </global>

12 ...

13 <float key="log attribute" value="2335.23" /> 14 <trace>

15 <string key="concept:name" value="Trace number one" /> 16 <event>

17 <string key="concept:name" value="Register client" /> 18 <string key="system" value="alpha" />

19 <date key="time:timestamp" value="2009-11-25T14:12:45.000+02:00" /> 20 <int key="attempt" value="23">

21 <boolean key="tried hard" value="false" />

22 </int>

23 </event> 24 <event>

25 <string key="concept:name" value="Mail rejection" /> 26 <string key="system" value="beta" />

27 <date key="time:timestamp" value="2009-11-28T11:18:45.000+02:00" /> 28 </event>

29 </trace> 30 </log>

2.1.2.5 Classicatori di eventi

In XES non esistono attributi con un signicato ben denito a priori. Ciascun attributo visto nora funge da contenitore di determinate in-formazioni, ma non chiarisce in alcun modo il signicato di queste ultime, limitandosi a rappresentarle all'interno del log.

(32)

Per dare un signicato alle informazioni contenute all'interno degli attri-buti degli eventi e soprattutto per poter confrontare questi ultimi in base proprio ai loro attributi e poter controllare se questi abbiano gli stessi valori, vengono introdotti i classicatori di eventi (event classiers).

Lo standard XES introduce il concetto di classicatore di eventi per rende-re la classicazione di questi elementi congurabile e essibile: un classica-tore associa a ciascun evento una identità, denendo un insieme di attributi che costituisce appunto il modo con il quale denire questa identità e che permette poi agli eventi di essere confrontati tra loro.

Nella forma più semplice, un classicatore è denito da un solo attributo, e il valore di quell'attributo denisce l'identità della classe di un evento. Per ogni valore di questo attributo all'interno del log, viene denita una classe e gli eventi sono raggruppati in queste classi in base al valore dell'attributo considerato.

I classicatori sono deniti per l'intero log e possono essere in numero arbitrario per ciascun documento.

Ciascuno di essi è denito dal rispettivo tag XML <classifier>, sotto-elemento del tag <log> del documento.

Un esempio di classicatore di eventi è il seguente:

1 <classifiername="Activity classifier" keys="name status" />

In questo esempio viene denito un classicatore il cui identicatore è "Activity classier" sull'insieme di attributi "name" e "status". Qualsiasi coppia di eventi che avrà gli stessi valori per entrambi gli attributi, sarà considerata uguale da quel classicatore.

(33)

Come si può vedere dall'esempio, l'attributo keys del tag <classifier> utilizza gli spazi per separare i nomi degli attributi (ovvero i loro identi-catori deniti all'interno del loro attributo name), ma l'identicatore di un attributo può avere a sua volta spazi al suo interno (ad es. name="attribute one"). Per decidere quindi quali spazi separino le chiavi degli attributi elenca-ti e quali invece siano contenuelenca-ti in queste ulelenca-time, XES uelenca-tilizza un approccio misto. Per prima cosa, viene fornita la possibilità di raggruppare le chia-vi attraverso singoli apici (ad es. keys="'attribute one' name"). Se le chiavi così denite non corrispondono ad attributi globali per eventi, par-tendo dalla prima si procede unendo questa alla successiva (avremo quindi keys="attribute one name"), ricercando questa nuova combinazione come chiave di attributo. Se questa viene trovata, avremo che il classicatore sarà denito sopra questa nuova combinazione di chiavi, altrimenti, se né la prima né le successive combinazioni corrispondono ad attributi globali per eventi, il classicatore sarà denito sulle singole chiavi denite inizialmente, anche se queste non corrispondono appunto a nomi di attributi globali per eventi.

E' importante notare come l'insieme di attributi utilizzati per denire un classicatore dovrebbe essere un sottoinsieme degli attributi globali per gli eventi di quel determinato log. In altre parole un classicatore di eventi dovrebbe essere denito solamente sull'insieme degli attributi globali per gli eventi.

Questa specica, sebbene non obbligatoria, risulta fondamentale ai ni dell'analisi del log, in quanto assicura che ciascun evento possa essere clas-sicato secondo l'insieme di attributi utilizzati per denire il clasclas-sicatore, poiché questi attributi sono globali per gli eventi e quindi ciascun evento

(34)

do-vrà necessariamente denirli al suo interno per rispettare lo standard XES e far risultare di conseguenza il documento come validato.

I classicatori di eventi sono una funzionalità obbligatoria dello standard XES, in quanto permettono l'analisi del log secondo speciche classicazioni dei suoi eventi, altrimenti non paragonabili tra loro.

2.1.2.6 Le estensioni

Lo standard XES non denisce uno specico set di attributi per il log, le tracce e gli eventi.

In conseguenza di ciò, la semantica degli attributi che questi oggetti contengono risulta ambigua, ostacolando la corretta interpretazione dei dati. Questa ambiguità viene risolta da XES grazie al concetto di estensioni (extensions). Una estensione infatti denisce un insieme di attributi per ogni livello della gerarchia di XES che abbiamo visto nora (log, tracce, eventi e meta-informazioni per gli attributi annidati), in modo da fornire una struttura per interpretare questi attributi (e di conseguenza gli oggetti ai quali appartengono).

Le estensioni quindi sono per prima cosa uno strumento per associare una semantica ad un insieme di attributi di un elemento, in modo da regolarne le chiavi ed i possibili valori per una interpretazione più immediata.

Possono essere utilizzate per molteplici ragioni, una prima importante è quella di introdurre e denire un insieme di attributi comunemente ricono-sciuti che sono vitali per una specica prospettiva o dimensione dell'analisi dei log di eventi. XES a tale scopo fornisce una serie di estensioni standard che deniscono insiemi specici di attributi per vari tipi di analisi.

(35)

Grazie a queste estensioni infatti (e alle altre che possono essere denite separatamente da un sistema per casi specici di analisi) si vengono a creare delle semantiche ben precise per gli attributi, in modo che i vari sistemi di analisi dei log di eventi, che utilizzano XES come formato per i log, possano facilmente riconoscere questi attributi e saperne interpretare ed utilizzare al meglio il valore. Vedremo nelle sezioni successive le estensioni standard che XES fornisce.

Un' altro motivo per utilizzare le estensioni è quello di denire ulteriori attributi per uno specico settore di applicazione, attributi che di solito sono generalmente riconosciuti in questo determinato ambito ed importanti per l'analisi di specici dati contenuti nei log memorizzati.

Nella serializzazione XML di XES, le estensioni sono dichiarate attraverso il corrispettivo tag <extension>, sotto-elemento del tag <log>.

Un esempio di dichiarazione di una estensione all'interno di un log è la seguente:

1 <extension name="Concept" prefix="concept" uri="http://www.xes-standard.org/concept. xesext" />

Questa riga specica che il log utilizza attributi contenuti nell'estensione Concept.

Il campo uri della dichiarazione contiene un URI4 _{univoco che rimanda}

alla denizione dell'estensione in formato XESEXT.

Ogni estensione denisce un personale presso (prex) che identica gli attributi in essa contenuti:

1 <string key="concept:name" value="Initialization" /> 4_{Uniform Resource Identier}

(36)

In questo esempio possiamo vedere come la chiave dell'attributo sia com-posta dal presso concept e separata dai due punti dal nome dell'attributo denito dall'estensione.

In questo modo gli attributi fanno riferimento diretto alle loro rispettive estensioni che li deniscono e si elimina ogni possibile ambiguità riguardo a quale attributo di quale estensione ci si stia riferendo.

2.1.3 Serializzazione XML di XES

Dopo aver concluso l'esposizione dei vari componenti del meta-modello di un documento XES ed aver nominato per ciascuno di essi il rispettivo tag nella serializzazione XML di XES, viene adesso presentato un esempio di come appare tale documento nella sua forma completa.

Il Syntax Diagram in Figura 2.2 mostra la corretta composizione di un documento XES.

Il diagramma presentato illustra tutte le possibili combinazioni di elemen-ti che possono far parte di un documento XES.

Qui di seguito mostriamo dunque il nostro esempio, ora completo di tutti gli elementi dello standard e conforme alla sintassi in Figura 2.2.

3 <extension name="Concept" prefix="concept" uri="http://www.xes-standard.org/concept .xesext" />

4 <extension name="Time" prefix="time" uri="http://www.xes-standard.org/time.xesext" />

5 <global scope="trace">

(37)

Figura 2.2: Il diagramma di usso per lo standard XES [7]

(38)

11 <string key="system" value="" /> 12 </global>

13 <classifier name="Activity" keys="concept:name" /> 14 <classifier name="Another" keys="concept:name system" /> 15 <float key="log attribute" value="2335.23" />

16 <trace>

17 <string key="concept:name" value="Trace number one" /> 18 <event>

24 </int>

29 <date key="time:timestamp" value="2009-11-28T11:18:45.000+02:00" /> 30 </event>

31 </trace> 32 </log>

2.1.4 Estensioni standard

Il meta-modello di XES riconosce e tratta tutte le estensioni come uguali, indipendentemente se facenti parte di quelle standard oppure di quelle ester-ne. Questo permette di estendere il formato di XES e di adattare questo standard a qualsiasi tipo di scopo e dominio di applicazione.

Vi sono comunque alcuni requisiti ricorrenti per la memorizzazione delle informazioni nei log di eventi, che necessitano una semantica universale e ben denita per essere riconosciuti da tutti i sistemi.

(39)

Per questo motivo, un insieme di sette estensioni sono state standar-dizzate. Utilizzare queste estensioni standard nei log di eventi permette di formalizzare il documento seguendo una semantica ben precisa e riconosciu-ta, permettendo un livello di conoscenza maggiore dei contenuti del log da parte dei sistemi di analisi e quindi una analisi più accurata ed approfondita dello stesso.

Verranno ora presentate le estensioni standard del formato XES.

2.1.4.1 Concept Extension

L'estensione Concept denisce, per tutti i livelli della gerarchia di XES, un attributo che memorizza il nome di riferimento di quel dato elemento della gerarchia, quello cioè che lo identica.

• Presso: concept

• URI: http://www.xes-standard.org/concept.xesext

Nella Tabella 2.2 sono mostrati gli attributi deniti da questa estensione, suddivisi per i vari livelli della gerarichia di XES.

2.1.4.2 Lifecycle Extension

L'estensione Lifecycle specica, per gli eventi, la transizione che essi rappre-sentano in un modello transazionale del ciclo di vita composto delle attività. Il modello transazionale può essere di tipo generico, ciononostante questa estensione denisce anche un modello transazionale standard per le attività, mostrato nella Figura 2.3 attraverso un automa a stati.

(40)

Livello Chiave Tipo Descrizione

Log, Trace, Event name string Memorizza un nome identicativo per ciascun elemento della gerar-chia. Per i log, il nome dell'attribu-to può registrare il nome del proces-so che è stato eseguito. Per le trac-ce, questo attributo memorizza di solito l'identicatore (ID) del caso registrato. Per gli eventi, l'attribu-to rappresenta il nome dell'evenl'attribu-to, ovvero il nome dell'attività esegui-ta rappresenesegui-taesegui-ta da questo evento all'interno del log.

Event instance string Denito per gli eventi, questo attributo rappresenta un identi-catore dell'istanza dell'attività la cui esecuzione ha generato questo evento.

Tabella 2.2: Gli attributi deniti dall'estensione Concept

Questa estensione può essere utilizzata in qualsiasi situazione dove gli eventi rappresentano transizioni di un ciclo di vita di un insieme di attività.

• Presso: lifecycle

• URI: http://www.xes-standard.org/lifecycle.xesext

Nella Tabella 2.4 sono invece riportati i possibili valori dell'attributo transition, quando il modello transazionale del ciclo di vita selezionato è quello standard per questa estensione.

(41)

Figura 2.3: L'automa a stati per il modello transazionale standard dell'estensione Lifecycle [7]

2.1.4.3 Organizational Extension

L'estensione Organizational è utile per domini di applicazione dove gli even-ti sono generaeven-ti da risorse umane, che sono in qualche modo parte di una struttura organizzativa.

Questa estensione specica tre attributi per gli eventi, i quali identi-cano la risorsa che ha causato l'evento e la sua posizione nella struttura organizzativa di cui fa parte.

• Presso: org

(42)

Log model string Questo attributo si riferisce al modello tran-sazionale del ciclo di vita utilizzato per tut-ti gli eventut-ti del log. Se questo attributo ha come valore "standard", verrà utilizzato il modello transazionale standard del ciclo di vita denito da questa estensione.

Event transition string Denito per gli eventi, questo attributo spe-cica la transizione del ciclo di vita rap-presentata da ciascun evento. Se il mo-dello transazionale utilizzato è quello stan-dard denito da questa estensione, il valore di questo attributo corrisponderà ad uno di quelli riportati nella Tabella 2.4.

Tabella 2.3: Gli attributi deniti dall'estensione Lifecycle

2.1.4.4 Time Extension

In quasi tutte le applicazioni, l'esatta data ed orario nel quale un evento si verica può essere registrata con precisione.

Lo scopo dell'estensione Time è proprio questo, registrare questa infor-mazione, ovvero un timestamp di quando un certo evento è accaduto.

Memorizzare questo dato per gli eventi è molto importante, in quanto esso costituisce un'informazione di enorme valore per tante tecniche di analisi dei log di eventi.

(43)

Valore Descrizione

schedule L'attività è pronta per l'esecuzione.

assign L'attività è assegnata ad una risorsa per l'esecuzione. withdraw L'assegnazione è stata revocata.

reassign Nuova assegnazione a seguito di una revoca. start Inizio dell'esecuzione dell'attività.

suspend L'esecuzione è stata sospesa. resume L'esecuzione è stata ripresa.

pi_abort L'intera esecuzione del processo è cancellata per questo caso. ate_abort L'esecuzione dell'attività è stata cancellata.

complete L'esecuzione dell'attività è stata completata. autoskip Il sistema ha saltato l'esecuzione dell'attività.

manualskip L'esecuzione dell'attività è stata saltata di proposito (manualmente).

unknown Valore da utilizzare per tutti gli altri tipi di transizione non considerati dalle precedenti categorie.

Tabella 2.4: I possibili valori dell'attributo transition durante l'utilizzo del modello transazionale standard da parte dell'estensione Lifecycle

• URI: http://www.xes-standard.org/time.xesext

2.1.4.5 Semantic Extension

In base alla vista di analisi che decidiamo di avere su di un processo, gli elementi della gerarchia potrebbero corrispondere a concetti diversi.

(44)

Event resource string Il nome, o identicatore, della risorsa che ha innescato questo evento.

Event role string Il ruolo della risorsa che ha innescato questo evento, all'interno della struttura organizzativa di cui fa parte.

Event group string Il gruppo all'interno della struttura organizza-tiva di cui la risorsa che ha innescato l'evento è membro.

Tabella 2.5: Gli attributi deniti dall'estensione Organizational Livello Chiave Tipo Descrizione

Event timestamp date La data e l'orario nel quale l'evento si è vericato.

Tabella 2.6: Gli attributi deniti dall'estensione Time

Per fare un esempio, il nome di un evento, specicato dall'estensione Con-cept, potrebbe riferirsi all'attività la cui esecuzione ha generato tale evento. Questa attività potrebbe però trovarsi in un livello basso del meta-modello del processo ed essere quindi parte di un livello più alto di aggregazione.

Questo potrebbe avvenire non solo per gli eventi, ma anche per gli altri elementi della gerarchia di XES, che potrebbero fare riferimento a più concetti allo stesso tempo.

Per esprimere il fatto che un elemento della gerarchia possa avere più signicati nel meta-modello del processo analizzato, si utilizza l'estensione Semantic.

(45)

Questa estensione suppone che esista una onotologia5 _{per il meta-modello}

del processo, dove ogni concetto possa essere identicato da un URI univoco. In questo modo l'estensione Semantic può denire un attributo, modelRefe-rence, che permette la memorizzazione di un insieme di riferimenti ai vari modelli, sotto forma di URI, per ciascun elemento della gerarchia di XES.

• Presso: semantic

• URI: http://www.xes-standard.org/semantic.xesext

Log, Trace, Event,

me-ta modelReference string Riferimenti ai concet-ti del modello in una ontologia. I riferimen-ti sono memorizzariferimen-ti in una singola stringa di testo, registrando una sequenza di URI, se-parati da virgola, che identicano i concetti della ontologia.

Tabella 2.7: Gli attributi deniti dall'estensione Semantic

2.1.4.6 ID Extension

L'estensione ID fornisce identicatori univoci (nel formato UUID) per gli elementi della gerarchia di XES.

5_{In informatica, un'ontologia è una rappresentazione formale, condivisa ed esplicita di}

una concettualizzazione di un dominio di interesse. Più nel dettaglio, si tratta di una teoria assiomatica del primo ordine esprimibile in una logica descrittiva. Fonte Wikipedia.

(46)

• Presso: identity

• URI: http://www.xes-standard.org/identity.xesext

Log, Trace, Event, meta id id Identicatore univoco per un elemento (UUID).

Tabella 2.8: Gli attributi deniti dall'estensione ID

2.1.4.7 Cost Extension

L'estensione Cost denisce un elemento annidato per memorizzare informa-zioni riguardanti i costi associati alle attività all'interno di un log.

L'obiettivo di questa estensione è cioè quello di denire una semantica per la registrazione dei costi che può essere utilizzata per gli eventi del log.

Riprendiamo il nostro esempio, aggiungendo a questo gli elementi dell'e-stensione Cost, in modo da rendere la descrizione di questa edell'e-stensione più semplice.

3 <extension name="Concept" prefix="concept" uri="http://www.xes-standard.org/concept .xesext" />

4 <extension name="Time" prefix="time" uri="http://www.xes-standard.org/time.xesext" />

(47)

6 <global scope="trace">

7 <string key="concept:name" value="" /> 8 </global>

11 <date key="time:timestamp" value="1970-01-01T00:00:00.000+00:00" /> 12 <string key="system" value="" />

13 </global>

14 <classifier name="Activity" keys="concept:name" /> 15 <classifier name="Another" keys="concept:name system" /> 16 <float key="log attribute" value="2335.23" />

17 <trace>

18 <string key="concept:name" value="Trace number one" /> 19 <string key="cost:currency" value="AUD" />

20 <float key="cost:total" value="20.00" /> 21 <string key="xyz123" value="">

22 <float key="cost:amount" value="20.00" /> 23 <string key="cost:driver" value="xyz123" /> 24 <string key="cost:type" value="Fixed Overhead" /> 25 </string>

26 <event>

32 </int>

33 <string key="cost:currency" value="AUD" /> 34 <float key="cost:total" value="123.50" /> 35 <string key="d2f4ee27" value="">

36 <float key="cost:amount" value="21.40" /> 37 <string key="cost:driver" value="d2f4ee27" /> 38 <string key="cost:type" value="Labour" />

39 </string>

40 <string key="abc124" value="">

41 <float key="cost:amount" value="102.10" /> 42 <string key="cost:driver" value="abc124" />

(48)

43 <string key="cost:type" value="Variable Overhead" />

44 </string>

49 <date key="time:timestamp" value="2009-11-28T11:18:45.000+02:00" />

50 ...

51 </event> 52 </trace> 53 </log>

L'estensione denisce innanzitutto tre attributi annidati, ovvero attributi che dovranno dovranno essere contenuti da un altro attributo:

1. amount, che conterrà l'importo che denisce questo attributo di costo. 2. driver, che rappresenterà il fattore di costo (cost driver) responsabile

per il sostenimento di tale costo. 3. type che identicherà il tipo di costo.

Come si vede nell'esempio, questi tre attributi sono utilizzati sia a livello di traccia che a livello di eventi, all'interno di un attributo principale la cui importanza è solo quella di fare da insieme per gli altri tre.

Questo attributo principale infatti ha l'unico scopo di separare in gruppi questi tre attributi, in modo da poter avere più attributi di costo per evento nel caso servisse, dato che lo standard XES non permette di avere attributi multipli con la stessa chiave all'interno dello stesso elemento.

Questi attributi di raggruppamento sono anche chiamati attributi di costo e non fanno direttamente parte di questa estensione, poiché le loro chiavi

(49)

necessitano di solito di essere dierenti e possono assumere qualsiasi valore per essere distinte tra loro (e quindi non rispettano uno standard preciso come quello che una estensione si propone di denire).

Poiché possono esistere più attributi di costo associati allo stesso evento o traccia, l'estensione denisce due attributi principali a livello sia di evento che di traccia:

1. total, che conterrà rispettivamente la somma complessiva dei vari costi dell'evento e la somma complessiva dei totali dei singoli eventi appartenenti alla traccia.

2. currency, che registra la valuta nella quale i costi sono espressi. Le informazioni sui costi possono essere quindi registrate sia a livello di tracce (ad es. per registrare che un dato caso ha generato un costo per il suo avvio), sia a livello di eventi (ad es. per eventi completati o cancellati per i quali ci interessa registrare il costo sostenuto durante l'esecuzione dell'attività che li ha generati).

Nella Tabella 2.9 sono mostrati gli attributi deniti da questa estensione e appena descritti, suddivisi per i vari livelli della gerarchia di XES.

• Presso: cost

• URI: http://www.xes-standard.org/cost.xesext

2.2 Sviluppo dell'applicazione

Dopo aver presentato lo standard XES, elemento fondamentale sulla quale si basa la gestione e analisi che l'applicazione sviluppata implementa, passiamo

(50)

Trace, Event total oat Il costo totale incorso per una traccia o un evento. Il valore rappresenta la somma di tutti gli importi registrati nel-l'attributo amount dei sotto-elementi di questo livello.

Trace, Event currency string La valuta di tutti i costi di questo elemento, espressa in qualsiasi formato valido per le valute.

meta amount oat Il valore dell'importo per il fattore di costo dichiarato.

meta driver string L'identicatore del fattore di costo uti-lizzato per calcolare questo elemento di costo.

meta type string Il tipo di costo (ad es. Fixed, Overhead, Materials).

Tabella 2.9: Gli attributi deniti dall'estensione Cost

ora a descrivere quali sono stati gli strumenti utilizzati per lo sviluppo di quest'ultima.

2.2.1 Il linguaggio di programmazione

La prima tecnologia da denire per lo sviluppo dell'applicazione è stata quella del linguaggio di programmazione da utilizzare.

La scelta è ricaduta sul linguaggio di programmazione Java: è un linguag-gio orientato agli oggetti ormai famoso in tutto il mondo e molto utilizzato anche in ambito universitario. Questa scelta ha permesso una organizzazione ottimale del codice ed implementazione dell'applicazione e permetterà una

(51)

facile manutenzione ed estensione della stessa da parte di una vasta comunità di sviluppatori e studenti universitari.

Java inoltre, come è noto in ambito informatico, è un linguaggio che permette, dopo una fase iniziale di compilazione del programma scritto per ottenere come risultato il cosiddetto bytecode6_{, di eseguire i programmi con}

esso sviluppati in maniera indipendente dall'hardware sottostante: è su-ciente avere installato nel proprio sistema una piattaforma Java (di cui ne è l'implementazione il Java Runtime Environment, o JRE7_{), che al giorno}

d'oggi è presente nella quasi totalità dei sistemi operativi.

Questa piattaforma prende il bytecode generato dalla compilazione del codice Java e lo "interpreta", utilizzando la macchina virtuale inclusa nella piattaforma stessa, chiamata Java Virtual Machine.

Java inne ha una grande comunità di sviluppatori nel mondo, proprio per il suo vasto utilizzo. Questo ha permesso lo sviluppo negli anni di moltissime librerie di codice disponibili online con licenza Open Source.

Queste librerie deniscono operazioni comuni e ricorrenti per molti do-mini di applicazione, permettendo quindi con facilità l'implementazione di particolari funzioni all'interno della nostra applicazione senza dover necessa-riamente scrivere il codice per la sua creazione, ma semplicemente riutiliz-zando del codice già disponibile (ovvero il principio del "riuso del codice"), facilitando il lavoro di programmazione stesso.

6_{Il bytecode è un linguaggio intermedio più astratto tra il linguaggio macchina e il}

linguaggio di programmazione, usato per descrivere le operazioni che costituiscono un programma. Un linguaggio intermedio come il bytecode è molto utile a coloro che realiz-zano linguaggi di programmazione perché riduce la dipendenza dall'hardware e facilita la creazione degli interpreti del linguaggio stesso. Fonte Wikipedia.

7_{Il JRE, o Java Runtime Environment, è un ambiente di esecuzione per applicazioni}

(52)

2.2.2 L'ambiente di sviluppo

Per poter scrivere codice in un determinato linguaggio di programmazione è necessario un ambiente di sviluppo all'interno del quale poter scrivere, compilare ed eseguire il suddetto codice.

Per lo sviluppo di questa applicazione è stato utilizzato Eclipse, un noto ambiente di sviluppo integrato (Integrated Development Environment, oppure semplicemente IDE) appartenente alla categoria dei software Open Source per la programmazione Java e non solo.

Questo software fornisce al programmatore tutta una serie di aiuti du-rante lo sviluppo del codice sorgente del programma, partendo da un editor completo di molte funzioni per la scrittura del codice, passando per la se-gnalazione di molti errori, ad esempio di sintassi o di semantica del codice scritto oppure nell'utilizzo di certi costrutti del linguaggio di programma-zione, nonché fornendo strumenti per la fase di debug8 _{del codice ed}

inclu-dendo un compilatore e/o un interprete per il linguaggio di programmazione selezionato.

La versione di Eclipse utilizzata per lo sviluppo dell'applicazione è "Luna SR2(4.4.2)".

Di questo IDE abbiamo utilizzato anche uno specico componente ag-giuntivo, ObjectAID, per a generazione automatica dei diagrammi UML delle classi a partire dal progetto Java sviluppato in Eclipse.

8_{Indica l'attività che consiste nell'individuazione da parte del programmatore della}

porzione di software aetta da errore (bug) rilevata nei software a seguito dell'utilizzo del programma. Fonte Wikipedia.

(53)

2.2.3 Il pattern Modied Model-View-Controller

Per lo sviluppo di questa applicazione era necessario combinare diverse fun-zionalità, a partire da quelle grache per fornire all'utente la possibilità di gestire, modicare ed analizzare i log tramite una interfaccia, passando per quelle necessarie all'elaborazione delle operazioni richieste dall'utente in ma-niera separata dalle componenti grache (che non hanno questa capacità), no a quelle utili per la memorizzazione e gestione dei dati necessari allo svolgimento di queste elaborazioni.

Per poter combinare queste funzionalità in maniera logica e struttura-ta, l'applicazione è stata sviluppata utilizzando il pattern Modied Model-View.Controller, di cui parleremo a fondo nella Sezione 3.1.

2.2.4 Le librerie esterne

Durante lo sviluppo dell'applicazione, per l'implementazione di alcune par-ticolari funzionalità, sono state selezionate delle librerie Java Open Source presenti online, che verranno adesso presentate.

Queste librerie sono state scelte per implementare in maniera professiona-le e compprofessiona-leta alcune delprofessiona-le funzioni che il sistema voprofessiona-leva fornire all'utente, non-ché per la gestione di determinati formati (primo tra tutti XES) all'interno dell'applicazione.

2.2.4.1 OpenXES

OpenXES è la libreria Java Open Source uciale dello standard XES, rila-sciata dagli stessi sviluppatori dello standard, descritto nella Sezione 2.1.

(54)

La versione utilizzata è la 2.0, ultima release uciale al momento della scrittura di questo elaborato.

Per la stesura di questa sezione riguardante la libreria OpenXES abbiamo fatto riferimento a [6].

La libreria, implementazione di riferimento dello standard, è stata creata con i seguenti obiettivi:

1. Essere aderente in ogni aspetto allo standard XES.

2. Essere di immediato utilizzo e facile da integrare per gli sviluppatori che ne vogliano fare uso.

3. Fornire la massima performance per quanto riguarda la gestione e la memorizzazione dei dati dei log, qualunque sia il tipo di log preso in esame.

4. Servire da chiara e comprensibile implementazione di riferimento per altre implementazioni dello standard.

Questa libreria è stata quindi pensata per tutti gli sviluppatori che neces-sitino di inserire nelle loro applicazioni Java la memorizzazione, gestione, serializzazione ed analisi dei log di eventi, nel rispetto totale dello standard XES.

Nella Figura 2.4 viene mostrato il diagramma UML 2.0 delle classi della libreria che implementano i rispettivi oggetti dello standard XES.

La libreria contiene oltre a queste altre classi per l'implementazione Java di molte funzionalità connesse al rispetto dello standard e alla