methodology for mapping business process into

Shaheen Khatoon et al. / International Journal of Engineering Science and Technology (IJEST)

METHODOLOGY FOR MAPPING BUSINESS PROCESS INTO EXECUTION LANGUAGE SHAHEEN KHATOON* Dept of Computer and Applied Technology Huazhong University of Science & Technology (HUST) Wuhan, China [email protected]

AZHAR MAHMOOD Dept of Computer and Applied Technology Huazhong University of Science & Technology (HUST) Wuhan, China [email protected] Abstract: Business process life cycle consists of different phases of development which are executed in certain order. Over the last decade, the discipline of Business Process Management has evolved to automate business processes for better performance. For this purpose, Business Process Modeling Notations (BPMN) and Business Process Execution language (BPEL) have been designed not only to facilitate business and technology people to effectively perform their work but also to bridge the gap between them. BPMN is a graph-oriented language developed to create notations for use by the business community to define abstract business process in workflow. BPEL on the other hand is a block structured language that has emerged as a de facto standard for implementing executable business processes which specify technical details of the workflow. In the current development scenario, the development of enterprise level application starts with BPMN models followed by transformation of these models into BPEL process definition for subsequent implementation by software developers. Since, BPMN diagrams can be mapped to BPEL processes, consequently it supports a seamless conversion of business model and IT implementation. However, this transformation is not straightforward due to conceptual mismatch of BPMN and BPEL. In this paper BPMN is evaluated analytically to find the representation and semantic mismatch with BPEL and propose a unique approach which can be used to remove the structural and synchronization mismatch of BPMN and BPEL. The proposed approach is accomplished by developing a methodology which transforms the BPMN model into a semantically equivalent block diagram which can be directly transformed into BPEL. Keywords: BPM; BPMN; BPEL; Model Transformation. 1. Introduction Business Process Management (BPM) is an important discipline for building, maintaining and evolving large enterprise systems. Different process models are employed through a business process life cycle by converting phases of development into design, implementation, deployment and evaluation. The design phase encompasses development of conceptual process models from a business analyst perspective. The resulting conceptual models in the design phase serve as an impetus for developing implementation models in the form of executable workflow specifications to help technical analysts. Finally, specification developed in the implementation phase deployed on a workflow engine. In the last phase, the deployed process is examined and evaluated for improvement in subsequent iteration of the business process life cycle [1].In the process design and implementation phases, different modeling languages are used to capture the business requirement as well as workflow specification. The conversion of design phase into an implementation phase is not straight forward and often results in inconsistencies due to which there is an utter loss of design considerations within the execution model. To overcome the above stated problem, Business Process Modeling Notation (BPMN) [2] has been developed to provide standard notations for executable process to bridge the gap between process design and implementation phases. The core objective of BPMN is to facilitate the communication between business analysts and technical analysts by allowing analysts to capture as much of the intended process as possible in a way that can be easily

ISSN : 0975-5462

Vol. 3 No. 1 Jan 2011

696


