Labels of EPC functions and events are the key to understanding EPC models by humans and by machines. Empirical studies show that the current labeling practice of model elements is conducted rather arbitrarily which inherently causes potential threats for understanding by humans. Thus, refactoring of model element labels is suggested either human-driven or with automated support while semantic annotation using domain-ontologies is well-recognized to approach the understanding of model elements by machines. Current research either focuses on improving the quality of labels or on semantic annotation to facilitate machine interpretability. To the best of our knowledge, there is a significant lack of approaches that facilitate to exploit the potentials and benefits arising from bridging the gap between approaches that improve human understandability and that facilitate machine interpretability. This work introduces a comprehensive, formalized approach that enables the modeling tasks automated refactoring of model elements and automated semantic annotation by bridging the gap between informal and formal representation of model elements.
TopIntroduction
Event-driven Process Chains (EPCs) (Keller, Nüttgens, & Scheer, 1992) have gained broad acceptance in industry for designing processes on a business-level with key objectives such as the documentation of processes, the automated translation of process models into enactable workflows (Van der Aalst, Hofstede, & Weske, 2003) or the automated discovery of common modeling practices (Bögl et al. 2008a). Unfortunatley, the achievement of these key objectives is hampered by lack of human understanding and machine interpretability of process models, due to ambiguities in model element labels and lack of behavioral correctness, which has been shown in recent research on process model quality and on guidelines of modeling (GOM) (Schütte & Totthowe 1998; Mendling, Reijers, & Van der Aalst 2009).
To elaborate on understandability and interpretability of EPC models we distinguish between structural aspects and labeling aspects. From a human perspective, structural aspects are concerned with the size, complexity of EPC models, for example. According to different studies in research and practice (e.g. Gruhn & Laue, 2006), it turned out that well-structured EPC models are easier to comprehend for humans and less error prone. For machines, however, size and complexity of EPC models do not affect the interpretability; it refers to the processability respectively the behavioral semantics of EPC models. The focus is on the semantic correctness to prevent errors at run-time, i.e. that no undesired process behavior occurs such as deadlocks or lack of synchronization (Vanhatalo, Völzer, & Leymann, 2007) or unreachable activities (Van der Aalst, et al., 2002). In this context, soundness (Van der Aalst, 1997) defines a minimum correctness criterion that an EPC should fulfill to ensure processability by machines. Structural aspects such as well-structuredness and soundness of EPC models are well researched and will not be further discussed in the rest of this paper (e.g. Laue & Mendling (2009), Mendling & Van der Aalst (2007), Kiepuszewski, Hofstede, & Bussler (2000), Boudewijn, Mendling, & Van der Aalst (2006), Dehnert & Zimmermann (2005)).
In contrast to structural aspects, labeling aspects are associated with natural text clauses in conjunction with some graphical representation. Natural text clauses are used to describe the process meaning of the model elements function and event of EPC models. A function captures an activity and an event describes its pre- and post-conditions. The process meaning of an EPC model element at least refers to the process items task and state each having a relationship to a process object. For example, the function “Define Software Requirements” means that the task “Define” is performed on process object “Software Requirements”; the event “Software Requirements Defined” means that the state “Defined” isstate for the process object “Software Requirements”.
Labeling model elements is inherent with certain subjectivism imposed by process modelers which lead to so-called linguistic or term defects such as synonyms, homonyms or vagueness. The following examples account some practical experiences and do not claim for completeness. If a lexical term of a model element is referred to as “Invoice”, a further element in another model as “Bill” and both terms represent the same real-world object then a synonymic labeling is at hand which allows much room for interpretation even for humans. Also, model element labels such as “printing notification” or “purchase requisition processing” are affected by ambiguity. The first label can be interpreted in the sense to print a notification or to notify somebody to carry out a print job, for the second label it is not obviously whether purchase or processing reflects an action (Leopold, Sergey, & Mendling, 2009). Apart from linguistic or term defects, different labels may express the same meaning due to freedom of modeling. For example, the functions “Define SW Requirements” and “Define Requirements for Software” are syntactically different but refer to the same process meaning.