Towards Flexible Business Process Modeling and Implementation: Combining Domain Specific Modeling Languages and Pattern-based Transformations

Transcription

1 Towards Flexible Business Process Modeling and Implementation: Combining Domain Specific Modeling Languages and Pattern-based Transformations Steen Brahe 1 and Behzad Bordbar 2 1 Danske Bank and IT University of Copenhagen, Denmark [email protected] 2 School of Computer Science, University of Birmingham, UK [email protected] Abstract. Design and implementation of a business process is a challenging task, which requires a diverse set of skills. There are often three groups of experts involved; business analysts, solution architects and developers. They collaborate with each other to transform a high-level design created by a business analyst to the final executable system based on e.g. BPEL. In this paper, we shall present a new approach based on using software tools to support and semi-automate this process of transformation. This involves the use of Domain Specific Modeling Languages (DSMLs) specific to a single organization to capture models of a business process at different levels of abstraction, each suitable for the use of one of the three groups of experts. The presented approach uses software tools to transform a model from one level of abstraction to a lower level. The key idea is to capture the knowledge required for transforming models from one abstraction level to another, as reusable patterns. An example of a mortgage approval process is used to illustrate the approach and to introduce a software tool that implements it. The tool enables semiautomated propagation of changes from the highest abstraction level, down through the modeling chain, resulting in automated code generation where only parameterized information has to be provided by the architect and the developer. 1 Introduction Information technology is undergoing a rapid change of role from being a mere provider of support for the business, to an active role in driving the revenue and profit [1]. Enterprises are beginning to adopt web services to be better equipped to evolve and adapt to changes in their environments [2]. In particular, the speed and precision in adapting an IT infrastructure to support a new business idea are crucial factors. To transfer a business idea into an IT system often requires a collaborative effort of a team of experts, many of whom with no or little IT expertise. A common scenario is the implementation of a business process in web services, which

2 mostly involves three groups of people: business analysts, solution architects and system developers. Firstly, business analysts must describe the business process; a set of logically related tasks performed to achieve a defined business outcome [3]. Such descriptions which are mostly captured in informal representations (e.g. in English and graphical depictions) must be refined by a solution architect to incorporate information about the IT infrastructure and systems supporting the company. Finally, the development team further refines the design to a format suitable for the creation of executable code such as BPEL [4]. This paper introduces a new tool-based approach to automate the repetitive part of the above process, resulting in shorter implementation time and better quality software products. The main idea of the approach is to capture knowledge from the different experts as reusable, parameterized patterns, which can be used for tool based transformations of the models. The presented method relies on Domain Specific Modeling Languages (DSML) [5,6,7,8] for capturing business processes at different abstraction levels. In this context, an enterprise defines and utilizes its own DSMLs for modeling its business processes. This builds on Brahe et al. [9], which describes a method of using DSMLs for specifying business processes using the UML profiling mechanism and activity diagrams [10]. The argument is that models based on enterprise specific languages are more precise compared to models based on a general process modeling language like BPMN [11]. We shall illustrate our method with the help an example of an imaginary bank called Estate Bank, within which we shall define three DSMLs each tailored for the use of a group of experts. Using the example, we shall illustrate that the process of implementing a new business idea, which starts from a design created by the business analysts and terminates in the final code, can be seen as a series of model transformations. Firstly, of models created in the DSML designed for the business analysts to the DSML for the solution architects, and subsequently, from the DSML of the solution architects to the DSML for the developers. We shall make use of Model Driven Architecture/Engineering (MDA/MDE) [12,13,14] techniques to execute such transformations. A major obstacle is that, since a model created by a business analyst is at a higher level of abstraction, it lacks information regarding the architecture of the system. Such extra information must be incorporated during the transformation from the DSML of the business analyst to the DSML of the solution architect. A similar situation arises when transforming from the DSML for the architects to the DSML for the developers. To overcome the above obstacle, the proposed method relies on design patterns [15,16,17] to capture knowledge required for transforming a model from one abstraction level to another. In this context, patterns are parameterized. Hence, to conduct our transformations, the value of parameters must be specified. We shall describe a prototype software tool that implements our approach by incorporating the value of parameters and conduct the transformation automatically. This can be seen as an extension of model transformation frameworks [18,19,20] to use parameterized patterns.

3 The paper is structured as follows. Section 2 provides an overview of background material. Our running example of a mortgage process in Estate Bank, is sketched in section 3. The example is used to illustrate some of the challenges of the design and implementation of a business process as web services. Section 4 describes the outline of our approach, which deals with these challenges. Section 5 applies the presented method to the mortgage example. Section 6 describes a prototype, which is developed on the basis of the idea presented in the paper. Section 7 contains related work and section 8 includes concluding remarks and future work. 2 Preliminaries This section describes introductory notions used in the paper. 2.1 UML, activity diagrams and DSMLs The Unified Modeling Language (UML) [10] is a family of languages accepted by the software industry as the de facto standard for visualizing, designing, specifying and documenting software based systems. Prevailing UML software tools, see [21] for an up-to-date list, which are equipped with capabilities such as code generation, reverse engineering and software management, are widely used. The UML specification [10] describes multiple languages and diagrams designed to be used in various software artifacts. Activity diagram, oneofthese languages, includes various constructs for representing; actions and control flows of sequential and parallel behavior. This makes the activity diagram suitable for modeling business processes. Moreover, the semantic of activity diagrams is very similar to Petri nets [22], which are extensively used in modeling and analysis of business processes and workflows [23,24]. Apart from languages described in its specification, the UML can be extended with the help of meta-models and profiles. Meta-models, models defining other models, make use of meta-modeling languages such as MOF [25] and Ecore [26] to formally define the syntax of new languages. Profiles (UML profiles) allow adapting the UML with constructs that are specific to a particular domain, platform or method [10]. Profiles have been used extensively in creating languages for describing business process modeling [16,27,28]. A profile is constructed by the extensibility elements: stereotypes, tagged values, and constraints, which are machine readable modeling construct used by UML tools. For example, various tasks in a business process are carried out either by a software system or a human agent. An activity diagram can be annotated to include stereotypes << Automatic >> and << HumanActivity >>. Such stereotypes clarify if a task is carried out by software or by a human being. Using these specialized tasks results in an extension of activity diagrams into a new (here, rather simplistic) language. For further information on profiles, we refer the reader to [10]. Applying this extension mechanisms, it is possible to create Domain Specific Modeling Languages (DSML) [5,6,7,8], which enables a company to use a