consumed by developers. The R & D work done so far in this area, however, shows that the desired goal is not yet achieved. On the other hand, in the area of process implementation, Business Process Execution Language (BPEL) [3] is emerging as a de facto standard for implementing executable business process which specifies the technical detail of workflow specification. BPEL process definitions are more detailed than BPMN. For example, BPEL include elements related to data manipulation, web service binding and other implementation aspects that are not present in its counterpart BPMN models [4]. In this paper, BPMN and BPEL are analyzed with respect to their basic modeling approaches, graph structure and block structure. Typically, mapping a model A to a model B and then reverse mapping the model B [13] results in a different model than the original model A. The main reason for this anomaly is that there are different strategies for the mapping and lack of support for arbitrary cycle and interleaved process in blockstructured languages. The arbitrary sequence flows allowed in BPMN are similar to GOTO statements. BPEL does not have a GOTO activity therefore, transformation is not possible without reengineering a semantically equivalent block diagram. There is a need to emulate these constraints by constructs offered by the blockstructured language. Our proposed approach accomplishes this task by redrawing semantically equivalent blockstructured diagram by developing a methodology which properly outlines the BPMN model before transmission. It is envisaged that by addressing these two aspects, a significant number of BPMN models can directly be transformed to BPEL.. BPMN models are created in editor of ADONIS business process management toolkit developed by BOC in collaboration with the University of Vienna that offers essential tool support for reengineering and reorganization of projects. This paper consists of seven sections. This section presents an introduction to BPM and its constituents. Section II provides background information related to our work. Literature review is outlined in section III. Section IV describes a Problem statement. Section V contains the proposed mapping methodology. Section VI contains case study use to validate the proposed model. Finally, conclusion and future work summarized in section VII. 2. BACKGROUND OF BPMN AND BPEL 2.1. BPMN The Business Process Management Initiative (BPMI) has developed a standard BPMN which is a graph oriented language that helps business analysts to create notations to define abstract business process in workflow [2]. The BPMN 1.0 specification was released in May, 2004 and adopted by Object Management Group (OMG) for standardization purpose in February 2006. The primary goal of the BPMN is to provide a notation that is readily understandable by all business users. BPMN not only helps the business analysts to create initial drafts of the business processes but also assist the technical developers who are responsible for implementing the technology that will execute those business processes; and finally, it is also useful to those individuals who will manage and monitor these business processes [6] .It also provides a more technical concepts as well as rich modeling notations for business experts. The BPMN working group developed a specification document that differentiates BPMN into a set of core graphical elements and an extended specialized set of constructs. The core set depicts the essence of business processes in intuitive graphical models, while the complete/specialized set provides additional constructs to support advanced process modeling concepts such as process orchestration and choreography, workflow specification, event-based decision making and exception handling. On the whole the complete BPMN specification defines 53 constructs plus attributes which are grouped into four basic categories of elements: - flow objects, connecting objects, Swimlanes and artifacts. Flow Objects are most basic elements such as events, activities and gateways that are, used to create Business Process Diagrams (BPDs). Connecting Objects are used to inter-connect flow objects through different types of arrows. Swimlanes are used to group activities into separate categories for different functional capabilities or responsibilities e.g. roles, systems or departments. Artifacts may be added to a diagram in order to display additional associated information such as processed data or other comments [7]. Fig. 1 shows the main symbols of BPMN.

ISSN : 0975-5462

Vol. 3 No. 1 Jan 2011

697


Figure 1. BPMN Main Symbols[8]

