8th International Conference of Modeling and Simulation - MOSIM’10 - May 10-12, 2010 - Hammamet - Tunisia “Evaluation and optimization of innovative production systems of goods and services”

MAPPING OF BPMN MODELS INTO UML MODELS USING SOAML PROFILE Y. LEMRABET, J. TOUZI, D. CLIN, M. BIGAND and J.-P. BOUREY Univ Lille Nord de France, F-59000 Lille, France Laboratoire de Modélisation et de Management des Organisations, Ecole Centrale de Lille, BP48 59651 Villeneuve d'Ascq cedex, France {Youness.Lemrabet, Jihed.Touzi, David.Clin, Michel.Bigand, Jean-Pierre.Bourey}@ec-lille.fr

ABSTRACT: Service-Oriented Architecture (SOA) is an architectural paradigm for the conception and construction of information systems. Service Oriented Architecture Modeling Language (SoaML) provides a standard way to architect and model SOA solutions using the Unified Modelling Language (UML). The SOA analysis and design disciplines of software development based on scenarios now take a broader approach when they attempt to focus at companywide problems rather than specific issues. In order to assess this need of a higher level scenario representation, notations for business process modelling have emerged from the different standard bodies, such as the Business Process Modeling Notation (BPMN). This paper describes the SoaML profile, BPMN and the mapping between them. The main contribution of this paper is a description of basic mechanisms of transformation of BPMN model to SoaML model. KEYWORDS: MDA, BPMN, UML, SOAML, ATL

1

INTRODUCTION

Nowadays, the communication between business and Information Systems (IS) specialists is crucial to make successful the Business/IT alignment of the enterprise. An efficient information system must answers perfectly the business needs of the enterprise. In the traditional IS development practices, manual transmission of business needs to IS developers risks a loose of critical information. Initial Business requirements are usually not accurate or lost in handoff from business to IT. Most projects result in a compromise because the feature set cannot be implemented in time for production deadlines. The application of model-driven development facilitates faster and more flexible integration by separating system description two different levels of abstraction. The global Model Driven Architecture (MDA) (MDA,2003) approach shows that it is possible to separate concerns by splitting implementation choices from specifications of business needs. Specifically, the MDA paradigm proposes to start from an Enterprise Modelling level that means at Computation Independent Model (CIM) level, defining the collaboration needs of a set of partners and to reach a Platform Independent Model (PIM) level defining a logical architecture of a collaborative solution. Finally the Platform specific Model (PSM) can be generated. The three models are in closed connections and passing from one layer to another one, must be facilitated by vertical transformation rules.

The design of collaborative solutions respecting SOA considerations has become one of the major topics in the domain of interoperability. As example, the PIM4SOA project (Platform-Independent Model for ServiceOriented Architecture) (Benguria et al., 2006) aims to develop a metamodel for SOA. This metamodel consists of a set of essential aspects for SOA. PIM4SOA addresses four system aspects (views): processes (logical order in terms of actions, control flows and interactions between services), information (related to the messages or structures exchanged by services), services (description of services: access, operations and types) and quality of services (extra-functional qualities that can be applied to services, information and processes). The project also provides a set of transformations that link the meta-model with specific platforms (Agents, Web services, etc.) following the MDA approach. However, transformation rules and mappings between PIM and PSM levels are not explicitly explained in the project. In the problematic tackled in this paper (Business to IT alignment) we consider the feasibility of the models transformation between two formalisms in both business and IS design modelling. The formalism considered to specify the business needs is Business Process Modelling Notation (BPMN). The formalism considered to design the IS solution is an UML profile called SoaML profile (which is Service Oriented Architecture (SOA) oriented). We want to answer to the question about how

MOSIM’10 - May 10-12, 2010 - Hammamet - Tunisia

to deduce automatically SoaML models starting from BPMN models? The second section of this paper presents some related knowledge to our problematic. The third section shows the generation of two UML models based on the SoaML profile starting from a BPMN example. 2

