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

Save this PDF as:
 WORD  PNG  TXT  JPG

Size: px
Start display at page:

Download "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 2 School of Computer Science, University of Birmingham, 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

A Pattern-based Approach to Business Process Modeling and Implementation in Web Services

A Pattern-based Approach to Business Process Modeling and Implementation in Web Services A Pattern-based Approach to Business Process Modeling and Implementation in Web Services Steen Brahe 1 and Behzad Bordbar 2 1 Danske Bank & IT University of Copenhagen, Denmark stbr@itu.dk 2 University

More information

Analysis of the Specifics for a Business Rules Engine Based Projects

Analysis of the Specifics for a Business Rules Engine Based Projects Analysis of the Specifics for a Business Rules Engine Based Projects By Dmitri Ilkaev and Dan Meenan Introduction In recent years business rules engines (BRE) have become a key component in almost every

More information

An Experiment on Creating Enterprise Specific BPM Languages and Tools

An Experiment on Creating Enterprise Specific BPM Languages and Tools IT University of Copenhagen An Experiment on Creating Enterprise Specific BPM Languages and Tools Steen Brahe IT University Technical Report Series TR-2008-102 ISSN 1600 6100 March 2008 Copyright c 2008,

More information

Model Driven Interoperability through Semantic Annotations using SoaML and ODM