2.2. BPEL BPEL [9, 10] is a standard expression language for defining executable processes and specifying business process behavior. BPEL is an extension of imperative programming languages with constructs specific to web service implementations. A BPEL process definition links up a number of basic and structured activities. Basic activities correspond to atomic actions such as: Invoke - invoking an operation on a web service, Receive waiting for a message from a partner, Exit - terminating the entire service instance, Empty - doing nothing. To enable the presentation of complex structures the following structured activities are defined: Sequence - for defining an execution order, Flow- for parallel routing, Switch- for conditional routing, Pick- for race conditions based on timing or external triggers, While- for structured looping, and Scope- for grouping activities into blocks to which event, fault and compensation handlers may be attached. An event handler is an event-action rule associated with a scope structure. It is enabled when the associated scope is under execution and may perform concurrently with main activity of the scope. When an occurrence of the event associated with an enabled event handler is registered (e.g., a message receipt or a timeout), the body of the handler is executed. The completion of the scope as a whole is delayed until all active event handlers have been realized. Finally, the fault and compensation handlers are designed for exception handling [10]. 3. Related Work Transformation between BPMN and BPEL is an active area of research and most of the research conducted in this field is analytical in nature and only few insights exist into the practical use of BPMN. In this section we discuss different approaches related to our work. Ouyang et al., [10, 11] proposed that BPMN to BPEL transformation be accomplished by phase matching of pattern and graph transformation. An algorithm for generating readable BPEL code from BPMN model is presented in [10] which generate BPEL code from BPMN model by discovering structural patterns in the BPMN models which in turn are mapped into BPEL structured activities. The original BPD is decomposed into well structured components having one entry and one exit point. The automated BPDs are then incrementally transformed into BPEL blocks. For example, a component having purely sequential structure is mapped into BPEL sequence construct, while a component holding a parallel structure is mapped into flow construct. BPEL generation algorithm also transforms unstructured subset of BPMN model by exploiting event handler construct of BPEL. As a result, any BPMN model that composed of tasks, events, parallel gateways and XOR gateways connected in arbitrary topologies can be mapped to BPEL. Whereas, a model with unstructured topologies or having constructs such as OR-join and complex gateway cannot be mapped to BPEL. Further, BPEL generation algorithm only translates a smaller set of patterns captured in core subset of BPMN model by applying certain restrictions on original model such as every loop must have one single entry and exit point. A well-formed core BPD may contain the components that are not well structured e.g. loops with more than one entry/exit point. Ouyang et al., [11] present an approach that can be used to translate such component into a scope activity by exploiting the event handler construct of BPEL. Event handler is enabled while the scope is under execution and thus the corresponding translation is based upon the event action rule. Since, a wellstructured pattern impose restriction on BPDs, therefore, proposed approach [11] not only maps block-structure in BPMN model but also accounts for quasi-structure and flow based acyclic fragment into block structure BPEL. Quasi-structure patterns are those patterns which can exhibit well-structuredness e.g. splitting a gateway into two gateways without changing semantics to separate the incompatible parts. Three types of quasi-structure patterns are define by exploiting FLOW, SWITCH and PICK constructs of BPEL. Acyclic patterns are also mapped to BPEL block structure code using BPEL control links. The key idea is to transform all well-structured

ISSN : 0975-5462

Vol. 3 No. 1 Jan 2011

698


