Applicazioni intelligenzaartificiale

Universit` degli Studi di Ferrara
a
`
Facolta di Ingegneria

Corso di Laurea Specialistica in
Ingegneria Informatica e dell’Automazione

Sperimentazione di un sistema di
Business Intelligence
Applicazioni di Intelligenza Artificiale

Relatore:
Ch.ma Prof.ssa Evelina Lamma
Correlatore: Laureanda:
Ch.mo Prof. Fabrizio Riguzzi Mariangela Antonella Maselli

Anno accademico 2007-2008

I was just guessing
at numbers and ﬁgures,
pulling your puzzles apart.
Questions of science,
science and progress,
Do not speak as loud as my heart.
(The Scientist. Coldplay)

Indice

E lenco delle fi gure 11

Introduzione 13

1 Business P rocess M anagement 15
1.1 Caratterizzazione del processo di business . . . . . . . . . . . 16
1.2 Fasi del B PM . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Il supporto dei Sistemi Informativi Aziendali al B PM . . . . . 18
1.4 Process Mining . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.5 W ork fl ow Mining . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.6 Composizione di un log di eventi . . . . . . . . . . . . . . . . 22

2 P rocess M ining 25
2.1 Conformance o discovery ? . . . . . . . . . . . . . . . . . . . . 25
2.2 T ecniche procedurali . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.1 Approccio basato sulle reti di Petri . . . . . . . . . . . 27
2.3 T ecniche dichiarative . . . . . . . . . . . . . . . . . . . . . . . 28
2.4 Process Mining come problema di classifi cazione . . . . . . . . 29

3 BP M e SCIF F 31
3.1 SCIFF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5

6 IND ICE

3.2 Apprendimento in ILP . . . . . . . . . . . . . . . . . . . . . . 32
3.3 L’apprendimento con ICL . . . . . . . . . . . . . . . . . . . . 33
3.4 D efi nizione degli Eventi in SCIFF . . . . . . . . . . . . . . . . 36
3.5 D efi nizione delle Aspettative . . . . . . . . . . . . . . . . . . . 36
3.6 Social Integrity Constraint . . . . . . . . . . . . . . . . . . . . 37
3.7 Apprendimento con SCIFF . . . . . . . . . . . . . . . . . . . . 39
3.7.1 Il language bias nello SCIFF . . . . . . . . . . . . . . . 4 0

4 BP M con D ecSerF low 41
4 .1 Cos’` D ecSerFlow . . . . . . . . . . . . . . . . . . . . . . . . . 4 2
e
4 .2 Formule di relazione . . . . . . . . . . . . . . . . . . . . . . . 4 5
4 .3 Formule di negazione . . . . . . . . . . . . . . . . . . . . . . . 4 9
4 .4 Formule con l’attributo chain . . . . . . . . . . . . . . . . . . 51
4 .5 T raduzione D ecSerFlow - SCIFF . . . . . . . . . . . . . . . . . 54

5 D ecM iner 55
5.1 T raduzione SCIFF - D ecSerFlow . . . . . . . . . . . . . . . . . 56
5.2 Req uisiti di D ecMiner . . . . . . . . . . . . . . . . . . . . . . 60
5.3 Struttura di D ecMiner . . . . . . . . . . . . . . . . . . . . . . 6 2
5.4 U so e applicazione in ProM . . . . . . . . . . . . . . . . . . . 6 4

6 E sperimenti 67
6 .1 Analisi dei dati e creazione del fi le di log . . . . . . . . . . . . 6 7
6 .2 Stati delle attivit` e T imestamps . . . . . . . . . . . . . . . . 6 9
a
6 .3 Classifi cazione delle istanze . . . . . . . . . . . . . . . . . . . . 73
6 .4 T est con vincoli D ecSerFlow . . . . . . . . . . . . . . . . . . . 74
6 .5 T est con vincoli SCIFF . . . . . . . . . . . . . . . . . . . . . . 80

Conclusioni 101

IND ICE 7

Bib liograﬁ a 103

Ringraziamenti 106

E lenco delle ﬁ gure

1.1 Fasi del B usiness Process Management . . . . . . . . . . . . . 17
1.2 Estrazione della conoscenza . . . . . . . . . . . . . . . . . . . 20
1.3 T ransizioni di stato di un evento . . . . . . . . . . . . . . . . . 23

2.1 Fasi di un process conformance/ discovery . . . . . . . . . . . . 26
2.2 Esempio di una rete di Petri . . . . . . . . . . . . . . . . . . . 28
2.3 Esempio di rete generata dall’algoritmo α . . . . . . . . . . . . 28

4 .1 Ex istence 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4
4 .2 Ex istence N . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4 .3 Absence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5
4 .4 Absence N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 5
4 .5 Ex actly N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4 .6 Responded Ex istence . . . . . . . . . . . . . . . . . . . . . . . 4 6
4 .7 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 6
4 .8 Precedence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7
4 .9 Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7
4 .10 Co-ex istence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7
4 .11 Alternate Response . . . . . . . . . . . . . . . . . . . . . . . . 4 8
4 .12 Alternate Precedence . . . . . . . . . . . . . . . . . . . . . . . 4 8
4 .13 Alternate Succession . . . . . . . . . . . . . . . . . . . . . . . 4 8

9

10 E LE NCO D E LLE F IG U RE

4 .14 Mutual Substitution . . . . . . . . . . . . . . . . . . . . . . . 4 9
4 .15 Responded Absence . . . . . . . . . . . . . . . . . . . . . . . . 4 9
4 .16 N egation Response . . . . . . . . . . . . . . . . . . . . . . . . 4 9
4 .17 N egation Precedence . . . . . . . . . . . . . . . . . . . . . . . 50
4 .18 N egation Succession . . . . . . . . . . . . . . . . . . . . . . . 50
4 .19 N ot Co-ex istence . . . . . . . . . . . . . . . . . . . . . . . . . 50
4 .20 N egation Alternate Response . . . . . . . . . . . . . . . . . . 51
4 .21 N egation Alternate Precedence . . . . . . . . . . . . . . . . . 51
4 .22 N egation Alternate Succession . . . . . . . . . . . . . . . . . . 51
4 .23 Chain Response . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4 .24 Chain Precedence . . . . . . . . . . . . . . . . . . . . . . . . . 52
4 .25 Chain Succession . . . . . . . . . . . . . . . . . . . . . . . . . 52
4 .26 N egation Chain Response . . . . . . . . . . . . . . . . . . . . 53
4 .27 N egation Chain Precedence . . . . . . . . . . . . . . . . . . . 53
4 .28 N egation Chain Succession . . . . . . . . . . . . . . . . . . . . 53

5.1 Ciclo di Process Mining con D ecMiner . . . . . . . . . . . . . 6 2
5.2 File del sistema D ecMiner . . . . . . . . . . . . . . . . . . . . 6 4
5.3 Stati degli eventi in ProM . . . . . . . . . . . . . . . . . . . . 6 5

6 .1 Esempio di una Process Instance interpretata da ProM . . . . 72
6 .2 Ex istence dell’attivit` Esame
a . . . . . . . . . . . . . . . . . . 76
6 .3 Ex istence dell’attivit` Esame con voto alto . . . . . . . . . . . 76
a
6 .4 Ex istence dell’attivit` Esame con voto medio . . . . . . . . . . 76
a
6 .5 N egation Chain Response tra Immatricolazione e Iscrizione. . 77
6 .6 Chain Precedence tra Iscrizione e Esame. . . . . . . . . . . . . 77
6 .7 Responded Ex istence tra esame con voto alto con lode ed
esame con voto alto senza lode . . . . . . . . . . . . . . . . . . 77

E LE NCO D E LLE F IG U RE 11

6 .8 Responded Ex istence tra esame con voto basso ed esame con
voto medio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6 .9 Ex istence iscrizione (intesa dal 2o anno in poi) . . . . . . . . . 78
6 .10 Absence attivit` trasferimento . . . . . . . . . . . . . . . . . . 79
a
6 .11 Responded Ex istence tra trasferimento ed esame convalidato . 79
6 .12 Responded Ex istence tra esame convalidato ed esame non con-
validato . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

Introduzione

N egli ultimi anni si ` resa evidente la necessit` di un sistema di B usiness
e a
Intelligence in grado di agevolare e migliorare la comprensione di informazioni
presenti come dati in grandi q uantit` negli attuali database o in sistemi in
a
grado di gestire la memorizzazione di eventi. N umerose proposte provengono
da vari campi dell’informatica e mirano da un lato alla gestione e al miglio-
ramento dei processi di business presenti nelle organizzazioni e alla scoperta
di vincoli temporali esistenti tra le attivit` , dall’altro mirano all’estrazione
a
di dati e associazioni non banali per facilitare l’analisi di grande q uantit` di
a
dati. T ali indagini riguardano sia la ricerca di vincoli e relazioni temporali,
sia correlazioni di carattere pi` generale legata al tipo e alle caratteristiche
u
dei dati esaminati. Il lavoro eff ettuato in q uesta tesi parte dallo studio delle
tecniche attualmente in uso per il Process Mining e prosegue soff ermandosi
sui dettagli dello SCIFF e del D ecSerFlow , analizzando le caratteristiche
e le prospettive d’uso di q uesti linguaggi. In particolare si soff erma sulle
specifi che del sistema D ecMiner, plugin sviluppato all’interno del framew ork
PRO M e utilizzato nella fase sperimentale. La fase sperimentale consiste
nella valutazione dei dati a disposizione (un dataset di studenti), sviluppo di
un classifi catore per le suddivisione delle istanze (che in q uesto caso sono gli
studenti e la loro carriera universitaria) e dalla fase di testing, seguita dalla
valutazione dei risultati ottenuti.

13