4 common vocabulary [9]. This allows better modeling, as such a vocabulary is understandable and agreed upon by the employees of the company, and the models will be created with higher precision as domain specific information is provided based on a meta-model. Moreover, modern UML tools with profiling capabilities can parse and manipulate such models. 2.2 Model Driven Architecture Model Driven Architecture/Engineering (MDA) [12,13,29,30] provides an approach to application design and implementation, where systems and applications are specified through meta-representations such as meta-models and profiles. In effect, all models in the model driven architecture are instances of metarepresentations. Central to the model driven approach is the automated model transformation. There are different types of model transformations and approaches in the MDA, for a classification see [31]. In this paper, we shall deal with transformations between models compliant to a UML profile of activity diagrams. In such transformations, a source model, m s must be transformed to a target model, m t, as depicted in the following picture. Fig. 1. MDA model Transformation Source and target represent meta-representation of the models m s and m t, respectively. A transformation definition includes a set of transformation rules that specify mapping between the source and target language. An MDA tool can be used to execute the transformation, i.e. creation of m t from m s.many industrial and academic case tools supporting model transformations [18,32,20] are available, ranging from complex framework, which include QVT-based [33] languages, to simple transformations such as SiTra [20,34], a Java based model transformation framework which also makes use of Java for specifying the transformations.

5 2.3 Web services and BPEL The Business Process Execution Language for web services or BPEL for short [4] provides an XML based-language for the formal specification of business processes and business interaction protocols. BPEL can be seen as an extension of the stateless WSDL [35] that provides basic one-way or request-response mechanisms for the Web service inter-communication. In contrast to WSDL, BPEL can support specification of complex business processes, which can be implemented as collaboration between multiple Web services. As a result, a business process coordinates the participant Web services towards common objectives, adding business value to Web services [2]. The BPEL language specifies a number of constructs to describe processes in details, allowing composition and coordination of activities such as sequential, parallel, iterative, conditional, compensational and fault execution. Research into the application of model driven techniques to the web service domain has recently received considerable attention [36,37,38,39,40]. A popular area of research is model transformations from platform independent languages to Web service languages. For example, Class Diagrams to WSDL [36] and Activity Diagrams to WS-BPEL or WS-WSCI [37,41]. Existing MDA tools can be used to implement such transformations. 3 Design and implementation of Business Processes Design and implementation of a business process often involves three groups of people: Business Analyst: describing and modeling concrete work processes focusing on business aspects. Solution architect: mapping the concrete business process into the IT infrastructure of the company by refining the model created by the business analyst System developer: implementing the refined model created by the architect into an executable system and code. Various models are created at different phases of the development process depending on the adopted methodology. For example, using Rational Unified Process [42], the business analyst models the business process in the inception phase of the project, while the architect and the developer create their models at the elaboration and construction phases, respectively. In this section, we shall describe the development process with the help of a simplified example of a mortgage process provided by a fictitious company called Estate Bank. The example is used throughout the paper to illustrate and explain the proposed method. Section 3.1 describes the mortgage example and presents a model from the business analyst s viewpoint. Section 3.2 describes the process of refining the model into an implementation. Finally, section 3.3 makes use of the example to point out challenges of modeling and implementing business processes.

6 3.1 Example of a mortgage approval process Fig. 2 depicts various tasks in a mortgage process as it is handled in Estate Bank via a UML activity diagram [10]. The first task is to collect the applicant s personal details and information, depicted by the activity GetCustomerInfo. Then, a number of parallel tasks occur: The applicant s details and her/his financial situation are verified with the help of a Credit Reference Agency (CreditRefernceAgency). Details of the property, including the property ownership status, are verified (CheckHouse). If the applicant is a current customer of the bank an internal credit check is made (CheckCredit). Fig. 2. Activity diagram of the mortgage approval process In case of a major problem with the house or the applicant s financial/credit status, the application is rejected. In this case, a rejection letter is sent to the customer terminating the process (SendReject). After the termination of all

7 three tasks, based on the customer profile and the information gathered about the property, a risk analysis is conducted (AccessRisk ). If the analysis predicts a high risk, the decision about approval or rejection is handed to a manager (SendToManager), otherwise the requested loans are created (CreateLoans) and a confirmation letter is sent to the customer (SendConfirmation). To keep the example simple, we have only described the control flow and actions part of the example, which are sufficient for describing our ideas. Message flows and data handling, which can be modeled similarly. Fig. 2 depicts a business analyst s view of the system. It is at a high level of abstraction focusing on business aspects. For example, there is no indication of details such as, how tasks inside the process should be executed. Here, a basic activity diagram has been used for the illustration. Inside Estate Banke the use of specific graphical symbols related to the business domain would make it easier to model, explain and understand the business idea for non-technical people. In the next subsection, we shall study refinement of the model, to add such details, to create an implementation. 3.2 From business analyst s model to the implementation To implement the mortgage approval process as an executable workflow using e.g. a web service composition language like BPEL [4], firstly a solution architect must map the business process model into an architectural model. An architectural model is often a specification of how the business process can be implemented, but without information about which technology to use. For instance, the architectural model can contain information about services to invoke, if the infrastructure of the enterprise is based on a Service Oriented Architecture, but it will not contain details about an implementation technology like BPEL. Using the Rational Unified Process [42], this model is created in the elaboration phase of the project. Secondly a developer must map the architectural model into an implementation model. This involves interpretation of tasks and application of additional information and knowledge to refine the model to a specific technology like e.g. BPEL. The implementation model represents the executable code for the business process. To illustrate the different models and how to map from one model to the next, we shall sketch the refinement of the CreateLoans task from Fig. 2 CreateLoans task: When a customer applies for a mortgage, it is possible for him/her to apply for more than one loan for the same property. For example, the mortgage can be divided into several smaller loans, each with a specific interest rate and financial terms. As a result, when the business analyst defines a CreateLoan task, the description may be along the following lines:... several loans should be created depending on the information provided on the mortgage application by the customer.... A textual description, such as the above, directs the solution architect to infer that the services/applications responsible for the creating loan should be executed iteratively, until all loans requested on the application form are created.

8 In addition, the solution architect must obtain the name and version of the services responsible for creating a loan and add this information to the architectural model. The system developer interprets the architectural model for creating an implementation model, here, based on the BPEL language [4,43]. The developer knows that an iteration of multiple tasks at the architectural level is represented as an assign node followed by a loop node at the development level. The service task described in the architectural model is transformed to a suitable assign node followed by an invocation node. The developer has to find or create a WSDL file based on the service name and version, which are specified by the architect, and annotate the invocation node suitably. Transformation between different modeling levels as described above must deal with several challenges. Some of them are listed in next subsection. 3.3 Some challenging aspects of design and implementation In the following section, the term task type is used to group, or to abstract, a set of similar tasks. For example, in the mortgage example, SendLetter is a task type for the tasks SendConfirmation and SendReject, which both involve sending letter to the customer, depending on the status of the process. A task type is a meta-class for concrete tasks in a business process model. The following challenges are faced when refining models from higher to lower abstraction levels and finally into the code. 1. How to model specific task types. What is the required information to model a task of a given task type adequately for the architect or the developer to understand it? The business analyst must e.g. find his own way of describing that several loans should be created. Another business analyst may model the same kind of task in an entirely different way. General modeling languages and textual description do not make any provisions for modeling domain specific tasks types. 2. Recognize task types. The architect must be able to recognize task types modeled by the business analyst to be able to determine the representation of the task at the architectural level. This is difficult, as there are only a fixed number of predefined task types in general modeling languages like UML, which being general can be interpreted in many different ways. The architect must rely on the textual description of the tasks to be able to determine how to model them at the architectural level. 3. Knowledge of representations of tasks at a lower abstraction level. Thearchitect and the developer must have knowledge of different task types at the higher abstraction level and the corresponding representations at their own abstraction level. For instance, the architect must know that the CreateLoans task must be represented as an iteration of a service call toaspecificservice responsible for creating loans 4. Information about required additional parameters. Additional parameters may have to be provided, when moving from a level of abstraction to a