patterns into BPEL as proposed in [10]. The transformation process first transforms the well-structured patterns followed by quasi-structured patterns and then the acyclic graphs to BPEL block structured code. A general framework for Business to IT transformation by considering the issues and variation points at different levels of transformation is presented by Stein et al., [12]. Their framework presented the entities at two levels of abstraction; business and IT as well as their relationship by using the modeling perspective of process, data and interaction. The framework proposed by Stein et al. lacks implementing the merge of different model versions. Moreover, the proposed framework is purely conceptual and does not provide any instance of practical validation. The conceptual mismatch between BPMN and BPEL are highlighted by Pecker and Mendling in [5]. Their analysis exposes mismatches with respect to various perspectives of BPM life cycle particularly from business and technical analyst perspectives. To identify the conceptual mismatch between business and technical analyst, process model should identify mismatch with respect to domain representation capabilities, control flow support and process representation paradigm. Their solution is built on the established evaluation theories in the domain of representation theory, control flow framework [8] and set of transformation strategies [1]. A critical analysis reveals that BPMN provides a richer set of modeling constructs and some of the constructs cannot be expressed in BPEL, therefore, there is a chance of information loss. During implementation phase, the BPEL process definition is changed. As a result, the inconsistencies may arise between the original business model and the implemented process. To tackle this issue a detailed analysis of BPEL to BPMN mapping and its pitfall is elaborated by Weidlich et al., in [13]. They evaluate the BPEL basic activities, structured activities and generic concepts to the corresponding constructs in BPMN. Their analysis shows that essential BPEL activities can be mapped directly to BPMN while some of them like event handlers, termination handlers and validate activity cannot be mapped. Pattern based assessment of BPMN and BPEL in area of data flow is presented by Wohed et al., in [14]. A comparison of language expressiveness of BPMN using the workflow pattern as an evaluation framework is outlined by the authors. BPMN is evaluated in terms of control flow, data and resource perspective. Ontological based evaluation of BPMN using Bunge-Wand-Weber (BWW) representation model as an evaluation framework is presented in [7, 15, 16]. This theoretical model is used to compare the expressiveness and complexity of process modeling language based on an analysis of their domain representational capabilities. Representational modeling capabilities between BPMN and BPEL4WS (Business Process Execution Language for Web Services) by using BWW model is analyzed in [7]. The model uses the representational analysis for investigation of modeling techniques’ strength and weaknesses. Two evaluation criteria as per the BWW representation are analyzed which are (i) ontological completeness: the analysis of the extent to which a process modeling technique covers completely the set of constructs proposed in the BWW representation model, and (ii) ontological clarity: the analysis of the extent to which process modeling technique constructs are deemed redundant, overloaded or excess Potential and perceived shortcomings of BPMN are highlighted by Pecker et al., in [15]. Their evaluation is based upon the BWW representational model which is capable to provide complete and clear description of domain being modeled. Two evaluation criteria ontological completeness and ontological clarity are studied according to BWW model. Their study derived nine theoretical propositions to show how the lack of ontology completeness and clarity lead to problem for a modeler using BPMN. The identified propositions are grouped into construct deficit, construct redundancy, construct access and construct overload. The identified propositions are tested by conducting semi-structured interview protocol. However, their investigation shows that most of the propositions are theoretical in nature and do not cause any potential problem in process modeling practice. Mendling et al., [1] studied the identification of different transformation strategies between graph-oriented and block-oriented modeling languages for transformation of underlying process representation in target modeling language. They used BPMN for graph-oriented paradigm using arc to define order of activities and gateway to express join and split behavior. BPEL uses the block oriented paradigm to represent control flow using structural activities. BPMN is abstracted as process graph and BPEL is abstracted as control flow. A process graph is structured if split gateway is matched to the join of the same type and if loop are entered at one XOR-join and exited at one XOR-split. Wohed et al., presented analytical evaluation of BPMN using Semiotic Quality Framework [17]. Semiotic framework is used for understanding and evaluating the quality of conceptual modeling in general. It is based on linguistic and semiotic concept such as syntax, semantic and pragmatics that enable the quality assertion at different levels. Their study concludes that BPMN particularly excels in terms of comprehensibility appropriateness due to its construct specializations and type aggregations, and is well-suited for the domain of business process modeling. As BPMN has widely been used to model complex software system, there is a need to define a formal semantic for BPMN to ensure precise specification and to assist developers for implementing correct business process. The comprehensive BPMN formalization is presented in [18, 19]. Decker and Mendling [18] have discussed incompatibilities between BPMN and BPEL regarding process instantiation. The authors introduce a

ISSN : 0975-5462

Vol. 3 No. 1 Jan 2011

699