Struttura e organizzazione della tesi
La tesi ` organizzata in q uesto modo:
e
il primo capitolo introduce la q uestione relativa al B usiness Process Mana-
gement e al supporto fornito dai sistemi informativi per il miglioramento e
l’automatizzazione di tale processo;
il secondo capitolo aff ronta il problema del Process Mining, analizzando le
tecniche pi` diff use e confrontando un approccio di tipo procedurale con un
u
approccio dichiarativo ;
nel terzo capitolo vengono spiegate le specifi che tecniche del linguaggio SCIFF
e dell’algoritmo ICL utilizzato per l’apprendimento;
nel q uarto capitolo viene analizzato il linguaggio grafi co D ecSerFlow e la sua
traduzione in vincoli SCIFF;
nel q uinto capitolo viene esaminato il plugin D ecMiner basato su SCIFF e
D ecSerFlow ;
nel sesto capitolo viene spiegata la sperimentazione eff ettuata sui dati di
una popolazione studentesca, partendo dall’analisi dei dati a disposizione e
proseguendo con la valutazione delle scelte eff ettuate e dei risultati ottenuti.

Capitolo 1

Business P rocess M anagement

O gni azienda, indipendentemente dalle dimensioni, dal settore in cui
opera e dal tipo di servizi di cui ` fornitrice, deve gestire al suo interno
e
processi di business complessi che sono alla base di tutte le attivit` . I pro-
a
cessi di business, molto diversi tra loro a causa della diversa complessit` ,
a
della diff erente durata, delle attivit` appartenenti al processo e delle en-
a
tit` partecipanti, devono essere effi caci ed effi cienti, integrando attivit` , in-
a a
terne o esterne, se in q ualche modo infl uenzano il processo, utenti, contenuti
ed eventuali normative. Il B usiness Process Management ` la una gestio-
e
ne dei processi di business capace di migliorare continuamente i processi e
prevede metodi per l’analisi e la comprensione dei dati, per la riprogettazione
e per l’attuazione delle modifi che, tecniche per la diagnosi e per il confron-
to dei risultati. Analizziamo di seguito il procedimento di B usiness Process
Management. Partiamo da alcune considerazioni circa i processi e le loro
caratteristiche.

15

16 1 . Business P rocess M anagement

1 .1 Caratterizzazione del processo di b usiness

I processi di business possono essere molto diversi tra loro e non soltanto
nel caso in cui essi provengano da contesti molto diff erenti; anche all’interno
di uno stesso contesto o di uno stessa organizzazione esistono processi ben
diversi. Al di l` delle entit` e delle attivit` che caratterizzano un processo,
a a a
del numero e della freq uenza con cui esse si presentano, vogliamo eviden-
ziare alcune propriet` che diversifi cano i processi:q uesti possono essere pi`
a u
meno complessi a seconda del livello di interazione tra le entit` , della col-
a
laborazioni tra i partecipanti, della sincronizzazione di attivit` o decisioni;
a
possono risultare pi` e meno predicibili a seconda delle circostanze che pos-
u
sono alterare o modifi carne l’esecuzione. In alcuni casi vi possono essere
situazioni fortemente impredicibili, in q uanto legati a fenomeni naturali, del
tutto aleatori o di cui non si ` ancora spiegata la causalit` . Inoltre possono
e a
essere pi` o meno ripetitivi, sulla base della freq uenza vengono eseguiti. La
u
comprensione e la gestione dei processi ` dunq ue un’operazione complessa
e
e delicata in q uanto pu` infl uenzare fortemente le situazioni all’interno di
o
un’organizzazione.

1 .2 F asi del BP M

Il B PM risulta dunq ue un’operazione complessa e generalmente vien vista
come costituita da q uattro fasi :

design : defi nizione di un modello per l’esecuzione delle attivit` ;
a

implementazione : adattamento del sistema al modello;

attuazione : applicazione del modello defi nito;

1 .2 F asi del BP M 17

diagnosi : analisi dei risultati.

Figura 1.1: Fasi del B usiness Process Management

N ell’approccio tradizionale la prima fase di un B PM ` la fase di design,
e
in cui si stabilisce un modello di processo sulla base delle attivit` necessarie,
a
seguita da una fase di implementazione nella q uale si adatta il sistema al
modello stabilito. La successiva fase di attuazione consiste nell’apportare le
modifi che e i cambiamenti, necessari per adeguare i processi a q uanto stabili-
to nella progettazione. L’esecuzione dei processi genera nuovi dati utilizzabili
in fase di diagnosi, fondamentale per analizzare gli eff etti ottenuti dal cambi-
amento e poter riprogettare i processi tenendo conto dei risultati precedenti.
T radizionalmente si pone particolare attenzione a q ueste prime due fasi che
ovviamente sono alla base delle operazioni successive e che sono svolte al fi ne
di ricercare migliorie apportabili ai processi esistenti. Le migliorie possono
riguardare l’ordinamento abituale dello svolgimento dello attivit` , sceglien-
a
done uno pi` adatto alle politiche, al regolamento e all’effi cienza, o l’ottimiz-
u
zazione delle performance, o il controllo degli accessi, riprogrammando la


politica d’accesso per non interferire nello svolgimento del lavoro abituale.
Le modalit` di attuazione di un processo di business sono legate a interessi
a
di vario tipo a seconda del settore in cui essi hanno luogo e dagli obiettivi
dell’azienda. O rganizzazioni commerciali avrenno come fi ni principali pro-
duttivit` e redditivit` , organizzazioni istituzionali avranno fi ni diretti alla
a a
migliore fruibilit` dei servizi da parte degli utenti. In tutti i casi a q ueste
a
motivazioni se ne aggiungono altre di tipo politico, vincoli di tempo, norma-
tive. N ella creazione di un modello, per` , il legame con gli obiettivi spesso
o
pu` risultare poco diretto. Senza una documentazione completa e senza stru-
o
menti adatti all’analisi, pu` risultare alq uanto diffi cile attuare procedure di
o
miglioramento dei processi, sia in fase di riprogettazione, sia in fase di at-
tuazione. Le principali problematiche da aff rontare in un approccio di q uesto
tipo sono principalmente di due tipi: da un lato possono esserci forti diver-
sit` , tra il modello defi nito in fase di design e la situazione realmente esistente
a
all’interno di una azienda, rendendo diffi cile il cambiamento o forzando un
cambiamento inadatto. D all’altro lato si presenta il problema dell’interpre-
tazione dei dati e di una possibile visione soggettiva da parte di manager e
analisti del sistema.

1 .3 Il supporto dei Sistemi Informativ i A zien-
dali al BP M

G li attuali sistemi informativi aziendali off rono sicuramente un valido
supporto per evitare q uesti problemi, ma generano allo stesso tempo una
situazione nuova e diff erente da q uella evidenziata in precedenza, che con-
sente di vedere il problema da un’altra prospettiva: la grande q uantit` di dati,
a
indubbiamente molto utile, necessita di strumenti adatti per essere elabora-

1 .3 Il supporto dei Sistemi Informativ i A ziendali al BP M 19

ta e fornire informazioni sostanziali che altrimenti resterebbero nascoste e
disperse all’interno della moltitudine di informazioni. E’ possibile pensare
ad un sistema in grado di utilizzare i dati a disposizione selezionando, ma-
nipolando, raggruppando i dati in ogni modo possibile, selezionando attivit`
a
e informazioni di particolare interesse. U n sistema informativo aziendale, in-
fatti, raccoglie, organizza, elabora e gestisce dati necessari per la conduzione
dell’azienda . T ali dati possono nascere nell’azienda in seguito allo svolgimen-
to dei vari processi oppure essere acq uisiti come risultato delle relazioni con
soggetti esterni e possono essere destinati a consumo interno o a terzi. Alcu-
ni sistemi informativi, infatti, contengono un modello esplicito di processi di
business e gestiscono il controllo di fl usso, altri supportano tool adatti alla
rilevazione del modello, ma senza defi nirne uno esplicitamente, altri memo-
rizzano semplicemente i dati e tengono traccia di ogni evento che si verifi ca
all’interno del sistema in esame. Le informazioni ottenute in q uesto modo
sono la base per la conoscenza dei processi del sistema e hanno il vantaggio
di non fornire alcuna visione soggettiva rispetto agli eventi fi nalizzata allo
sviluppo di sistemi per un controllo di fl usso automatizzato. G li eventi me-
morizzati, assieme ovviamente alle indicazioni circa il tempo, la modalit` , le
a
caratteristiche con cui tali eventi si verifi cano e le entit` coinvolte, costitui-
a
scono i cosiddetti log di eventi e rappresentano il punto di partenza per il
process mining. Partiamo da q ueste osservazioni per defi nire un sistema di
B usiness Intelligence a supporto della gestione dei processi. Per sistema di
B usiness Intelligence intenderemo genericamente sia l’insieme di processi per
raccogliere ed analizzare informazioni strategiche, sia la tecnologia utilizza-
ta nella realizzazione del sistema e le informazioni ottenute come risultato.
Scopo di un sistema di q uesto tipo sar` non solo l’organizzazione regolare
a
e sistematica delle informazioni sugli eventi di un’azienda, ma anche l’es-


trazione di informazioni aggiuntive, nascoste, ma spesso fondamentali per
comprendere associazioni tra gli eventi.

Figura 1.2: Estrazione della conoscenza

1 .4 P rocess M ining
L’obiettivo del Process Mining ` estrarre informazioni circa i processi a
e
partire dai log di transazioni. Come spiegato nei paragrafi precedenti lo
svantaggio di tecniche classiche di B PM ` q uello di partire dal design senza
e
conoscere a fondo la situazione esistente, dove per conoscenza si intende non
solo la cognizione delle tempistiche e dell’ordine esecutivo delle azioni, ma
anche la comprensione di alcune informazioni aggiuntive. Il Process Mining
consente di invertire il processo partendo non dal design del fl usso, ma dalla
raccolta delle informazioni sui processi che hanno luogo, utilizzando i log di
eventi dei Sistemi Informativi. G li eventi indicano q ualcosa che si ` verifi cato
e
e fanno riferimento ad un’azione (che chiameremo attivit` ) e appartengono ad
a
un caso. Supponiamo che i Sistemi Informativi memorizzino tali informazioni

1 .5 W ork fl ow M ining 21

assieme naturalmente ad un riferimeto temporale. Il formato utilizzato dai
sistemi transazionali come ERP, CRM, o sistemi di gestione del w ork fl ow
purtroppo non ` omogeneo. In q uesto contesto non ci addentreremo in q uesto
e
problema, ma ci baseremo sull’assunzione della possibilit` di memorizzare i
a
dati sugli eventi in un log. T ali log sono usati per costruire una specifi ca di
processo che modelli adeguatamente i comportamenti registrati.

