Conformance Checking
This functionality is available in QPR ProcessAnalyzer 2018.3.
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.
There are functions AnalyzeConformance and IsConformant available for Case and Variation objects. The IsConformant return true or false depending whether the Case or Variation is conformant or not with theh provided ConformanceModel. 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:
- 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.
Identified 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
When creating a design model from a BPMN XML file (http://www.omg.org/spec/BPMN/2.0/), the following BPMN elements are supported.
Element type | Supported subtypes | Supported attributes |
---|---|---|
Flow |
|
|
Events |
|
|
Tasks |
|
Supported sub-entities:
|
Gateway |
|
id |
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. |