information is not clearly formalized. These two transformations should be bidirectional for reverse engineering.

RELATED KNOWLEDGE

This part defines the basic concepts related to our research work. MDA, BPMN and SoaML profile are presented. 2.1

Model Driven Architecture (MDA)

The MDA is a framework for software development defined by the Object Management Group (OMG). The aim of MDA is to promote the use for models and their transformations for software engineering. The process of software development is based on 4 levels (Figure 1). The Computation Independent Model (CIM) level collects characteristics and needs of the firm. This model enables a representation and an understanding of how the firm works, to capitalize its knowledge and its knowhow for a subsequent use. The Platform Independent Model (PIM) level models the subset of the organization which is concerned by the software development. It represents the different functional entities of a system with their relations, expressed only with the terms of firm. The Platform Specific Model (PSM) level takes into account peculiarities linked to the platform of development by the Platform Development Model (PDM). The last level is that of the applications of firm, the computer code, Enterprise Software Application (ESA).

Figure 2: Four levels of MDA architecture The main interest of this automated process is to allow the reusing of the same PIM for implementation on several platforms; moreover, it allows the bridging between several PSM and ESA, what is very interesting for software interoperability. Finally, during the maintenance of the software, the modifications aren’t done at ESA level, but at PIM level in order to maintain a high level consistency of the models. MDA is based on the 4 modelling layers of the OMG (Figure 2). Based on MDA, Model Driven Interoperability (MDI) (Bourey et al.,2006) has been proposed, that takes into account the interoperability between firms at the enterprise modelling level. 2.2

Figure 1: MDA software development process In an ideal way, all these levels are connected by automated transformations. In reality, the transition between CIM and PIM levels results from organization choices and needs complementary information; so, it cannot be fully automated. The two transformations should be automated; it is at the moment only partially operational and additional needed

Business (BPMN)

Process

Management

Notation

BPMN (OMG, 2009a) is a graphical notation whose aim is to model enterprise processes. It has been developed by Business Process Management Initiative (now a part of the OMG). The objective of BPMN is to give a picture of the processes that is common to the different actors, and that can be transformed in an execution language in order to automate the processes (with a workflow tool). The main interest of BPMN for our purpose is that it allows services and participants identification, with service tasks and pools. Several patterns of BPMN models exist; there are parts of models of common interest that can be re-used and adapted to a particular context. Such patterns are current for general interest (how to represent an OR condition, for example). Business patterns have been proposed (Yahia et al., 2009) in the framework of ASICOM project for international trading.

MOSIM’10 - May 10-12, 2010 - Hammamet - Tunisia

2.3

Service Oriented Architecture Language (SoaML).

Modeling

SoaML (Berre, 2008) is an UML (OMG, 2009b) extension for Service Oriented Architecture (SOA) with a MDA approach. It is an answer to the OMG call for proposal and it keeps main modelling principles of PIM4SOA. SoaML concerns the logical architecture of an information system, independently of the technical components. The aim is to give to UML users a mean to model a SOA including the notions of services consumers and suppliers, and contract. SoaML defines a metamodel and a profile for services design in a modelling approach. SoaML metamodel extends the UML metamodel; it provides minimal extensions to UML to accomplish the goals and requirements of service modelling. SoaML profile includes the specification of services systems, services interfaces and services implementation. The main stereotypes of SoaML profile used in this paper are: ServiceContract, ServiceInterface, Participants, and Service Data. 3

THE BPMN / SOAML MAPPING

In this section we focus on the first elements of two complementary mapping proposals from BPMN to SoaML. The presentation is based on a online shopping case. The objective is to show how elements of a BPMN source model can be mapped onto SoaML models. In this paper Component Architecture and Services Architecture have been chosen as the target models. 3.1

• Buyer: customer who comes to online shop to buy products. • Seller: an online shop, which faces the buyer. It plays the role of mediator to enable the collaboration with bank and logistic company. • Bank: it processes the payment. • Shipper: it processes the shipping function during the process, the delegate would be logistic company.