1 .5 W ork fl ow M ining

Il termine Process Mining si riferisce ai metodi per fi ltrare una descrizione
strutturata del processo partendo da un set di dati reali. Poich´ q uesti meto-
e
di evidenziano i cosiddetti processi case-driven, basati sui casi, attualmente
supportati da sistemi di gestione del w ork fl ow , useremo spesso il termine
w ork fl ow mining. Q uesta tecnologia si sta evolvendo nella direzione di una
maggiore fl essibilit` operativa in grado di aff rontare la gestione delle eccezioni
a
nel w ork fl ow ed eventualmente la sua evoluzione. Ci` signifi ca che gli agen-
o
ti del sistema non sono completamente vincolati all’andamento prestabilito,
ma possono allontanarsi leggermente da q uesto e seguire un andamente dif-
ferente, ma pur sempre controllato. L’evoluzione del sistema, tenuta sotto
controllo, pu` indicare come gestire le eccezioni: una deviazione, infatti, pu`
o o
restare un caso unico e isolato, ma pu` anche ripresentarsi con una certa fre-
o
q uenza tanto da richiedere la rivisitazione e la modifi ca del modello prestabil-
ito. In situazioni come q uesta sarebbe auspicabile creare un ciclo che, tramite
il feedback proveniente dagli eventi, consenta di cercare le imperfezioni nel
design e individuare i cambiamenti necessari.


1 .6 Composizione di un log di ev enti
G li eventi che un sistema informativo deve memorizzare possono essere
molto diversi e diverse sono le modalit` con cui ` preferibile memorizzarli.
a e
Ci` non vuol dire per` che non sia possibile individuare un formato facil-
o o
mente utilizzabile nella maggior parte dei casi. Sfortunatamente i sistemi
informativi attualmente esistenti fanno uso di un formato specifi co. N on an-
dremo nello specifi co della discussione, ma ci baseremo sulla semplice e valida
assunzione che il log contenga comunq ue informazioni sugli eventi eseguiti,
a prescindere dal formato utilizzato. In ogni caso l’analisi svolta in q uesto
lavoro si basa sul formato X ML, supportato da molti tool e utilizzabile in
una serie di prodotti esistenti sul mercato.
Q uesto formato risulta particolarmente comodo, in q uanto consente il log-
ging di processi multipli in un semplice fi le X ML.
O gni caso ` un’istanza di un processo e viene dunq ue chiamata ProcessIn-
e
stance . Essa ` composta da pi` eventi, chiamati A uditTrailEntry. O gni
e u
A uditTrailEntry corrisponde a un singolo evento e rientra in un tipo di
W orkfl owM odelElement che consente di diff erenziare un tipo di evento da
un altro. U n W orkfl owM odelElement pu` riferirsi ad un singolo task o ad un
o
sottoprocesso.
Per ogni A uditTrail ` necessario specifi care lo stato dell’evento tramite
e
l’attributo EventType. Sono stati individuati 8 possibili stati di transizione
di un evento all’interno di un sistema di w ork fl ow illustrati in fi g.
I possibili stati di un evento sono:

new : se ` appena stato creato ;
e

sch edule : abilitato;

start : avviato;

1 .6 Composizione di un log di ev enti 23

w ith draw : eliminato;

suspend : sospeso;

resume : ripreso;

ab ort : terminate con anomalia;

complete : terminata;

Figura 1.3: T ransizioni di stato di un evento

E’ bene per` precisare che q uesta scelta deriva dal freq uente uso di siste-
o
mi di w ork fl ow per il monitoraggio di eventi legati a processi informatici, in
cui il tipo di evento indica concretamente il suo stato all’interno del sistema,
specifi ca cio` in che fase della propria esecuzione si trova l’evento. Q uesta
e
tipizzazione naturalmente non rispecchia tutti i casi di applicazioni di Pro-
cess Mining, in cui spesso si incontrano situazioni in cui gli stati di un evento
possono essere semplicemente due o tre. Su molti dataset reali, per esempio,
diff use sono le situazioni in cui un evento pu` trovarsi in uno stato di start
o


o di complete, mentre tutti gli altri stati non hanno alcun signifi cato prati-
co. Q uesta classifi cazione, q ui esposta al fi ne di una comprensione generale
sull’argomento, non sar` utilizzata nella fase sperimentale di q uesto lavoro,
a
dove, trattando azioni eff ettuate da personale umano, si utilizzeranno solo
azioni eff ettuate e q uindi in uno stato complete.
W orkfl owM odelElement e EventType sono attributi obbligatori per ogni A u-
ditTrailEntry. E’ possibile specifi care altri elementi opzionali: Data, Time-
stamp, and O riginator .
I Data sono gli elementi che possono essere utilizzati per memorizzare i dati
relativi agli eventi del caso . Il Timestamp indica il momento di esecuzione
ed ` fondamentale per calcolare i risultati da un punto di vista temporale:
e
tempo di fl usso, durata del servizio, utilizzo, ma anche semplicemente re-
lazioni di precedenza e seq uenzialit` . L’attributo O riginator si riferisce agli
a
attori , utenti o organizzazioni, che eseguono l’evento. A partire dal log di
eventi, strutturato secondo le modalit` descritte sopra, sono state sviluppate
a
tecniche di Process Mining che verrano discusse nei capitoli successivi.

Capitolo 2

P rocess M ining

Come illustrato da Agraw al in (10) il Process Mining ` la costruzione
e
automatica di modelli di processo a partire da log di eventi che sono la fonte
oggettiva di grandi q uantit` di informazioni. N egli ultimi anni sono stati
a
proposti e sviluppati vari metodi per l’estrazione di modelli di processo. In
q uesto capitolo aff ronteremo alcune tematiche generali relative al Process
Mining analizzando i vari approcci e le diverse possibilit` che q uesti off rono.
a

2 .1 Conformance o discov ery ?

U na delle prime distinzioni che va fatta ` tra le tecniche di verifi ca di
e
conformance e q uelle di discovery .
Le tecniche di verifi ca di conformance prevedono la presenza di un modello a
priori e l’utilizzo di un log di eventi per il confronto e la ricerca di discordanze
tra il modello inizialmente creato e l’eff ettiva esecuzione delle attivit` . Q uesto
a
tipo di modello risulta particolarmente adatto in tutti q uei casi che hanno
un modello di base esistente, ma necessitano di un sistema di monitoraggio.
T ra gli esempi pi` importanti di q uesto tipo Rozinat e Aalst espongono un
u

25

26 2 . P rocess M ining

sistema di controllo delle decisioni in cui il log degli eventi viene consultato
per comprendere lo stato del sistema nel momento in cui viene eff ettuata una
scelta e comprendere gli elementi che vanno ad infl uenzare la scelta.
Le tecniche di discovery , invece, non prevedono alcun modello presente a
priori nel sistema, ma costruiscono un modello soltanto sulla base delle in-
formazioni ottenute dal fi le di log.
Q ueste tecniche suscitano grande interesse e si sono sviluppate in pi` di-
u
rezioni: da un lato mirano a gestire fl ussi temporali individuando vincoli
seq uenziali, come relazioni di precedenza o di successione, dall’altro lato cer-
cano di approfondire la conoscenza delle informazioni rilevando relazioni -
nascoste esistenti tra le attivit` . Anche se inizialmente il Process Mining
a
nasce all’interno di aziende con il fi ne di migliorare la gestione dei processi
aziendali, il suo utilizzo si estende a numerosi campi col fi ne di indagare re-
lazioni tra gli eventi, anche in q uei casi in cui le condizioni sembrano casuali
e imprevedibili, come possono essere molti fenomeni naturali o la diff usione
di alcune malattie.

Figura 2.1: Fasi di un process conformance/ discovery

2 .2 T ecnich e procedurali 27

2 .2 T ecnich e procedurali

In q uesto campo sono stati sviluppati numerosi algoritmi di diverso genere.
Per molti anni l’approccio ` stato sempre di tipo procedurale, in q uan-
e
to risentiva dell’infl uenza dei meccanismi del Business Process M anagement
classico.

Come spiega G oedertierin in (7) un modello di processo di business ` det-
e
to procedurale se contiene esplicite informazioni su come il processo dovrebbe
svolgersi e solo implicitamente avere traccia del perch´ vengono fatte q ueste
e
scelte di progettazione. G eneralmente q ueste tecniche descrivono tutti i pos-
sibili andamenti di un processo, spesso devono specifi care il numero di volte
in cui deve essere eseguita un’attivit` , devono indicare i momenti di deci-
a
sione, ma non ` sempre chiaro sulla base di cosa debbano essere prese le
e
decisioni.
U n classico esempio di sistemi procedurali sono q uelli basati sulle reti di
Petri, proposti da Aalst in (8).

Esponiamo brevemente alcune caratteristiche di q uesti esempi al fi ne di
comprendere meglio la diff erenza tra un’approccio procedurale e uno dichia-
rativo.

2 .2 .1 A pproccio b asato sulle reti di P etri

Q uesto tipo di approccio ` basato su una specifi ca classe chiamata worlfl ow
e
nets e mira a costruire reti di Petri a partire da un log di eventi. Analizzando
una classica rete di Petri, come q uella di fi g. 2.2 notiamo subito la diffi colt`
a
che si pu` incontrare nel descrivere operazioni come A ND-join, cio` punti in
o e
cui due o pi` attivit` ad esecuzione parallela convergono in un unico processo
u a


o come l’ A ND-split, cio` un punto in cui un singolo processo si divide in due
e
o pi` fl ussi che vengono eseguiti parallelelamente.
u

Figura 2.2: Esempio di una rete di Petri

U na delle tecniche di Process Mining pi` diff usa ` q uella dell’algoritmo α.
u e
Q uesto metodo consente di generare reti di w ork fl ow in cui vengono eliminate
tali operazioni e viene generata una rete con un fl usso che conserva q ueste
azioni in modo implicito, come mostrato in fi gura 2.3

Figura 2.3: Esempio di rete generata dall’algoritmo α