9 lower level below. The architect and the developer must know what parameters are required and how to find them. For example, the developer has to provide a WSDL file for an invocation task when transforming a service task from the architectural level. The above four items are among day-to-day challenges of designing and implementing business processes by large teams. Our approach, which is based on the use of software design tools, deals with these challenges. We shall end this section by listing a set of deficiencies of the current methods of implementation of business processes which can be removed, if the above listed challenges are addressed. Manual transformation of tasks to lower levels of abstraction. When a certain task type has been recognized or found, the transformation of concrete tasks of this task type is a repetitive process. For instance, a service task type in an architectural model always has to be transformed to a sequence of an assign node and an invocation node in the development model. Missing data required for describing various tasks. The business analyst or solution architect may describe a task without including sufficient information. This requires further correspondence, where the architect/developer must return to the analysts/architect, respectively, to ask for further details. For example, if the architect has forgotten to define a service name at a service task, the developer will not be able to create a WSDL document when transforming the task. The developer must contact the architect to get the name before continuing the transforming. Lack of common standards for modeling different task types. Tasks are modeled in a general model language like UML or BPMN [11], which does not specify required information for a specific task type. BPMN is in this context considered a general modeling language as it is only specific to process modeling and not to a specific business domain or a specific enterprise. The business analyst and architect have to use general modeling elements to model domain specific tasks which results in lack of precision in the produced models. A general modeling language cannot constrain an architect to provide e.g. a service name and a version when he is modeling a service task, because the service task type does not exist in the general modeling language. Poor quality. Often the same kind of transformation must be repeated many times. Manual transformation often introduces errors, resulting in poor quality models. Also, manual transformation of models also means that several models must be manually updated when changes occurs. Under such circumstances inconsistency is often introduced because changes often are made directly in the development model without updating models at higher abstraction levels. The listed challenges presented in this section must be addressed, as the above deficiencies result in longer development cycles, poor quality of the resulting systems, and inconsistency between models created by different teams of experts. The next section outlines a method of dealing with the four challenges listed above.

10 4 Model Transformation with the help of patterns The first two challenges described in the previous chapter are addressed in earlier work [9], which advocates the use of domain specific modeling languages for business process modeling using UML activity diagrams and profiles. The arguments are that the use of DSMLs enables creation of precise, machine-readable model applicable for automated model transformations possible customized tool support to enhance usability and performance by e.g. allowing specific wizards for data collection models that are easier to create and understand as the experts uses domain concepts and graphical representations familiar to them The first challenge is addressed by providing a modeling tool designed specifically for the modelers. Two software tools ADModeler and ADSpecializer, also described in [9], allow creation of such domain specific modeling languages. Challenge 2, dealing with recognizing task types, is addressed by DSMLs because each task will have a domain specific task type. This paper builds on the idea presented in [9] and proposes the use of a number of different DSMLs, each one suitable for one level of abstraction, for example corresponding to the business analyst, the solution architect and the developer. This paper is an extended version of our earlier work [9]. Here, we are describing our method in the context of the challenges of modelling and implementation of business processes. Moreover, this paper reports on our extended case study of Estate Bank system and reflects on the lesson learnt, highlything advantages and also limitations of our approach. To address challenge 3 and 4, the information required to capture the transformation between models at different abstraction levels are specified as reusable patterns. Derived from Alexander s work [45] on architectural patterns, and now commonplace in software engineering [15], they have been embraced by the workflow and business process community [16,17]. A pattern describes a recurring problem that occurs in a given context, and based on a set of guiding principles, suggests a solution. The patterns described in this paper are domain, or enterprise, specific, i.e. they are specific to the Estate Bank. They make use of attributes and parameters related to the models. Hence, we shall use the phrase parameterized patterns [46] to distinguish such patterns from high level patterns described in [15]. A parameterized pattern includes three pieces of information; a pattern template, someadditional parameters and transformation rules. Pattern templates capture the overall structure of a task type in the source language represented at a lower level of abstraction and are defined in the target language. Additional parameters specify information required for fitting and customizing the pattern template for a specific task. Transformation rules use values of the additional parameters and attribute values of the task to change and fit the pattern template into the target model. The use of parameterized patterns will capture the information on how to transform a domain specific task type from one abstraction level to another, and

11 hence, addresses challenges 3 and 4 above. As described in the previous section, the developer and the architect have to know about the patterns and knowledge about required additional information for different types of task. Having defined a parameterized pattern for a specific task type, tools can now collect the required information for a concrete task in a source model. This information has to be provided by the developer or architect, but they are not required to remember or know details about the patterns and which additional parameters are required. A tool can execute the transformation of the task to the lower abstraction level. Hence, the repetitive manual part of the process is eliminated, resulting in faster development cycle and better quality models and systems.consequently, the challenge of modeling and implementing business processes then becomes one of identifying and defining domain specific task types, DSMLs and transformations between different DSMLs. Now, we shall introduce a transformation framework based on two DSMLs and knowledge captured by patterns, rules and additional transformation data. The framework is applicable for control flow based DSMLs like e.g. UML activity diagrams extended by UML profiles. 4.1 Conceptual transformation framework Fig. 3 depicts an outline of our approach for conducting model transformation between different DSMLs, which results in refinement of a model to a lower level of abstraction. Fig. 3. Model transformation between DSMLs Let us consider a source DSML L s and a target DSML language L t. Suppose that L s consists of a number of domain specific task types E 1, E 2,... The aim is to transform a source model m s defined in the language L s to a target model m t