Figure 3: View of BPMN

BPMN Model

The objective of the BPMN formalism is to support process management by both technical and business users. Interactions in BPMN are mainly represented using the “message flow” concept which shows an exchange of data between two actors of the process. Actors can be people or organisations. These actors are represented using “pool” concept. Pools can be divided in many “lanes” (different roles of an actor). There are many synchronization mechanisms in BPMN: sequencing (“sequence flow” concept), events (“start event”, “intermediate event” and “end event” concepts), forking (“parallel gateway” concept), conditioning (“databased gateway” and “event-based gateway” concepts), etc. BPMN was chosen because it is sufficiently rich and expressive and it provides a notation that is intuitive to business users yet able to represent complex processes. The online shopping case describes the processes allowing a customer to purchase products through an online shop, to perform online payment and to benefit from an offline shipping of products. Figure 3 shows the whole processes of this example and Figure 4 shows the details of the upper left part of the diagram. This diagram contains totally four pools which correspond to the actors of the process:

Figure 4: Detail of the BPMN process The Buyer searches through available products in the online shop. Then he decides to add an order of available products. When he has finished, he confirms his order and sends it to the Seller. Then the order get a confirmed status and the Seller instantiates the process for retrieving transport proposals and corresponding prices. Alternative transport plans and prices are given to the Buyer and he has to decide which plan fit his needs. When the Buyer has selected a plan, he submits his choice with payment information to the Seller. Then it processes the payment information and a request is sent to the bank. After receiving the information from the Seller, the bank contacts the Buyer to get confirmation and sends the confirmation to the Seller. Then the Seller sends, a ship-

MOSIM’10 - May 10-12, 2010 - Hammamet - Tunisia

ping request to the Shipper and the Buyer gets a confirmation that order is completed.

coming from other sub-processes. But they be consistent with the top view.

From Figure 3 we can see there are 7 main communications flows in the process.

3.2.1 Mapping to Component Architecture

• Communication between Buyer and Seller for processing products’ search; • Communication between Buyer and Seller for proposing shipping plans; • Communication between Buyer and Seller for setting payment; • Communication between Seller and Bank for processing set of payment functions; • Communication between Buyer and Bank for processing confirmation of payment; • Communication between Seller and Shipper for processing set of production shipping; • Communication between Buyer and Shipper: processing confirm of production shipping;

In Component Architecture diagram there are Participant and ServiceInterface, so we use the top view to describe the mapping rules. In SoaML, the concept of Participant is defined and the stereotype is used to label UML classes or components. Participants are types of actors defined both by the roles they play in services architectures (the participant role) and the “contract” requirements of entities playing those roles. In BPMN, a Pool represents a Participant in a Process. It is also acts as a graphical container for partitioning a set of activities from other Pools. So a BPMN Pool can be directly mapped onto a SoaML Participant. A ServiceInterface defines the interface and responsibilities of a participant to provide or consume a service. It is used as the type of a Service or Request port (Berre, 2008). The service interface has the additional feature that it can specify a bi-directional service – where both the provider and consumer have responsibilities to send and receive messages and events. The stereotype is defined from the perspective of the service provider using three primary sections: The interfaces, the Service Interface class and the Behavior. Service interface is the super type of “Provider” and “Consumer” and is used for service contracts with more than two roles. The activity from different roles fulfils the function. They use message flow to combine each other and work together, just like collaboration. So the activities should be the port. The ServiceInterface has no direct mapping elements from BPMN as the functions point of view.

For example processing search products (communication between Buyer and Seller): when the Buyer logs onto the online shop platform and when he chooses products. This process will communicate with the Seller a few times to make sure the product list. Buyer first sends a product view request. Seller receives the message include keyword, the search product process find product info and generate product list return to Buyer. 3.2

Mapping rules

