Conformance Checking - Revision history

Ollvihe: /* DesignModel */

2023-04-17T13:06:23Z

DesignModel

← Older revision		Revision as of 13:06, 17 April 2023
Line 191:		Line 191:
	\|\|Returns an array of all the top-level start DesignModelEvents in the design model.		\|\|Returns an array of all the top-level start DesignModelEvents in the design model.
	\|-		\|-
	\|\|Tasks (~~DesignModelNode~~*)		\|\|Tasks (DesignModelTask*)
	\|\|Returns an array of all ~~the~~ Tasks in the model.		\|\|Returns an array of all Tasks in the design model.
	\|}		\|}

Ollvihe: /* DesignModel */

2023-04-17T13:05:38Z

DesignModel

← Older revision		Revision as of 13:05, 17 April 2023
Line 190:		Line 190:
	\|\|StartEvents (DesignModelEvent*)		\|\|StartEvents (DesignModelEvent*)
	\|\|Returns an array of all the top-level start DesignModelEvents in the design model.		\|\|Returns an array of all the top-level start DesignModelEvents in the design model.
			\|-
			\|\|Tasks (DesignModelNode*)
			\|\|Returns an array of all the Tasks in the model.
	\|}		\|}

Ollvihe: /* Introduction to Conformance Checking */

2023-03-08T14:11:56Z

Introduction to Conformance Checking

← Older revision		Revision as of 14:11, 8 March 2023
Line 1:		Line 1:
	== Introduction to Conformance Checking ==		== Introduction to Conformance Checking ==
	Conformance checking compares a process mining model (i.e., eventlog) to a design model defined using BPMN, and finds which cases don't conform to the design model and which are the actual violations. In the process mining model, conformance can be tested for cases or variations, and each case or variation is either considered as conformant or nonconformant. For nonconformant cases/variations, the conformance checking is also able to identify one or several reasons for the nonconformance. For example the case or variation might contain events that are not in the design model, or the sequence of events doesn't correspond to the defined sequence in the design model.		Conformance checking compares a process mining model (i.e., eventlog) to a design model defined using BPMN, and finds which cases don't conform to the design model and which are the actual violations. In the process mining model, conformance can be tested for cases or variations, and each case or variation is either considered as conformant or nonconformant. For nonconformant cases/variations, the conformance checking is also able to identify one or several reasons for the nonconformance. For example the case or variation might contain events that are not in the design model, or the sequence of events doesn't correspond to the defined sequence in the design model.

			The design model can be drawn in a way that the same task (event type name) appears multiple times in the design model. Sometimes its easier to create the design model when each variation/path is drawn as an own sequence (separated by exclusive gateways). In this approach, same tasks may appear multiple time in the design model. Alternatively, the design model may be drawn using more of the gateways to avoid using same tasks multiple times. From the conformance checking viewpoint, both approaches are suitable and it's more a matter of taste which design model is easier to read.

	The conformance checking calculation is implemented by functions ''AnalyzeConformance'' and ''IsConformant'' that are available for [[QPR_ProcessAnalyzer_Objects_in_Expression_Language#Case\|Case]] and [[QPR_ProcessAnalyzer_Objects_in_Expression_Language#Variation\|Variation]] objects. In addition, the design model needs to be provided as a parameter. 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.		The conformance checking calculation is implemented by functions ''AnalyzeConformance'' and ''IsConformant'' that are available for [[QPR_ProcessAnalyzer_Objects_in_Expression_Language#Case\|Case]] and [[QPR_ProcessAnalyzer_Objects_in_Expression_Language#Variation\|Variation]] objects. In addition, the design model needs to be provided as a parameter. 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.

Ollvihe: /* Conformance Checking Settings */

2023-03-08T14:06:13Z

Conformance Checking Settings

← Older revision		Revision as of 14:06, 8 March 2023
Line 22:		Line 22:
	\|\|IgnoreEventTypesMissingInModel		\|\|IgnoreEventTypesMissingInModel
	\|\|		\|\|
	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 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'').
	\|-		\|-
	\|\|IgnoreIncompleteCases		\|\|IgnoreIncompleteCases
	\|\|		\|\|
	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''.		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''.
	\|}		\|}