Model Driven Interoperability through Semantic Annotations using SoaML and ODM Model Driven Interoperability through Semantic Annotations using SoaML and ODM JiuCheng Xu*, ZhaoYang Bai*, Arne J.Berre*, Odd Christer Brovig** *SINTEF, Pb. 124 Blindern, NO-0314 Oslo, Norway (e-mail:

More information

Project VIDE Challenges of Executable Modelling of Business Applications

Project VIDE Challenges of Executable Modelling of Business Applications Project VIDE Challenges of Executable Modelling of Business Applications Radoslaw Adamus *, Grzegorz Falda *, Piotr Habela *, Krzysztof Kaczmarski #*, Krzysztof Stencel *+, Kazimierz Subieta * * Polish-Japanese

More information

SOA Enabled Workflow Modernization

SOA Enabled Workflow Modernization Abstract Vitaly Khusidman Workflow Modernization is a case of Architecture Driven Modernization (ADM) and follows ADM Horseshoe Lifecycle. This paper explains how workflow modernization fits into the ADM

More information

Business Process Modeling and Standardization

Business Process Modeling and Standardization Business Modeling and Standardization Antoine Lonjon Chief Architect MEGA Content Introduction Business : One Word, Multiple Arenas of Application Criteria for a Business Modeling Standard State of the

More information

Winery A Modeling Tool for TOSCA-based Cloud Applications

Winery A Modeling Tool for TOSCA-based Cloud Applications Institute of Architecture of Application Systems Winery A Modeling Tool for TOSCA-based Cloud Applications Oliver Kopp 1,2, Tobias Binz 2, Uwe Breitenbücher 2, and Frank Leymann 2 1 IPVS, 2 IAAS, University

More information

BPMN by example. Bizagi Suite. Copyright 2014 Bizagi

BPMN by example. Bizagi Suite. Copyright 2014 Bizagi BPMN by example Bizagi Suite Recruitment and Selection 1 Table of Contents Scope... 2 BPMN 2.0 Business Process Modeling Notation... 2 Why Is It Important To Model With Bpmn?... 2 Introduction to BPMN...

More information

SERVICE-ORIENTED MODELING FRAMEWORK (SOMF ) SERVICE-ORIENTED SOFTWARE ARCHITECTURE MODEL LANGUAGE SPECIFICATIONS

SERVICE-ORIENTED MODELING FRAMEWORK (SOMF ) SERVICE-ORIENTED SOFTWARE ARCHITECTURE MODEL LANGUAGE SPECIFICATIONS SERVICE-ORIENTED MODELING FRAMEWORK (SOMF ) VERSION 2.1 SERVICE-ORIENTED SOFTWARE ARCHITECTURE MODEL LANGUAGE SPECIFICATIONS 1 TABLE OF CONTENTS INTRODUCTION... 3 About The Service-Oriented Modeling Framework

More information

The OMG BPM Standards

The OMG BPM Standards The OMG BPM Standards Derek Miers CEO, BPM Focus +44 (20) 8742 8500 UK Office +44 (7703) 178 500 UK Cell +1 (714) 600 9010 US Cell miers@bpmfocus.org A BPM Definition Business Process Management is primarily

More information

SEARCH The National Consortium for Justice Information and Statistics. Model-driven Development of NIEM Information Exchange Package Documentation

SEARCH The National Consortium for Justice Information and Statistics. Model-driven Development of NIEM Information Exchange Package Documentation Technical Brief April 2011 The National Consortium for Justice Information and Statistics Model-driven Development of NIEM Information Exchange Package Documentation By Andrew Owen and Scott Came Since

More information

Foundations of Model-Driven Software Engineering

Foundations of Model-Driven Software Engineering Model-Driven Software Engineering Foundations of Model-Driven Software Engineering Dr. Jochen Küster (jku@zurich.ibm.com) Contents Introduction to Models and Modeling Concepts of Model-Driven Software

More information

Designing a Semantic Repository

Designing a Semantic Repository Designing a Semantic Repository Integrating architectures for reuse and integration Overview Cory Casanave Cory-c (at) modeldriven.org ModelDriven.org May 2007 The Semantic Metadata infrastructure will

More information

Applying 4+1 View Architecture with UML 2. White Paper

Applying 4+1 View Architecture with UML 2. White Paper Applying 4+1 View Architecture with UML 2 White Paper Copyright 2007 FCGSS, all rights reserved. www.fcgss.com Introduction Unified Modeling Language (UML) has been available since 1997, and UML 2 was

More information

Open Source egovernment Reference Architecture Osera.modeldriven.org. Copyright 2006 Data Access Technologies, Inc. Slide 1

Open Source egovernment Reference Architecture Osera.modeldriven.org. Copyright 2006 Data Access Technologies, Inc. Slide 1 Open Source egovernment Reference Architecture Osera.modeldriven.org Slide 1 Caveat OsEra and the Semantic Core is work in progress, not a ready to use capability Slide 2 OsEra What we will cover OsEra

More information

Business Process Modeling Information Systems in Industry (372-1-4207 )

Business Process Modeling Information Systems in Industry (372-1-4207 ) Business Process Modeling Information Systems in Industry (372-1-4207 ) Arnon Sturm The material of this presentation is adopted from various people including:, Pnina Soffer, Iris Reinhartz-Berger 1 Outline

More information

Overview. Stakes. Context. Model-Based Development of Safety-Critical Systems

Overview. Stakes. Context. Model-Based Development of Safety-Critical Systems 1 2 Model-Based Development of -Critical Systems Miguel A. de Miguel 5/6,, 2006 modeling Stakes 3 Context 4 To increase the industrial competitiveness in the domain of software systems To face the growing

More information

Ontological Identification of Patterns for Choreographing Business Workflow

Ontological Identification of Patterns for Choreographing Business Workflow University of Aizu, Graduation Thesis. March, 2010 s1140042 1 Ontological Identification of Patterns for Choreographing Business Workflow Seiji Ota s1140042 Supervised by Incheon Paik Abstract Business

More information

A UML 2 Profile for Business Process Modelling *

A UML 2 Profile for Business Process Modelling * A UML 2 Profile for Business Process Modelling * Beate List and Birgit Korherr Women s Postgraduate College for Internet Technologies Institute of Software Technology and Interactive Systems Vienna University

More information

Chap 1. Introduction to Software Architecture

Chap 1. Introduction to Software Architecture Chap 1. Introduction to Software Architecture 1. Introduction 2. IEEE Recommended Practice for Architecture Modeling 3. Architecture Description Language: the UML 4. The Rational Unified Process (RUP)

More information

Meta-Model specification V2 D602.012

Meta-Model specification V2 D602.012 PROPRIETARY RIGHTS STATEMENT THIS DOCUMENT CONTAINS INFORMATION, WHICH IS PROPRIETARY TO THE CRYSTAL CONSORTIUM. NEITHER THIS DOCUMENT NOR THE INFORMATION CONTAINED HEREIN SHALL BE USED, DUPLICATED OR

More information

The Unified Software Development Process

The Unified Software Development Process The Unified Software Development Process Technieche Universal Darmstadt FACHBEREICH IN-FORMAHK BLIOTHEK Ivar Jacobson Grady Booch James Rumbaugh Rational Software Corporation tnventar-nsr.: Sachgebiete:

More information

Implementing BPM Experienced Challenges and Lessons learned

Implementing BPM Experienced Challenges and Lessons learned Implementing BPM Experienced Challenges and Lessons learned Steen Brahe, stbr@danskebank.dk Finance IT Tuesday Agenda BPM implementation: The Customer package process Business Perspective Software Engineering

More information

Generating Aspect Code from UML Models

Generating Aspect Code from UML Models Generating Aspect Code from UML Models Iris Groher Siemens AG, CT SE 2 Otto-Hahn-Ring 6 81739 Munich, Germany Iris.Groher@fh-hagenberg.at Stefan Schulze Siemens AG, CT SE 2 Otto-Hahn-Ring 6 81739 Munich,

More information

Business Modeling with UML

Business Modeling with UML Business Modeling with UML Hans-Erik Eriksson and Magnus Penker, Open Training Hans-Erik In order to keep up and be competitive, all companies Ericsson is and enterprises must assess the quality of their

More information

Business-Driven Software Engineering Lecture 3 Foundations of Processes

Business-Driven Software Engineering Lecture 3 Foundations of Processes Business-Driven Software Engineering Lecture 3 Foundations of Processes Jochen Küster jku@zurich.ibm.com Agenda Introduction and Background Process Modeling Foundations Activities and Process Models Summary

More information

Revel8or: Model Driven Capacity Planning Tool Suite

Revel8or: Model Driven Capacity Planning Tool Suite Revel8or: Model Driven Capacity Planning Tool Suite Liming Zhu 1,2, Yan Liu 1,2, Ngoc Bao Bui 1,2,Ian Gorton 3 1 Empirical Software Engineering Program, National ICT Australia Ltd. 2 School of Computer

More information

Basic Unified Process: A Process for Small and Agile Projects

Basic Unified Process: A Process for Small and Agile Projects Basic Unified Process: A Process for Small and Agile Projects Ricardo Balduino - Rational Unified Process Content Developer, IBM Introduction Small projects have different process needs than larger projects.

More information

Business Process Execution Language for Web Services

Business Process Execution Language for Web Services Business Process Execution Language for Web Services Second Edition An architect and developer's guide to orchestrating web services using BPEL4WS Matjaz B. Juric With Benny Mathew and Poornachandra Sarang

More information

Developing SOA solutions using IBM SOA Foundation

Developing SOA solutions using IBM SOA Foundation Developing SOA solutions using IBM SOA Foundation Course materials may not be reproduced in whole or in part without the prior written permission of IBM. 4.0.3 4.0.3 Unit objectives After completing this

More information

From Business World to Software World: Deriving Class Diagrams from Business Process Models

From Business World to Software World: Deriving Class Diagrams from Business Process Models From Business World to Software World: Deriving Class Diagrams from Business Process Models WARARAT RUNGWORAWUT 1 AND TWITTIE SENIVONGSE 2 Department of Computer Engineering, Chulalongkorn University 254

More information

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II)

Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) Software Engineering Prof. N.L. Sarda Computer Science & Engineering Indian Institute of Technology, Bombay Lecture-4 Overview of Phases (Part - II) We studied the problem definition phase, with which

