Arzobispo, Prefecto y Papa

BPM research is concerned with the understanding and the management of business processes and with the design of technologies to support them. Objectives of BPM theories and models are the support of business activities through making explicit the roles and functions of the people (or the organisational units) involved, clarify the operations to be undertaken in the various phases, and standardise the actions and methods by means of clearly defined protocols. Standard bodies like OASIS52_{and The Object Management Group (OMG) played an important role in the dissemination} and promotion of standards and practices of BPM in software engineering. For example, the Software and Systems Process Engineering Meta-Model (SPEM) aims at supporting the activity of software development and maintenance [OMG and Notation (2008); Ruiz-Rube et al. (2013)]. Within this context, several models have been theorised and developed with the purpose of supporting different activities such as design, execution, monitoring, diagnostics, and interoperability of processes [Ko et al. (2009)]. Therefore, several languages and modelling approaches have been developed, each one of them with capabilities targeted to the different purposes.

Process design is supported by visual languages and graphical tools. The Unified Modelling Language (UML) is a general-purpose family of languages popularly adopted in the field of object- oriented software engineering. UML Activity Diagrams have the purpose to support the design of processes (see Figure 2.10)53_{. UML Activity Diagrams (UML-AD) resemble closely the concepts} of Petri Nets, including states, triggers and transitions [Havey (2005)], meant for the description of systems’ processes. UML-AD defines a small set of elements focusing on the description of the control flow. Event-driven process chains (and the related XML language EPML) are also based on events and functions connected through logical operators and support sequential and parallel control flows [Mendling and Nüttgens (2006)]. The Business Process Model and Notation (BPMN)54 provides a set of graphical elements including: Event, Activity, Gateway, Sequence flow, Message flow, Pool, Lanes and so forth. Data objects represent requirements or preconditions for Activities to be performed or what they produce. Data objects can represent single items or collections and can be input or output of activities. An example of BPMN model is depicted in Figure 2.1155.

Executable process models (also called workflows) are developed with the objective to support software development by means of reusable components that can be combined and configured in complex chains. A workflow engine is a software application that executes (and manages) business

52_{OASIS: https://www.oasis-open.org/.}

53_{Figure 2.10 was generated from http://thoughtpad.net/alan-dean/http-headers-status.}

gif(CC BY 2.5) - By Alan Dean.

54_{BPMN 2.0: http://www.omg.org/spec/BPMN/2.0/PDF/}

2.10: An UML acti vity diagram. The example describes the resolution of the HTTP response status cod e, gi v en v arious headers.

2.7. REPRESENTATION OF PROCESS KNOWLEDGE 69

Figure 2.11: Example of BPMN model.

process models. Workflow engines can execute a given workflow multiple times by orchestrating the actions of different users (or agents) involved, allowing them to adapt the process to different data sources (configuration) and monitor its execution for quality control. OASIS56develops the Web Services Business Process Execution Language (WS-BPEL)57, commonly known as BPEL, an executable language for representing actions within business processes as Web services. The core element of a BPEL process is an Activity, which specifies the nature of the operation to be performed. Some types of BPEL activities are: receive, reply, sequence, if, while, repeatUntil, flow. Each activity type can have a number of inputs and outputs. BPEL supports nesting of workflows (composite activities) and parallel executions. Workflow engines developed for the Business Process Execution Language (BPEL) are based on the Service Oriented Architecture (SOA) paradigm (more

56_{https://www.oasis-open.org/}

about SOA and Web Services on Section 2.7.3).

The Workflow Patterns Framework58_{was developed in the context of Process-Aware Information} Systems (PAIs) with the purpose of evaluating the suitability of process modelling solutions. Workflow Patterns are a set of generic, recurring constructs under which existing modelling solutions can be evaluated [Russell et al. (2006); Wohed et al. (2006)]. Following a bottom-up approach to process modelling, this conceptual framework lead to the development of Yet Another Workflow Language (YAWL), also having its foundation on Petri Nets [van Der Aalst et al. (2003)]. Research on Workflow Patterns identified a wide range of constructs, notably the representation of a data perspective, delineated in four groups of patterns: data visibility, data interaction, data transfer, data-based routing. Data visibility deals with the scope of the data in the system (from local bound data objects to environmental variables). Data Interaction patterns represent the various ways in which data can be passed through the various components of the system (one to one, one to many, whether the data is pushed or pulled and so forth). Data Transfer patterns list the possible methods in which data is transferred, from shared memory to pass-by-reference or by copying, or when transformation might occur to adapt the output data to fulfil the requirements of the receiver input. Overall, Workflow Data Patterns analyse with a certain degree of accuracy the various aspects involved in the management of data in complex software processes [Russell et al. (2004)], although it has been argued that “there is no statistical underpinning” demonstrating that the patterns are representatives of real business processes [Börger (2012)].

After more than two decades of extensive research in process-aware software engineering, and the development of numerous competing standards, there is a lack of consensus about how best to describe processes [ter Hofstede et al. (2009)]. One of the main issues with traditional process modelling techniques is the trade-off between automation of model execution and intuitiveness of the language for BPM domain experts. On the one hand, easy to use tools for BPM design lack rigorous semantics, therefore the resulting models cannot effectively elucidate software requirements. On the other hand, while there are numerous workflow engines supporting more formal languages (like BPEL), these can only be used by experienced developers, therefore it is difficult for BPM domain expert to assess their capacity to fulfil the original requirements. As an example, the relation between the standard notation BPMN and its executable counterpart BPEL is insufficiently precise and incomplete, an aspect that is amply documented in the literature [Gong and Xiong (2009); Recker and Mendling (2007, 2006); Weidlich et al. (2008)]. The Subject-Oriented approach to BPM (S-BPM) is based on a controlled language that aligns BP descriptions to three basic constituents of elementary natural language expressions: subjects that perform actions on objects, communicating

2.7. REPRESENTATION OF PROCESS KNOWLEDGE 71 by sending or receiving messages [Fleischmann et al. (2014)]. Recently, a modelling practice based on Abstract State Machines (ASM) was proposed in order to provide a sound computable basis for the modelling of distributed algorithms, in an alternative to Petri Nets [Börger (2016)]. Abstract State Machines Nets (ASM Nets) can be defined by combining a textual based representation (similar to natural language) with graphical constructs (to reflect the control flow), and therefore can be combined with S-BPM in order to obtain rigorous, understandable models and potentially certifiable implementations [Börger and Fleischmann (2015)].