framework known as Creation, Activation, Subscription and Un-subscription (CASU) to categories process instantiation mechanism. BPEL processes always instantiated through a single message either received by a receive activity or by a pick activity. For creating multiple instances, the message activities are configured for instantiation purpose via the Boolean attribute create instance. BPEL follows the variety of scenarios with respect to multiple start activities. Subscription is established either for all of the remaining start activities or only for reachable start activities. The study in [18] reveals that there is a no way to issue subscription with respect to multiple start events. There is only one possibility for multiple start events i.e. multiple start events are directly connected to an activity which is configured by dedicated attributes, so, multiple start event has to wait for occurrence of all events before the process instance is created. BPEL scenarios involving multiple start activities cannot be expressed in BPMN owing to lack of subscription mechanism. Evaluation of BPMN core and extended set in term of its construct usage is presented by Muehlen and Recker [20]. They analyzed 120 BPMN models empirically - using mathematical and statistical techniques such as cluster analysis, frequency analysis, covariance analysis and distribution analysis - to demine which elements of BPMN are used in practice. Three sample set data sources consisting of web (models from internet search), seminar (models obtain from education seminar taught by authors) and consulting (consulting projects) models are used for analysis. The results reported by the authors show that four constructs are common to more than 50% of diagrams i.e. Sequence Flow, Task, Start and End Events. In addition to identification of most frequent constructs in use, pairs of BPMN constructs that are generally used in combination or alternating fashion are also identified. The reported results show that the combination of Task and Sequence Flow is primarily the more apparent subset followed by the Start and End Event. However, the empirical evidence presented by the authors is limited to smaller set of data. 4. Problem Statement Pattern-based analysis of BPMN and BPEL [14] shows that BPEL misses the equivalent transformation for arbitrary cycles and multiple merge patterns. It has been observed during creation of BPMN models, if these two mismatches are addressed then a broad range of BPMN models can by transformed directly into BPEL. In our proposed approach, a solution to two other scenarios i.e., arbitrary cycles and interleaved flow is presented. By adopting this solution, a large set of BPMN models can be transformed to BPEL. 4.1. Arbitrary Cycles BPMN provide direct support for arbitrary cycles i.e. the support for multiple ways of entering and exiting the areas with repetitive activities. BPEL does not allow modeling of arbitrary cycle. BPEL only supports structured cycles, with one entry point and one exit point that can be map directly to a BPEL “while" activity as the “while" activity only captures structured cycles [11]. Arbitrary loops would cause problems in Synchronizing Workflow Models (SWM) by creating deadlocks and multiple active instance of same activity [21]. Multiple instances can lead to some undesirable results, such as redundant activities, competition for resources and dangling activities (e.g., one instance is synchronized with an activity and the other instances are left dangling). 4.2. Interleaving Processes The second aspect of transformation addressed in this paper is how to handle models that contain interleaving process segments. In an interleaved process, multiple activities merge on a single activity without any control. In BPMN, interleaved processes are modeled by using multiple merge patterns i.e., when a token arrives at an activity, that activity is instantiated. Thus, if there are multiple paths converging on an activity without any token control then it is possible that the activity will be instantiated only once for each of the paths which are merged. Furthermore, the tokens will continue independently through the remainder of the process. Hence, for each Token that arrives at an incoming Sequence Flow, a separate instance of the activity will be generated. Multiple Merge pattern is potentially very confusing for a business person to be able to understand the behavior of a section of the process. The flow can be executed in any order which causes multiple instances of the same activity. There is a restriction in BPEL against cycles in flows that makes it difficult to represent interleaved loops in standard BPEL. 5. Proposed Methodology Our proposed model to resolve interleaved flow and arbitrary cycle problems described in this section. As shown in figure 2, it takes valid BPD model as input and producing BPEL constructs as output. The proposed model is based on arbitrary cycles and multiple merge workflow patterns which are not supported by BPEL. The final output is deployable BPEL fit into special business need to improve the efficiency of project team. As the transformation process generates valid BPEL processes similar to that already in use, the implementation of the solution has only minimal impact onto the overall development process.

ISSN : 0975-5462

Vol. 3 No. 1 Jan 2011

700


A BPD will be initially validated, after the validation the model search for both problems sequentially. First look for arbitrary cycles and if exists it resolves as per methodology by removing generalization and introduce gateways, messages flows, breakdown entities and remove deadlocks by directing sequence flows towards gateways. It is done by decomposing the original model into structural one which can be translated directly to BPEL. If the original graph is well-structured, the resulting BPEL code follows structure of the original graph and accurate transformation is achieved. But, if the BPMN graph is not structured then the translation generates quite convoluted BPEL code and the way back to BPMN becomes complicated. It also increases readability of business process and also helps in reverse transformation, While solving arbitrary cycles it may possible that the model contains the problem of interleaved flows, the model search this problem and then resolve by creating a reference activity where the deadlock occurs. For structure language transformation it is necessary that every activity must have one input and output before transforming into execution language.

