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

Conformance related objects

ConformanceModel

ConformanceModel properties	Description
Id (Integer)	Returns an unique id for the conformance model. New random id is always assigned to the conformance model object when creating a new conformance model object.
EndEvents (ConformanceModelEvent*)	Returns an array of all the top-level end event objects (##) in the model.
Flows	Returns an array of all the top-level flow objects (##) in the model.
Nodes	Returns an array of all the top-level nodes in the model.
StartEvents (ConformanceModelEvent*)	Returns an array of all the top-level start events in the model.

ConformanceModelFlow

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

ConformanceModelNode

This object type is an abstract type defining common properties and functions available for all its sub-types.

ConformanceModelFlow properties	Description
Id (Integer)	Id of the node.
IncomingFlows	Array of incoming flows (flows whose To -property equals this node).
Name (String)	Name of the node.
OutgoingFlows	Array of outgoing flows (flows whose From -property equals this object).
Type	1. Type of the node. Supported values are: 1.1. Event 1.2. Task 1.3. Gateway

ConformanceModelEvent

ConformanceModelEvent objects inherit all the properties from ConformanceModelNode -object (#34175#). 2. In addition to these inherited properties and functions, the child requirements of this requirement describe properties and functions available for this object type only.

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

ConformanceModelGateway

ConformanceModelGateway objects inherit all the properties from ConformanceModelNode. In addition to these inherited properties and functions, the child requirements of this requirement describe properties and functions available for this object type only.

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

ConformanceModelTask

ConformanceModelTask objects inherit all the properties from ConformanceModelNode. In addition to these inherited properties and functions, the child requirements of this requirement describe properties and functions available for this object type only.

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