More information

Tool Support for Model Checking of Web application designs *

Tool Support for Model Checking of Web application designs * Tool Support for Model Checking of Web application designs * Marco Brambilla 1, Jordi Cabot 2 and Nathalie Moreno 3 1 Dipartimento di Elettronica e Informazione, Politecnico di Milano Piazza L. Da Vinci,

More information

Dr. Jana Koehler IBM Zurich Research Laboratory

Dr. Jana Koehler IBM Zurich Research Laboratory Precise Modeling of Business Processes with the Business Process Modeling Notation BPMN 2.0 Dr. Jana Koehler IBM Zurich Research Laboratory ZRL BIT at a Glance Computer Science at ZRL: Security/Cryptography

More information

UML TUTORIALS THE USE CASE MODEL

UML TUTORIALS THE USE CASE MODEL UML TUTORIALS THE USE CASE MODEL www.sparxsystems.com.au Sparx Systems 2004 Page 1/5 describes the proposed functionality of the new system. A Use Case represents a discrete unit of interaction between

More information

Chapter 4 Software Lifecycle and Performance Analysis

Chapter 4 Software Lifecycle and Performance Analysis Chapter 4 Software Lifecycle and Performance Analysis This chapter is aimed at illustrating performance modeling and analysis issues within the software lifecycle. After having introduced software and

More information

Workflows and Decision Tables for Flexible Early Warning Systems

Workflows and Decision Tables for Flexible Early Warning Systems Workflows and Decision Tables for Flexible Early Warning Systems Felix Riedel Fraunhofer IOSB felix.riedel@iosb.fraunhofer.de Fernando Chaves Fraunhofer IOSB fernando.chaves-salamanca@iosb.fraunhofer.de