2 .3 T ecnich e dich iarativ e
D all’esempio emerge come in approcci di tipo procedurale spesso si ren-
dono necessarie ulteriori specifi che descrittive per comprendere l’andamento

2 .4 P rocess M ining come prob lema di classifi cazione 29

dei processi e le modalit` di scelta dei diversi percorsi possibili. Per cui si `
a e
spesso costretti a dover fare una serie di assunzioni non presenti nelle richie-
ste iniziali o specifi care pi` di q uanto strettamente necessario per descrivere
u
il modello.
Ci` naturalmente non vuol dire che tali modelli non siano validi. T uttavia
o
col tempo ` emersa la necessit` di affi ancare a descrizioni di q uesto tipo anche
e a
modelli basati su un linguaggio pi` semplice e immediato.
u
In alternativa alle tecniche procedurali van der Aalst e Pesic in (5) pro-
pongono il linguaggio D ecSerFlow , linguaggio basato su logica dichiarati-
va con una semplice rappresetazione grafi ca, le cui caratteristiche verranno
esaminate con maggior dettaglio nel capitolo 4 .

2 .4 P rocess M ining come prob lema di classi-
fi cazione

U no dei casi pi` freq uenti dell’uso del Process Mining ` comprendere le
u e
condizioni che distinguono le diverse classi di un insieme di processi, dove
per classi intendiamo raggruppamenti di processi che presentano una o pi`
u
caratteristiche simili tra loro e che si distinguono dalle altre per specifi che
propriet` .
a
Molto diff uso ` per esempio il caso in cui si vogliono individuare le condizioni
e
sotto le q uali una transazione ha luogo e in q uali casi no, oppure, pi` in gen-
u
erale, i casi in cui una transazione risulta positiva e in q uali risulta negativa.
Q uesto tipo di classifi cazione pu` riguardare eventi di ogni tipo: per esem-
o
pio una banca potrebbe voler distinguere le transazioni fraudolente da q uelle
corrette, una azienda potrebbe voler distinguere i clienti che accettano una
proposta commerciale da q uelli che la rifi utano, in campo medico si potreb-


bero voler identifi care le condizioni sotto le q uali una cura ha esito positivo
e i casi in cui ha esito negativo.
In generale l’apprendimento per la classifi cazione consiste nell’apprendere
come assegnare un’istanza ad una classe o ad un gruppo predefi nito, sulla
base di alcune caratteristiche note.
L’obiettivo del Process Mining, in q uesto caso, ` dunq ue apprendere caratte-
e
ristiche che diff erenziano una classe da un’altra in modo da poter assegnare,
in modo pi` o meno automatico, un’istanza ad una determinata classe, a
u
seconda dei contesti in cui il processo ha luogo.

Capitolo 3

BP M e SCIF F

T ra le proposte di tecniche di Process Mining basati su linguaggi logico-
dichiarativi in (14 ) viene proposto SCIFF.
In q uesto capitolo saranno analizzate le caratteristiche tecniche di q uesto
framew ork .

3 .1 SCIF F

SCIFF ` un framew ork basato su logica computazionale e programmazione
e
logica abduttiva che fu inizialmente sviluppato per la descrizione e la verifi ca
di protocolli di interazione fra agenti in societ` aperte (14 ). SCIFF con-
a
sente, dato un insieme di attivit` descritte nel log di eventi, di individuare
a
interazioni, relazioni, associazioni temporali tra le attivit` al fi ne di ottenere
a
schemi di esecuzione fi ssa o comunq ue generalmente diff usa. Si inserisce al-
l’interno dei metodi che utilizzano la classifi cazione per rilevare caratteristi-
che proprie di una certa classe di processi. Alcuni metodi di Process Mining,
infatti, considerano solo istanze positive. Caratteristica di SCIFF, invece, `
e
di partire da una suddivisione delle tracce in conformant e non conformant

31

32 3 . BP M e SCIF F

(potremmo deﬁ nirle tracce con esiti positivi e tracce con esiti negativi) ed
individuare q uelle caratteristiche che distinguono le une dalle altre. T ali ca-
ratteristiche vengono espresse tramite regole tipiche della programmazione
logica, ottenendo in q uesto modo semplici pattern su cui basare i modelli
di processo. In SCIFF, q uindi, non si vuole estrarre un modello completo,
ma ricavare costrutti che legano le attivit` tra di loro. In q uesto modo si
a
ottiene un modello semplice, conciso e facilmente leggibile delle relazioni es-
senziali. Inoltre l’utilizzo di un linguaggio di tipo logico consente di utilizzare
le tecniche sviluppate nel campo dell’ILP (Inductive Logic Programming) per
apprendere modelli partendo da una conoscenza di back ground.

3 .2 A pprendimento in ILP
N ella Programmazione Logica Induttiva una clausola C viene considerata
vera in un’interpretazione I se per ogni sostituzione θ che rende ground C
vale :
(I |= bo dy(C)θ) → (he ad(C)θ ∩ I = ∅)

Altrimenti viene considerata falsa.
U na clausola C ` una formula del tipo :
e

b1 ∧ ... ∧ bn → h1 ∨ ... ∨ hm

dove bi sono letterali logici e hi sono atomi logici.
U na formula ` detta ground se non contiene variabili e un’interpretazione I
e
` un insieme di atomi ground.
e
Si deﬁ nisce:
he ad(C) = h1 ∨ ... ∨ hm

bo dy(C) = b1 ∧ ... ∧ bn

3 .3 L’apprendimento con ICL 33

Il problema dell’apprendimento in ILP pu` essere formulato come segue:
o

D ati:

uno spazio di possibili teorie a clausole H (language bias);
un set P di interpretazioni positive;
un set N di interpretazioni negative;
una teoria a priori B.

T rov are una teoria a clausole H ∈ H tale che:

per ogni p ∈ P , H ` vera in p in M (B ∪ p);
e
per ogni n ∈ N , H ` falsa in n in M (B ∪ n).
e

H ` lo spazio delle ipotesi e q uindi lo spazio di ricerca. La descrizione
e
di q uesto spazio ` detta language bias e specifi ca i letterali che possono es-
e
sere usati nelle ipotesi. B (background knowledge) ` un insieme di predicati
e
di cui si conosce la defi nizione, ` la conoscenza a priori del dominio, e in
e
q uanto tale pu` anche non essere presente. Si dice che la clausola C copre
o
l’interpretazioni I se C ` vera in M (B ∪ I) Si dice che la clausola elimina
e
un’interpretazione I se C non copre I.

3 .3 L’apprendimento con ICL
L’algoritmo ICL (Inductive Logic Constraint), su cui si basa l’apprendi-
mento in SCIFF, ha un meccanismo di tipo top dow n, parte cio` da una
e
clausola generale che viene via via raffi nata, ma con un fi ne diverso rispetto
a q uello classico: cerca infatti di trovare una teoria che ricopra tutti i casi
positivi ed elimini alcuni negativi. La funzione utilizzata da SCIFF per eli-
minare progressivamente le interpretazioni negative dal set N ` la seguente:
e


function Learn(P,N ,B )
H :- ∅
do
C := F indBe s tClau s e (P, N, B)
if best clause C = ∅ then
add C to H
remove from N all interpretations that are false for C
w hile C = ∅ e N = ∅
return H

Funzione di apprendimento ICL.

function FindB estClause(P,N ,B )
B eam:=f als e ← tr u e
B estClause := ∅
do
w hile B eam = ∅
N ew B eam := ∅
for each clause C in B eam do
for each reﬁ nement Ref of C do
if Ref is better than B estClause then B estClause:=Ref
if Ref is not to be pruned then
add Ref to N ew B eam
if size of N e w Be am > M axBe am S iz e then
remove w orst clause from N ew B eam
B eam:=N ew B eam
return B estClause

Funzione di ricerca della clausola migliore.

3 .3 L’apprendimento con ICL 35

La funzione di apprendimento L earn parte inizializzando la teoria H come
un insieme vuoto e come clausola iniziale utilizza f als e ← tr u e , clausola che
elimina tutte le interpretazioni negative, ma anche tutte q uelle positive. Il
ciclo richiama la funzione F indBestClause che restituisce ad ogni iterazione
una clausola da aggiungere alla teoria.
Il ciclo esterno termina q uando N ` vuoto o q uando non si trovano pi`
e u
clausole. Il fi ne del F indBestClause ` q uello di ottenere una clausola che
e
risulta vera in tutte le interpretazioni positive e falsa in alcune interpre-
tazioni negative. N aturalmente q uesta clausola potrebbe non esistere, per
cui sar` considerata BestClause q uella clausola che risulta vera nel maggior
a
numero di interpretazioni positive possibili e falsa nella maggior numero di
interpretazioni negative.
La funzione euristica A(C) utilizzata per la scelta della clausola migliore ´ :
e

A(C) = nr (C)/(pr (C) + nr (C))

dove nr e pr indicano rispettivamente il numero di interpretazioni negative e
positive eliminate dalla clausola in esame. La clausola iniziale viene generaliz-
zata gradualmente da un operatore di raffi namento secondo la θ sussunzione:
C ` pi` generale di D ( D sussume C ) se esiste una sostituzione θ tale che
e u
D θ ⊆ C.
Il raffi namento delle clausole avviene aggiungendo letterali al corpo o atomi
alla testa. T ramite un language bias, un insieme di dichiarazioni che specifi ca
q uali raffi namenti considerare, ` possibile specifi care i letterali che possono
e
essere aggiunti.

Sulla base di q uesto modello teorico ` stata sviluppato l’algoritmo per
e
l’apprendimento di regole SCIFF.


