Conformance Checking

Introduction to Conformance Checking

Conformance is tested for all Cases or Variations in an EventLog separately starting from each start event in the design model. If conformance check succeeds from any start event, the conformance check succeeds. A sequence of event type names is extracted from the object to be checked (i.e., Case or Variation).

If IgnoreEventTypesMissingInModel is false and there are EventTypes in the Case that don't exist in the conformance model (comparing using EventType names), the path does not conform with the model. Then the InvalidEventType will be added as nonconformance reason.

A new empty conformance model run-time state is initialized with the start event. This sequence is then traversed one Event at a time as follows:

• If event type does not exist in the model and IgnoreEventTypesMissingInModel is set to true, move to the next EventType and follow the same step. Based on the run-time state, find next BPMN task whose name matches with the EventType. If such a task is found, update the run-time state to according to the path required to be traversed in order to reach the found task. If such a task is not found, the tested event log object does not conform with the model. InvalidStateChange will be added as nonconformance reason.

After the iteration, if IgnoreIncompleteCases is false and the current run-time state is such that end event is not reachable without traversing through any additional tasks, the tested event log object does not conform with the model. NotCompleted will be added as nonconformance reason.

The conformity of any given case or variation can be checked against a conformance model specified in BPMN notation. Conformance checking functions support the parameters listed in child requirements of this requirement.

Conformance Check Settings

• IgnoreEventTypesMissingInModel: Boolean parameter used to configure whether the check should ignore any event types that are present in the variation but not in the model. Default value is true (unknown event types are filtered automatically before performing conformance check)
• IgnoreIncompleteCases: Boolean parameter used to configure whether the check should count unfinished variations as conformance violations. Default value is false (incomplete variation is counted as nonconformant).

Checked Nonconformance Reasons

The following mentioned reasons for nonconformance are identified for a case if the case is not conformant. The conformance checking may identify several reasons for a single case.

• InvalidEventType: InvalidEventType (=1) nonconformance occurs when the tested EventType name sequence has EventType names that do not exist as similarly named tasks in the design model. This nonconformance reason can be ignored using the IgnoreEventTypesMissingInModel parameter. As an additional information for this type of nonconformance, an array having the following elements will be added after the reason identifier: An array of all the invalid event type names not found in the model that exist in the object being checked.
• NotCompleted: NotCompleted (=2) nonconformance occurs when the model, after replaying the whole event type name sequence extracted from the object being checked, did not end up into a valid end state of the design model. This nonconformance reason can be ignored using IgnoreIncompleteCases parameter. For this nonconformance reason, there is no additional information.
• InvalidStateChange: InvalidStateChange (=3) nonconformance occurs when the event sequence in a Case is not possible according to the design model due to missing connections between successive tasks. As an additional information for this type of nonconformance, an array having the following elements will be added after the reason identifier:
  • Index of the first event type name that was not possible to reach in the design model.
  • Name of the previous event type or null if this was the first event type name in the sequence.
  • Name of the failed event type.

Supported BPMN Elements and Attributes

• Flows:
  • Supported attributes: id, sourceRef, targetRef
  • sequenceFlow
• Events:
  • Supported attributes: id
  • startEvent
  • endEvent
• Tasks:
  • Supported attributes: id, name
  • Supported sub-entities: standardLoopCharacteristics, multiInstanceLoopCharacteristics (with and without isSequential attribute)
  • sendTask
  • receiveTask
  • userTask
  • manualTask
  • businessRuleTask
  • serviceTask
  • scriptTask
• Gateways:
  • Supported attributes: id
  • parallelGateway
  • exclusiveGateway
  • inclusiveGateway

Design Model Objects

The design model is is a specific entity ConformanceModel in the expression language. There are also entities ConformanceModelFlow, ConformanceModelNode, ConformanceModelEvent, ConformanceModelGateway and ConformanceModelTask.

ConformanceModel

ConformanceModel represents the whole design model. A new design model can be created from a BPMN description.

ConformanceModel properties	Description
Id (Integer)	Returns an unique id for the design model. The id is assigned automatically when a new ConformanceModel is created.
EndEvents (ConformanceModelEvent*)	Returns an array of all the top-level end ConformanceModelEvents in the design model.
Flows (ConformanceModelFlows*)	Returns an array of all the top-level ConformanceModelFlows in the design model.
Nodes (ConformanceModelNode*)	Returns an array of all the top-level ConformanceModelNodes in the design model.
StartEvents (ConformanceModelEvent*)	Returns an array of all the top-level start ConformanceModelEvents in the design model.

ConformanceModelFlow

ConformanceModelFlow connects two ConformanceModelNodes, ConformanceModelGateways or ConformanceModelEvents in the design model.

ConformanceModelFlow properties	Description
Id (Integer)	Id of the ConformanceModelFlow.

ConformanceModelNode

ConformanceModelNode is an upper level type defining common properties and functions available for its subtypes. Available subtypes are ConformanceModelEvent, ConformanceModelGateway.

ConformanceModelFlow properties	Description
Id (Integer)	Id of the node. The id is assigned automatically when a new ConformanceModelNode is created.
IncomingFlows (ConformanceModelFlow*)	Array of incoming flows (flows whose To -property equals this node).
Name (String)	Name of the node.
OutgoingFlows (ConformanceModelFlow*)	Array of outgoing flows (flows whose From -property equals this object).
Type (String)	Type of the node. Allowed values are Event, Task and Gateway.

ConformanceModelEvent

ConformanceModelEvent represents BPMN start and end events. It's inherited from ConformanceModelNode getting all ConformanceModelNode's properties and functions.

ConformanceModelEvent properties	Description
EventType (String)	Type of the event. Allowed values are Start and End.

ConformanceModelGateway

ConformanceModelGateway represents a BPMN gateway in the design model. It's inherited from ConformanceModelNode getting all ConformanceModelNode's properties and functions.

ConformanceModelGateway properties	Description
GatewayType (String)	Type of the gateway. Allowed values are Parallel, Exclusive and Inclusive.
BranchType (String)	Branching type of gateway. Allowed values are Fork and Join.

ConformanceModelTask

ConformanceModelTask represents a BPMN task in the design model. Corresponding object in the process mining model is Event. When running conformance analysis, ConformanceModelTask name is matched with EventType name. ConformanceModelTask is inherited from ConformanceModelNode getting all ConformanceModelNode's properties and functions. In addition there are the following properties for ConformanceModelTasks.

ConformanceModelTask properties	Description
LoopType (String)	Type of looping allowed for the task. Allowed values are null (meaning there is no loop), StandardLoopCharacteristics, MultiInstanceLoopCharacteristics and MultiInstanceSequentialLoopCharacteristics.
TaskType (String)	Type of the task. Allowed values are Task, Send, Receive, User, Manual, BusinessRule, Service and Script.