More information

Development of Enterprise Architecture of PPDR Organisations W. Müller, F. Reinert

Development of Enterprise Architecture of PPDR Organisations W. Müller, F. Reinert Int'l Conf. Software Eng. Research and Practice SERP'15 225 Development of Enterprise Architecture of PPDR Organisations W. Müller, F. Reinert Fraunhofer Institute of Optronics, System Technologies and

More information

UML Modelling of Automated Business Processes with a Mapping to BPEL4WS

UML Modelling of Automated Business Processes with a Mapping to BPEL4WS UML Modelling of Automated Business Processes with a Mapping to BPEL4WS Tracy Gardner IBM UK Laboratories, Hursley Park, Winchester, SO21 2JN, UK tgardner@uk.ibm.com Abstract. The Business Process Execution

More information

From BPMN 2.0 to the Setting-Up on an ESB - Application to an Interoperability Problem

From BPMN 2.0 to the Setting-Up on an ESB - Application to an Interoperability Problem From BPMN 2.0 to the Setting-Up on an ESB - Application to an Interoperability Problem Y. Lemrabet, D. Clin, M. Bigand, and J.-P. Bourey Univ Lille Nord de France, F-59000 Lille, France Laboratoire de

More information

Nr.: Fakultät für Informatik Otto-von-Guericke-Universität Magdeburg

Nr.: Fakultät für Informatik Otto-von-Guericke-Universität Magdeburg Nr.: Fakultät für Informatik Otto-von-Guericke-Universität Magdeburg Nr.: Fakultät für Informatik Otto-von-Guericke-Universität Magdeburg Impressum ( 5 TMG) Herausgeber: Otto-von-Guericke-Universität Magdeburg

More information

RUP Design Workflow. Michael Fourman Cs2 Software Engineering