Ollvihe: /* Introduction to Conformance Checking */

2023-03-08T14:05:31Z

Introduction to Conformance Checking

← Older revision		Revision as of 14:05, 8 March 2023
Line 1:		Line 1:
	== Introduction to Conformance Checking ==		== 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.		Conformance checking compares a process mining model (i.e., eventlog) to a design model defined using BPMN, and finds which cases don't conform to the design model and which are the actual violations. In the process mining model, conformance can be tested for cases or variations, and each case or variation is either considered as conformant or nonconformant. For nonconformant cases/variations, the conformance checking is also able to identify one or several reasons for the nonconformance. For example the case or variation might contain events that are not in the design model, or the sequence of events doesn't correspond to the defined sequence in the design model.

	The conformance checking calculation is implemented to functions ''AnalyzeConformance'' and ''IsConformant'' that are available for [[QPR_ProcessAnalyzer_Objects_in_Expression_Language#Case\|Case]] and [[QPR_ProcessAnalyzer_Objects_in_Expression_Language#Variation\|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~~.		The conformance checking calculation is implemented by functions ''AnalyzeConformance'' and ''IsConformant'' that are available for [[QPR_ProcessAnalyzer_Objects_in_Expression_Language#Case\|Case]] and [[QPR_ProcessAnalyzer_Objects_in_Expression_Language#Variation\|Variation]] objects. In addition, the design model needs to be provided as a parameter. 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.		There are settings ''IgnoreEventTypesMissingInModel'' and ''IgnoreIncompleteCases'' affecting how the conformance checking is done. If ''IgnoreEventTypesMissingInModel'' is ''false'' and there are events in the case that don't exist in the conformance model (comparing using event type names), the path doesn't conform with the model. Then the ''InvalidEventType'' is mentioned as a nonconformance reason.

	The conformance checking works as follows:		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:		* 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 event does not exist in the design model and ''IgnoreEventTypesMissingInModel'' is set to ''true'', move to the next event.
	** If the checked ~~EventType~~ exists in the design model, find next ConformanceModelTask whose name matches with the ~~EventType~~ name.		** If the checked event exists in the design model, find next ConformanceModelTask whose name matches with the event type 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.		** 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.		* 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 to the design model. ''NotCompleted'' will be added as nonconformance reason.

	== Conformance Checking Settings ==		== Conformance Checking Settings ==
Line 30:		Line 30:

	== Types of Nonconformance Reasons ==		== 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.		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.

	{\| class="wikitable"		{\| class="wikitable"
Line 40:		Line 40:
	\|\|InvalidEventType		\|\|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, there is a list of all the invalid EventType names not found in the design model, but occurring in the ~~Case~~ or ~~Variation~~.		Occurs when the tested case or variation has events that do not exist in the design model (event type 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, there is a list of all the invalid EventType names not found in the design model, but occurring in the case or variation.

	Example:		Example:
Line 50:		Line 50:
	\|\|2		\|\|2
	\|\|NotCompleted		\|\|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, the following elements will be added after the reason identifier:		\|\|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, the following elements will be added after the reason identifier:
	* Zero based index of the last event.		* Zero based index of the last event.
	* Type name of the last event.		* Type name of the last event.
Line 62:		Line 62:
	\|\|InvalidStateChange		\|\|InvalidStateChange
	\|\|		\|\|
	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. Note that this reason doesn't show those invalid transitions, where the target event type is invalid (i.e., is listed as the InvalidEventType reason). As an additional information, the following elements will be added after the reason identifier:		Occurs when the event sequence in a case or Variation is not possible according to flow of tasks described by the design model. 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. Note that this reason doesn't show those invalid transitions, where the target event type is invalid (i.e., is listed as the InvalidEventType reason). As an additional information, the following elements will be added after the reason identifier:
	* Zero based index of the detected nonconformant event.		* Zero based index of the detected nonconformant event.
	* Name of the previous EventType or null if this was the first event type name in the Case or Variation.		* Name of the previous EventType or null if this was the first event type name in the Case or Variation.

Ollvihe: /* Types of Nonconformance Reasons */

2023-02-27T14:05:27Z

Types of Nonconformance Reasons

← Older revision		Revision as of 14:05, 27 February 2023
Line 62:		Line 62:
	\|\|InvalidStateChange		\|\|InvalidStateChange
	\|\|		\|\|
	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, the following elements will be added after the reason identifier:		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. Note that this reason doesn't show those invalid transitions, where the target event type is invalid (i.e., is listed as the InvalidEventType reason). As an additional information, the following elements will be added after the reason identifier:
	* Zero based index of the detected nonconformant event.		* Zero based index of the detected nonconformant event.
	* Name of the previous EventType or null if this was the first event type name in the Case or Variation.		* Name of the previous EventType or null if this was the first event type name in the Case or Variation.

Ollvihe: /* Types of Nonconformance Reasons */

2023-02-09T13:39:11Z

Types of Nonconformance Reasons

← Older revision		Revision as of 13:39, 9 February 2023
Line 40:		Line 40:
	\|\|InvalidEventType		\|\|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 containing~~ all the invalid EventType names not found in the model ~~that occurs~~ in the Case or Variation.		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, there is a list of all the invalid EventType names not found in the design model, but occurring in the Case or Variation.

	Example:		Example:
Line 50:		Line 50:
	\|\|2		\|\|2
	\|\|NotCompleted		\|\|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:		\|\|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, the following elements will be added after the reason identifier:
	* Zero based index of the last event.		* Zero based index of the last event.
	* Type name of the last event.		* Type name of the last event.
Line 62:		Line 62:
	\|\|InvalidStateChange		\|\|InvalidStateChange
	\|\|		\|\|
	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:		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, the following elements will be added after the reason identifier:
	* Zero based index of the detected nonconformant event.		* Zero based index of the detected nonconformant event.
	* Name of the previous EventType or null if this was the first event type name in the Case or Variation.		* Name of the previous EventType or null if this was the first event type name in the Case or Variation.

Ollvihe: /* Conformance Checking Settings */

2023-02-09T13:34:35Z

Conformance Checking Settings

← Older revision		Revision as of 13:34, 9 February 2023
Line 14:		Line 14:

	== Conformance Checking Settings ==		== Conformance Checking Settings ==
	The following settings are supported by the conformance checking, affecting ~~how~~ the conformance checking ~~works~~:		The following settings are supported by the conformance checking, affecting the conformance checking behavior:

	{\| class="wikitable"		{\| class="wikitable"

Ollvihe: /* Identified Reasons for Nonconformance */

2023-02-08T23:02:21Z

Identified Reasons for Nonconformance

← Older revision		Revision as of 23:02, 8 February 2023
Line 29:		Line 29:
	\|}		\|}

	== ~~Identified~~ Reasons ~~for Nonconformance~~ ==		== Types of Nonconformance Reasons ==
	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.		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.

	{\| class="wikitable"		{\| class="wikitable"

Ollvihe: /* Identified Reasons for Nonconformance */

2023-02-08T15:52:11Z

Identified Reasons for Nonconformance

← Older revision		Revision as of 15:52, 8 February 2023
Line 50:		Line 50:
	\|\|2		\|\|2
	\|\|NotCompleted		\|\|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.		\|\|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:
			* Zero based index of the last event.
			* Type name of the last event.

	Example:		Example:
	<pre>		<pre>
	[2]		[2, 3, "Invoice sent"]
	</pre>		</pre>
	\|-		\|-