On the Support of Activity Patterns in ProWAP : Case Studies , Formal Semantics , Tool Support

Recently, research on workflow activity patterns emerged in order to increase the reuse of recurring business functions (e.g., request for task execution, notification, approval and decision). While workflow patterns have been defined for several aspects related to process execution, recurrent business functions have been only partially addressed by existing work. Related to this challenge we proposed a set of seven workflow activity patterns in previous work. In this paper we report on the results of several case studies we performed in Brazilian and European companies in order to investigate how frequently the activity patterns occur in real-world process models. We further formalize the identified activity patterns using π−calculus. This formalization as well as our analysis results are applied in the development of a BPM tool fostering the reuse of business functions specifications.


Introduction
In order to fulfill their business goals, companies have adopted several technologies related to the improvement of their business processes; e.g., workflow management systems and Business Process Management (BPM) tools [Dadam 2000] [Mutschler 2008].In particular, such technologies enable the definition, execution and monitoring of the operational processes of an enterprise [Lenz, 2007], [Müller 2006], [Weske 2007], whereby different process variants may have to be managed along the process lifecycle [Hallerbach 2008].
A business process is a set of (structured) activities which jointly realize a particular business goal [Weske 2007].Such activities are related to specific business functions or process fragments (e.g., notification, information request, approval) having a well defined semantics [Thom 2008].In particular, a certain process fragment or business function (e.g., enabling document approval) can occur several times within one or different process models.That means multiple logical copies of the same process fragment may be used with same or different parameterization (e.g. approval by a single actor or by multiple actors).As example consider Figure 1, which shows the procedure for carrying out a medical examination.This process includes the following activities (in the given order): a) First an order entry is created with a request for the medical examination; b) then an appointment with the radiologist is made; c) next, an authorization from the patient for beginning his or her treatment is needed; if the patient does not agree with the treatment all appointments with the radiologist will be cancelled; d) otherwise, the patient is prepared for the examination; e) at the day of the examination the patient is transported to the radiology unit; f) the physician performs the examination; g) based on the results of the examination the physician writes a report; h) as last step, the physician who requested the examination validates the report.Interestingly, this simple process model comprises (atomic) fragments related to activity patterns like Request for Activity Execution without Answer (Activities a, b and h), Request for Activity Execution with Answer (Activities d, e, f and g), and Approval (Activity c).In this paper we use the term Workflow Activity Pattern (WAP or activity pattern for short) to refer to the description of such business functions as they frequently re-occur in business process models.

Problem Statement
Usually, the above mentioned process fragments are re-designed for each workflow application [Flores 1998], [Medina-Mora 1992], [Malone 2004], [zur Muehlen 2002].This lack of reusing model fragments and process knowledge, in turn, has resulted in high costs and error rates regarding the modeling and maintenance of process-oriented applications.
While some research has been reported on how metadata can be organized to manage large-scale modeling projects [Thomas and Scheer 2006], there is not much work providing evidence for the existence of activity patterns that can be used to define recurrent business functions for real-world process models.Furthermore, there is a lack of investigations proofing the necessity and completeness of respective activity patterns with respect to process modeling.Finally, contemporary BPM tools like Intalio, ARIS Toolset and WBI Modeler do not support process designers in defining, querying and reusing activity patterns as building blocks for business process modeling.

Background and Contributions
In this paper we report on the results from ProWAP1 project, which addresses the aforementioned challenges.We first present an empirical study in which we analyze the relative frequency of the activity patterns presented in [Thom 2006b] in a collection of 239 real-world process models from application domains like quality management, software access control, textile manufacturing, and electronic change management.For selected process categories, we further discuss results of an additional analysis in which we investigate the frequency of co-occurring activity patterns.
The results of this second analysis are additionally utilized for developing a BPM tool, which shall foster the modeling of business processes based on the reuse of activity patterns [Thom 2008].Given some additional information about the kind of process to be designed, the results of our analysis can be further used by this BPM tool to suggest a ranking of the activity patterns suited best to succeed the last pattern applied during process modeling.
Our BPM tool also provides support for analyzing and verifying model properties of composed processes like syntactical correctness or absence of deadlocks.Basic to this is a formalization of the activity patterns, which further contributes to reduce ambiguities.Different formalisms have been suggested for defining the formal semantics of process modeling languages, including Petri Nets [van der Aalst 2003a], Temporal Logic [Eshuis 2002], and -calculus [Puhlmann 2005].In this paper we are using -calculus to define formal semantics of our activity patterns.This formalism has been successfully applied before in the context of software process formalization [Szturc 1999] as well as for formalizing workflow patterns [Puhlmann 2005] and block-structured process modeling languages (e.g., XLang [Thatte 2001]).
The remainder of this paper is organized as follows: Section 2 discusses related work.Section 3 gives background information on the workflow activity patterns we identified in previous work.Section 4 evaluates the existence and completeness of these activity patterns with respect to real-world process models.In Section 5 we provide a formalization of the patterns using -calculus.Section 6 introduces our BPM tool which offers activity patterns to the process designer.Section 7 concludes with a summary and outlook.