12 defined in the language L t. To achieve this, a transformation definition T,which contains transformation rules for mapping tasks from L s to tasks of L t,isused. The transformation definition T consists of a number of sub transformations T j, responsible for the transformation of one task type E j in the source model to a structure S j in the target language L t. When transforming a source model m s the global transformation T orchestrates and coordinates which sub transformations should be executed at the different tasks contained in m s, collects all generated structures by the sub transformations and connects the generated structures together to the target model m t. During the transformation, Values of Additional Parameters, VoAP j, must be provided. These values are instances of the meta data descriptions of required Additional Parameters AP J that are required for the different subtransformations. A sub transformation T j captures and represents a parameterized pattern, and hence it represents domain specific knowledge of how to represent a task type at a lower level of abstraction in the target language L t.thismakesthe sub transformations the most essential part of the transformation. The sub transformation T j is defined by the following elements: 1. Pattern template PT j. A model template defined in the target language L t. The model template represents the structure of the source task E j transformed to L t. 2. Additional Parameters AP j. When transforming a source task E j to a lower abstraction level L t, additional information may be required to enrich and customize the pattern template so the structure S j defined in L t can be generated. 3. Transformation rules. Rules that specify how the pattern template PT j is customized into the structure S j. The rules make use of Values of Additional Parameters VoAP j and values of attributes at the source task E j. Having presented our approach, now we will apply it to the mortgage example. 5 Application of the approach to the example In this section we shall illustrate the above framework with the help of the mortgage example. We start by defining subsets of three DSMLs, one for the business analyst, one for the architect and one for the developer. The DSMLs are meant to be specific to Estate Bank, i.e. they are not designed for the use in other enterprises. Then, we define required domain specific patterns for Estate Bank at the architectural and development level, to allow transformation of the mortgage process first to the architectural level, and then to the implementation. Transformations rules can be specified using an exiting formalism like QVT, ATL or Java [33,19,20]. However, producing such specifications is not a focus of this paper. Hence, we describe the transformations in plain text. We describe in detail how one task, CreateLoans, from the mortgage process can be generalized as a domain specific task type, which we refer to as a Bundle 3 3 The word Bundle is a common jargon used by business analysts working with the first author.

13 at the business level. Using sub transformations, we demonstrate transformation of the CreateLoans task of type Bundle, first to the architectural level, and then, to the development level with only limited interference from the architect and the developer. Using the Bundle task type to model the CreateLoans task in the business model helps the business analyst to create a precise model, and the architect and developer does not have to manually transform the task to their abstraction level. Finally, we present a complete model of the mortgage process, which has evolved from the domain of the analyst to the architect and to the developer. 5.1 A DSML for Business analysts In this section, we shall present a Domain Specific Modeling Language for the business analysts affiliated to Estate Bank. Table 1 depicts a set of five task types and their corresponding tasks from the mortgage example at Fig. 2. To define the task types E j, we have used illustrative names as follows. Table 1. Business analyst task types and application at the mortgage process tasks Task type E j Automatic B HumanActivity B Risk B SendLetter B Bundle B Task in mortgage process CheckCredit, GetCustomerInfo SendToManager, CheckHouse, CreditRefAgency AssesRisk SendReject, SendConfirmation CreateLoans An Automatic B task type is any task which can be executed by Estate Bank s IT system, whereas a HumanActivity B task type is any manual activity handled by an employee. A task of type Risk B estimates the risk involved in giving a loan of a certain amount, on a property at a specific location to a specific customer. The Bundle B task type is used for executing an activity several times. In the mortgage process, this type can be used to model the CreateLoans task to create several loans. We call the business analyst language L B, where index B stands for Business. Using this language and specific task types, the business analyst can model the mortgage process as illustrated in Fig. 4. Here, stereotypes are used visually to indicate different task types. A tool based implementation as e.g. ADModeler [9] also provides the ability to visually present the process using custom graphical notation. A domain specific graphical representation of the mortgage process would make it easier for the business analyst to understand and to explain the process to others. The task types are exclusive to Estate Bank. They can be used for modeling many different business process scenarios, and provide business analysts in the Bank with a common domain specific vocabulary to be used in modeling business processes. The use of domain specific types helps the analyst to reuse common

14 Fig. 4. The Mortgage process modeled in the business analyst language types and ensure that required information for that type is defined. This means precise machine-readable models, which are easier to understand, and which are applicable for semi-automated model transformations. 5.2 A DSML for Solution architects The Solution architect refines a model created by a business analyst. As a result, the DSML used by the Solution architect requires more details than the DSML used by the business analyst. In this section, we shall explain only three of the task types used by the Solution architects; Loop A, Service A and Receive A, which are used in refining the task type Bundle B, explained in previous section. We call the architect language L A, where A stands for architect. The Loop A task type indicates that an iteration should be executed over a sequence of tasks. The architect may, for example,usealooptasktoindicatethat a certain service must be called a few times. The Service A task type indicates calling a specific service available for the use of Estate Bank. Such services are identified by their name and version. The architect determines which service to be executed and specifies the name and version for the service task. For instance, the service could be responsible for calculatingariskprofileforacustomeror creating a specific loan. The Receive A type indicates that the process is waiting for external events to occur. For example, the Receive A typecanbeusedina

15 process to indicate waiting for a customer to accept conditions send by . When the customer accepts the condition, for example, by logging into a website and confirming, the process can continue. 5.3 DSML for Developers The developer uses a language similar to BPEL. Hence the DSML for the developer requires more details than the one for the solution architect. The language is not specific to Estate Bank as it is similar to the BPEL language. We present four exemplary task types: Assign D, Invoke D, Loop D,andReceive D.Wecall the developer language L D, where index D stands for Developer. An Assign D task type maps data between variables and is used to initialize input data to service invocations. An Invoke D task type is similar to BPEL s invoke and is described by a WSDL document. A Loop D task type iterates over a sequence and can be compared with a for, or a while loop in traditional programming languages. A Receive D task type waits to be called from outside the process and is defined as a web service. Using a Receive D task type makes it possible for others services and processes to call the process from the outside. Models created in this DSML can be compiled directly to BPEL code without any additional parameters required. The models must be defined completely, i.e. themodelsmustberichenough to be executable. 5.4 Attributes at task types Now, we have defined fractions of three languages at three different abstraction levels where each language consists of a number of task types. Each task type is identified by its name and a contains a number of attributes. When a modeler is creating a task of a certain type, he/she must specify values of the required attributes defined for the task type. Attributes for the defined task types in our languages can be found in table 2. Only task types relevant to the CreateLoans task example have been illustrated. As mentioned in section 5.1, the CreateLoans task, which creates multiple loans, is of type Bundle B. In the next section, the above task types are used to model pattern templates for, firstly transforming a Bundle task type to the architectural level and then, to transfer the result to the development level. 5.5 Sample of patterns in Estate Bank Each task type Ej B in the business DSML has a pattern representation PTj BA in the architectural DSML, as has each task type Ej A in architectural DSML a pattern representation PTj AD in the developer DSML. The super indices BA and AD indicates transformation from L B to L A and from L A to L D. Table 3 illustrates architectural pattern templates for the different task types at the business level and table 4 illustrates development pattern templates for the different task types at the architectural level.