Nowadays, the model driven approach is followed by numerous projects and communities like INTEROP (Interop, 2007) in the European Union and Model Driven Architecture (MDA) (OMG, 2003), which is carried out by the Object Management Group (OMG)1. MDA, for instance, intends to promote the use of models as fundamental way of designing and implementing different kinds of systems. This article intends to provide an innovative methodology to develop a collaborative architecture (that provides interoperability capacity to partners) following the MDA approach. In this paper we use first Component Architecture as SoaML target model. In order to map this BPMN model efficiently to the SoaML model, we should make some rules for the BPMN model. We consider the diagram from two points of view: top view and detail view. The top view is more general and the structure of detail view, just to give the main activities of the whole business process and it describes communications between different participants. The only elements appearing in BPMN top view are activities, message flows, and both begin and end events. The detail view is the extension of top view; it just enlarges the content, not revising it. We could just use sub-processes to describe in details what is inside the activities. Each sub-process has a start event and an end event. There also could be message flows 1

www.omg.org

BPMN Pool Analyze of message flows and pools relation

Condition none none

SoaML Participant Service Interface

Table 1: First mapping of BPMN onto SoaML ComponentArchitecture

Figure 5 shows the Component Architecture deduced when applying theproposed BPMN
SoaML mapping. Here we can contrast with BPMN diagram. First we take the BPMN top view and find each pool and its activities. Then the ServiceInterface are defined according to the message flow between activities. In this example, there are four pools in the BPMN diagram, so there are four components. And we can find seven main communication flows between activities. For example the ISearchProduct is provided by the component Seller stereotyped by . This interface is required by the participant Buyer for choosing products. This interface is defined

MOSIM’10 - May 10-12, 2010 - Hammamet - Tunisia

from the first message exchange detailed in Figure 3. Table 1 shows the mapping from BPMN to Component Architecture.

Figure 5: Component Architecture

mapping elements from BPMN but can be defined as soon as a message exchange is defined between two pools. Request port: we can see that there are two kinds of interfaces supported by the port: required interfaces and provided interfaces. Service interface is the super type of “Provider” and “Consumer” and is used for service contracts with more than two roles. The activity from different roles fulfils the function. They use message flow to combine each other and work together, just like collaboration. So the activities define the ports. Activities with outgoing message flows (resp. incoming message flows) define Request ports (resp. and Service ports). The participant roles are filled by participants with service ports required of the entities that fill these roles and are then bound by the services architectures they participate in. A participant plays a role as the provider or user of service contracts. So we can use message flows to define role. Figure 6 shows obtained service architecture when this mapping applied to the online shopping case.

3.2.2 Mapping to Service Architecture One of the key benefits of SOA is the ability to enable a community or organizations to work together more cohesively using services without getting overly coupled. This requires an understanding of how people, organizations and systems work together, or collaborate, for some purpose. We make it possible to represent this collaboration by creating a services architecture model. The services architecture puts a set of services in context and shows how participants work together for a community or organization. So we give another mapping between BPMN and SoaML, services architecture. Table 2 shows the mapping BPMN onto Services Architecture. BPMN Pool Activity Activity Message Flow

Condition none With outgoing message flow With incoming message flow none

SoaML Participant Request port Service port ServiceContract + Roles

Table 2 : Mapping BPMN to SoaML ServiceArchitecture

Like in the previous mapping, a BPMN Pool is mapped onto a Participant. SoaML defines the ServiceContract concept (Berre, A.J.,2008): ServiceContracts can cover requirements, service interactions, quality of service agreements, interface and choreography agreements, and commercial agreements. The service contract is a binding on both the provider and consumer of that service. It has no direct

