Introduction to Conformance Checking
The conformance checking functionality compares the QPR ProcessAnalyzer process mining model with a design model defined using BPMN. In the process mining model, conformance can be tested for Cases or Variations. Each Case or Variation is either considered as conformant or nonconformant. For nonconformant Case or Variation, the conformance checking is also able to identify one or several reasons for the nonconformance. For example the Case or Variation might contain EventTypes that are not in the design model, or the sequence of Events doesn't correspond with the defined sequence in the design model.
The conformance checking calculation is implemented to functions AnalyzeConformance and IsConformant that are available for Case and Variation objects. In addition, the design model needs to be provided as a parameter for the functions. IsConformant function returns true or false depending whether the Case or Variation is conformant or not. AnalyzeConformance function also return reasons for nonconformance for nonconforming Cases or Variations.
There are settings IgnoreEventTypesMissingInModel and IgnoreIncompleteCases which affect how the conformance checking works. 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 is mentioned as a nonconformance reason.
The conformance checking works as follows:
- The sequence of Events in the checked Case or Variation is traversed one Event at a time as follows:
- If the checked EventType does not exist in the design model and IgnoreEventTypesMissingInModel is set to true, move to the next EventType.
- If the checked EventType exists in the design model, find next ConformanceModelTask whose name matches with the EventType name.
- If such ConformanceModelTask is not found, the tested Case or Variation does not conform with the design model. InvalidStateChange is added as a nonconformance reason.
- After the iteration, if IgnoreIncompleteCases is false and the current state in the design is such that any end Event is not reachable without traversing through any additional ConformanceModelTasks, the tested Case or Variation does not conform with the design model. NotCompleted will be added as nonconformance reason.
Conformance Checking Settings
The following settings are supported by the conformance checking, affecting how the conformance checking works:
Defines whether the check should ignore any EventTypes that are present in the Case or Variation but not in the design model. Defined as a boolean value (true or false). Default value is false. When true, unknown EventTypes are filtered out before performing conformance check. Defined as a boolean value (true or false).
Defines whether the check should count unfinished (incomplete) Cases or Variations as conformance violations. Unfinished cases are cases where the last event is reached, but the case should continue to a next event according to the design model. Defined as a boolean value (true or false). Default value is false. When false, incomplete Cases or Variations are counted as nonconformant. When there are pending Cases in the model, it might be useful to set this to true.
Types of Nonconformance Reasons
The following reasons for nonconformance are identified for a nonconforming Cases or Variations. All the InvalidEventType reasons are identified for each Case or Variation, and for the NotCompleted and InvalidStateChange the first encountered reason in the Case or Variation is identified.
|Reason number||Reason name||Description|
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 containing all the invalid EventType names not found in the model that occurs in the Case or Variation.
[1, "Sales order changes", "Customer return", "Invoice cancelled"]
|2||NotCompleted||Occurs when the Case or Variation ends (the last Event is reached), but according to the design model, the Case or Variation should continue. Checking this nonconformance reason can be ignored using the IgnoreIncompleteCases setting. As an additional information, an array having the following elements will be added after the reason identifier:
[2, 3, "Invoice sent"]
Occurs when the event sequence in a Case or Variation is not possible according to flow of tasks described by the DesignModel. When this type of nonconformance reason is detected, the conformance check doesn't continue, so there may be further reasons in the Case causing nonconformance. As an additional information, an array having the following elements will be added after the reason identifier:
[3, 5, "Invoice sent", "Sales order changed"]
Supported BPMN Elements and Attributes
When creating a design model from a BPMN 2.0 XML file (specification: http://www.omg.org/spec/BPMN/2.0/), the below listed elements are supported. If the file contains any other types, an error is caused when trying to create the design model.
|Element type||Supported subtypes||Used attributes||Supported subentities|
Creating Design Model
BPMN 2.0 XML document (String)
In the BPMN 2.0 XML file, the http://www.omg.org/spec/BPMN/20100524/DI section is not used by the function, and thus it can be omitted to reduce transferred data.
Note that the quotation marks need to be escaped if the BPMN 2.0 XML is provided as a literal in the expression.
let myConformanceModel = DesignModelFromXml( "<?xml version=\"1.0\" encoding=\"UTF-8\"?> <bpmn:definitions xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xmlns:bpmn=\"http://www.omg.org/spec/BPMN/20100524/MODEL\" xmlns:bpmndi=\"http://www.omg.org/spec/BPMN/20100524/DI\"> <bpmn:process id=\"Process_1\" isExecutable=\"false\"> <bpmn:startEvent id=\"StartEvent_1\" /> <bpmn:task id=\"Task_0y5w837\" name=\"abc\"> <bpmn:outgoing>SequenceFlow_10mpkws</bpmn:outgoing> </bpmn:task> <bpmn:task id=\"Task_0c16r07\" name=\"def\"> <bpmn:incoming>SequenceFlow_10mpkws</bpmn:incoming> </bpmn:task> <bpmn:sequenceFlow id=\"SequenceFlow_10mpkws\" sourceRef=\"Task_0y5w837\" targetRef=\"Task_0c16r07\" /> </bpmn:process> <bpmndi:BPMNDiagram id=\"BPMNDiagram_1\"> ... </bpmndi:BPMNDiagram> </bpmn:definitions>");
Design Model Objects
The design model is is a specific entity DesignModel in the expression language. There are also entities DesignModelFlow, DesignModelNode, DesignModelEvent, DesignModelGateway and DesignModelTask.
DesignModel is an object representing the whole model consisting of nodes and flows. A new design model can be created from a BPMN 2.0 XML file.
|Id (Integer)||Returns an unique id for the design model. The id is assigned automatically when a new DesignModel is created.|
|EndEvents (DesignModelEvent*)||Returns an array of all the top-level end DesignModelEvents in the design model.|
|Flows (DesignModelFlow*)||Returns an array of all the top-level DesignModelFlows in the design model.|
|Nodes (DesignModelNode*)||Returns an array of all the top-level DesignModelNodes in the design model.|
|StartEvents (DesignModelEvent*)||Returns an array of all the top-level start DesignModelEvents in the design model.|
DesignModelFlow connects two DesignModelNodes, DesignModelGateways or DesignModelEvents in a DesignModel.
|Id (Integer)||Id of the DesignModelFlow.|
|From (DesignModelNode)||Starting node of the DesignModelFlow.|
|To (DesignModelNode)||Ending node of the DesignModelFlow.|
|Type (String)||Type name of the DesignModelFlow SequenceFlow.|
DesignModelNode is an upper level type defining common properties and functions available for its subtypes. Available subtypes are DesignModelEvent, DesignModelGateway and DesignModelTask.
|Id (Integer)||Id of the node. The id is assigned automatically when a new DesignModelNode is created.|
|IncomingFlows (DesignModelFlow*)||Array of incoming DesignModelFlows to this DesignModelNode.|
|Name (String)||Name of the node.|
|OutgoingFlows (DesignModelFlow*)||Array of outgoing DesignModelFlows to this DesignModelNode.|
|Type (String)||Type of the node. Allowed values are Event, Task and Gateway.|
DesignModelEvent represents start and end events. It's inherited from DesignModelNode getting all DesignModelNode's properties and functions.
|EventType (String)||Type of the event. Allowed values are Start and End.|
DesignModelGateway represents a gateway in the DesignModel. It's inherited from DesignModelNode getting all DesignModelNode's properties and functions.
|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.|
DesignModelTask represents tasks/activities in the DesignModel. Corresponding object in the process mining model is EventType. When running conformance analysis, DesignModelTask name is matched with EventType name. DesignModelTask object is inherited from DesignModelNode object, getting all DesignModelNode's properties and functions. In addition, there are the following properties for DesignModelTasks:
|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.|