16 Table 2. Task types and their attributes DSML Task type Attributes Description Business L B Bundle B description A description of what is bundled iterations The number of iterations if it is known Architect L A Loop A iterations The number of iterations knownatbuildtime Number of iterations is known at build time? Service A name The name of the service to invoke version The version of the service to invoke Developer L D Assign D data mappings Mapping of data between variables Invoke D wsdl Document describing the service to call Table 3. Architectural Pattern templates of business task types Business Analyst type Automatic B Architectural pattern template PT BA j <<Service>> someservice HumanActivity B <<Service>> callhuman <<Receive>> waitforfinish <<Service>> autorisk [No] High Risk? Risk B [Yes] <<Service>> callhuman <<Receive>> waitforfinish SendLetter B <<Service>> createcontent <<Service>> sendletter Bundle B <<Loop>> loop <<Service>> setuploop

17 Table 4. Developmental pattern templates of architectural task types Architect type Pattern template PT AD j Service A <<Assign>> setupdata <<Invoke>> servicetocall Loop A <<Assign>> setuploop <<Loop>> loop At the business analyst language, the architectural pattern for the Automatic B type is a single Service A task indicating that a service in Estate Banks IT systems is responsible for executing the task. For the HumanActivity B type, the pattern consists of two tasks; a Service A task, responsible for calling a human activity system, and a Receive A task waiting for the human activity system to signal back, that the activity has finished. The pattern for a Risk B type contains several nodes; first, an automatic risk calculation is made. If the result from this task indicates a high risk, the human activity system is called to let a person manually evaluate the risk calculation. If the risk is low, no further action is required. For the SendLetter B type, the pattern consist of two Service A tasks; a content service is called to create the content and layout of the letter, and then a send letter service is called to create the physical letter and send it by mail. The Bundle B type and the types and patterns found in table 4 are described in details in the following paragraphs. The pattern templates are defined in target language representation. However, they are named according to source language model elements, e.g. the Bundle pattern. All patterns are modeled using UML activity diagrams and using different profiles for each language. In the next section we shall describe in details the Bundle B task type, the pattern representation of it at lower abstraction levels and how it can be transformed first to the architectural language and then to the development language by use of sub transformations containing pattern templates, transformation rules and additional transformation data. 5.6 Bundle task type and pattern Whenever a business analyst models a task as a Bundle B type, for example CreateLoans, he must specify values of the required attributes of the task as listed in table 2. Firstly, the description attribute clarifies the purpose of the Bundle. Secondly, the iterations attribute, if the number of iterations is known at modeling time, specifies the number of times the Bundle should execute. The architectural pattern PTBundle BA for modeling the equivalent to a Bundle B is a Loop A task type, and inside the loop, a Service A task type is present. The Loop A task type requires values for two attributes to be completely defined:

18 1. knownatbuildtime: Boolean if the iteration numbers is known at build time 2. iterations: the number of times the iteration should run. Both these attributes can be extracted from the attributes of the Bundle B task type, so no additional information is required here. The Service A task type also requires data for two attributes: 1. Service name: The name of the service which the bundle invokes multiple times. 2. Service version: The version of the service to be invoked. These attributes cannot be extracted from the Bundle B task type at the business level, so they must be provided as additional parameters APBundle BA during the transformation of a task of the Bundle B type. The business analyst has only provided a description of the purpose of the task of type Bundle B. The architect must based on this description localize which service and what version to call and specify the attribute values of the service task. A sub transformation TBundle BA can be defined for transformation of the Bundle B task type at the business level to the architectural level. Table 5 shows the pattern template, a textual description of the transformation rules and the required additional transformation parameters. The Bundle sub transformation generates a model structure SBundle A defined Table 5. Sub transformation for Bundle B level task type from business to architectural Pattern template Add. params Rules PT BA Bundle AP BA Bundle <<Loop>> loop <<Service>> setuploop -Service name -Service version Set name and version at << Service >> attribute in the architect language. This structure contains two tasks, one of type Loop A, and one of type Service A. The structure can be transformed to the development level by use of two different sub transformations, one sub transformation T AD Loop for the Loop A task type and one T AD Service for the Service A task type. As illustrated in table 6, a loop task at the architectural level is transformed to an assign task and a loop task at the development level. The service task at the architectural level is transformed to a sequence of an assign task followed by an invoke task at the development level. The two assign nodes at the development level both need additional parameters for determining how to map data for variables to the loop node and the invoke task respectively. This information can be provided at modeling time, however since the focus of the paper is on the control flow part of the models, we will not deal with this aspect here. The loop

19 Table 6. Sub transformation of Service A and Loop A task type from architect to developer level Task type Pattern template Add. params Rules Service A <<Assign>> setupdata PT AD j <<Invoke>> servicetocall AP AD j -WSDL file Change the invoke node to use WSDL Loop A <<Assign>> setuploop <<Loop>> loop -logic Set iteration number at loop node needs logic to determine when is should terminate, and the invoke node need to know the WSDL document defining the service to invoke. The logic and the document have to be provided for the transformations as values of additional parameters, VoAP Bundle. Fig. 5 illustrates how the CreateLoans task from the mortgage approval process, if modeled as a Bundle B type, can be transformed into code with only limited work done by the architect and the developer. The architect has to provide the service name and version of the service that in the IT systems fulfills the requirements specified by the business analyst. The developer has to provide a WSDL document based on the service name and version and logic for when the loop should terminate. Based on these additional transformation data, the described sub transformations in table 5 and table 6 handle the rest of the work of transforming the business model to an implementation. Using the illustrated languages and sub transformations, the mortgage process can be transformed to an architectural and an executable model. Fig. 6 depicts a bird s eye view of the structure of the mortgage process at the different abstraction levels, i.e. for the analyst, the architect and the developer. It can be seen that the overall structure of the model evolves as the refinement process incorporate various domain specific patterns. 5.7 Discussion By applying our proposed transformation framework at the CreateLoans task from the mortgage example we have shown that knowledge of how to transform models between different abstraction levels can be formalized by definition of domain specific tasks, pattern templates, additional transformation parameters and transformation rules. By formalizing this information, it becomes easier for the business analyst to create precise models, the architect and the developer does not have to remember dozens of different patterns, and they do not need to remember what information to provide.

20 Analyst <<Bundle>> CreateLoans Architect <<Loop>> CreateLoans <<Service>> CREATELOAN -name=createloan -version=02 Business 2 Architect Val of Add. Parameters name=createloan version=02 Developer <<Assign>> initiateloop <<Loop>> CreateLoans <<Assign>> <<Invoke>> mapcreateloan CREATELOAN -wsdl=createloan.wsdl Architect 2 Developer Val of Add. Parameters wsdl=createloan.wsdl <process name="mortgageapproval"> <sequence> <receive partner="...">... </receive> </sequence> </process> Compile BPEL Fig. 5. CreateLoan task transformed from business level, to architect level, and to development level

21 Fig. 6. A birds eye view of the mortgage process models by analyst, architect and developer