Survey on Workflow Patterns
A pattern is the abstraction from a concrete form which keeps recurring in specific nonarbitrary contexts [Gamma 2005].Patterns capture existing, well-proven experience in software development and help to promote good design practices [Buschmann 1996], [Eriksson 2001].They have been used for many different domains.However, patterns for business process and workflow modeling are still subject of discussion and research.One of the first contributions in this respect was a set of process patterns to be used in connection with the software processes of an organization [Ambler 1998].Russell (2006a) proposes 43 workflow patterns for describing process.Each pattern represents a routing element (e.g., sequential, parallel and conditional routing) which can be used to process modeling.In the meantime these workflow patterns have been additionally used for evaluating process specification languages and process modeling tools [van der Aalst 2003b], [Wohed 2006].Rinderle (2006) shows how selected control flow patterns contribute to automatically cope with certain exceptions in process-aware information systems.
A set of data patterns is proposed by [Russell 2005].These patterns are based on data characteristics that occur repeatedly in different workflow modeling paradigms.Examples are data visibility and data interaction.In related work, Russell presents a set of resource patterns each of them describing a way through which resources can be represented and utilized in process models [Russell 2004].A resource is considered as an entity being capable of doing work.It can be either human (e.g., a worker) or nonhuman (e.g., equipment).Examples of resource patterns include Direct Allocation and Role-Based Allocation.
Recently, Russell presented a pattern-based classification framework for characterizing exception handling in workflow systems [Russell 2006b].This framework has been used to examine the exception handling capabilities of workflow and BPM tools and to evaluate process specification as well as process execution languages accordingly.As a result, limited support for exception handling in existing workflow management systems could be observed.Mulyar (2005) proposes 34 implementation patterns to be used in the design of process models with Colored Petri Nets tools [Mulyar 2005].An example is the synchronous transfer pattern which allows transportation of data from one location to another, ensuring that actors who post a request are blocked until they receive the requested information.Barros (2005) proposes a set of service interaction patterns, which allow for service interactions, pertaining to choreography and orchestration, to be benchmarked against abstracted forms of representative scenarios.As example consider the Send and the Send/Receive patterns.
Altogether Russell and Barros provide a thorough examination of the various perspectives that need to be supported by a workflow language and tool respectively.However, none of these approaches investigate which are the most frequent patterns recurrently used during process modeling and in which way the introduction of such activity patterns eases process modeling.Furthermore, recent work has shown that consideration of the strong linkage existing between data and process allows for sophisticated IT support in all phases of the process lifecycle.For example consider the work done in COREPRO [Müller 2007], [Müller 2008] and ProCycle [Weber 2009].This observation has not yet been fully covered in research on workflow patterns.
Obviously, broad support for workflow patterns allows for building flexible processaware information systems.However, an evaluation of a PAIS regarding its ability to deal with process flexibility and change needs a broader view [Weber 2007], [Weber 2008a].In addition to build-time flexibility (i.e., the ability to model flexible execution behavior based on advanced workflow patterns), run-time flexibility has to be considered as well [Reichert 1997], [Rinderle 2004].The latter is to some degree addressed by the aforementioned exception handling patterns [Russell 2006b], which describe different ways for coping with the exceptions occurring during process execution.To also cope with process adaptation, in addition, the aforementioned process change patterns have been introduced by [Weber 2008a], [Weber 2007].A formalization of these change patterns is given in [Rinderle-Ma 2008].Weber (2008b), in turn, shows how these change patterns can be used for refactoring process models in order to increase their quality.
PICTURE proposes a set of 37 domain-specific process building blocks.More precisely, these building blocks are used by end users in public administrations to capture and model the process landscape.The building blocks have been evaluated in practice [Becker 2007].
Concerning the formal representation of workflow patterns one of the first approaches used Petri Nets to formalize control flow patterns [van der Aalst 2003a].Following this, with YAWL [van der Aalst 2005] presented a Petri-net based workflow specification language covering all control flow patterns on Petri nets.
In the context of process algebra, [Brogi 2004] used CCS (Calculus of Communicating Systems) to formalize web service flows.In another approach, CCS was used for defining a workflow modeling language called SMAWL (Small Workflow Language) [Stefansen 2005].
The -calculus, in turn, was first used by Yang Dong and Zhang Shen-Sheng to formalize basic control flows and to define workflow activities [Dang 2003].Based on the latter work, [Puhlmann 2005] formalize the control flow patterns described in [van der Aalst 2003a] based on -calculus.