RUP Design Workflow. Michael Fourman Cs2 Software Engineering RUP Design Workflow Michael Fourman Introduction Design architecture that can meet all requirements Understand non-functional requirements and constraints related to technologies Identify subsystems (overall

More information

Tool Support for Software Variability Management and Product Derivation in Software Product Lines

Tool Support for Software Variability Management and Product Derivation in Software Product Lines Tool Support for Software Variability Management and Product Derivation in Software s Hassan Gomaa 1, Michael E. Shin 2 1 Dept. of Information and Software Engineering, George Mason University, Fairfax,

More information

A Service-Oriented approach dedicated to Internet based Business Process Networks: Building a MDA based collaborative platform with opensource

A Service-Oriented approach dedicated to Internet based Business Process Networks: Building a MDA based collaborative platform with opensource A Service-Oriented approach dedicated to Internet based Business Process Networks: Building a MDA based collaborative platform with opensource solutions EBM WebSourcing Jean-Pierre LORRE R&D Manager ObjectWeb

More information

Organization of DSLE part. Overview of DSLE. Model driven software engineering. Engineering. Tooling. Topics:

Organization of DSLE part. Overview of DSLE. Model driven software engineering. Engineering. Tooling. Topics: Organization of DSLE part Domain Specific Language Engineering Tooling Eclipse plus EMF Xtext, Xtend, Xpand, QVTo and ATL Prof.dr. Mark van den Brand GLT 2010/11 Topics: Meta-modeling Model transformations

More information

Model-Driven Development - From Frontend to Code

Model-Driven Development - From Frontend to Code Model-Driven Development - From Frontend to Code Sven Efftinge sven@efftinge.de www.efftinge.de Bernd Kolb bernd@kolbware.de www.kolbware.de Markus Völter voelter@acm.org www.voelter.de -1- Model Driven

More information

AMFIBIA: A Meta-Model for the Integration of Business Process Modelling Aspects

AMFIBIA: A Meta-Model for the Integration of Business Process Modelling Aspects AMFIBIA: A Meta-Model for the Integration of Business Process Modelling Aspects Björn Axenath, Ekkart Kindler, Vladimir Rubin Software Engineering Group, University of Paderborn, Warburger Str. 100, D-33098

More information

NASCIO EA Development Tool-Kit Solution Architecture. Version 3.0

NASCIO EA Development Tool-Kit Solution Architecture. Version 3.0 NASCIO EA Development Tool-Kit Solution Architecture Version 3.0 October 2004 TABLE OF CONTENTS SOLUTION ARCHITECTURE...1 Introduction...1 Benefits...3 Link to Implementation Planning...4 Definitions...5

More information

Classical Software Life Cycle Models

Classical Software Life Cycle Models Classical Software Life Cycle Models SWEN 301 Trimester 1, 2015 Lecturer: Dr Hui Ma Engineering and Computer Science Lecture slides make use of material provided on the textbook's companion website Motivation

More information

Process Implications of Model-Driven Software Development

Process Implications of Model-Driven Software Development Process Implications of Model-Driven Software Development Author: Jorn Bettin Version 1.0 September 2004 Copyright 2003, 2004 SoftMetaWare Ltd. SoftMetaWare is a trademark of SoftMetaWare Ltd. All other

More information

Towards Collaborative Requirements Engineering Tool for ERP product customization

Towards Collaborative Requirements Engineering Tool for ERP product customization Towards Collaborative Requirements Engineering Tool for ERP product customization Boban Celebic, Ruth Breu, Michael Felderer, Florian Häser Institute of Computer Science, University of Innsbruck 6020 Innsbruck,

More information

An Automated Workflow System Geared Towards Consumer Goods and Services Companies

An Automated Workflow System Geared Towards Consumer Goods and Services Companies Proceedings of the 2014 International Conference on Industrial Engineering and Operations Management Bali, Indonesia, January 7 9, 2014 An Automated Workflow System Geared Towards Consumer Goods and Services

More information

To introduce software process models To describe three generic process models and when they may be used

To introduce software process models To describe three generic process models and when they may be used Software Processes Objectives To introduce software process models To describe three generic process models and when they may be used To describe outline process models for requirements engineering, software

More information

Aplicando enfoque MDE a aplicaciones WEB-SOA

Aplicando enfoque MDE a aplicaciones WEB-SOA Aplicando enfoque MDE a aplicaciones WEB-SOA María Consuelo Franky lfranky@javeriana.edu.co Dpto. Ingeniería de Sistemas Universidad Javeriana Bogotá - 2010 http://sophia.javeriana.edu.co/~lfranky/ 1 Temario

More information

Business Rule Standards -- Interoperability and Portability

Business Rule Standards -- Interoperability and Portability Rule Standards -- Interoperability and Portability April 2005 Mark H. Linehan Senior Technical Staff Member IBM Software Group Emerging Technology mlinehan@us.ibm.com Donald F. Ferguson IBM Fellow Software

More information

Change Pattern-Driven Traceability of Business Processes

Change Pattern-Driven Traceability of Business Processes Proceedings of the International MultiConference of Engineers and Computer Scientists 2014 Vol I,, March 12-14, 2014, Hong Kong Change Pattern-Driven Traceability of Business Processes Watcharin Uronkarn

More information

Clarifying a vision on certification of MDA tools

Clarifying a vision on certification of MDA tools SCIENTIFIC PAPERS, UNIVERSITY OF LATVIA, 2010. Vol. 757 COMPUTER SCIENCE AND INFORMATION TECHNOLOGIES 23 29 P. Clarifying a vision on certification of MDA tools Antons Cernickins Riga Technical University,

More information

OMG releases BPMN 1.1 - What's changed?

OMG releases BPMN 1.1 - What's changed? OMG releases BPMN 1.1 - What's changed? (revised version as of April 2008) Gero Decker 1 and Torben Schreiter 2 1 Hasso Plattner Institute, Potsdam, Germany 2 inubit AG, Berlin, Germany Abstract The Business

More information

1.. This UI allows the performance of the business process, for instance, on an ecommerce system buy a book.

1.. This UI allows the performance of the business process, for instance, on an ecommerce system buy a book. * ** Today s organization increasingly prompted to integrate their business processes and to automate the largest portion possible of them. A common term used to reflect the automation of these processes

More information

Chapter 13: Program Development and Programming Languages

Chapter 13: Program Development and Programming Languages Understanding Computers Today and Tomorrow 12 th Edition Chapter 13: Program Development and Programming Languages Learning Objectives Understand the differences between structured programming, object-oriented

More information

Requirements engineering

Requirements engineering Learning Unit 2 Requirements engineering Contents Introduction............................................... 21 2.1 Important concepts........................................ 21 2.1.1 Stakeholders and

More information

BPMN VS. UML ACTIVITY DIAGRAM FOR BUSINESS PROCESS MODELING

BPMN VS. UML ACTIVITY DIAGRAM FOR BUSINESS PROCESS MODELING Accounting and Management Information Systems Vol. 11, No. 4, pp. 637 651, 2012 BPMN VS. UML ACTIVITY DIAGRAM FOR BUSINESS PROCESS MODELING Cristina Venera GEAMBAŞU 1 The Bucharest University of Economic

More information

Budapest University of Technology and Economics Department of Measurement and Information Systems. Business Process Modeling

Budapest University of Technology and Economics Department of Measurement and Information Systems. Business Process Modeling Budapest University of Technology and Economics Department of Measurement and Information Systems Business Process Modeling Process, business process Workflow: sequence of given steps executed in order

More information

Designing and Enacting Cross-organisational Business Processes: A Model-driven, Ontology-based Approach

Designing and Enacting Cross-organisational Business Processes: A Model-driven, Ontology-based Approach Designing and Enacting Cross-organisational Business Processes: A Model-driven, Ontology-based Approach Stephan Roser Dissertation Programming Distributed Systems Department of Computer Science University

More information

Rules and Business Rules

Rules and Business Rules OCEB White Paper on Business Rules, Decisions, and PRR Version 1.1, December 2008 Paul Vincent, co-chair OMG PRR FTF TIBCO Software Abstract The Object Management Group s work on standards for business

More information

BUSINESS RULES CONCEPTS... 2 BUSINESS RULE ENGINE ARCHITECTURE... 4. By using the RETE Algorithm... 5. Benefits of RETE Algorithm...

BUSINESS RULES CONCEPTS... 2 BUSINESS RULE ENGINE ARCHITECTURE... 4. By using the RETE Algorithm... 5. Benefits of RETE Algorithm... 1 Table of Contents BUSINESS RULES CONCEPTS... 2 BUSINESS RULES... 2 RULE INFERENCE CONCEPT... 2 BASIC BUSINESS RULES CONCEPT... 3 BUSINESS RULE ENGINE ARCHITECTURE... 4 BUSINESS RULE ENGINE ARCHITECTURE...

More information

Development of Tool Extensions with MOFLON

Development of Tool Extensions with MOFLON Development of Tool Extensions with MOFLON Ingo Weisemöller, Felix Klar, and Andy Schürr Fachgebiet Echtzeitsysteme Technische Universität Darmstadt D-64283 Darmstadt, Germany {weisemoeller klar schuerr}@es.tu-darmstadt.de

More information

VbTrace: Using View-based and Model-driven Development to Support Traceability in Process-driven SOAs

VbTrace: Using View-based and Model-driven Development to Support Traceability in Process-driven SOAs VbTrace: Using View-based and Model-driven Development to Support Traceability in Process-driven SOAs Huy Tran and Uwe Zdun and Schahram Dustdar Distributed Systems Group Information System Institute Vienna

More information

Business Process Modelling Notation A tutorial

Business Process Modelling Notation A tutorial Business Process Modelling Notation A tutorial Sam Mancarella Chief Technology Officer Sparx Systems sam.mancarella@sparxsystems.com OMG SOA in Healthcare January 14, 2011 Tutorial Objectives This tutorial

More information

INTRODUCTION TO BUSINESS PROCESS MODELING NOTATION BPMN 1.2 AND BPMN 2.0

INTRODUCTION TO BUSINESS PROCESS MODELING NOTATION BPMN 1.2 AND BPMN 2.0 INTRODUCTION TO BUSINESS PROCESS MODELING NOTATION BPMN 1.2 AND BPMN 2.0 Email: {goliva,gerosa}@ime.usp.br / Twitter: @golivax Agenda 2 Introduction to Business Processes BPMN 1.2 Introduction Elements

More information

California Enterprise Architecture Framework

California Enterprise Architecture Framework Version 2.0 August 01, 2013 This Page is Intentionally Left Blank Version 2.0 ii August 01, 2013 TABLE OF CONTENTS 1 Executive Summary... 1 1.1 What is Enterprise Architecture?... 1 1.2 Why do we need

More information

Comparison of Model-Driven Architecture and Software Factories in the Context of Model-Driven Development

Comparison of Model-Driven Architecture and Software Factories in the Context of Model-Driven Development Comparison of Model-Driven Architecture and Software Factories in the Context of Model-Driven Development Ahmet Demir Technische Universität München Department of Informatics Munich, Germany AhmetDemir@gmx.de

More information

Robust Object Oriented System Analysis

Robust Object Oriented System Analysis Robust Object Oriented System Analysis Dr Jie Zhao, Dunstan Thomas Consulting Summary Uses cases are widely accepted as the best approach to capturing system requirements, in particular, functional requirements.

More information

BPMN PATTERNS USED IN MANAGEMENT INFORMATION SYSTEMS

BPMN PATTERNS USED IN MANAGEMENT INFORMATION SYSTEMS BPMN PATTERNS USED IN MANAGEMENT INFORMATION SYSTEMS Gabriel Cozgarea 1 Adrian Cozgarea 2 ABSTRACT: Business Process Modeling Notation (BPMN) is a graphical standard in which controls and activities can

More information

What is a life cycle model?

What is a life cycle model? What is a life cycle model? Framework under which a software product is going to be developed. Defines the phases that the product under development will go through. Identifies activities involved in each

More information

Increasing Development Knowledge with EPFC

Increasing Development Knowledge with EPFC The Eclipse Process Framework Composer Increasing Development Knowledge with EPFC Are all your developers on the same page? Are they all using the best practices and the same best practices for agile,

More information

Surveying and evaluating tools for managing processes for software intensive systems

Surveying and evaluating tools for managing processes for software intensive systems Master Thesis in Software Engineering 30 Credits, Advanced Level Surveying and evaluating tools for managing processes for software intensive systems Anuradha Suryadevara IDT Mälardalen University, ABB

More information

Information systems modelling UML and service description languages

Information systems modelling UML and service description languages Internet Engineering Tomasz Babczyński, Zofia Kruczkiewicz Tomasz Kubik Information systems modelling UML and service description languages Student Contact Hours: 25.02.2015- Location: 325 C3 room 25.03.2015:

More information

A Business Process Driven Approach for Generating Software Modules

A Business Process Driven Approach for Generating Software Modules A Business Process Driven Approach for Generating Software Modules Xulin Zhao, Ying Zou Dept. of Electrical and Computer Engineering, Queen s University, Kingston, ON, Canada SUMMARY Business processes

More information

Propagation of States from BPEL Process Instances to Chevron Models

Propagation of States from BPEL Process Instances to Chevron Models Universität Stuttgart Fakultät Informatik, Elektrotechnik und Informationstechnik Propagation of States from BPEL Process Instances to Chevron Models David Schumm, Dimka Karastoyanova, Frank Leymann, and

More information

Services Modeling Using BPMN 2.0 - It s Not Just Boxes and Arrows Anymore! - Presented By Lloyd Dugan September 11, 2013

Services Modeling Using BPMN 2.0 - It s Not Just Boxes and Arrows Anymore! - Presented By Lloyd Dugan September 11, 2013 Services Modeling Using BPMN 2.0 - It s Not Just Boxes and Arrows Anymore! - Presented By Lloyd Dugan September 11, 2013 Outline Overview of BPMN Services Modeling with BPMN Enterprise Services in BPMN

More information

MODEL DRIVEN DEVELOPMENT OF BUSINESS PROCESS MONITORING AND CONTROL SYSTEMS

MODEL DRIVEN DEVELOPMENT OF BUSINESS PROCESS MONITORING AND CONTROL SYSTEMS MODEL DRIVEN DEVELOPMENT OF BUSINESS PROCESS MONITORING AND CONTROL SYSTEMS Tao Yu Department of Computer Science, University of California at Irvine, USA Email: tyu1@uci.edu Jun-Jang Jeng IBM T.J. Watson

More information

A Mind Map Based Framework for Automated Software Log File Analysis

A Mind Map Based Framework for Automated Software Log File Analysis 2011 International Conference on Software and Computer Applications IPCSIT vol.9 (2011) (2011) IACSIT Press, Singapore A Mind Map Based Framework for Automated Software Log File Analysis Dileepa Jayathilake

More information

7. Classification. Business value. Structuring (repetition) Automation. Classification (after Leymann/Roller) Automation.

7. Classification. Business value. Structuring (repetition) Automation. Classification (after Leymann/Roller) Automation. 7. Classification Business Process Modelling and Workflow Management Business value Lecture 4 (Terminology cntd.) Ekkart Kindler kindler@upb.de Structuring (repetition) Automation UPB SS 2006 L04 2 Classification

More information

Information Science 1

Information Science 1 Topics covered Information Science 1 Terms and concepts from Week 05 The software development process Program'Development /Algorithms'and'Problem'Solving/'' ' software software life cycle life-cycle models

More information

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville

Software Engineering. Software Processes. Based on Software Engineering, 7 th Edition by Ian Sommerville Software Engineering Software Processes Based on Software Engineering, 7 th Edition by Ian Sommerville Objectives To introduce software process models To describe three generic process models and when

More information

Consistency in Multi-Viewpoint Architectural Design of Enterprise Information Systems

Consistency in Multi-Viewpoint Architectural Design of Enterprise Information Systems Consistency in Multi-Viewpoint Architectural Design of Enterprise Information Systems Remco M. Dijkman 1,2, Dick A.C. Quartel 2, Marten J. van Sinderen 2 1 Eindhoven University of Technology, Eindhoven,

More information

A Business Process Services Portal

A Business Process Services Portal A Business Process Services Portal IBM Research Report RZ 3782 Cédric Favre 1, Zohar Feldman 3, Beat Gfeller 1, Thomas Gschwind 1, Jana Koehler 1, Jochen M. Küster 1, Oleksandr Maistrenko 1, Alexandru

More information

A standards-based approach to application integration

A standards-based approach to application integration A standards-based approach to application integration An introduction to IBM s WebSphere ESB product Jim MacNair Senior Consulting IT Specialist Macnair@us.ibm.com Copyright IBM Corporation 2005. All rights

More information

Chapter 13: Program Development and Programming Languages

Chapter 13: Program Development and Programming Languages 15 th Edition Understanding Computers Today and Tomorrow Comprehensive Chapter 13: Program Development and Programming Languages Deborah Morley Charles S. Parker Copyright 2015 Cengage Learning Learning

More information

Software Specification and Testing

Software Specification and Testing Software Specification and Testing Using UML and OCL Jonathan Milley Faculty of Engineering and Applied Science MUN St. John s, Newfoundland Email: jmilley@engr.mun.ca Dr. Dennis K. Peters Faculty of Engineering

More information

BPEL. A Step by Step Guide: Model-Driven Generation with. Enterprise Architect. T his document will teach you how to use the Business Process

BPEL. A Step by Step Guide: Model-Driven Generation with. Enterprise Architect. T his document will teach you how to use the Business Process BPEL A Step by Step Guide: Model-Driven Generation with Enterprise Architect T his document will teach you how to use the Business Process Modeling Notation (BPMN 1.1) as a visual approach to producing

More information

Verification of Good Design Style of UML Models

Verification of Good Design Style of UML Models Verification of Good Design Style of UML Models Bogumiła Hnatkowska 1 1 Institute of Applied Informatics, Wrocław University of Technology, Wybrzeże Wyspiańskiego 27, 50-370 Wrocław, Poland Bogumila.Hnatkowska@pwr.wroc.pl

More information

A SOA visualisation for the Business

A SOA visualisation for the Business J.M. de Baat 09-10-2008 Table of contents 1 Introduction...3 1.1 Abbreviations...3 2 Some background information... 3 2.1 The organisation and ICT infrastructure... 3 2.2 Five layer SOA architecture...

More information

3C05: Unified Software Development Process

3C05: Unified Software Development Process 3C05: Unified Software Development Process 1 Unit 5: Unified Software Development Process Objectives: Introduce the main concepts of iterative and incremental development Discuss the main USDP phases 2

More information

UML-based Test Generation and Execution

UML-based Test Generation and Execution UML-based Test Generation and Execution Jean Hartmann, Marlon Vieira, Herb Foster, Axel Ruder Siemens Corporate Research, Inc. 755 College Road East Princeton NJ 08540, USA jeanhartmann@siemens.com ABSTRACT

More information

Lecture 9: Requirements Modelling

Lecture 9: Requirements Modelling A little refresher: What are we modelling? Lecture 9: Requirements Modelling Requirements; Systems; Systems Thinking Role of Modelling in RE Why modelling is important Limitations of modelling Brief overview

More information

In this Lecture you will Learn: Development Process. Unified Software Development Process. Best Practice

In this Lecture you will Learn: Development Process. Unified Software Development Process. Best Practice In this Lecture you will Learn: Development Chapter 5C About the Unified Software Development How phases relate to workflows in an iterative life cycle An approach to system development Major activities

More information

Generating Enterprise Applications from Models

Generating Enterprise Applications from Models Generating Enterprise Applications from Models Vinay Kulkarni, R Venkatesh, Sreedhar Reddy Tata Research Development and Design Centre, 54, Industrial estate, Hadapsar, Pune, 411 013, INDIA { vinayk, rvenky,

More information