3 .4 D efi nizione degli E v enti in SCIF F
La defi nizione di evento risulta fortemente legata al dominio di appli-
cazione. N on ci addentreremo in q uesto problema che non risulta di parti-
colare interesse in q uesto contesto, ma partiremo da come un evento viene
descritto in SCIFF. SCIFF, infatti, lascia agli sviluppatori la scelta degli
eventi da trattare e di come modellare il dominio, tenedo conto che tutto ci`
o
che pu` essere descritto da un atomo, pu` essere un evento nello SCIFF.
o o
U n evento accaduto viene rappresentato come un atomo:

H(Ev ent,Time)

dove Event ` un termine e Time ` un intero che rappresenta il momento in
e e
cui l’evento si ` verifi cato all’interno di un dominio del tempo discretizzato.
e
U na traccia di esecuzione pu` essere modellata come un set di eventi accaduti
o
e l’insieme di tracce costituisce il log degli eventi.

3 .5 D efi nizione delle A spettativ e
U n importante concetto introdotto da SCIFF ` il concetto di aspetta-
e
tive, che pu` essere positiva o negativa: positiva se sulla base di alcune
o
informazioni iniziali ci si aspetta che si verifi chi un evento, negativa se ci si
aspetta che non si verifi chi un dato evento. T ali aspettative, come gi` detto,
a
nascono dal fatto che le tracce presentino caratteristiche coincidenti con un
modello identifi cato in precedenza.
Per indicare aspettative positive viene utilizzata la seguente sintassi:

E(Event,Time)

mentre q uelle negative vengono defi nite in q uesto modo:

3 .6 Social Integrity Constraint 37

EN(Ev ent,Time)

per indicare rispettivamente che ci si aspetta o non ci si aspetta che l’evento
Event si verifi chi al tempo precisato in Time. Per una maggior precisione,
eventi e aspettative vengono defi niti come mostrato q ui di seguito:

Event::=H (G roundTerm[,Integer ])
Expectation::= PosExp | NegExp
PosExp::=E (Term[,V ariable|Integer ])
NegExp::=EN (Term[,V ariable|Integer ])
L iteral ::=[not]A tom

T abella 3.1: Sintassi di eventi e aspettative

Per esprimere le correlazioni esistenti tra gli eventi accaduti e le aspettative
di altri eventi vengono utilizzati vincoli di integrit` , le cui specifi che verranno
a
analizzate nel paragrafo successivo.

3 .6 Social Integrity Constraint
I Social Integrity Constraint, o ICs sono regole forward della forma:

Bo dy → He ad

in cui Body pu` contenere letterali e congiunzioni di eventi (aspettative o
o
esecuzioni), e Head contiene disgiunzioni di aspettative.
La tabella seguente illustra la sintassi, utilizzata in ICs.


ICs ::= [IC]
IC ::=Body→Head
Body::=(Event | Expectation | A bducibleL iteral )[ ∧ BodyL iteral ]*
BodyL iteral ::=Event | ExtL iteral
Head ::=HeadDisjunct [∨ HeadDisjunct ]*| false
HeadDisjunct::= ExtL iteral [∧ ExtL iteral ]*
ExtL iteral ::=L iteral | A bducibleL iteral | Expectation | Constraint

T abella 3.2: Sintassi ICs

La struttura di una formula ICs assume, q uindi, la seguente forma:

b1 ∧ ... ∧ bl → D is j E1 ∨ ... ∨ D is j En ∨ D is j EN1 ... ∨ D is j ENm

dove bi sono letterali, e descrivono gli eventi accaduti. U n evento ev veri-
ﬁ catosi al tempo T viene rappresentato come H(e v , T ), secondo la sintassi
deﬁ nita nel paragrafo precedente.
Le disgiunzioni presenti nella testa, invece, corrispondono alle aspettative
positive o negative, e vengono rappresentati come E(e v , T ) ∧ d1 ∧ ... ∧ dk se
positive, e come EN (e v , T ) ∧ d1 ∧ ... ∧ dk se negative, dove di sono letterali
che vengono utilizzati per informazioni aggiuntive.
U n esempio di formula ICs ` :
e

H(a(u te nte 1), T ) ∧ T < 10,
→ E(b(u te nte 2, T 1) ∧ T < T 1∨
EN (c(u te nte 3, T 1)) ∧ T > T 1)

che va letta in q uesto modo : se l’attivit` a ` eseguita dall’utente 1 al tempo
a e

3 .7 A pprendimento con SCIF F 39

T e T ` minore di 10, allora ci si aspetta che l’utente 2 esegua l’attivit` b al
e a
tempo T 1 > T , oppure l’utente 3 esegua l’attivit` c al tempo T 1 < T .
a

3 .7 A pprendimento con SCIF F
Come gi` accennato in precedenza l’apprendimento in SCIFF ` del tutto
a e
simile all’apprendimento di una teoria a clausole e in particolare all’algoritmo
ICL descritto nel paragrafo 3.3.
A partire dal log di eventi vengono deﬁ nite tracce conformant e non con-
formant, che costituiscono gli insiemi di interpretazioni positive e negative
P ed N. Sulla base di q uesta suddivisione si ricercano ICs che risultino veri
nelle interpretazioni positive e falsi in almeno una interpretazione negativa.

L’operatore di raﬃ namento ρ(C) su un IC C pu` eseguire le seguenti
o
operazioni:

- aggiungere un letterale al body di C fra q uelli ammessi dal template del
vincolo;

- aggiungere un disgiunto all’head di C fra q uelli ammessi dal template del
vincolo;

- rimuovere un letterale da un disgiunto positivo dell’head ;

- aggiungere un letterale a un disgiunto negativo.

Per far ci` utilizza un language bias costituito da un insieme di template di
o
vincoli, ognuno dei q uali indica:

- il set di letterali che sono ammessi nel body;

- il set di disgiunti ammessi nell’head ;


- i letterali che possono apparire nell’head.

3 .7 .1 Il language b ias nello SCIF F

Il language bias usato nello SCIFF ` un insieme di template costituito da
e
coppie del tipo (BS, HS): dove BS ` l’insieme dei letterali che possono essere
e
aggiunti al body di una clausola; HS ` l’insieme dei disgiunti che possono
e
essere aggiunti all’head.
O gni elemento di HS ` una coppia
e

(S e g no , L e tte r ali)

dove Segno ha valore + se si tratta di un disgiunto positivo e indica q uindi
un’ aspettativa positiva, - se si tratta di un disgiunto negativo.
L etterali contiene i letterali che possono apparire nel disgiunto.
E’ possibile defi nire q uattro modalit` d’uso del template: B S e H S pos-
a
sono essere dichiarati come fixed o dynamic. N el caso si usi la specifi ca fixed
nella ricerca dovranno essere aggiunti tutti i letterali specifi cati. N el caso
si usi la specifi ca dynamic potranno essere aggiunti alla clausola anche solo
alcuni dei letterali specifi cati.
In q uesta tesi sono stati testati, su uno stesso dataset, entrambi i tipi di
language bias, ottenendo naturalmente risultati diversi tra loro e che saranno
illustrati nel capitolo 6 .

Capitolo 4

BP M con D ecSerF low

Come abbiamo visto nel capitolo precedente SCIFF riesce a svincolare
l’estrazione di un modello di processo da una serie di diffi colt` ed esigenze
a
che si possono incontrare utilizzando linguaggi procedurali, come l’esigenza
di specifi care vincoli e assunzioni aggiuntivi oltre a q uelli strettamente richi-
esti, precisare punti di scelta sul percorso da eseguire o dover descrivere tutti
i possibili fl ussi all’interno di un processo.
SCIFF riesce invece a estrarre parti del processo in forma di regole che
caratterizzano le relazioni esistente tra le attivit` . Il risultato delle regole
a
SCIFF, pur avendo una sintassi semplice e intuitiva, pu` non risultare par-
o
ticolarmente comprensibile agli utenti non esperti o che comunq ue abbiano
poca dimestichezza con linguaggi di tipo logico. In (5) Aalst propone D ec-
SerFlow , un linguaggio che si basa su una logica temporale, e prevede una
rappresentazione grafi ca. In q uesto capitolo analizzeremo le caratteristiche
di D ecSerFlow e la sua facile associazione con le regole ICs del framew ork
SCIFF.

41

42 4 . BP M con D ecSerF low

4 .1 Cos’` D ecSerF low
e

D ecSerFlow ` un linguaggio logico temporale che consente il modellamen-
e
to dei processi tramite due elementi :

• Attivit` , intese come unit` atomiche di lavoro;
a a

• V incoli tra le attivit` per modellare regole di business.
a

T ali vincoli si basano su formule di tipo Linear T emporal Logic (LT L) e
rappresentano le relazioni esistenti tra le attivit` . La nozione di attivit`
a a
` la stessa di altri linguaggi di w ork fl ow , ` atomica e corrisponde a un’u-
e e
nit` logica di lavoro. La natura delle relazioni tra le attivit` , tuttavia, pu`
a a o
risultare leggermente diversa dai linguaggi procedurali: per esempio le reti
di Petri descrivono dipendenze causali e consente di specifi care cicli di iter-
azioni, parallelismi, alternative. In q uesto modo ` possibile defi nire come il
e
fl usso viene eseguito.
Le relazioni tra le attivit` in D ecSerFlow sono vincoli che rappresentano
a
politiche o regole di business. U tilizzando D ecSerFlow in un sistema di con-
trollo, per esempio, ` possibile valutare i vincoli per verifi care la correttezza
e
del processo durante l’esecuzione. I vincoli, basati su formule di tipo LT L,
consentono, in modo chiaro e compatto, di dare specifi che circa relazioni tem-
porali esistenti tra due attivit` . E’ da notare che il linguaggio LT L risponde
a
perfettamente alla necessit` , espressa fi no a q uesto momento, di utilizzare
a
un linguaggio dichiarativo per descrivere solo il necessario senza modellare
interamente il processo.
I linguaggi di tipo LT L forniscono operatori temporali come successione,
precedenza, e operatori per esprimere i concetti di eventualit` . Sfortunata-
a
mente i linguaggi di tipo LT L rimangono pur sempre linguaggi di tipo testuale