Workflow Activity Patterns
Starting with an extensive literature study (e.g., [Flores 1998], [Medina-Mora 2002], [zur Muehlen 2002]) we derived seven activity patterns.Each of them represents a frequently recurring business function as it can be found in real-world processes.The identified activity patterns are based on message exchanges where the sender and receiver of a particular message may belong to the same organization or to different ones the latter applies when dealing with inter-organizational processes [Dadam 2000].
Table 1 gives an overview of the seven activity patterns we identified.Generally, these patterns are close to the abstraction level or vocabulary used within an organization.This, in turn, fosters their reuse when modeling business processes, and therefore contributes to more standardized and better comparable business process models.
We have characterized each activity pattern by giving a description, an example illustrating the context in which the pattern can be applied, a problem motivating its use specific issues arising in this context, design choices (patterns variants) which allow for pattern parameterization keeping the number of distinct patterns manageable, related patterns, and implementation details in particular.The design choices were defined based on the process models we analyzed.For example, we define three variants of the approval pattern, namely single approval (i.e., approval is required from exactly one organizational role), iterative approval (i.e., sequential approval is required from a list of reviewers) and concurrent approval (i.e., approval is required from a list of reviewers simultaneously).Information about the variants we defined for the other six patterns can be found in [Thom 2009].Note that Table 1 only shows selected pattern variants, but does not contain all possible parameterizations.Reason is that most of these properties are out of the scope of this paper.A question which emerges during process enactment has to be answered.This pattern allows to formulate the question, to identify the organizational role(s) who shall answer it, to send the question to the respective role(s), and to wait for the response(s) (single-question-response).WAP 3: Unidirectional Performative A sender requests the execution of a particular task from another process participant.The sender continues process execution immediately after having sent the request for performing the activity.WAP 4:

Bi-directional Performative
A sender requests the execution of a particular task from another process actor.The sender waits until this actor notifies him that the requested task has been performed.WAP 5: Notification The status or result of an activity execution is communicated to one or more process participants.

WAP 6: Information Request
An actor requests certain information from a process participant.He continues process execution after having received the requested information.

WAP 7: Decision
This pattern can be used to represent a decision activity in the flow with different connectors to subsequent execution branches.Exactly those branches will be selected for execution whose transition conditions evaluate to true.
In the following sections we informally summarize pattern semantics using UML activity diagrams (cf.Fig. 2).As examples we discuss the Uniand Bi-directional Performative Pattern and the Approval Pattern.The complete set of activity patterns is described in [Thom 2006a andThom 2006b].It is important to observe that the send and receive signals (cf.Fig. 2) do not configure process activities from the application domain perspective.They are used to implement the logic of the pattern.An object (e.g. a document) has to be approved by one or more organizational roles.Depending on the respective context, the evaluation is executed only once (single approval) or multiple times.In the latter variant, approval either can be accomplished in sequence (iterative approval) or in parallel (concurrent approval).

Receive approval request
Approval request

Receive approval request
Approval request

Receive approval result
<<single>> Reviewer requestor (human or automated) Reviewer (human or automated)

Figure 3. Approval pattern
Fig. 3 illustrates a single approval where an organizational role "reviewer" performs a document review either resulting in approval or disapproval.Generally, the Approval Pattern is related to the structural aspect "centralization on decision making"; i.e., the authority to make decisions in organizations can be more or less allocated to the highest positions within an organization (e.g., head of department, manager, director).The more centralized this authority is, the higher will be the number of organizational roles being involved in approval following the organizational scalar chain [Chiavenato, 2000].

Unidirectional Performative Pattern (WAP 3)
The unidirectional performative pattern represents a unidirectional message as described in [zur Muehlen 2002].A sender uses unidirectional performative messages to request the execution of a particular activity from a receiver (e.g., human or software agent) involved in the process (cf.Fig. 4).The sender continues execution of his part of the process immediately after having sent the request.For example, in a procurement process, the execution of an activity to partially cancel an order can be requested from a manager if some irregularities occur.The flow continues execution after the cancel activity is requested.

Activity request
The sender will continue execution immediatey after sending the request

Execute activity
Execution result

Activity request
The sender will continue execution immediatey after sending the request

Execute activity
Execution result

Bi-directional Performative Pattern (WAP 4)
A sender requests the execution of a particular activity from another role (e.g., a human or a software agent) involved in the process.The sender waits until the receiver notifies him that the requested activity has been performed (cf.Fig. 5).As example consider a customer requesting changes concerning the design of a particular product.This triggers a process at the manufacturer site where -first of all -a designer is requested to adapt the product design according to the specifications made by the customer.The manufacturer process then has to wait until the designer finishes this task.Afterwards the process continues with a review of the new product design by another actor.

Activity request
The sender will block waiting for a reply to continue execution

Execute activity
Execution result

Receive notification of activity execution complete
Activity result

Send notification of activity execution complete
The sender continues execution when the receiver completes execution

Activity request
The sender will block waiting for a reply to continue execution

Execute activity
Execution result

Receive notification of activity execution complete
Activity result

Send notification of activity execution complete
The sender continues execution when the receiver completes execution

Evaluating the Existence and Completeness of Activity Patterns
To identify activity patterns in real-world processes we analyzed 239 process models.These process models have been modeled either with the Oracle Builder tool or an UML modeler.Our analysis has been based on process models instead of event logs, since we consider the semantics and the context of process activities as being fundamental for identifying activity patterns.Altogether, the analyzed process models stem from 14 different organizations -private as well as governmental ones -and are related to different applications like Total Quality Management (TQM), software access control, document management, help desk services, user feedback, document approval, textile manufacturing, and electronic change management.In most of organizations the respective process models are computerized, i.e. they are supported by a process-aware information system.Table 2 summarizes information about involved organizations and analyzed process models.

