Conformance Checking

# 프로세스 모델과 로그의 관계
1) play-out: 모델이 로그를 생성
2) play-in: 로그로부터 모델을 생성
3) replay: 로그와 프로세스 모델 활용, 로그가 모델에서 replay됨으로써 다양한 현상 분석

---

Conformance Checking

# Conformance Checking의 목적
프로세스 모델의 자취와 로그의 자취를 비교함으로써 공통점과 차이점을 파악
전체적인 비교 결과 수치 뿐만 아니라 세부적인 차이 파악에 활용
- 부정사례 발견!
- 데이터 평가: 로그에 기록된 현실이 모델이 부합하는지
- 모델 평가 : 모델이 현실에 부합하는지 확인

# 로그와 모델의 비매칭의 결과 해석
* 서술적(모델 관점) : 모델이 현실을 더 파악하기 위해 향상될 필요가 있다는 것을 의미 

Descriptive : 로그가 정답 (즉, 모델이 모든 로그를 설명하지 못해 문제가 있다.)


* 규범적(로그 관점) : 프로세스 자체의 컨트롤 부족, 작업자들이 고객에게 더 나은 행동을 제공하기 위해 모델을 따르지 않음
Normative : 모델이 정답 (즉, 로그의 일부가 모델을 따르지 않아 문제가 있다.)




# 차이를 파악하는 두 가지 관점 (전제: 모델과 현실에 차이 발생)
- 모델이 현실을 반영하지 않음 (어떻게 개선?)
- 로그의 행동이 모델을 따르지 않는 다는 것 (어떻게 케이스가 따르게 할 것인지?)

*** Token replay를 통해 fitness를 수치화하자!

 

---

naive approach : 해당 traces가 모델 자체에서 설명이 가능한지를 테스트 -> 실제 프로세스에서는 잘 맞지 않음 -> 하나의 place가 추가로 생성되면 기존에 높은 정확도를 가지고 있던 모델도 fitness가 낮아짐 -> 전체 trace가 아닌 이벤트 레벨의 접근 방법이 필요

Token Replay : 이벤트 레벨의 접근 방법 -> 로그에 있는 정보를 모델에 하나씩 매핑하는 것 의미
(P, C, M, R)

* 장점
- 세부적으로 어떤 부분이 문제인지 확인 가능(R, M의 빈도수)
- NAIVE보다는 정확도가 높음 (이벤트 레벨의 접근 방식이기 때문)

 

* 한계 

- 전반적으로 적합도 수치가 높음 (하나의 한계점이 될 수도, 다른 모델과 비교 애매)

- 페트리넷 의존적인 방법이며, 다른 모델에서는 변환 후 활용해야 함

- 해당 케이스의 모델을 통한 해당 경로를 나타내주지 않음 (최적 경로를 알려주지 않음, 어떤 부분이 문제인지만 알려줌)

 

 

 

---

 

Alignments

- 최적의 alignments : 주어진 trace와 모델의 가장 적합한 일치 형태

- 어느 부분이 문제인지 알 수 있음

 

# 적절한 alignments 찾는 방법- synchronous move : replay가능, 비용발생하지 않음- move on log, move on model에 비용 부과 : cost가 가장 낮은 모델이 좋은 모델

 

# 적합도 계산- 가장 나쁜 alignments의 비용, 최적 alignments의 비용을 바탕으로 적합도 산출

 

 

---

Comparing Footprints

선후행 관계표를 활용한 적합도 계산- 모델 및 로그로부터 선후행 관계표 도출- 두 선후행 관계표를 비교하여 차이를 수치화함