Figure 2. Model Architecture

6. Case Study Proposed methodology is implemented by using case study of Student Registration System. We have used ADONIS business process management toolkit developed by BOC for implementation. Results shows the redrawn model using the proposed methodology is 100% transformable into BPEL code ready to deploy. 6.1. Methodology adopted for Arbitrary Cycles Arbitrary cycle is validated using a scenario of Student Registration System shown in Fig.3.In given scenario a student submit the Project proposal based on this proposal student will complete the project and submit the Project to the respective supervisor. After the review, supervisor may approve the project or forward to senior supervisor for the Final Approval. The senior supervisor may approve the project or suggest changes back to In case of suggest changes from senior supervisor and in case of supervisor rejection produced the arbitrary cycle but for BPMN it’s a valid BPD. While transforming into BPEL it generates semantic error. This problem is resolved by applying proposed methodology that defines rules to resolve such type of problems and removes generalization from the process. Generalizations in IT systems don’t belong in a business process e.g. in a business process there is a difference between the first time (Complete the project and submit it) and the consecutive actions that are taken. You can’t avoid the first edit by supervisor and review, but every edit action after that should be kept to a minimum. A new activity called Suggest Changes and an event will be added in the process to show either it’s a revision change or submission message. Finally, review flow will also be changed so if the supervisor agrees with all the changes made by the student he can directly approve or may consult senior supervisor to approve or reject the proposal. The overall BPM is redrawn as shown in Fig 4.

ISSN : 0975-5462

Vol. 3 No. 1 Jan 2011

701


Figure 3. Arbitrary Cycles Problem

Figure 4. Arbitrary Cycles Solution

6.2. Methodology adopted for Interleaved Flows Interleaved Flows is validated by using another scenario of Student Registration System shown in Fig.5. A student application comes for registration, if all the documents are completed it forward to Approval activity, if editing is required it sends to Editing activity and make changes by admission officer then send to Approval activity, and if approval is not required and all the relevant documents are complete then admission officer directly approve the application. For BPMN this is valid model implemented through multiple merge patterns i.e. when approval Token arrives at an Approval activity, that activity will be instantiated but for BPEL generator Application=Approval path mixes the tokens. So now after validation of BPD, BPEL generator shows error due to interleaved flows found in BPD. This problem is resolved by applying proposed methodology that defines rules to resolve such type of problems by creating duplicate activity of approval task which is a reference to original activity. It makes the model large but increases the readability and removes the interleaved problem as shown in Fig.6. The redrawn model through proposed methodology is successfully validates and transform into BPEL without generating any errors.

Figure 5. Interleaved Flows Problem

ISSN : 0975-5462

Vol. 3 No. 1 Jan 2011

702


Figure 6. Interleaved Flows solution

7. Conclusion In this fast changing world, the business needs are rapidly varying due to global competition being faced by the organizations. An efficient and preset orchestration of business processes is need of the time to get better performance results by meeting the business needs. An evaluation of the BPM processes indicates that the recent transformation techniques neglect the challenges in mapping of BPMN to BPEL. The challenges indicate that there is still a room for further improvement in both areas to overcome mismatches among these technologies. In this paper, a mapping methodology is proposed to remove couple of issues based on arbitrary cycles and multiple merge workflow patterns which are not supported by BPEL. The final output is deployable BPEL that fulfils special business needs and improves efficiency of the project team. As the transformation process generates valid BPEL processes similar to that already in use, the implementation of the solution has only minimal impact onto the overall development process. In future we are going to develop a tool which automatically detect anomalies in existing BPM model and redraw it according to format supported by BPEL. 8. References [1]

[2] [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19]