22 Having tools implementing the methodology and framework presented, the architect and the developer just need to provide additional transformation parameters for different tasks in the business and architectural model, and the models will be generated automatic with better quality and faster implementation speed compared to the traditional approach. Hence, the proposed approach has addressed the four challenges previously described. In the next chapter we briefly present a tool, that implements the presented transformation framework and that successfully has been applied at the mortgage approval example. 6 Brief sketch of tool implementation Brahe and Østerbye [9] uses UML activity diagrams as the semantic base for business process modeling and are using profiles to create DSMLs for different purposes inside an enterprise. They also presented two Eclipse based tools, ADSpecializer and ADModeler, which are able to generate new DSMLs and customized tool support based on UML activity diagrams and the extension mechanism of Eclipse. To implement the proposed approach, we have developed a tool called AD- Transformer. The tool can transform a model defined in a source language to a new model defined in a target language. ADTransformer uses the concepts of sub transformations and parameterized patterns and requires that the source and target languages are based on UML activity diagrams and profiles. ADTransformer therefore suits well with ADModeler and ADSpecializer, and the three tools together form a prototype of a complete language and transformation workbench, which supports creation of languages and modeling tools, modeling using these customized languages and tools, and transformation of models between different languages or abstraction levels. ADTransformer has reduced transformation of models between languages to transformation of models between UML activity diagrams using different profiles. ADTransformer has been implemented as an Eclipse based tool and provide an extension point, which enables definition of a transformation and a set of sub transformations between a source and a target language. The model created by the developer contains all necessary information to be executable. Hence this model can be compiled directly to code, like e.g. BPEL. For this purpose, ADTransformer uses SiTra [34] which is a simple, but powerful Java based transformation framework, where the transformation rules are writteninjava. 7 Related work Research into business process modeling and implementation started in the 70 s, where much attention were given to automation of office procedures [47,48]. During the 80 s this intense interest seemed to die out, firstly due to the lack of maturity of technology and secondly, due to rigid structure of the organisations

23 at the time, which were not fitted for process automation. [49], [50, p.8]. In early 90 s Business Process Reengineering (BPR) [3] received considerable attention by the industry, resulting in renewed interest in business process modeling and automation. Recently, the introduction of SOA and its popularity within the industry as a new enterprise architecture and development paradigm [51] has caused much attention in discovery of methods for modeling, analysis, specification and implementation of business processes. Our research aims to support such methods by providing a conceptual, tool based framework. One major challenge is to identify suitable modeling and specification languages for expressing business processes. There are various formal and semiformal languages used for modeling business processes. In this paper, we make use of Activity diagrams which are very similar to Petri nets [22]. Petri nets are particularly suitable for capturing the flow of actions in a system in forms of various sequential and parallel behavior. Moreover, extensions of Petri nets, such as Colored Petri nets [52], which allow capturing complex models by incorporating data types and capability to manipulate data, are used for modeling business processes [24,53]. Petri nets have strong underlying formalism, hence can be used for conducting analysis [54,55]. For example, Petri nets are used for analysis [56,57] of modelling and specification lanugages such as event-driven process chain (EPC) [50]. EPS developed in 1992, partly by SAP A/G is a key component of SAP R/3 s modeling concepts for business engineering. However, despite being very powerful, Petri nets have received very little attention from industrial software developers. In particular, tool support for the use of Petri nets by the industry is very limitted. Business Process Modeling Notation (BPMN) [11] is another modelling and specification language which has received considerable attention recently. BPMN is a visual notation targeted business developers, to model business processes at the business level. For modeling business processes, BPMN is quite similar to activity diagrams, but provides more modeling types for the business analysts and a more compelling graphical representation. In this paper, we have adopted activity diagram [10], which includes various constructs for modeling business processes. Activity diagrams are extensively used by both academia and industry for its widely adoption and available tool support. Dumas [58] argues based on workflow patterns that the expressiveness of activity diagrams as a workflow language is large. Brahe [9] uses activity diagrams as a basis for the semantic of domain specific modeling languages for business process modeling based on UML profiles. Guntama [59] has extended activity diagrams to enable flexible business workflow modeling. There are also various UML profiles for business process modeling, e.g. List [28] who considers both the business process flow as well as the business process context. One of the main reasons for adopting Activity diagrams in this paper is that, they are well suited for domain specific modeling because of the profiling mechanism of UML. Using profiles, one can create precise, machine-readable and domain specific models of business processes, which are feasible as input to

24 model transformations. To the best of our knowledge, neither of Petri net, EPC or BPMN support this kind of extensibility of the language. Transformation and code generation of models created in the above languages is another major challenge. Model Driven Development and the Model Driven Architecture [14,12] have been used extensively in transforming business process models to implementations, particularly from UML activity diagrams to service composition languages. Bezivin [36] uses the ATL transformation languages to transform UML models into three different target platforms; Java, Web Services and Java Web Service Developer Pack. Bordbar [41,37] studies transformation of activity diagrams to BPEL and WSCI based on their MOF compliant metamodels. Skogan [60] proposes a method that uses activity diagrams to design web service compositions and transforms them into different service composition languages. The method also builds on transforming WSDL descriptions into UML, which can then be used to build the service compositions. Koehler [61,62] has worked on model driven generation of BPEL implementations based on activity diagrams using techniques originating from compiler theory and declarations of rules in the Object Constraint Language. The BMNM specification contains a chapter that specifies how BPMN models can be mapped to BPEL. Using BPMN ensures using a language which is specifically designed for business process modeling. Moreover, the transformation to BPEL allows implementation of the business process. The method presented in this paper has a different approach compared to the research described above, which mostly supports a one-to-one mapping of elements in a modeling language, e.g. the UML activity diagram or BPMN, into elements in a target language, as e.g. BPEL. Using such one-to-one mappings, the source model and the target model become quite similar in their structures. Above papers operate with two levels of abstraction, mainly mentioned the platform independent model and the platform specific model, where platform specific information either has to be retrieved from the source model or manually applied to the target model. The two abstraction levels are close to each other, as the structural relationship is one-to-one. In contrast, our method allows transformations between multiple levels of abstraction and it incorporates platform specific information as additional parameters provided to the transformation, as depicted in Fig. 5. It also supports transformation between abstraction levels far from each other, where the structural relationship is not one-to-one. Our method differs from previous work in three ways: Firstly, it allows flexibility in defining and utilizing modeling languages and the corresponding transformations to lower levels of abstraction. Our approach can be used to define a BPMN like language and a similar transformation to BPEL as defined in the BPMN specification, but it can also be used to define a more detailed language specific to enterprises, e.g. Estate Bank, and corresponding transformations meaning that the enterprise is able to define its own modeling methodology and how models are implemented. As suggested by [9] using custom languages also allow using customized tool support which include