Applied Method
To our knowledge there exist no mining techniques for extracting activity patterns from real-world process models; i.e., contemporary process mining tools like ProM or MinAdept analyze the event logs (e.g., execution or change logs) related to process execution and do not extract information related to the semantics and the (internal) logic of process activities [van der Aalst 2003a], [Ellis 2006], [Günther 2008], [Li 2008a].Therefore, we perform a manual analysis in order to identify relevant activity patterns as well as their co-occurrences within the 239 process models.
For each workflow activity pattern WAP * we calculate its support value S WAP* , which represents the relative frequency of the respective activity pattern within the set of analyzed process models; i.e., S WAP* := Freq(WAP * )/239 where Freq(WAP * ) denotes the absolute frequency of WAP * within the collection of the analyzed 239 models; for each process model we count at most one occurrence of a particular pattern.Reason is that in some process models, the activity patterns were identified not only in atomic activities but also in pairs (sequences) of activities.

Frequency of Activity Patterns in Real Process Models
Our analysis has shown that five out of the seven activity patterns (cf.Table 1) are not dependent on a specific application domain or a particular organizational structure (e.g., the degree of centralization in decision making or the standardization of work abilities).Any kind of process model might contain these patterns independent of the application domain (e.g., healthcare, automotive engineering) or the kind of organization (e.g., process oriented, functional and matrix).More precisely, this applies to the following five patterns: UNIDIRECTIONAL and BI-DIRECTIONAL PERFORMATIVE (WAP 3+4), NOTIFICATION (WAP 5), INFORMATIVE (WAP 6) and DECISION MAKING (WAP 7).We can identify these five patterns with high frequency in almost all process models we analyzed.The APPROVAL pattern, in particular, can also be identified with high frequency because of the high degree of centralization regarding decision-making within the considered organizations.This high centralization implies the use of approval activities [Davis 1996].By contrast, most of the analyzed process models do not contain QUESTION-ANSWER activities.Figure 7 graphically illustrates the relative frequency of each activity pattern with respect to the set of analyzed process models.

Analyzing Process Models from an Austrian Textile Manufacturer
As data source we consider process models in the context of facility management.The models have been collected at a medium-sized enterprise operating in the Austrian textile industry.The decision-making within the company can be described as rather centralized.In total we analyzed 25 processes which comprise several hierarchy levels and which contain between 2 and 21 activities (for an overview see Fig. 8).Fig. 9 graphically illustrates the frequency of our activity patterns within the set of 25 process models from facility management.The diagram shows that the activity patterns based on organizational structural aspects (WAP 1 and WAP 2) only occur in 12% of the analyzed process models.Interestingly, WAP 1 (Approval) occurs relatively rarely for a company with centralized decision-making.This observation can be explained by the fact that the roles associated with the activities are relatively high up in the hierarchy, which reduces the need for approvals.In contrast, the activity patterns based on recurrent functions (WAP 3 -WAP 6) occur much more frequently.In 88% of all process models at least one of these patterns can be identified.WAP 4, for example, occurs much more frequently than all the other activity patterns (in average 4 times per process model).This high frequency of WAP 4 is mainly due to the nature of the analyzed process models, which primarily deal with the distribution of work.

Analyzing Process Models from an Automotive Company
For this analysis we consider process models in the context of Electronic Change Management.The models have been collected at a large enterprise working in the automotive industry.Decision-making within the company can be described as rather centralized.In total we analyze 24 processes which have several hierarchy levels and comprise between 2 and 8 activities.
In this study for each activity pattern we determine its absolute frequency as well as its support value, which represents the relative frequency of the respective patterns within the 24 analyzed process models.We also calculate the support value by design choice (e.g., single, iterative, concurrent approval).Fig. 10 graphically illustrates the frequency of each activity pattern within the set of 24 process models.The diagram shows that WAP1 -i.e., single approval was identified in 24% of the process models and concurrent approval in 12%.Interestingly, WAP 1 (Approval) occurs relatively rarely for a company with centralized decision-making.Like in the facility management processes (cf.Section 4.2.1), the roles associated with the activities are relatively high in the hierarchy, which reduces the need for approvals.By contrast, the activity patterns based on recurrent functions (WAP 3, WAP 5 and WAP7) occur much more frequently.
In 54% of all process models at least one of these patterns can be identified.