J. Mendling, K. Lassen, and U. Zdun, "Transformation strategies between block-oriented and graph-oriented process modelling languages, In Lehner, F., N¨osekabel, H., Kleinschmidt,P., eds.: MultikonferenzWirtschaftsinformatik 2006. Band 2. GITO-Verlag, Berlin,Germany ". pp. 297–312. OMG, “Business Process Modeling Notation Version 1.2,” OMG Standard, 2009. B. Alexandre Alves, I. Assaf Arkin, I. Sid Askary et al., “Web services business process execution language version 2.0,” Technical report, OASIS (January 2007) C. Ouyang, M. Dumas, W. Aalst et al., “From business process models to process-oriented software systems,” ACM transactions on software engineering and methodology (TOSEM), vol. 19, no. 1, pp. 2, 2009. J. Recker, and J. Mendling, "On the translation between BPMN and BPEL: Conceptual mismatch between process modeling languages, Eleventh Int. Workshop on Exploring Modeling Methods in Systems Analysis and Design (EMMSAD’06)." pp. 521–532. S. White, “Introduction to BPMN,” IBM Cooperation, pp. 2008–029, 2004. M. Indulska, A. Brisbane, J. Recker et al., “Are We There Yet? Seamless Mapping OF BPMN TO BPEL4WS,” AMCIS 2007 Proceedings, pp. 439, 2007. P. Wohed, W. Van Der Aalst, M. Dumas et al., "Pattern-based Analysis of BPMN." pp. 35–50. J. Ziemann, and J. Mendling, "EPC-based modelling of BPEL processes: a pragmatic transformation approach, In Proceedings of MITIP 2005, Italy, 2005.." C. Ouyang, W. van der Aalst, M. Dumas et al., “Translating bpmn to bpel,” BPM Center Report BPM-06-02, BPMcenter. org, 2006. C. Ouyang, M. Dumas, S. Breutel et al., "Translating standard process models to BPEL, Advanced Information Systems Engineering." pp. 417-432. S. Stein, S. Kuhne, and K. Ivanov, "Business to IT Transformations Revisited, 1st International Workshop on Model-Driven Engineering for Business P rocess M anagement (MDE4BPM), Milan, Italy (Septembert 2008)." M. Weidlich, G. Decker, A. Großkopf et al., “BPEL to BPMN: the myth of a straight-forward mapping,” OTM Conferences (1), ser. LNCS, vol. 5331, pp. 265–282, 2008. P. Wohed, W. Van Der Aalst, M. Dumas et al., "Pattern-based Analysis of BPMN -An extensive evaluation of the Control-flow, the Data and the Resource Perspectives, Workshop on Web Services and Formal Methods (WSFM)." pp. 35–50. J. Recker, M. Indulska, M. Rosemann et al., “How good is BPMN really? Insights from theory and practice,” 2009. M. Rosemann, P. Green, M. Indulska et al., “Using ontology for the representational analysis of process modeling techniques,” International Journal of Business Process Integration and Management, vol. 4, no. 2, 2009. T. Wahl, and G. Sindre, “An analytical evaluation of BPMN using a semiotic quality framework,” Advanced Topics in Database Research: Volume 5, pp. 94, 2006. G. Decker, and J. Mendling, “Instantiation semantics for process models,” Proceeding of 6th BPM, Milan Italy, pp. 164-179, 2008. P. Wong, and J. Gibbons, “A process semantics for BPMN,” Formal Methods and Software Engineering, pp. 355-374, 2008.

ISSN : 0975-5462

Vol. 3 No. 1 Jan 2011

703


[20] M. Muehlen, and J. Recker, "How much language is enough? theoretical and practical use of the business process modeling notation, Advanced Information Systems Engineering, CAiSE 2008." pp. 465-479. [21] R. Liu, and A. Kumar, “An analysis and taxonomy of unstructured workflows,” Business Process Management, pp. 268-284, 2005

ISSN : 0975-5462

Vol. 3 No. 1 Jan 2011

704