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 stbr@danskebank.dk 2 School of Computer Science, University of Birmingham, UK B.Bordbar@cs.bham.ac.uk 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