25 guidance of providing required domain specific data during modeling. This can improve the modeling efficiency and model quality. Secondly, it makes use of flexible, parameterized and pattern-based transformations. One can customize transformations to a specific domain and required platform specific information can be provided during transformation time. This means that information does not have to be defined in the source model or manually defined in the implementation after transformation. Thirdly, it supports an arbitrary number of abstraction levels in the development process meaning that the method can be used to define languages and transformations, but also to be fitted to a specific development process in an enterprise. Several aspects of our method have not yet been dealt with and are subjects of further research. This includes addressing challenges related to data and message flows, as this paper mostly deals with the control flow part of business processes. It seems that modeling data flows requires extension to the modeling langauge and the transformations. As we are using activity diagram, we can use message flows from here in our models. We shall investigate its use and requirements and complications for message tranformations and data mappings in a case study in the furture. Another set of aspects which need attention is the provision of support for manually introducted changes to generated models. A typical example is when a modeller must apply additional information and changes to a model after it has been generated by a model transformation. A developer may e.g. have to change data mappings for a service invocation or change the web service to be invoked. This causes troubles as the changes will be overridden when the source model is changed and the transformation reapplied. To avoid this scenario, methods should be developed to allow introduction of manual changes in target models, which is protected against future transformations. Such methods would improve two scenarios; First, in our method, the overall control flow structure remains fixed; the control flow structure defined in the model at the highest abstraction level cannot be changed by the transformations, as each sub transformation only makes changes to a local area of the model, i.e. it creates a model structure to be inserted into a particular place in the target model. The global control flow is not affected. There may be cases, where the structural relationship between different abstraction levels is not intact; e.g. additional structures may be added at lower levels, or the global control flow structure changed. Second, additional information may have to be added and changes made to elements in generated models, as e.g. changing which web service to invoke, which the transformation cannot handle. There are also challenges which are not specific to our work but relate to our direction of research. These include discovery of methods of analysis of model transformations, for example ensuring that a transformed model is correct? There is a clear need for discovery of methods of debugging, validation and verification. Another major challenge is to identify appropriate methods of

26 specifying transformation rules. This is a popular area of research and currently there are various languages and tools for specifying such transformations [33,12]. 8 Conclusion and future work This paper describes a method for bridging the gaps between models at different abstraction levels of a business process. The main idea of the adopted approach is to capture domain, or enterprise, specific knowledge of the coherence between one abstraction level and another as parameterized patterns consisting of pattern templates, additional transformation parameters and transformation rules. We have introduced an example of a mortgage approval process, which is used to illustrate the challenges of creating models at different abstraction levels. The example is further used to describe our approach which simplifies and semiautomates the transformation from the business level to the architectural level and from the architectural level to the development level. The presented method can be implemented as a software tool to allow 1. Shorter software development cycle 2. Better synchronization of models at different levels of abstraction 3. Higher quality of code and design through reuse 4. Improved development process A prerequisite for applying the method is the use of different DSMLs for different abstraction levels. A business analyst, an architect and a developer for a specific company each needs his or her own language to create models with required precision and information details. As future work, we will extend our approach to include message- and data flows and we will further explore transformation rules in the global transformation and in the sub transformations. We will examine approaches to model refactoring which will allow survival of manually introduced changes in generated models, and we plan to make case studies at different domains using the sketched tools to evaluate our approach and find limitations. References 1. Wagner, H.T., Beimborn, D., Franke, J., Weitzel, T.: IT Business Alignment and IT Usage in Operational Processes: A Retail Banking Case. In: Proceedings of the 39th Annual Hawaii International Conference on System Sciences (HICSS 06). Volume 8. (2006) Alonso, G., Casati, F., Kuno, H., Machiraju, V.: Web Services: Concepts Architectures and Applications. Springer-Verlag (2004) 3. Davenport, T.H.: Process Innovation: Reengineering Work Through Information Technology. Harvard Business School Press, Boston, Mass. (1993) 4. BEA, IBM, Microsoft, SAP, A., Systems, S.: Business Process Execution Language for Web Services (BPEL4WS). Version 1.1, ibm.com/developerworks/library/specification/ws-bpel/ (2003)

27 5. Vokac, M., Glattetre, J.M.: Using a Domain-Specific Language and Custom Tools to Model a Multi-tier Service-Oriented Application - Experiences and Challenges. In: 8th International Conference on Model Driven Engineering Languages and Systems, MoDELS 05. Volume 3713 of Lecture Notes in Computer Science. (2005) Chen, K., Sztipanovits, J., Neema, S.: Toward a semantic anchoring infrastructure for domain-specific modeling languages. In: EMSOFT 05: Proceedings of the 5th ACM international conference on Embedded software, ACM (2005) Wile, D.S.: Supporting the DSL Spectrum. Journal of Computing and Information Technology 9 (2001) Deursen, A.V., Klint, P., Visser, J.: Domain-Specific Languages: An Annotated Bibliography. ACM SIGPLAN Notices 35 (2000) Brahe, S., Østerbye, K.: Business Process Modeling: Defining Domain Specific Modeling Languages by use of UML Profiles. In: Second European Conference on Model Driven Architecture Foundations and Applications. Volume 4066 of Lecture Notes in Computer Science. (2006) UML2.0: UML 2.0 Superstructure Specification, Final Adopted Specification, available at (2004) 11. White, S.: Business Process Modeling Notation, Version 1.0, final adopted version, avaiblable at (2006) 12. Stahl, T., Völter, M., Bettin, J., Haase, A., Helsen, S.: Model-Driven Software Development: Technology, Engineering, Management. Wiley (2006) 13. Frankel, D.S.: Model Driven Architecture: Applying MDA to Enterprise Computing. OMG Press (2003) 14. MDA: Model Driven Architecture, Object Management Group, (2005) 15. Gamma, E., Helm, R., Johnson, R., Vlissides, J.: Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley (1994) 16. Eriksson, H., Penker, M.: Business Modeling with UML. Business Patterns at Work. John Wiley & Sons, Inc. (2000) 17. van der Aalst, W., Hofstede, A., Kiepuszewski, B., Barros, A.: Workflow Patterns. Distributed and Parallel Databases 14 (2003) Arcstyler: Arcstyler 5.5, (2007) 19. Jouault, F., Kurtev, I.: Transforming Models with ATL. In: Proceedings of the Model Transformations in Practice Workshop at MoDELS 2005, Montego Bay, Jamaica. (2005) 20. SiTra: Simple Transformer (SiTra): an MDE tool, bxb/sitra.html (2006) 21. UML: The UML website, (2006) 22. Murata, T.: Petri Nets: Properties, Analysis and Applications. Proceedings of the IEEE 77 (1989) Chrzastowski-Wachtel, P., Benatallah, B., Hamadi, R., O Dell, M., Susanto, A.: A Top-Down Petri Net-Based Approach for Dynamic Workflow Modeling. In: Business Process Management, International Conference, BPM Lecture Notes in Computer Science (2003) van der Aalst, W.: The Application of Petri Nets for Workflow Management. The Journal of Circuits, Systems and Computers 8 (1998) MOF: Meta Object Facility (MOF) 2.0 Core Specification, available at (2006)