Identifying Co-occurrences of Activity Patterns in Real Process Models
One of the use cases for the knowledge base of our BPM tool (cf.Section 6) is based on a mechanism that gives design time recommendations with respect to the most suited activity patterns to be combined with an already used pattern.This mechanism utilizes empirical data we gathered during our case studies, which we also summarize in this section.To obtain the frequencies for pattern co-occurrences, we analyze the sequences of the co-occurring activity patterns in 154 of the 239 process models studied.When this analysis was performed only 154 of the 239 process models were available.In the future we intend to analyze the complete set of processes models, i.e., the 239 as well as further processes we might have access.
In earlier work, we have shown that when classifying the process models into humanoriented (i.e., with human intervention during execution) and fully automated (i.e., with no human intervention during execution) we can identify certain activity patterns more often in one of the two categories [Chiao 2008].We tried to classify the processes based on common characteristics (e.g., application domain), also considering classifications from the literature in this context.However, most of the studied classifications are based on specific application domains of the related process models [Dowson 1987], [Harrington 1991] and [Weske 2007].Accordingly, those approaches are not applicable to our analysis because the set of the process models we have been investigating does not cover all the categories addressed by these approaches.
We therefore decided to apply Le Clair (2007) approach which classifies business processes into systemand human-intensive.System-intensive processes are characterized by being handled on straight-through basis, i.e., there is minimal or no human intervention and few exceptions occur.Human-intensive processes, in turn, require people to get work done by relying on business applications, databases, documents, and other actors interacting with them.This type of process requires human intuition or judgment for decision-making during individual process activities.
By classifying our set of process models in those two categories, we obtain 123 humanintensive and 31 system-intensive process models respectively.Remember that in this analysis we consider 154 of the 239 process models.The next step is to evidence the occurrence of the activity patterns in the two categories of process models.Figure 11 shows the frequency of the activity patterns with respect to system-intensive and humanintensive processes.Note that some patterns (i.e.approval, informative, questionanswer) do not appear in the system-intensive process models at all.These patterns are usually related to human activities, i.e., they are executed by an organizational role.

Figure 11. Frequency of co-occurrences of activity patterns
In another analysis we search for frequent co-occurrences of activity patterns within the process models.Relying on these common occurrences the knowledge base should present to process designers a ranking of the most frequent activity patterns which normally follow the activity pattern the user has applied before for process modeling.
For example, Figure 12 shows how often the PERFORMATIVE UNIDIRECTIONAL PATTERN is applied immediately after one of the other activity patterns when regarding the set of process models we analyzed.Note that for the two kinds of processes (i.e.human vs. system intensive processes), a specific pair of patterns may occur with different frequency.For example, the pattern pair PERFORMATIVE UNIDIRECTIONAL  PERFORMATIVE UNIDIRECTIONAL (WAP 3) occurs more often in system-intensive than in human-intensive processes (60 % vs. 25 %).By contrast, the pair PERFORMATIVE UNIDIRECTIONAL  APPROVAL occurs more frequently in human-intensive processes.

On the Completeness of Activity Patterns for Process Modeling
When analyzing the process models our main goal was to measure the frequency with which each of the activity patterns occurs within the set of considered process models.We did this in order to verify whether certain process fragments (e.g., task execution request, approval, notification) can be considered as patterns with high probability for reuse in the context of process modeling.
While some patterns can be identified by simply analyzing activity descriptions (e.g., in connection with decisions, approvals and notifications patterns), others require a more detailed analysis.For instance, the information request pattern (cf.Table 1) can be identified in the context of activities for which the user has to provide information to the system (e.g., by entering data via an electronic form).In case of the uniand bidirectional performative patterns, in turn, both activity descriptions and activity results (e.g., whether results are mandatory or not to trigger the subsequent activity in the process) are important to measure how often patterns occur.
What surprises is the fact that all analyzed process models can be defined as a composition of the investigated patterns; i.e., the described set of activity patterns is necessary and sufficient to design all 239 process models that have been subject of our analysis.(Remember that Table 1 only shows selected pattern variants and does not cover all process fragments that can be configured).Furthermore, in each process, a specific activity pattern may appear multiple times in combination with other patterns.
The latter observation can be considered as very important one, which raises additional research issues.One challenging question, for example, is to what degree the identified patterns will be helpful when integrating them into a workflow modeling tool.In Section 6 we describe such a tool we are currently developing.In particular, it should foster reuse of activity patterns (cf.Section 6).Fig. 13 shows an example of a process model which has been composed solely based on the described activity patterns.

Formalizing Activity Patterns with -Calculus
Basically, the activity patterns are independent of a concrete process modeling language; i.e., they can be adapted to any BPM tool if desired.In order to enable this, a precise formal semantics of the described patterns is needed.Such formal semantics is also fundamental for the correct modeling of business processes and thus for implementing robust process-aware information systems [Reichert 1998].Thus, when composing process models out of activity patterns it is extremely important to verify their correctness.
Commercial BPM tools (e.g., Oracle BPEL Engine, Intalio), however, do not rely on a formal semantics in order to verify process model correctness.

Decision result
Preparation request

Receive request to perform examination Perform examination
Transportation request

Receive request to write report Write report
Report

Decision result
Preparation request

Receive request to perform examination Perform examination
Transportation request

Receive request to write report Write report
Report request

Appointment request
Patient prepared

System
Approval result

