OCBC Conformance Checking Software

This software is used to check the conformance between an XOC log and an OCBC model.

Download Executable JAR (2017.Dec.23)


Next, we briefly introduce how to check conformance between an input log and a reference model using this software. For more details, please refer to the manual.

Download manual

1. Design a reference model

The starting point of checking conformance is that we have logs and reference models. The logs are extracted data generated by our information systems while the reference model could be a designed model which is consistent with the scenario indicated by the information system. Next, we check the conformance in the OTC scenario of the Dolibarr ERP system. The logs are generated by the Dolibarr ERP system in the OTC scenario. Accordingly, we design an OCBC model to represent the normal business process of this scenario as follows.

Model Editor

The model indicates constraints both on behavioral and data perspectives. For instance, as we can see in the model, there is a response constraint from "create_order" activity to "create_shipment" activity which means each "create_order" event should be eventually followed by one or more "create_shipment" events.

2. Check conformance

The conformance checking software support to detect nine types of deivations as follows:

1. Diagnostics for Type I problems (validity of object models): Highlight the □ cardinality constraints that make the object model invalid.

2. Diagnostics for Type II problems (fulfilment): Highlight the ◇ cardinality constraints that do not hold at the end of the log.

3. Diagnostics for Type III problems (monotonicity): Report objects that disappear or change class over time.

4. Diagnostics for Type IV problems (activity existence): List the activities appearing in the log and not in the model and highlight the corresponding events in the event log.

5. Diagnostics for Type V problems (object existence): Highlight all references to non-existing objects.

6. Diagnostics for Type VI problems (proper classes): Highlight the events that refer to classes they should not refer to. This can also be shown at the model level, e.g., counting how many times an event corresponding to activity a incorrectly refers to class oc.

7. Diagnostics for Type VII problems (right number of events per object): Highlight the (a; oc) connection if objects in oc do not (eventually/always) have the required number of a events. One can count the number of violations and annotate the connections. These violations can also be shown in the event log.

8. Diagnostics for Type VIII problems (right number of objects per event): Highlight the (a; oc) connection if a events do not refer to the specified number of objects in class oc. One can count the number of violations and annotate the connections. The corresponding events can also be highlighted in the event log.

9. Diagnostics for Type IX problems (behavioral constraints are respected): Highlight the constraints that are violated. Per constraint one can count the number of reference events for which the constraint is violated. These reference events can also be highlighted in the event log.

Model Editor


We provide some example OCBC models and XOC logs with deviations.

Order TO Cash

The model is based on the OTC scenario and log contains deviations over the nine types of conformance checking problems.

Download dataset