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 Checking Settings

The following settings are supported by the conformance checking, affecting how the conformance checking works:

• IgnoreEventTypesMissingInModel: Boolean value to configure whether the check should ignore any EventTypes that are present in the Case or Variation but not in the design model. Default value is true. When true, unknown EventTypes are filtered out before performing conformance check.
• IgnoreIncompleteCases: Boolean value to configure whether the check should count unfinished Cases or Variations as conformance violations. Default value is false. When false, incomplete Cases or Variations are counted as nonconformant.

Conformance Checking Reasons for Nonconformance

The following reasons for nonconformance are identified for a nonconforming Case or Variation. The conformance checking may identify several reasons for a single Case or Variation.

• InvalidEventType: Occurs when the tested Case or Variation has EventType names that do not exist in the design model (EventType names should match with the design model task names). This nonconformance reason can be ignored using the IgnoreEventTypesMissingInModel setting. 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 EventType names not found in the model that exist in the object being checked. Corresponding numerical value 1.
• NotCompleted: Occurs when the Case or Variation ends (the last Event is reached), but according to the compared design model, the Case or Variation should continue, i.e. the end event in the design model is not reached. Checking of this nonconformance reason can be ignored using the IgnoreIncompleteCases setting. For this nonconformance reason, there is no additional information. Corresponding numerical value 2.
• InvalidStateChange: InvalidStateChange nonconformance occurs when the event sequence in a Case is not possible according to the design model due to missing connections between successive tasks. Corresponding numerical value 3. 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 EventType name that was not possible to reach in the design model.
  • Name of the previous EventType or null if this was the first event type name in the Case or Variation.
  • Name of the nonconformant EventType.

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 and ConformanceModelTask.

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 ConformanceModelFlows to this ConformanceModelNode.
Name (String)	Name of the node.
OutgoingFlows (ConformanceModelFlow*)	Array of outgoing ConformanceModelFlows to this ConformanceModelNode.
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.