Figure 13. Real medical examination process build up exclusively from the combination of workflow activity patterns
Recently, a couple of approaches has emerged which allow to map business process models (e.g., specified with BPMN or UML) to formal process specifications (e.g., using Petri Nets or -calculus) [Brogi 2004], [Puhlmann 2005].Based on such formalizations, for example, it becomes possible to ensure formal process model properties (e.g., soundness [Dehnert 2005], to decide whether two process models are equivalent [Li 2008b], or to optimize and refactor process models [Weber 2008b].
In the following we propose a formalization of the activity patterns using -calculus.
The -calculus formalism constitutes an extension of CCS [Szturc 1999].In particular, it allows representing the behavior of concurrent and dynamic processes.In recent work -calculus was used to formalize business process models and workflow patterns [Smith 2003], [Puhlmann 2005].As mentioned, there exist other methods (e.g., Petri Nets) which can be used to formalize workflow patterns [van der Aalst 2003a].Due to their dynamic properties, however, the formalization of specific workflow patterns (e.g., advanced synchronization patterns, multi-choice patterns and cancel patterns) is not trivial when using Petri Nets.In addition, as -calculus is based on message exchanges, it provides an efficient formalism to represent cross-organizational processes.
Our BPM tool uses the formalization of the activity patterns to create the formal representation of the process models composed out of the different patterns.Thus the composed process model can be simulated and validated already at design time in order to exclude errors.In the following we show how the activity patterns can be formally represented based on the -calculus formalism.We first introduce the -calculus formalism, explain how it is used to formalize the activity patterns, and finally present the formal representation of a process modelled solely based on the activity patterns.

An Introduction to -Calculus
The -calculus formalism was introduced by [Milner 1992].Its underlying theory captures core characteristics of concurrent systems such as mobility and dynamics.
Basically the -calculus consists of processes and names, whereas the names define links between the processes.For the present work we use the monadic version of the calculus in accordance with the following grammar (see [Milner 1992]): Here a and b are meta-variables over elements of a countable and infinite set of names (N).Processes can be the stop process 0, prefixed process .P, restricted process (a)P, sum of processes P+Q, parallel composition P|Q, and replication !P.A prefix  can be:  a silent prefix .P representing an internal action of the process;  an input prefix a(b).P , which receives a new name through a, whereupon the process P continues with all the occurrences of b substituted by the new name;  an output prefix ab.P where the name b is sent to another process through a;  a match prefix [a = b].P; i.e., if a equals b, the process will continue as .P.
In this work we are considering the semantics as presented in [Milner 1992]; we use a graphical notation to visualize the processes.Figure 14 shows the graphical representation for the following simple process: A|B with A = a(b).0and B = ab.0.

Figure 14. Example of Graphical Representation
In the used graphical notation, a process is represented by a circle with its name inside the circle (in the following denoted as -process).Furthermore, the processes are connected by a line representing a communication channel between them.The end of the line, which connects the processes, represents the input prefix.It is marked with a point followed by the communication channel name.

Mapping Workflow Activities to -Processes
Our formalization is based on the following idea: all activities contained in a process model are mapped to corresponding -processes, whereas each -process has its preand post-conditions.In principle, this corresponds to Event-Condition-Action (ECA) rules [Puhlmann 2005].
An ECA rule has three components: an Event, a Condition, and an Action.The Event component specifies when a rule must be evaluated.If an event occurs, the Condition component will have to be verified.If the condition evaluates to "true", the Action component will have to be executed.For process models we must additionally consider other kinds of rules including Event-Condition-Action-Action (ECAA) and Event-Action (EA).It is beyond the scope of this paper to describe ECA rules in details.Further information can be found in [Puhlmann 2005].
Regarding a -process events are modeled as input prefix.Following such an input prefix one can include an optional condition to be evaluated.This condition is modeled as a match operator (e.g., [a = b]) of the -calculus.Furthermore, actions are divided in two parts.In the first part the execution of the activity is represented by a silent action of the -calculus ().The second part corresponds to an output prefix that enables synchronization with a subsequent -process.Thus, a -process that represents a workflow activity is defined as follows: x .[a = b] . y .0 A -process begins with a trigger of its input prefix x which corresponds to the event of an ECA rule.Afterwards, matching operator [a = b] is evaluated and mapped to a condition of the ECA rule.The component ( y) corresponds to the action of an ECA rule; the -process executes internal action  and synchronizes with a subsequent process through output prefix y.

Basic Control Flow
Recently, the semantics of the control flow patterns [van der Aalst 2003a] was specified using -calculus [Puhlmann 2005].Control flow patterns are particularly useful for defining workflow behavior.In the following we exemplarily consider the control flow patterns Sequence, AND-Split, and AND-Join in order to better understand how process behavior can be formalized using -calculus.In addition, the respective control flow patterns will be later used in the formalization of our activity patterns.
Sequence: Using this control flow pattern, an activity is enabled after completion of its preceding activity (within same process model).As aforementioned, activities can be represented as -processes.Thus, a sequence between two -processes A and B can be realized by sending a synchronization message from A to B as shown in Figure 15.i.e., the names exchanged between the -processes are not relevant with respect to the control flow between the two activities.Accordingly, in this paper the label of the message to be transmitted has no influence regarding the execution of the patterns.

AND-Split:
A single thread of control splits into multiple threads of control that can be executed in parallel, thus allowing activities to be executed simultaneously or in any order.Accordingly, a -process A needs to synchronize with the other two -processes B and C in parallel, i.e. after executing A, activities B and C are executed in parallel.This representation is depicted in Figure 16.-calculus has proven to be an adequate formalism for enabling the verification of correctness properties of a process [Yang 2003], [Puhlmann 2005], [Szturc 1999].In the following we sketch how some of the described activity patterns can be formalized based on -calculus.For a complete formalization we refer to [Nascimento 2007].
Approval Pattern: Fig. 18 shows the formal definition of the single approval pattern, using -calculus.Note that we represent the approval cycle for exactly one organizational role as bidirectional pattern.The sender is represented by WORKFLOW_APP and the receiver by REVIEWER.The pattern synchronizes with an approval (represented through the -process NA') or with a disapproval (represented through the -process NR').Unidirectional Performative Pattern: In order to formalize the unidirectional performative pattern in -calculus we translate the roles Sender and Receiver into two concurrent -processes SENDER and RECEIVER respectively.Furthermore, as for other patterns there must be a concurrent -process (here denoted as START) to enable interaction with others activities of the workflow.The processing of the pattern begins with the -process START.This -process synchronizes with the -process SENDER through a message labeled a.In the sequel -process SENDER, synchronizes with the -process RECEIVER through a message labeled b.After triggering this -process, it can execute the respective task (here denoted as  z ).Note that after synchronizes with RECEIVER the -process SENDER itself continues as NS' without waiting for a response from the -process SENDER.Here, NS' means that the pattern can synchronize with a subsequent activity through a message with label c (substituting NS' for c.0) or terminates the process with 0 (substituting NS' for 0).This mapping is presented in Figure 19.In Figure 19 the unidirectional performative pattern is instantiated passing inf as parameter.This label represents the information request which is transmitted to the receiver through the exchange of messages between the -processes.Note that inf is transmitted as message to SENDER using label a in START.The label inf then substitutes parameter x transmitted to SENDER.The same applies to SENDER which forwards the message received in y through label b to RECEIVER.Thus RECEIVER receives the message for z; the notation  z  represents the internal processing of the message by RECEIVER.Finally, another important aspect depicted in Figure 19 concerns the scope of the labels between activities.Labels a and b are used to enable communication between the -processes START (SENDER) and SENDER (RECEIVER).These labels are restricted to the scope of the pattern.If NS' represents the synchronization of the pattern with the following workflow activity, NS' will have a label not restricted to the pattern to enable this communication (e.g., c.0).

Bi-directional Performative Pattern:
To formalize the bidirectional performative pattern we synchronize the -processes SENDER and RECEIVER immediately after RECEIVER has processed its message ( z ).This synchronization is represented using label c.The SENDER continues execution with NS' similar to the unidirectional performative pattern.Figure 20 shows the -calculus representation of this pattern.

Example of a Process Model Formalized with -Calculus
To illustrate the use of -calculus we formalize the healthcare process from Fig. 13.Fig. 21 shows the resulting representation in-calculus.We use names an, bn and cn (where n is a number) as internal names of each activity.The names sn (where n is a number) represent names to synchronize the activities.
The first activity OE (Order Entry) begins with  and the subsequent activities synchronize with the previous ones.For example, MAR (Make Appointment with Radiologist) synchronizes with OE through s1.Observe that VMR (Validate Medical Report) has no name for synchronization (s n ) since this activity terminates the process.
Another important aspect is the activities MAR (Make Appointment with Radiologist) and GAP (Get Authorization from the Patient) which represent a loop in the process.When a disagreement occurs the two activities may be repeated.This particular situation is represented through the replication command of -calculus (!).The two activities are replicated after their execution.

Towards a BPM tool based on Activity Patterns
This section presents basic components of a BPM tool, which allows for the design of process models based on activity patterns and their reuse.The patterns are described by means of an ontology, which has been described in details in [Thom 2008].This ontology must be used for implementing the recommendation mechanism of our BPM Tool.Altogether, the main goal of this ontology is to better structure the activity patterns, their attributes, and their relationships.In addition, the ontology maintains the use statistics of each activity pattern (in the context of process modeling) as well as the co-occurrences of patterns pairs (cf.Section 4.3).
Core functionalities of our BPM tool are as follows: Assisting users in designing proper process models: First, the process designer selects the kind of business process (e.g., human intensive) to be modeled, which is then matched to a set of business functions as maintained in the ontology; i.e., the BPM tool adopts a set of business functions to be used for process modeling in the given context.Following this, the process designer chooses a business function and provides contextual data (e.g., about the organization).This information is then matched to an activity pattern as maintained in the aforementioned ontology.Furthermore, the BPM tool recommends the use of the respective activity pattern and helps to apply corresponding design choices; i.e., to configure a concrete pattern variant.Afterwards, the tool recommends the most suitable activity patterns to be used together with the activity pattern applied before.In addition, it informs the user about how frequently each pair of activity pattern (i.e., the previously applied activity pattern plus the recommended activity pattern) was used in earlier modeling.This module is developed based on the analysis results presented in Section 4.3.
Ontology construction for activity patterns: Our ontology for activity patterns does not only maintain the patterns themselves, but also the frequency with which each pattern has co-occurred with a previously used one.Through analyses of additional process models (e.g., from the automotive as well as the healthcare domain) we aim at increasing the support value of such pairs of activity patterns (cf.Section 4.3).Thus, at design time the pattern pairs being recommended help to design a process model which is closer to the business process as we can find it in the organization.
Core components of our BPM Tool are as follows (cf.Fig. 22):  Query Component: It provides a query mechanism for matching the activity patterns maintained by the ontology with the given kind of business process (e.g., human intensive), business function (e.g., approval), organizational context (e.g., level of centralization in decision-making), and corresponding design choice as selected by the user (if not set automatically).
 Ontology Manager: It comprises ontology and query mechanism (enabling queries for business functions and activity patterns respectively).The ontology describes the activity patterns (cf.Fig. 6) and their properties (e.g., attributes and relationships with other patterns).The provided query and update mechanisms give design time recommendations with respect to the most suited activity patterns to be combined with a previously used one.An example of a query would be the selection of the business functions which occur more frequently in systemintensive process models.In addition, our update mechanism has to be used to adapt the relative frequency of each pattern pair (e.g., based on the analysis of new process models) as identified in our process model analysis.
 Scheme Translation: This component is responsible for translating a process model (based on translation algorithms) which uses activity patterns as building blocks (stored in XML code) to either a conventional notation (e.g., BPMN) or an existing process execution language (e.g., WS-BPEL).The use of this translation component is optional, i.e., it will be only applicable if the user wants the respective process model being translated to another notation and process execution language respectively.
 Business Process Model Checker (BPMC): The objective of this module is to verify the correctness of the process models as composed out of the activity patterns.The verification is done through simulation and verification of the properties of the composed process models.This module consists of two parts: -Translation of process model into a -calculus representation: consists of algorithms to translate a composed process model into a -calculus representation.This translation is done based on the formalization of the activity patterns as sketched in Section 4.3.
-Model Checking Algorithms: the obtained -process is simulated through model checking algorithms as known from -calculus theory.The simulation must prove the correctness properties of the modeled process.
Related to that we are considering the use of existing tools for model checking in -calculus (e.g., [Björn 1994]).Thus the BPMC module will only interact with the model checking tool, without considering the complexity of the algorithms used to simulate a -process execution.Altogether our BPM tool fosters the modeling of business processes based on the reuse of activity patterns.In particular, the recommendation mechanism supported by this tool can be considered as a very important functionality which shall optimize the process design and increase its correctness.Finally, we plan to use our tool for conducting a series of experiments in which we compare process modeling with and without activity pattern support.

Summary and Outlook
This paper has deal with workflow activity patterns, each of them based on a frequent process fragment (e.g., a task execution request, notification activity, approval).The patterns are tool-independent, which make them easier to be adapted for any business process modeling (BPM) tool.Moreover, based on a relatively small set of patterns a multitude of processes can be modeled.This, in turn, contributes to reduce complexity with user learning.The analysis of 239 processes models, stemmed from different organizations and application domains, has evidenced that the patterns appear to be necessary and enough to design at least the process models we have analyzed.We have also investigated how often specific co-occurrences of activity patterns appear in a selected set of the studied process models.These analyses must be used in the development of a recommendation BPM tool.
By formally representing the patterns using -calculus we expect to reduce their ambiguity.Moreover, a workflow model written in -calculus can express the dynamic behavior of the business process, thus making it possible to verify formal properties of the model, such as soundness, deadlocks, livelocks and equivalence.
The specification of processes in -calculus can also improve workflow optimization.A business process written in -calculus can be optimized through the identification of active names.Nascimento (2006) shows algorithms to optimize -processes through active names collection.Thus, we could map business processes to -calculus and use algorithms to reduce the size of the business process.
The -calculus is a textual notation (action based) and it has no intuitive graphical notation.To minimize this problem, we intend to map some conceptual language such as BPMN to the -calculus.This would allow us to use the -calculus as an internal representation of a framework for workflow modeling.By doing that we expect to enable the specification based on a business process in high-level notation, but without losing the possibility of formal verification.
As future work we will consider the results of the aforementioned case studies as well as the analyses of other process models in order to derive new pattern variants and patterns, respectively.We also intend to make an experiment for comparing process modeling with and without workflow activity patterns support.Last but not least, we intend to investigate how to transform process models defined with our tool (and being based on the activity patterns) into conventional notations and languages respectively.

Figure 1 .
Figure 1.Process for accomplishing a medical examination of a patient Figure 2. UML Notation used to informally summarize the activity patterns semantics

Figure 7 .
Figure 7. Frequency of activity patterns within real process models

Figure 10 .
Figure 10.Frequency of activity patterns within Electronic Change Management

Figure 12 .
Figure 12.Frequency of co-occurrences of the decision pattern within other pattern

Figure 16 .
Figure 16.AND-Split Pattern AND-Join: After the execution of two parallel processes it becomes necessary to synchronize them.For example, synchronization of two -processes B and C with a subsequent -process D is illustrated by Figure 17.

Figure
Figure 17.AND-Join Pattern

Figure 18 .
Figure 18.Formal Definition of the Single Approval Pattern.

Figure 19 .
Figure 19.Formal Definition of the Unidirectional Performative Pattern

Figure 20 .
Figure 20.Formal Definition of the Bidirectional Pattern.