a university for the world real R © 2009, Chapter 18 Process Configuration Florian Gottschalk Marcello La Rosa

a university for the world real R 2 © 2009, Overview 1.Introduction to Configurable Process Models 2.Process Configuration in YAWL 3.Questionnaire-driven Approach for Process Configuration 4.Tool Support 5.Conclusions

a university for the world real R 3 © 2009, Tape variantFilm variant What is a configurable process model? commonality = variability + variation point Integrated representation of multiple variants of a same process in a given domain, which can be configured for a specific setting, leading to an indivi- dualized process model.

a university for the world real R 4 © 2009, Configurable Process Models in the Process Lifecycle design configurationindividualizationimplementationexecution

a university for the world real R 5 © 2009, Features of a Configurable Process Model should guide the user to a model that fits his requirements must be able to generate all possible process variants must be a complete, integrated set of all possible process variants is the least common multiple of all process variations

a university for the world real R 6 © 2009, Variant BSuperclass Configurable ModelVariant A Inheritance Subclass Configuration A Theoretical explanation Inheritance of workflow behavior:

a university for the world real R 7 © 2009, Blocking Hiding –also called skipping Configuration Techniques block τ τ τ hide

a university for the world real R 8 © 2009, Port Configuration Task Ports enabled blocked hidden (skipped)

a university for the world real R 9 © 2009, Port types in YAWL Flow of tokens is determined by functions assigned to a YAWL task: join  input ports split  output ports rem  cancellation port nofi  multiple instance configuration

a university for the world real R 10 © 2009, Input ports (inflow) XOR-join Task is enabled if a token arrives from any arc  One input port for each incoming arc AND-join Task is enabled if tokens are arriving from all arcs  One input port for the whole task OR-join Task is enabled if tokens are arriving from all arcs from which a token can potentially arrive  One input port for the whole task

a university for the world real R 11 © 2009, Output ports (outflow) XOR-split Task releases one token via one of the arcs  One output port for each outgoing arc AND-split Task releases tokens via all arcs only  One output port for the whole task OR-split Task can release tokens via any combination of outgoing arcs  One output port for every combination of outgoing arcs

a university for the world real R 12 © 2009, Configuration Example (A, B, C, E) or (A, B, D, E) (A, B, C, E) (B, C, E)

a university for the world real R 13 © 2009, Cancellation ports (inflow) Cancellation also represents an inflow of tokens, but can also take 0 tokens Takes the maximum number of available tokens, similar to the OR-join  One cancellation port for the whole task Hiding of Cancellation ports makes no sense  No skippable action between the activation of the cancellation port and the outflow of tokens

a university for the world real R 14 © 2009, Multiple Instance configuration 1.Increase of the minimal number of instances to be started 2.Decrease of the maximal number of instances to be started 3.Increase of the threshold value 4.Restrict dynamic creation of instances to static creation

a university for the world real R 15 © 2009, Multiple Instance configuration 1.Increase of the minimal number of instances to be started 2.Decrease of the maximal number of instances to be started

a university for the world real R 16 © 2009, 3.Increase of the threshold value Multiple Instance configuration

a university for the world real R 17 © 2009, 4.Restrict from dynamic to static instance creation dyn Multiple Instance configuration

a university for the world real R 18 © 2009, Transforming a port configuration

a university for the world real R 19 © 2009, Example 1 Transforming a port configuration: the OR-split

a university for the world real R 20 © 2009, Example 2 Transforming a port configuration: the OR-split

a university for the world real R 21 © 2009, Example 3 Transforming a port configuration: the OR-split

a university for the world real R 22 © 2009, Questionnaire-driven configuration Configuring a process model can be difficult and time- consuming, due to: –size of the variability space, –complexity of the domain. Domain experts usually have little or no knowledge about modeling notations (e.g. in the screen business). Need to facilitate the configuration of process models by domain experts, without requiring process modeling knowledge.

a university for the world real R 23 © 2009, Questionnaire-based approach Configuration can be simplified if carried out by answering a set of questions no need to be aware of modeling notations. The basic concepts of the approach are questions and domain facts: –a question is composed of a set of domain facts; –a domain fact encodes a business choice and can be set to “true” or “false”. Variation points in the process model are mapped to boolean expressions over domain facts. Questions may affect one or multiple variation points:

a university for the world real R 24 © 2009, Domain constraints The configuration space of the domain is restricted by a set of propositional logic domain constraints over the domain facts. By means of domain constraints, answers to questions may be determi- ned by previous answers. DC 10 : f 11  f 12 DC 11 :  f 10 ⇒  f 12 DC 10 DC 11

a university for the world real R 25 © 2009, Questionnaire model

a university for the world real R 26 © 2009, Order dependencies

a university for the world real R 27 © 2009, Mapping process models to questionnaire models Process Model Mapping Questionnaire Model p SEQ ⇔  f 12 c a 2 2 p SEQ ⇔  f 11 c b 2 2 p AND ⇔ f 11  f 12 c 2 p OR ⇔ false c 2 p XOR ⇔ false c 2 MC 6 : MC 7 : MC 8 : MC 9 : MC 10 :

a university for the world real R 28 © 2009, Mapping process models to questionnaire models A mapping links process facts to domain facts: The mapping ensures domain compliance and process model correctness. C-EPC C-YAWL

a university for the world real R 29 © 2009, Constraints in action DC 6 DC 8 MC 22 MC 25 PC 4 DC 6 : f 5 ⇒ f 13 DC 8 : f 8 ⇒ f 15 MC 22 : p ON ⇔ f 13 d MC 25 : p ON ⇔ f 15 e PC 4 : p ON ⇒  p SEQ d c4c4 b4b4 Domain constraints MappingProcess constraints

a university for the world real R 30 © 2009, = Application of the approach Interactive QuestionnaireConfigurable Process Model Individualized Model answers input to Questionnaire model Mapping +

a university for the world real R 31 © 2009, Tool support: Synergia Open-source Modular: 6 standalone applications, Provides end-to-end support for process model configuration, Independent of specific modeling notations, Supports C-EPC and C-YAWL.

a university for the world real R 32 © 2009, Discussion Is there a need for configurable models? –Do you have the same experience that highly-standardized processes (such as the Order Fulfillment example) are still adapted to individual needs? Is it feasible to create configurable models? –What do you think about how we individualized the Order Fulfillment model compared to the intended use of your software? Are configurable models useful? –Can you imagine that you provide similar models which can be adapted “without drawing arcs and nodes”?

a university for the world real R 33 © 2009, Conclusions Process Configuration is a viable mechanism to automate the derivation of customized models from a reference model in a specific domain Process Configuration in YAWL is grounded in the concept of Inheritance of Workflow Behavior and is achieved via 2 operators: hide, block The Questionnaire-based approach facilitates the configuration of (complex) process models such as the Order Fulfillment example by non-modeling experts Tool support is available with the Synergia toolset

a university for the world real R 34 © 2009, For more information… …visit