4 .1 Cos’` D ecSerF low
e 43

e non sono semplicissimi da usare per i non esperti. La rappresentazione grafi -
ca di D ecSerFlow elimina q uesto problema e off re un ambiente user-friendly
comprensibile anche dai non esperti.
Per creare vincoli vengono utilizzati dei template. O gni vincolo D ecSer-
Flow consiste in una formula LT L e una rappresentazione grafi ca. I template
defi niscono vari tipi di dipendenze tra le attivit` e una volta defi nito un tem-
a
plate pu` essere riutilizzato per realizzare nuovi vincoli. La semplicit` con
o a
cui ` possibile cambiare, rimuovere,e aggiungere nuovi template rende D ec-
e
SerFlow un linguaggio aperto e estensibile, facilmente adattabile a contesti
diversi. Il set iniziale di vincoli distingue tre tipi di template che chiameremo
formule:

• formule di esistenza;

• formule di relazione;

• formule di negazione:

N ella sezione successiva analizzeremo nel dettaglio le caratteristiche delle
specifi che formule.

F ormule di esistenza

Le formule di esistenza sono regole che danno indicazioni sulla cardinalit`
a
delle attivit` .Possono essere di tre tipi:
a

ex istence : per specifi care aspettative di esistenza di un’attivit` ;
a

ab sence : per specifi care aspettative di assenza di un’attivit` ;
a

ex actly : per specifi care aspettative sul numero esatto di volte con cui si
presenta un’attivit` .
a


E x istence N :
Le formule di q uesto gruppo vengono usate per esprimere aspettative
di almeno un numero N di esecuzioni di un’attivit` . La formula Ex-
a
istence 1, la cui rappresentazione grafi ca formale ` q uella mostrata in
e
fi g.4 .1 , indica q uindi che ci si aspetta sia presente almeno una volta
l’attivit` specifi cata.
a

Figura 4 .1: Ex istence 1.

Per specifi care aspettative di almeno 2, 3... N attivit` si usano, rispet-
a
tivamente, le formule Ex istence 2, Ex istence 3, ... Ex istence N .

Figura 4 .2: Ex istence N .

A b sence N :
Le formule di q uesto gruppo vengono usate per esprimere situzioni in
cui ci si aspetta che un’attivit` non si presenti un numero N di volte
a
o, per spiegarlo diversamente, ci si aspetti che un’attivit` si presenti
a
al massimo N − 1 volte. In q uesto caso, dunq ue, la regola A bsence o
A bsence 1, indica l’assenza totale dell’attivit` . G rafi camente vengono
a
rappresentate in q uesto modo:

4 .2 F ormule di relazione 45

Figura 4 .3: Absence.

Figura 4 .4 : Absence N .

E x actly N :
Se si veriﬁ cano le previsioni, descritte nelle formule precedenti, che
un’attivit` sia presente almeno N volte e al massimo N volte, chiara-
a
mente si ottiene l’esatto numero di volte di esecuzioni di un’attivit` . Si
a
ricava una terza formula deﬁ nita Ex actly N .

Figura 4 .5: Ex actly N .

4 .2 F ormule di relazione

Le formule di q uesto gruppo esprimono relazioni di tipo temporale o
vincoli di esistenza, esistenti tra due attivit` .
a


Responded E x istence :
Il signiﬁ cato della formula R esponded Existence ` che se viene eseguita
e
l’attivit` A, allora deve venire eseguita anche l’attivit` B , (utilizzando
a a
i nomi delle attivit` mostrate in ﬁ g.4 .6 ), senza alcun vincolo temporale
a
di precedenza o successione.

Figura 4 .6 : Responded Ex istence.

Response :
Aggiunge un vincolo temporale alla formula di Responded Ex istence.
Indica, infatti, che se viene eseguita l’attivit` A, allora successivamente
a
deve essere eseguita anche l’attivit` B .
a

Figura 4 .7: Response.

P recedence :
Aggiunge alla formula di R esponded Existence il vincolo temporale di
precedenza : se viene eseguita l’attivit` B , deve essere preceduta da
a
un’attivit` A.
a

Succession :
La formula Succession ` l’insieme delle due precedenti: ogni esecuzione
e
di A ` seguita da B e ogni esecuzione di B ` preceduta da A.
e e

4 .2 F ormule di relazione 47

Figura 4 .8: Precedence.

Figura 4 .9: Response.

Co-ex istence :
La formula Co-existence nasce dall’unione di due R esponded existence,
cio` speciﬁ ca che la presenza di una delle due attivit` A o B implica la
e a
presenza dell’altra.

Figura 4 .10: Co-ex istence.

A lternate Response - P recedence - Succession :
Estendono le regole di Response, Precedence, Succession:
L’A lternate R esponse Indica che se viene eseguita l’attivit` A, allora
a
successivamente ci deve essere l’attivit` B e tra due esecuzioni di A ci
a
deve essere almeno un B . In pratica la seq uenza [A, B, C, A, B] rispetta
la regola.

L’A lternate Precedence ` simile alla precedente, ma con vincolo di
e
precedenza anzich` di successione: ogni esecuzione di B deve essere
e


Figura 4 .11: Alternate Response.

preceduta da A, e tra due esecuzioni di B ci deve essere almeno un A.
U n esempio di seq uenza che soddisfa q uesti req uisiti ` [A, B, A, C, B].
e

Figura 4 .12: Alternate Precedence.

L’ A lternate Succession speciﬁ ca una situzione in cui si veriﬁ cano con-
temporaneamente le due formule precedenti.

Figura 4 .13: Alternate Succession.

M utual Sub stitution :
V iene usata per indicare che ci si aspetta l’esecuzione di almeno una
delle due attivit` .
a

4 .3 F ormule di negazione 49

Figura 4 .14 : Mutual Substitution.

4 .3 F ormule di negazione
Le formule di negazione sono praticamente la negazione delle precedenti.
D i seguito vengono fornite le rappresentazioni graﬁ che seguite dalle interpre-
tazioni testuali delle formule:

Responded A b sence :
Indica che se ` presente l’attivit` A, allora non deve essere presente
e a
l’attivit` B .
a

Figura 4 .15: Responded Absence.

Negation Response :
Aﬀ erma che se ` presente l’attivit` A, non deve essere seguita dall’at-
e a
tivit` B .
a

Figura 4 .16 : N egation Response.


Negation P recedence :
Se ` presente l’attivit` B , non deve essere preceduta dall’attivit` A.
e a a

Figura 4 .17: N egation Precedence.

Negation Succession :
E’ l’unione delle due formule precedenti: A non deve essere seguita da
B , e B non deve essere preceduto da A.

Figura 4 .18: N egation Succession.

Not Co-ex istence :
Indica che se ` presente una delle due attivit` A o B , allora non deve
e a
essere presente l’altra.

Figura 4 .19: N ot Co-ex istence.

Negation A lternate Response :
Se viene eseguita A, allora tra un’esecuzione di A e la sua successiva
non pu` essere presente B .
o

4 .4 F ormule con l’attrib uto chain 51

Figura 4 .20: N egation Alternate Response.

Negation A lternate P recedence :
Se viene eseguita A, non pu` essere presente un B tra q uesta e la
o
precedente esecuzione di A.

Figura 4 .21: N egation Alternate Precedence.

Negation A lternate Succession :
Richiede che siano soddisfatte entrambe le condizioni precedenti.

Figura 4 .22: N egation Alternate Succession.

4 .4 F ormule con l’attrib uto chain

Al set di base di formule deﬁ nite precedentemente sono da aggiungere
formule simili ma legate da una caratteristica in pi` , che potremmo chiamare
u
concatenazione: q uesta attributo sta ad indicare lo stretto legame temporale


esistente tra due attivit` che si presentano una di seguito all’altra. D i seguito
a
vengono fornite le rappresentazioni graﬁ che e le interpretazione testuale di
q ueste formule:

Ch ain Response :
Se viene eseguita A, l’attivit` immediatamente successiva ` B .
a e

Figura 4 .23: Chain Response.

Ch ain P recedence :
Se ` presente A, l’attivit` immediatamente precedente ` B .
e a e

Figura 4 .24 : Chain Precedence.

Ch ain Succession :
E’ l’insieme delle due precedenti: l’attivit` immediatamente successiva
a

Figura 4 .25: Chain Succession.

ad ogni A ` B , e l’attivit` immediatamente precedente a B deve essere
e a
A.

4 .4 F ormule con l’attrib uto chain 53

Negation Ch ain Response :
Se ` presente l’attivit` A, l’attivit` immediatamente successiva non `
e a a e
B.

Figura 4 .26 : N egation Chain Response.

Negation Ch ain P recedence :
Se ` presente l’attivit` A, l’attivit` immediatamente precedente non `
e a a e
B.

Figura 4 .27: N egation Chain Precedence.

Negation Ch ain Succession :
Se ` presente l’attivit` A, l’attivit` immediatamente successiva non `
e a a e

Figura 4 .28: N egation Chain Succession.

B e l’attivit` immediatamente precedente ad ogni B non ` A.
a e


4 .5 T raduzione D ecSerF low - SCIF F
Come emerge dalla descrizione del paragrafo precedente, le regole D ecSer-
Flow sono facilmente esprimibili nella sintassi SCIFF descritta nel paragrafo
3.4 . I vincoli D ecSerFlow sono pi` semplici di q uelli realizzabili in SCIFF,
u
in q uanto esprimono legami tra due attivit` e risultano sicuramente molto
a
utili nei casi in cui sono richieste relazioni binarie, come ad esempio relazioni
di seq uenzialit` tra le attivit` . Si ` dunq ue individuato un gruppo di for-
a a e
mule SCIFF facilmente traducibili in D ecSerFlow , in modo da realizzare un
sistema, chiamato D ecMiner, in grado di generare regole binarie SCIFF e
rappresentarle automaticamente in D ecSerFlow . Le funzionalit` di q uesto
a
sistema saranno illustrate nel capitolo successivo.

Capitolo 5

D ecM iner