28 26. Budinsky, F., Steinberg, D., Merks, E., Ellersick, R., Grose, T.J.: Eclipse Modeling Framework: A Developer s Guide. Addison Wesley (2003) 27. Gardner, T.: UML Modelling of Automated Business Processes with a Mapping to BPEL4WS. In: 17th European Conference on Object-Oriented Programming (ECOOP), Darmstadt, Germany (2003) 28. List, B., Korherr, B.: A UML 2 Profile for Business Process Modelling. In: Perspectives in Conceptual Modeling, ER 2005 Workshops. Volume 3770 of Lecture Notes in Computer Science. (2005) Atkinson, C., Kuhne, T.: Model-Driven Development: a Metamodelling Foundation. IEEE Software, IEEE computer Society 20 (2003) Kleppe, A., Warmer, J., Bast, W.: MDA Explained: The Model Driven Architecture Practice and Promise. The Addison-Wesley Object Technology Series. Addison-Wesley (2003) 31. Czarnecki, K., Helsen, S.: Classification of Model Transformation Approaches. In: Online proceedings of the 2nd OOPSLA03 Workshop on Generative Techniques in the Context of MDA. (2003) 32. Eclipse: (Generative Modeling Technologies (GMT) project, QVT: Object Management Group: MOF 2.0 Query / Views / Transformations. Final Adopted Specification, available at 01.pdf (2005) 34. Akehurst, D., Bordbar, B., Evans, M., Howells, W., McDonald-Maier, K.: SiTra: Simple Transformations in Java. In: ACM/IEEE 9TH International Conference on Model Driven Engineering Languages and Systems. Volume 4199 of Lecture Notes in Computer Science. (2006) Chinnici, R., Moreau, J.J., Ryman, A., Weerawarana, S.: Web Services Description Language (WSDL) Version 2.0, W3C (2006) 36. Bezivin, J., Hammoudi, S., Lopes, D., Jouault, F.: An Experiment in Mapping Web Services to Implementation Platforms. Technical report, LINA, University of Nantes (2004) 37. Bordbar, B., Staikopoulos, A.: On Behavioural Model Transformation in Web Services. In: Conceptual Modelling for Advanced Application Domain (ecomo), Shanghai, China (2004) Denno, P., Steves, M., Libes, D., Barkmeyer:, E.: Model-Driven Integration Using Existing Models. IEEE Software, IEEE computer Society 20 (2003) Staikopolous, A., Bordbar, B.: A Comparative Study of Metamodel Integration and Interoperability in UML and Web Services. In: First European Conference Model Driven Architecture : Foundations and Applications -ECMDA-FA. Volume 3748 of Lecture Notes in Computer Science. (2005) Lopes, D., Hammoudi, S., Bezivin, J., Jouault, F.: Generating transformation definition from mapping specification: Application to web service platform. In: Advanced Information Systems Engineering. 17th International Conference (CaiSE 2005), Porto, Portugal (2005) Bordbar, B., Staikopoulos, A.: Modelling and transforming the behavioural aspects of web services. In: Third Workshop in Software Model Engineering (WiSME 2004) at UML, Lisbon, Portugal (2004) 42. Kroll, P., Kruchten, P.: The Rational Unified Process Made Easy. A Practitioner s Guide to the RUP. Addison Wesley (2003) 43. Havey, M.: Essential Business Process Modeling. OReilly Media, Inc. (2005) 44. Brahe, S., Bordbar, B.: A Pattern-based Approach to Business Process Modeling andimplementationinwebservices. InAhrens,M.,Schönherr, M., eds.: First

29 International Workshop on Service Oriented Modeling (ICSOC 2006), Chicago, USA (2006) Alexander, C.: Notes on the Synthesis of Form. Cambridge, Massachusetts: Harvard University Press. Harvard University Press, Cambridge (1964) 46. MacDonald, S., Szafron, D., Schaeffer, J., Anvik, J., Bromling, S., Tan, K.: Generative design patterns. In: IEEE International Conference on Automated Software Engineering. (2002) Zisman, M.D.: Representation, Specification and Automation of Office Procedures. PhD thesis, University of Pennsylvania, Wharton School of Business (1977) 48. Ellis, C.A.: Information Control Nets: A Mathematical Model of Office Information Flow. In: Proceedings of the Conference on Simulation, Measurement and Modeling of Computer Systems, Boulder, CO, ACM Press (1979) Ellis, C.A., Nutt, G.J.: Workflow: The Process Spectrum. In: NSF Workshop on Workflow and Process Automation in Information Systems, Athens, Georgia (1996) 50. Dumas, M., van der Aalst, W., Hofstede, A.: Process-Aware Information Systems: Bridging People and Software through Process Technology. John Wiley & Sons, Inc. (2005) 51. Erl, T.: Service Oriented Architecture: Concepts, Technology and Design. Prentice Hall (2005) 52. Jensen, K., Rozenberg, G.: High-level Petri Nets. Theory and Application. Springer Verlag (1991) 53. Liu, D., Wang, J., Chan, S.C.F., Sun, J., Zhang, L.: Modeling workflow processes with colored petri nets. Computers in Industry 49 (2002) 54. van der Aalst, W.: Workflow Verification: Finding Control-Flow Errors Using Petri- Net-Based Techniques. In: Business Process Management, Models, Techniques, and Empirical Studies. Volume 1806 of Lecture Notes in Computer Science. Springer Berlin / Heidelberg (2000) Xiao, Y.Y., Tan, Q., Yong: Verifying web services composition based on hierarchical colored petri nets. In: first international workshop on Interoperability of heterogeneous information systems, ACM Press (2005) van Dongen, B., van der Aalst, W., Verbeek, H.: Verification of EPCs: Using Reduction Rules and Petri Nets. In: Conference on Advanced Information Systems Engineering (CAiSE 2005). Volume 3520 of Lecture Notes in Computer Science. Springer Berlin / Heidelberg (2005) Sarshar, K., Loos, P.: Comparing the Control-Flow of EPC and Petri Net from the End-User Perspective. In: Business Process Management: Second International Conference, BPM (2005) 58. Dumas, M., Hofstede, A.H.M.: UML Activity Diagrams as a Workflow Specification Language. In: UML Volume 2185 of Lecture Notes in Computer Science. (2001) Guntama, E., Chang, E., Jayaratna, N., Pudhota, L.: Extension of Activity Diagrams for Flexible Business Workflow Modeling. International Journal of Computer Systems Science & Engineering 18 (2003) Skogan, D., Grønmo, R., Solheim, I.: Web Service Composition in UML. In: Eighth IEEE International Enterprise Distributed Object Computing Conference (EDOC 04). (2004) Koehler, J., Hauser, R., Kapoor, S., Wu, F.Y., Kumaran, S.: A Model-Driven Transformation Method. In: 7th International Enterprise Distributed Object Computing Conference (EDOC 2003). (2003)

30 62. Koehler, J., Hauser, R., Sendall, S., Wahler, M.: Declarative Techniques for Model- Driven Business Process Integration. IBM Systems Journal 44 (2005) 47 65