Figure 6: Services architecture with participant roles and services In this architecture we can see the BPMN online shopping process is transformed into a ServiceArchitecture and its four pools are transformed into four Participants. Let us have a focus on the ServiceContracts between the participants Seller and Buyer. First, the participants Seller, Buyer are defined by the corresponding BPMN pools. As we mentioned before there are three ServiceInterfaces: ISearchProduct, ISetShippingConditions and ISetPayment. The both interfaces ISearchProduct, ISetPayment are used by Buyer to define his product list and set his payment. So we could group them into one ServiceContract named BuyingService. The other ServiceContract named ShippingScheduleService defines how the agreements are set up between the Buyer and the Seller for the shipping activities. We have defined a specific ServiceContract for this relation because it could depend indirectly on the Ser-

MOSIM’10 - May 10-12, 2010 - Hammamet - Tunisia

viceContract the Seller has with the Shipper. The decision to group or not services into one or several ServicesContract depends on the context of the relationships between participants. 4

CONCLUSION

Our work is linked to research works in the Model Driven Interoperability field. In this paper we have defined, using two basic mappings, two UML models based on the SoaML profile (PIM) from a BPMN model (CIM).We have showed how we can derive from a CIM model the necessary information to create PIM-level models. However; the transformation from BPMN to SoaML could not be completely automated because it is needed both to add information concerning the context and to make decisions (for example to group or not services into a same Service contract) . SoaML is not currently a standard but a draft. We are working on a prototype to implement our proposition. The ATL (Jouault et al., 2006) models transformation tool is used to realize our mapping rules. Two other open source tools that run in the Eclipse platform (STP BPMN Modeler and TopCased) are respectively used to design BPMN models and visualize generated UML models. We are also working on integration of the new forthcoming version of BPMN (BPMN2.0) planned by the end of June 2010. ACKNOWLEDGMENTS This work is partially founded by the ASICOM project (a French acronym for “Interoperable Information System Architecture for Trade Industry”). This project is approved by two French poles of competitiveness: PICOM2 in Trade Industries domain and Nov@log3 in Logistics domain. REFERENCES Benguria, G., Larrucea, X., Elveseater, B., Neple, T., Beardsmore, A., Friess, M., 2006. Platform Independent Model for Service Oriented Architectures. Enterprise Interoperability: New Challenges and Approaches- Springer Verlag - ISBN-10: 1846287138, pp 23-32. Berre, A.J.,2008. Service oriented architecture Modeling Language (SoaML) - Specification for the UML Profile and Metamodel for Services (UPMS), http://www.omg.org/docs/ad/08-08-04.pdf. Bourey, J.P., Grangel, R., Doumeingts, G., and Berre, A, 2006. INTEROP NoE: Deliverable DTG2.2: Report 2

http://www.picom.fr/

3

http://www.novalog.eu/

on Model Interoperability. http://interopvlab.eu/ei_public_deliverables/interop-noedeliverables/tg2-model-driven-interoperability/. Jouault, F., Allilaire, F., Bezivin, J., Kurtev, I., and Valduriez, P, 2006. ATL: a QVT-like transformation language. In P.L. Tarr and W.R. Cook (eds.), OOPSLA Companion, 719-730. ACM. INTEROP, 2007. Interoperability Research for Networked Enterprises Applications and Software NoE (IST-2003-508011). http://www.interop-vlab.eu/. OMG, 2009a, BPMN: OMG Document Number: formal/2009-01-03 version 1.2, http://www.omg.org/spec/BPMN/1.2/PDF (2009) OMG , 2003. MDA Guide Version 1.0.1. [online] Available from: http://www.omg.org/docs/omg/03-0601.pdf [Accessed 07 September 2009]. OMG, 2009b. Unified Modeling Language: Superstructure, version 2.2. [online] Available from: http://www.omg.org/spec/UML/2.2/ [Accessed 07 September 2009]. Yahia, E., Bigand, M., Bourey J.P and Castelain, E, 2009. Supply chain business patterns definition for process interoperability, In 13th IFAC Symposium on Information Control Problems in Manufacturing, Moscow. http://www.ifac-papersonline.net/Detailed/40609.html [Accessed 07 March 2010].