N ei capitoli precedenti si ` evidenziata la necessit` di tecniche dichia-
e a
rative di Process Mining tali da off rire un ambiente facilmente fruibile e
comprensibile anche dai non esperti della logica dichiarativa, come possono
essere manager e analisti dei processi di business che generalmente utilizzano
i risultati derivanti dal Process Mining. Sono state esaminate le caratteristi-
che di due linguaggi: SCIFF, che, tramite l’algoritmo ICL, off re la possibilit`
a
di rappresentare regole esistenti tra due o pi` attivit` di un processo e D ec-
u a
SerFlow , linguaggio dichiarativo con rappresentazione grafi ca, in grado di
esprimere relazioni binarie tra le attivit` .
a
Il framew ork ProM consente la creazione e l’integrazione di plug-in per il
Process Mining. All’interno di q uesto framew ork ` stato sviluppato il plug-in
e
D ecMiner per l’estrazione di regole SCIFF e traduzione grafi ca in D ecSer-
Flow . In q uesto capitolo verranno analizzate le specifi che di q uesta traduzione
e la loro applicazione all’interno del framew ork ProM.

55

56 5 . D ecM iner

5 .1 T raduzione SCIF F - D ecSerF low
I linguaggi SCIFF e D ecSerFlow esaminati in precedenza presentano ca-
ratteristiche molto simili in q uanto entrambi sono modellati su attivit` in-
a
tese come unit` atomiche e vincoli tra di esse. Per tradurre in SCIFF i
a
vincoli D ecSerFlow un’attivit` a viene mappata in un evento performed(a),
a
e q uindi il suo veriﬁ carsi viene descritto attraverso la sintassi SCIFF come:
H(performed(a),T) dove T indica il tempo in cui a si ` veriﬁ cata. In q uesto
e
modo, vista la semplicit` dei due linguaggi, risulta molto agevole tradurre
a
le regole D ecSerFlow in linguaggio SCIFF. Q ui di seguito viene mostrata la
corrispondenza dei vincoli D ecSerFlow con la sintassi SCIFF.

F ormule di E sistenza

E x istence N :
N
→ i= 1 E(pe r f o r m e d(a), Ti ) ∧ Ti > Ti−1

A b sence N :
N
i= 1 H(pe r f o r m e d(a), Ti ) ∧ Ti > Ti−1
→ EN (pe r f o r m e d(a), T )∧ > TN

E x actly N :
e xis te nce N (a) ∧ abs e nce N (a)

F ormule di Relazione

Responded ex istence :
H(pe r f o r m e d(a), Ta ) → E(pe r f o r m e d(b), Tb )

Coex istence :
e xis te nce (a) ∧ e xis te nce (b)

5 .1 T raduzione SCIF F - D ecSerF low 57

Response :
H(pe r f o r m e d(a), Ta ) E(pe r f o r m e d(b), Tb ) ∧ Tb > Ta

P recedence :
H(pe r f o r m e d(b), Tb )
→ E(pe r f o r m e d(a), Ta ) ∧ Ta < Tb

Succession :
r e s po ns e (a, b) ∧ pr e ce de nce (a, b)

A lternate response :
H(pe r f o r m e d(a), Ta )
→ E(pe r f o r m e d(b), Tb ) ∧ Tb > Ta
∧EN (pe r f o r m e d(a), Ta2 ) ∧ Ta2 > Ta ∧ Ta2 < Tb

A lternate precedence :
∧EN (pe r f o r m e d(b), Tb2 ) ∧ Tb2 > Ta ∧ Tb2 < Tb

A lternate succession :
alte r nate r e s po ns e (a, b) ∧ alte r nate s u cce s s io n(a, b)

M utual sub stitution :
→ E(pe r f o r m e d(a), Ta ) ∨ E(pe r f o r m e d(b), Tb )

F ormule di Negazione

Responded ab sence :
H(pe r f o r m e d(a), Ta ) → EN (pe r f o r m e d(b), Tb )

58 5 . D ecM iner

Not co-ex istence :
H(pe r f o r m e d(b), Tb ) → EN (pe r f o r m e d(a), Ta )

Negation response :
→ EN (pe r f o r m e d(b), Tb ) ∧ Tb > Ta

Negation precedence :
→ EN (pe r f o r m e d(a), Ta ) ∧ Ta < Tb

Negation succession :
ne g atio n r e s po ns e (a, b) ∧ne g atio n pr e ce de nce (a, b)

Negation alternate response :
∧H(pe r f o r m e d(b), Tb ) ∧ Tb > Ta
→ EN (pe r f o r m e d(a), Ta2 ) ∧ Ta2 > Tb

Negation alternate precedence :
∧H(pe r f o r m e d(a), Ta ) ∧ Ta < Tb
→ EN (pe r f o r m e d(b), Tb2 ) ∧ Tb2 < Tb

Negation alternate succession :
ne g atio n alte r nate r e s po ns e (a, b)∧ne g atio n alte r nate s u cce s s io n(a, b)

F ormule con l’attrib uto ch ain

Il concetto di concatenazione tra due attivit` , cio` il fatto che un’attivit`
a e a
sia eseguita immediatamente dopo l’altra, pu` essere tradotto introducendo
o

5 .1 T raduzione SCIF F - D ecSerF low 59

un’altra attivit` x per poter specifi care che tra le due attivit` non ne deve es-
a a
sere presente un’altra di diverso tipo. Ci` vuol dire che nella Chain Response
o
tra a e b ` necessario specifi care che dopo l’esecuzione di a deve essere ese-
e
guita b e tra le due non deve esserci un’altra attivit` x. Allo stesso modo nel
a
vincolo N egation Chain Response tra a e b ` necessario specifi care che dopo
e
a,prima che venga eseguita b, deve esserci necessariamente un’attivit` x.
a

Ch ain response :
→ E(pe r f o r m e d(b), Tb ) ∧ Tb > Ta
∧EN (pe r f o r m e d(x), T ) ∧ T > Ta ∧ T < Tb

Ch ain precedence :
∧EN (pe r f o r m e d(x), T ) ∧ T > Ta ∧ T < Tb

Ch ain succession :
chain r e s po ns e (a, b) ∧ chain s u cce s s io n(a, b)

Negation ch ain response :
→ E(pe r f o r m e d(x), Tx ) ∧ Tx > Ta
∧EN (pe r f o r m e d(y), Ty ) ∧ Ty > Ta ∧ Ty < Tx
∧x = b
∨EN (pe r f o r m e d(x), Tx ) ∧ Tx > Ta

60 5 . D ecM iner

Negation ch ain precedence :
→ E(pe r f o r m e d(x), Tx ) ∧ Tx < Tb
∧EN (pe r f o r m e d(y), Ty ) ∧ Ty > Tx ∧ Ty < Tb
∧x = a
∨EN (pe r f o r m e d(x), Tx ) ∧ Tx < Tb

Negation ch ain succession :
ne g atio n chain r e s po ns e (a, b) ∧ ne g atio n chain s u cce s s io n(a, b)

E’ da specifi care, tuttavia, che in un sistema in cui il tempo T ` discre-
e
tizzato, un vincolo di concatenazione ` dato anche dal caso in cui Ta sia
e
l’elemento immediatamente successivo (o immediatamente precedente) a Ta
nel dominio di tempo discreto.
ProM, leggendo i timestamps delle attivit` , assegna automaticamente un
a
valore intero al tempo T in modo seq uenziale, per cui se b ` l’attivit` im-
e a
mediatamente successiva ad a, Tb = Ta + 1. La formulazione della chain
response risulta semplifi cata nel seguente modo:

Ch ain response :
→ E(pe r f o r m e d(b), Tb ) ∧ Tb = Ta + 1

Allo stesso modo ` possibile semplifi care, all’interno di ProM, le altre formule
e
di tipo chain.

5 .2 Req uisiti di D ecM iner
ProM ` un framew ork che off re un valido supporto per le tecniche di
e
Process Mining tramite un sistema di integrazione di plug-in. La possibilit`
a

5 .2 Req uisiti di D ecM iner 61

di creare plug-in e integrarli nel sistema consente agli sviluppatori di fruire
della piattaforma preesistente, che fornisce alcune funzionalit` di base come
a
l’accesso al fi le di log, la sua interpretazione e la gestione delle classifi cazioni,
evitando agli sviluppatori di dover implementare funzioni di basso livello.
La scelta di sviluppare D ecMiner (Declarative M iner ) come plug-in nel
framew ork ProM, presenta sicuramente grossi vantaggi: permette non soltan-
to di utilizzare l’interfaccia del programma, ma soprattutto di sfruttare la
potenza di Prolog per la ricerca del modello evitando all’utente di dover
utilizzare direttamente il motore Prolog per fornire o modifi care i dati di
ingresso.
D ecMiner ` stato progettato con i seguenti req uisiti:
e

• leggere le istanze direttamente da un fi le di log;

• classifi care le istanze suddividendole tra positive e negative: le istan-
ze possono essere gi` classifi cate inserendo un valore di yes o no per
a
l’attributo conformant di ogni istanza nel fi le MX ML. In q uesto modo
ProM classifi cher` automaticamente le istanze. In ogni caso dall’inter-
a
no del programma ` possibile modifi carne la classifi cazione;
e

• scegliere q uali attivit` e q uali attributi devono essere tenute in conside-
a
razione durante la fase di apprendimento, in modo da poter eff ettuare
l’apprendimento in base alle attivit` pi` utili e signifi cative .
a u

• modifi care alcuni parametri usati dall’algoritmo di apprendimento, tra
cui l’accuratezza minima valida per l’estrazione di una regola, la di-
mensione massima del beam, il numero minimo di esempi negativi che
devono essere esclusi da una regola e il numero massimo di nodi di
ricerca;

62 5 . D ecM iner

• scegliere i templati da utilizzare per la ricerca. Q uesto consente di
scegliere soltanto q uei template che si ritengono eventualmente pi`
u
idonei o signifi cativi per rappresentare i processi.

Figura 5.1: Ciclo di Process Mining con D ecMiner.

