Conformance Checking

1. Conformance is tested for a specific event log object separately starting from each start event in the BPMN model. 1.1. If conformance check succeeds from any start event, the conformance check succeeds. 2. A sequence of event type names is extracted from the object to be checked (I.e., Case or Variation). 3. If IgnoreEventTypesMissingInModel (#34204#) is false and the sequence of event type names contains event type names that don't have similarly named tasks in the conformance model, the path does not conform with the model. 3.1. InvalidEventType (#34211#) will be added as nonconformance reason. 4. A new empty conformance model run-time state is initialized with the start event. 5. This sequence is then traversed one event type name at a time as follows: 5.1. If event type does not exist in the model and IgnoreEventTypesMissingInModel (#34204#) -property is set to be true, move to the next event type name and go to 5.1. 5.2. Based on the run-time state, find next BPMN task whose name matches with the event type name. 5.2.1. 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. 5.2.2. If such a task is not found, the tested event log object does not conform with the model. 5.2.2.1. InvalidStateChange (#34212#) will be added as nonconformance reason. 6. After the iteration, if IgnoreIncompleteCases (#34205#) 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. 6.1. NotCompleted (#34213#) 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.

IgnoreEventTypesMissingInModel 1. Boolean parameter used to configure whether the check should ignore any event types that are present in the variation but not in the model. 2. Default value = true (unknown event types are filtered automatically before performing conformance check)

IgnoreIncompleteCases 1. Boolean parameter used to configure whether the check should count unfinished variations as conformance violations. 2. Default value = false (incomplete variation is counted as nonconformant).

InvalidEventType 1. InvalidEventType (=1) nonconformance occurs when the tested event type name sequence has event type names that do not exist as similarly named tasks in the BPMN conformance model. 1.1. This nonconformance reason can be ignored using IgnoreEventTypesMissingInModel (#34204#) parameter. 2. As additional information for this type of nonconformance, an array having the following elements will be added after the reason identifier: 2.1. An array of all the invalid event type names not found in the model that exist in the object being checked.

InvalidStateChange 1. InvalidStateChange (=3) nonconformance occurs when the tested event type name sequence is not possible according to the BPMN conformance model due to missing connections between successive tasks. 2. As additional information for this type of nonconformance, an array having the following elements will be added after the reason identifier: 2.1. Index of the first event type name that was not possible to reach in the BPMN conformance model. 2.2. Name of the previous event type or null if this was the first event type name in the sequence. 2.3. Name of the failed event type.

NotCompleted 1. 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 BPMN conformance model. 1.1. This nonconformance reason can be ignored using IgnoreIncompleteCases (#34205#) parameter. 2. In this case, there is no additional information.

Supported BPMN Elements and Attributes 1. Flows: 1.1. Supported attributes: id, sourceRef, targetRef 1.2. sequenceFlow 2. Events: 2.1. Supported attributes: id 2.2. startEvent 2.3. endEvent 3. Tasks: 3.1. Supported attributes: 3.1.1. id, name 3.2. Supported sub-entities: 3.2.1. standardLoopCharacteristics, multiInstanceLoopCharacteristics (with and without isSequential attribute) 3.3. sendTask 3.4. receiveTask 3.5. userTask 3.6. manualTask 3.7. businessRuleTask 3.8. serviceTask 3.9. scriptTask 4. Gateways: 4.1. Supported attributes: 4.1.1. id 4.2. parallelGateway 4.3. exclusiveGateway 4.4. inclusiveGateway