5 .3 Struttura di D ecM iner
Le procedure per l’apprendimento, discusse fi nora, sono state realizzate in
D ecMiner nel fi le ICL .pl, che implementa l’algoritmo ICL tramite funzioni di
programmazione logica: ICL testa le relazioni scelte e se una relazione elimina
almeno una traccia negativa e tutte o la maggior parte di istanze positive
(q uesti parametri devono essere tali da rendere l’euristica superiore ad una
soglia prefi ssata), la regola viene aggiunta alla lista di clausola trovate, mentre
vengono eliminate le tracce negative che la regola esclude. L’apprendimento
termina q uando sono state eliminate tutte le tracce negative o q uando non
ci sono pi` regole da testare.
u

5 .3 Struttura di D ecM iner 63

ProM legge il fi le di log .MX ML e all’avvio del processo di apprendimento
genera dei fi le contenenti i dati relativi alle tracce e utilizzati da ICL .pl :

datasetF orICL.b g : ` un fi le gi` presente nei sorgenti di D ecMiner e con-
e a
tiene la background knowledge di SCIFF, conoscenza valida per ogni
apprendimento;

datasetF orICL.k b : contiene la knowledge base relativa al dominio, cio`
e
tutte le tracce con le attivit` e i relativi attributi;
a

datasetF orICL.l : contiene il language bias dei template scelti dall’utente
e viene utilizzato dalla funzione di apprendimento per eff ettuare il raf-
fi namento. Come anticipato nel paragrafo 3.7.1, la struttura dei tem-
plate, composti da una coppia (BS, HS), pu` essere di q uattro tipi:
o
B S e H S possono essere dichiarati fixed o dynamic. N el caso di ap-
prendimento di vincoli D ecSerFlow ProM genera automaticamente il
fi le datasetF orICL .l sulla base delle attivit` e dei template selezionate
a
dall’utente, utilizzando un template di tipo (fixed,fixed ).
Per utilizzare un language bias con template di tipo (dynamic, dyna-
mic) attualmente non ci sono mezzi o interfacce grafi che automatiche,
per cui ` necessario creare manualmente il fi le sulla base di q uanto
e
spiegato nel paragrafo 3.7.1.

Se si usa un template di tipo (fixed, fixed) il fi le DecParser.pl, converte
automaticamente le regole estratte tramite ICL nella rappresenzione grafi ca
del linguaggio D ecSerFlow .

64 5 . D ecM iner

Figura 5.2: File del sistema D ecMiner.

5 .4 U so e applicazione in P roM

ProM legge automaticamente il fi le di log .MX ML in cui sono memo-
rizzate le tracce secondo la sintassi di un fi le .X ML descritta nel paragrafo
1.6 . Come gi` detto in precedenza gli stati in cui si pu` trovare un’attivit`
a o a
sono diversi a seconda che il processo sia appena iniziato, pronto, sospeso,
terminato in condizioni normali o anomale. A diff erenza di q uanto speci-
fi cato nel paragrafo 1.6 ProM off re la possibilit` di specifi care 13 diff erenti
a
stati: schedule, assign, reassign, withdraw, start, suspend, resume, complete,
caseabort, istanceabort, manskip, autoskip, unknown, le cui fasi di transizione
sono mostrate in fi g.5.3.
Se il log aperto non ` classifi cato ` necessario procedere manualmente alla
e e
classifi cazione. Prima di lanciare il processo di apprendimento ` necessario:
e

• selezionare i templati da usare;

• defi nire i parametri di minima dimensione del B eam, massimo nu-
mero di nodi e accuratezza dell’apprendimento. Per q uesti parametri,
q ualora non vengano settati, saranno utilizzati parametri di default.

5 .4 U so e applicazione in P roM 65

Figura 5.3: Stati degli eventi in ProM.

I risultati vengono memorizzati nel ﬁ le datasetF orICL .icl.out, che mostra
le regole apprese, l’accuratezza di ogni regola, il numero di tracce positive
che la regola copre e il numero di tracce negative che la regola elimina. Au-
tomaticamente viene anche generato la rappresentazione graﬁ ca dei risultati
ottenuti.
N el capitolo successivo vedremo l’applicazione pratica di q uesti strumenti su
un insieme di informazioni provenienti da un database di dati reali.

Capitolo 6

E sperimenti

Le tecniche e i procedimenti di apprendimento, implementati dal plug-in
D ecMiner, sono stati testati su un dataset di studenti, contenente le infor-
mazioni relative alla carriera universitaria. In q uesto capitolo vedremo il
procedimento usato per eff ettuare il Process Mining sui dati, partendo dal-
l’analisi dei dati in q uestione e terminando con la valutazione dei risultati
ottenuti.

6 .1 A nalisi dei dati e creazione del fi le di log

I dati su cui si vogliono eff ettuare gli esperimenti sono q uelli degli studenti
iscritti alla facolt` di Ingegneria, Corso di Laurea in Informatica dell’U niver-
a
sit` di B ologna dal 2001 al 2007. G li studenti presenti nel database sono
a
1229. Q uelli che hanno terminato la carriera, con esito positivo o negativo,
sono in tutto 579. E’ possibile classifi care soltanto q ueste ultimi, per cui
le analisi eff ettuate prenderanno in considerazione solo i casi di cui si ha la
carriera completa.
I dati a disposizione sono i seguenti :

67

68 6 . E sperimenti

D ati anagrafi ci : anno nascita,provincia residenza, nazione residenza, tipo
scuola, anno diploma, voto diploma, lode(SI/ N O );

D ati relativ i alle iscrizioni eff ettuate : carriera, anno accademico, anno
di corso (1-2-3), ripetente (SI/ N O );

F ine carriera : carriera, causale fi ne, data fi ne, voto laurea (se la carriera
` terminata con la laurea), lode(SI/ N O );
e

E sami sostenuti : carriera dello studente, codice materia, nome materia,
data esame, voto, lode.

D a q uesti dati, forniti in formato Ex cel, ` stato generato un fi le MX ML
e
contenente le tracce relative alle carriere degli studenti: per ogni studente `
e
stata creata una ProcessInstance alla q uale ` possibile assegnare i seguenti
e
A uditTrail :

T rasferimento : evento presente nei casi di studenti provenienti da altre
U niversit` , Facolt` o altri Corsi di Laurea;
a a

D ati anagrafi ci : anno nascita, provincia residenza (B ologna/ Fuori B ologna),
nazione residenza (Italia/ Estero), tipo scuola (Licei, Istituti T ecnici,
Istituti Superiori stranieri, altro, non specifi cato), anno diploma, voto
diploma (suddiviso per categoria : alto , medio, basso), lode (SI/ N O );

Immatricolazione e Iscrizione : un A uditTrail per ogni anno di iscrizione
con attributi : anno accademico, anno di corso (1,2,3), ripetente anno
(SI/ N O );

F ine carriera : causale fi ne (Laurea, T rasferimento, Passaggio ad altro cor-
so, Rinuncia, altro), data fi ne, voto laurea (se la carrierea termina con

6 .2 Stati delle attiv it` e T imestamps
a 69

la laurea, altrimenti ` considerato nullo), lode (SI/ N O ), categoria vo-
e
to di laurea (basso se inferiore al 90, medio se inferiore a 100, alto se
superiore a 100);

E sami : un A uditTrail per ogni esame con attibuti : codice materia, nome
materia, data registrazione, voto convalidato (SI/ N O ), categoria voto
(alto se superiore a 26 , medio se compreso tra 23 e 26 , basso se inferiore
a 23, altro nei casi di idoneit` o di convalide in cui non risulta il voto).
a

A pag. 70 viene riportato a titolo di esempio parte del fi le .mx ml in cui
viene descritta una Process Instance.

6 .2 Stati delle attiv it` e T imestamps
a
N elle attivit` considerate, come gli esami o le iscrizioni degli studenti,
a
ovviamente non ha senso defi nire fasi di transizione dell’attivit` , considerato
a
anche il fatto che i dati memorizzati dalle segreterie sono q uelli relativi a uno
stato completo delle attivit` . Le attivit` , q uindi, sono state considerate tutte
a a
nello stato complete per indicare che ` stata eseguita e terminata un’attivit` .
e a
Per l’assegnazione di un timestamp ad un A uditTrail si ` utilizzato il campo
e
data presente tra gli attributi dell’A uditTrail. Il tool ProM sulla base dei
timestamps presenti nelle attivit` ordina gli eventi in modo seq uenziale, come
a
mostrato in fi g. 6 .1

70 6 . E sperimenti

−−−−−File M X M L ch e d e sc riv e la P ro c e ss Insta nc e −−−−−

<P ro c e ssInsta nc e id = ” 58 1−−− 1” d e sc rip tio n= ” c a rrie ra stu d e nte ” >
<Da ta >
<Attrib u te na m e = ” Co nfo rm a nt” >Y e s</Attrib u te >
</Da ta >
<Au d itT ra ilEntry >
<Da ta >
<Attrib u te na m e = ” a nno im m a tric o la z io ne ” >20 0 2</Attrib u te >
<Attrib u te na m e = ” a nno 1” >1</Attrib u te >
</Da ta >
<W o rk fl o w M o d e lEle m e nt>im m a tric o la z io ne </W o rk fl o w M o d e lEle m e nt>
<Ev e ntT y p e >c o m p le te </Ev e ntT y p e >
<T im e sta m p >20 0 2−0 9 −0 2T 0 0 :0 0 :0 0 .0 0 0 + 0 1:0 0 </T im e sta m p >
</Au d itT ra ilEntry >
<Da ta >
<Attrib u te na m e = ” P INCO DE” >58 1−−−</Attrib u te >
<Attrib u te na m e = ” a nno na sc ita ” >19 8 3</Attrib u te >
<Attrib u te na m e = ” p ro v inc ia re sid ” >Fu o ri BO </Attrib u te >
<Attrib u te na m e = ” sta to re sid e nz a ” >IT AL IA</Attrib u te >
<Attrib u te na m e = ” tip o m a tu rita ” >L ic e o </Attrib u te >
<Attrib u te na m e = ” a nno m a tu rita ” >20 0 2</Attrib u te >
<Attrib u te na m e = ” v o to m a tu rita ” >a lto </Attrib u te >
</Da ta >
<W o rk fl o w M o d e lEle m e nt>d a ti m a tric o la </W o rk fl o w M o d e lEle m e nt>
<Da ta >
<Attrib u te na m e = ” a nno ” >2</Attrib u te >
<Attrib u te na m e = ” a nno a c c a d e m ic o ” >20 0 3</Attrib u te >
<Attrib u te na m e = ” rip e te nte ” >N</Attrib u te >
</Da ta >
<W o rk fl o w M o d e lEle m e nt>isc riz io ne </W o rk fl o w M o d e lEle m e nt>

Applicazioni intelligenzaartificiale

Applicazioni intelligenzaartificiale

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (20)

Similar to Applicazioni intelligenzaartificiale

Similar to Applicazioni intelligenzaartificiale (20)

Applicazioni intelligenzaartificiale