A Modeling Approach for Collaborative Business Processes based on the UP-ColBPIP Language Pablo David Villarreal1, Ivanna Lazarte1, Jorge Roa1, Omar Chiotti1,2 1

CIDISI, Universidad Tecnológica Nacional - Facultad Regional Santa Fe, Lavaisse 610, S3004EWB, Santa Fe, Argentina {pvillarr, ilazarte, jroa}@frsf.utn.edu.ar 2 INGAR-CONICET, Avellaneda 3657, S3002GJC, Santa Fe, Argentina {chiotti}@santafe-conicet.gov.ar

Abstract. The modeling of collaborative business processes is an important issue in order to allow enterprises to implement B2B collaborations with their business partners. We have proposed an MDA-based methodology for the modeling, verification and implementation of collaborative processes. Since collaborative process models are the main artifacts in this MDA-based methodology, a suitable modeling approach is required to design collaborative processes. In this work we describe a modeling approach for collaborative processes based on the UP-ColBPIP language, which is oriented to support the model-driven development of collaborative processes and B2B information systems. The behavior of collaborative processes is modeled through interaction protocols. Enhances to the control flow constructors of interaction protocols are introduced. In addition, we describe an Eclipse-based tool that supports this language. Keywords: Collaborative Business Process, Business-to-Business, ModelDriven Development, UML Profile, Interaction Protocol

1 Introduction The modeling of collaborative business processes is an important issue in order to allow enterprises to implement B2B collaborations. Business-to-Business collaborations entail a process-oriented integration among heterogeneous and autonomous enterprises at a business level and a technological level. At the business level, enterprises focus on the design of collaborative processes to define and agree on the behavior of the inter-enterprise collaboration. A collaborative business process defines the global view of the interactions between enterprises to achieve common business goals [20]. Through these processes, partners agree to jointly carry out decisions, coordinate their actions, and exchange information through B2B systems. At the technological level, enterprises focus on the implementation, integration and interoperability of their B2B information systems to execute collaborative processes. This implies the generation of B2B specifications, i.e. interfaces of the partners’ systems and business process specifications based on a B2B standard, required by

each enterprise to execute the role performed in a collaborative process and implement it in a business process management system (BPMS). In previous works, a methodology for the modeling, verification and implementation of collaborative processes was proposed [16, 17, 20]. This methodology uses techniques, languages and methods that exploit the principles of the model-driven architecture (MDA) [13] to guarantee the alignment between the business solution and the technological solution of a B2B collaboration. This MDAbased methodology enables both the design of collaborative processes independent of the idiosyncrasies of particular B2B standards, and the automatic generation of B2B specifications based on a B2B standard from conceptual collaborative process models. The main benefits of this methodology are: (1) the increase of the abstraction level because the main development artifacts are the technology-independent collaborative process models; (2) the reduction of development time and costs along with the guarantee of alignment of the business solution with the technological solution, since process specifications are generated automatically from collaborative process models; and (3) the independence of collaborative process models from B2B standards. Since collaborative process models are the main artifacts in this MDA-based methodology, a suitable modeling approach is required for collaborative processes. A collaborative process model should be independent of the implementation technology, understandable and easy to read by business analysts and system developers. Besides, the modeling approach should fulfill the capabilities required by B2B interactions [20, 22]: global choreography of B2B interactions, enterprise autonomy, decentralized management, peer-to-peer interactions and representation of complex negotiations. In this work we describe a modeling approach for collaborative business processes based on the UP-ColBPIP language (UML Profile for Collaborative Business Processes based on Interaction Protocols). This is oriented to support the modeldriven development of collaborative processes and B2B information systems and fulfill the requirements mentioned above. The behavior of collaborative processes is modeled through interaction protocols, which are focused on the representation of the communicative aspects of B2B interactions. Enhances to this language are introduced to provide a complete set of control flow constructors to model collaborative processes. In addition, a case tool that supports the UP-ColBPIP language is presented, which is built on the Eclipse open development platform [3]. This paper is organized as follows. Section 2 describes the MDA-based methodology for collaborative processes. Section 3 describes the modeling approach for collaborative processes based on the UP-ColBPIP language. Section 4 presents the Eclipse-based tool that supports this language. Section 5 discusses related work and Section 6 presents conclusions and future work.

2 MDA-based Methodology for Collaborative Business Processes The model-driven architecture (MDA) [13] was identified as a key enabler to support the development of collaborative processes [17]. An MDA-based approach was proposed to support the modeling of collaborative processes and the automatic generation of process specifications and partners’ system interfaces based on a B2B

standard [20]. Also, an MDA-based approach was proposed to generate formal specifications of collaborative processes and verify if they are well-formed [21]. Both approaches make up the MDA-based methodology for collaborative processes [17], which consists of three phases: analysis and design of collaborative processes, verification of collaborative processes and generation of B2B specifications. The analysis and design of collaborative processes is about the modeling of these processes from a business perspective, i.e. using concepts that are less bound to the implementation technology and are closer to the B2B collaboration domain. To support this phase, the UP-ColBPIP language [16, 20] is used in order to enable the modeling of technology-independent collaborative processes. The second phase consists of verifying the correctness of collaborative processes defined in a UP-ColBPIP model. The purpose is to support the verification of these processes at an early stage of the development, when most of the fundamental decisions of a B2B collaboration are carried out, i.e. previous to the generation of the technological solution. The verification is essential to allow partners to make sure the behavior of collaborative processes is well-defined. To support this, the MDA-based approach for generating Petri Net specifications from a UP-ColBPIP model is applied [21] (see Figure 1.a). Interaction protocols are formalized, transformed and mapped into Colored Petri Net [7] specifications, which are then verified with CPN Tools [2].

Fig. 1. MDA-based approaches for Collaborative Business Processes

Finally, the third phase consists of selecting the target implementation technology (i.e. the B2B standards) and generating the B2B specifications (i.e. the business process specifications and interfaces of the partners’ systems) that fulfill the collaborative processes defined in the first phase. Figure 1.b shows the MDA-based approach that supports this phase. The input is a UP-ColBPIP model that contains collaborative processes based on interaction protocols and partners’ business interfaces. From this model, technology-specific business process models and technology-specific partners’ interface models are made. Then, B2B specifications are generated. In previous work we described the application of this MDA approach to generate technological solutions based on the widely used B2B standards: ebXML [20], WS-BPEL [18] and WS-CDL [19]. We showed how UP-ColBPIP models can be used to generate technological solutions with these standards.

3 Modeling Collaborative Processes with the UPColBPIP Language The UP-ColBPIP language extends the UML2 semantics to model technologyindependent collaborative processes [16, 20]. The language was defined as a UML Profile in order to provide well-known graphical notations for modeling collaborative processes that were easy to understand by business analysts and system designers. This language encourages a top-down approach to model collaborative processes and provides the conceptual elements to support the modeling of five views: • The B2B Collaboration View defines the participants (partners and their roles) of a B2B collaboration with their communication relationships. UP-ColBPIP extends the semantics of UML2 collaborations to represent B2B Collaborations. This view also describes the hierarchy of common business goals that partners agree on. To represent it, UP-ColBPIP extends the semantics of UML classes and objects. • The Collaborative Business Process View is concerned with the identification of collaborative processes required to achieve the agreed business goals. Current management principles suggest a business process should achieve a business goal. Key performance indicators can be associated with business goals to allow the evaluation of collaborative processes for their redesign or improvement. UPColBPIP extends the semantics of use cases to define collaborative processes as informal specifications of a set of actions performed by partners to achieve a goal. • The Interaction Protocol View defines the behavior of collaborative processes through the definition of interaction protocols. This view is described below. • The Business Document View focuses on representing business documents to be exchanged in collaborative processes. Business documents and their types are represented in class diagrams, and they are referenced in collaborative processes and interaction protocols. UP-ColBPIP does not provide any particular concepts to define the syntactic and semantics structure of business documents. To do that, other suitable languages can be used, such as the approach proposed in [1]. • The Business Interface View describes the interfaces of each role performed by partners. A business interface (service) contains business operations that support the asynchronous message exchange of interaction protocols. To represent it, UPColBPIP extends the semantics of the UML2 composite structures and interfaces. Due to space limitations, in this work we only describe the Interaction Protocol View in order to present the modeling approach we propose to model the behavior of collaborative processes. More details about this language can be found in [20]. 3.1 Interaction Protocol View One of the main purposes of this language is to fulfill the requirements for the conceptual modeling of collaborative processes and B2B collaborations [20, 22]: global view of the interactions between partners, enterprise autonomy, decentralized management, peer-to-peer interactions and representation of complex negotiations. To fulfill these requirements, the UP-ColBPIP language incorporates the interaction protocol concept to define the behavior of collaborative processes. An interaction protocol describes a high-level communication pattern through a choreography of business messages between partners who play different roles.

Modeling interaction protocols focus on representing the global view of the interactions between partners. The message choreography describes the global control flow of peer-to-peer interactions between partners as well as the responsibilities of the roles they fulfill. This also enables the representation of the decentralized management of the interactions between partners. Interaction protocols focus on the exchange of business messages representing interactions between partners, preserving the enterprise autonomy. Internal activities of the partners cannot be defined in protocols and hence, they are hidden to partners. In addition, B2B interactions should not only represent the information exchange but also the communication of actions between partners. Coordination and communication aspects of B2B interactions are represented in interaction protocols through the use of speech acts. In an interaction protocol, a business message has an associated speech act, which represents the intention the sender has with respect to the business document exchanged in the message. Thus, decisions and commitments between partners can be known from the speech acts. This enables the definition of complex negotiations and avoids the ambiguity in the semantics and understanding of the business messages of collaborative processes. UP-ColBPIP extends the semantics of UML2 Interactions to model interaction protocols. Hence, they are defined using UML2 Sequence Diagrams. Following we describe the main conceptual elements used to define interaction protocols. Partners and the Role they fulfill are represented through lifelines. The basic building blocks of an interaction protocol are the business messages. A business message defines a one-way asynchronous interaction between two roles, a sender and a receiver. It contains a business document (the exchanged information) and its semantics is defined by the associated speech act. In this way, a business message expresses that the sender has done an action that generates the communication of a speech act representing the sender’s intention with respect to the exchanged business document. Also, the message indicates the sender’s expectation is that the receiver acts according to the semantics of the speech act. A Protocol Reference represents a sub-protocol or nested protocol. When the subprotocol is called, the protocol waits until the sub-protocol ends. Protocols have an implicit termination. A Termination represents an explicit end event of a protocol. Termination events are: success, which implies the successful termination; and failure, which implies the protocol business logic ends in an unexpected way. A Time Constraint denotes a deadline associated with messages, control flow segments or protocols; i.e. the available time limit for the execution of such elements. A time constraint can be defined using relative or absolute date and time. A Control Flow Segment (CFS) represents complex message sequences. It contains a control flow operator and one or more interaction paths. An interaction path contains a ordered sequence of protocol elements: messages, termination events, protocol references and nested control flow segments. The semantics of a CFS depends on the operator used. Some control flow operators of exception handling were adapted and other advanced synchronization and multiple instance operators were introduced in order to provide a complete set of control flow constructors to model collaborative processes. The aim is to fulfill the main workflow patterns [14] for the modeling of collaborative processes. The control flow operators of the UP-ColBPIP language are:

• The And operator (Table 1.a) represents the parallel execution of paths. The thread of control is passed to the next protocol element when all paths are completed. • The Xor operator represents that only one path can be executed from a set of alternative paths. A data-based Xor contains conditions on the paths to be evaluated to select the execution path (see Table 1.b). An event-based Xor is based on the occurrence of the sending event of the first message of each path to select the execution path. Paths have no associated conditions. A timer can also be defined on a path to represent the execution of the path when a time event occurs. • The Or operator represents two or more alternative paths that can be executed. Path conditions must be evaluated to allow the execution of each path. Four types of path synchronization can be defined, which are denoted by the corresponding label at the top-left of the CFS (see Table 1.c). (1) Synchronizing Merge (<>): the thread of control is passed to the next protocol element when each enabled path is completed. (2) Discriminator (<>): the thread of control is passed to the next protocol element when the first interaction path is completed. (3) N out of M (<>) represents the convergence of two or more paths (say M) into a single subsequent path. The synchronization event must be enabled once N paths are completed. The remaining paths (M-N) are ignored. (4) Multimerge (<>): for each completed path there is a thread of control which is passed to the next protocol element. • The Loop operator represents a path that is executed several times while its condition is satisfied. An “Until” loop has the condition “(1, n)” so that the path is executed at least once; a “While” loop has the condition “(0, n)” and it means that the execution of the path is performed zero or more times (see Table 1.d). • The Exception defines the path to be followed after an exception takes place, which is identified at design time. A CFS with the Exception operator consists of one path that encloses the scope of the exceptions (for all protocol element involved in the path) and other exception handler paths, one for each exception to be caught and managed. An exception handler path has an exception condition to determine when the exception is raised. After an exception handler path is completed, the protocol continues with its normal execution. Two types of exception can be managed: time and logical. (see Table 1.e). • The Cancel operator defines the path to be followed after an exception takes place. The difference between Cancel and Exception operators is that the former finalizes the execution of the protocol when the path that handles the exception is completed. A control flow segment with a Cancel operator is used to finalize a protocol in a coherent and consistent way after an exception. • The Multiple Instances operator is used to represents multiple instances of an interaction path. Four types of synchronization of multiple instances can be defined, which are denoted by a label at the top-left of the CFS (see Table 1.f). The number of instances can be defined: (1) at design-time (<

>); (2) at run-time (<>), where the variable that contains the number of instances is indicated; (3) without a priori run-time knowledge (<>), where the expression condition that enables the creation of new instances is indicated. Multiple instances without synchronization are denoted by the <> label. • The If operator represents a path which is enabled when its condition is evaluated to True. Else, a path with the Else condition is executed if it is defined.

Table 1. Graphical notations of the control flow segments of an interaction protocol Enterprise X :Role A

Enterprise Y :Role B

SpeechAct(BusinessDocument) Xor [Var1=True] SpeechAct(BusinessDocument) [Var2=True]

a) Enterprise X :Role A

SpeechAct(BusinessDocument)

b)

c)

Enterprise Y :Role B

SpeechAct(BusinessDocument) Loop [(0,n), Var1=True] SpeechAct(BusinessDocument) SpeechAct(BusinessDocument)

f)

d) e)

As an example, Figure 2 shows a sequence diagram of the Collaborative Demand Forecast protocol, which describes a collaborative process to be carried out as part of a Collaborative Planning, Forecasting and Replenishment (CPFR) business model [15]. This protocol defines a simple negotiation process between a customer and a supplier to collaborate and agree on a demand forecast of products to be exchanged.

Figure 2. Collaborative Demand Forecast protocol.

The process begins with the customer who requests for a demand forecast. The request message conveys the data to be considered in the forecasting (e.g.: products,

forecast time-frame). The supplier handles the request and should respond by accepting or rejecting it. If it is accepted, the supplier undertakes to realize the required forecast, as it is indicated by the agree speech act; otherwise, the process finishes with a failure. If the supplier accepts the request, the customer informs in parallel a sales forecast of its points of sales (POS) and its planned sale policies. With this information, the supplier then generates a demand forecast, informs it to the customer and the process ends. The response messages that the supplier sends and the information messages the customer sends have defined time constraints with relative times that represent the deadline for the sending and reception of these messages. As an example, the deadlines of the agree and refuse messages indicate these messages have to be sent two days in advance, after the occurrence of the first message. In order to handle time exceptions on these messages, the control flow segment cancel is added. It contains an interaction path that spans the messages with time constraints, and it also contains two other exception paths that handle the time exceptions defined in the above messages. In both paths, the exception handling consists of the sending of a cancel message.

4 Eclipse-based Tool for Modeling Collaborative Processes In order to provide a development environment for the MDA-based methodology for collaborative business processes and support the modeling approach based on the UPColBPIP language, we have developed a tool that supports this language and the model transformations proposed in this methodology. Several requirements were considered in the development of the tool: implementation of visual editors to support the UP-ColBPIP language, implementation of the metamodel of this language to manipulate and validate the constraints of UP-ColBPIP models, extension mechanisms to allow the addition of new editors and model transformation machines, management of B2B collaboration projects, and separation of UP-ColBPIP model and diagram files to facilitate model-to-model and model-to-code transformations. The developed tool is based on the Eclipse open development platform [3]. There are several tools for modeling business processes that are based on this platform. Thus, we take advantage of a well-known development environment and we can also make a reuse and integration of other Eclipse-based tools with our tool. The Architecture of the Eclipse-based Tool for Modeling Collaborative Processes consists of the following components (Figure 3): • A set of Eclipse-based plug-ins, which are graphical editors that support the definition of UP-ColBPIP diagrams and models. They were built with the Graphical Modeling Framework (GMF) [5], which provides an infrastructure for developing visual editors based on the Eclipse Modeling Framework (EMF) [4] • A Transformation Machine for Petri Net specifications, which was built using the Eclipse Java Emitter Templates (JET) [9] to carry out model-to-code transformations. This machine takes a UP-ColBPIP model as input and produces a Petri Net specification for each interaction protocol defined in the input model. • A Transformation Machine for BPEL specifications that is built using the ATL [10]. It takes a UP-ColBPIP model as input, and by means of model

transformations [18] it produces BPEL specifications of partner roles for each protocol of the input model, as well as a WSDL specification for each partner.

Fig. 3. Architecture of the Eclipse-based Tool for Collaborative Processes

The Eclipse plug-ins for the UP-ColBPIP language were developed by means of GMF and support the UP-ColBPIP language. The UP-ColBPIP metamodel was implemented by means of EMF. In order to define a B2B Collaboration and its collaborative processes it is necessary to create a new UP-ColBPIP project. A UPColBPIP model is created when a new B2B Collaboration diagram is generated with the B2B Collaboration Editor plug-in. Then, collaborative processes and interaction protocol diagrams can be created by using the Collaborative Business Process Editor and the Interaction Protocol Editor. An interaction protocol diagram is created when a new collaborative process is defined. Each diagram is stored in a file separated from the file containing the UP-ColBPIP model. Thus the model is clearly separated from its graphical representation. Figure 4 shows the Eclipse-based tool with the example described in section 3.1. The organization of the UP-ColBPIP project is shown in the Project Explorer view. It consists of a folder for the UP-ColBPIP model and a folder for each view of the UPColBPIP model with their corresponding diagrams. The main edition area shows tabs that contain the editors. In particular, the Interaction Protocol editor with the interaction protocol Collaborative Demand Forecast is shown. In the right side of Figure 4 is the tool palette with the elements to model an interaction protocol. A protocol can be defined and modified through the drag and drop of the palette’s elements into the diagram. On the bottom side, the property view is used to set attributes of the model elements defined in the diagrams.

5

Related Work

Several modeling languages allow the representation of B2B business processes. However, it is necessary to highlight what kind of B2B processes they support. Modeling interaction protocols focus on representing the global control flow of interactions between partners, required to model collaborative processes. Instead, activity-oriented business process languages such as UML2 Activity Diagrams or the Business Process Modeling Notation (BPMN) [12] are more suitable to model interface or private processes from the viewpoint of a partner. Although BPMN allows the definition of B2B processes by representing the message exchange among

interface processes of the partners (BPMN pools), it does not provide the semantics to describe the dependencies of the global control flow of the message exchange.

Fig. 4. A B2B Collaboration project created with the Eclipse plug-ins for UP-ColBPIP

The UN/CEFACT modeling methodology (UMM) [8] is a UML modeling approach for global choreographies of B2B scenarios. It is a top-down approach that makes use of worksheets to capture domain requirements. UMM encourages the definition of the global choreography of a collaborative process in a hierarchy of views. A business collaboration view represents a collaborative process described by a choreography of business transactions, which are its basic construction blocks. The partner actions and exchanged business documents are described in each business transaction view, according to a business transaction pattern. This hierarchical approach makes it difficult to model and understand the interactions between partners in a high abstraction level along with the global choreography of a collaborative process. Thus, to identify these interactions into a business collaboration, the knowledge of each business transaction, which is modeled in a separate way of the choreography of the business collaboration, is required. This also results in a higher complexity to model negotiations in collaborative processes. In [11], a UML2 modeling approach that supports platform independent modeling of Web Service collaboration protocols was proposed. This approach uses a hierarchy of views similar to the approach proposed by UMM to model collaborative processes. Another modeling approach to describe global choreographies is Let’s Dance [23]. This is an independent-technology language, although it focuses on the modeling of Web Services choreographies that support service interaction patterns.

A survey of business process modeling methodologies based on UML has shown that the MDA-based methodology for collaborative processes, which uses the modeling approach based on the UP-ColBPIP language, is comprehensive enough to address most of the required aspects for collaborative processes [6]. In interaction protocols, business messages describing interactions between partners are the basic construction blocks. The global choreography of a protocol defines the message sequences. In addition, the use of speech acts associated with messages and the types of control flow segments allow the representation of complex negotiations.

6

Conclusions and Future Work

In this work we have presented a modeling approach for collaborative business processes based on the UP-ColBPIP language. This is oriented to be used in a MDAbased methodology for collaborative processes. This language enables the design of technology-independent collaborative process models, which are the main development artifacts in order to generate formal specifications and B2B specifications for the verification and implementation of collaborative processes. Through the use of interaction protocols to model collaborative processes, the language uses suitable abstractions to represent the features of B2B collaborations and fulfill the modeling requirements of collaborative processes. Interaction protocols allow describing the commonly agreed global choreography of interactions between partners. Modeling interaction protocols focus not only on information exchange, but also on the coordination and communicative aspects of B2B interactions. Business messages based on speech acts allow representing intentions that partners have when they exchange information in collaborative processes. By means of speech acts, parties can create, modify, cancel or fulfill commitments. This enables the definition of complex negotiations as well as provides a suitable semantics without ambiguity to achieve a common understanding of the meaning of each message. In this work we have provided a complete set of control flow operators to model the message choreography of interaction protocols, based on the workflow patterns, in order to model complex control flow structures in collaborative processes. Through the use of this UML Profile, business analysts and system developers can apply well-known notations for modeling collaborative processes and can also use existing UML2 case tools to model these processes. However, in order to provide a tool that can enforce the metamodel of the UP-ColBPIP language and enable the automatic generation of formal specifications and B2B specifications, we have introduced a case tool based on the Eclipse platform. This tool consists of visual editors implemented as Eclipse plug-ins that support the UP-ColBPIP language. Future work is aimed at providing a verification and validation methodology for collaborative processes. To enhance the support for verification, the new control flow constructors of interaction protocols will be formalized by using Colored Petri Nets and the model transformations that generate CPNs will be updated. The validation will be done through an ontology-based semantics analysis of the speech acts used in the messages of a protocol.

References 1. Caliusco, M.L., Galli, M.R., Chiotti O.: Technologies for Data Semantic Modeling. International Journal of Metadata Semantics and Ontology. Vol 1(4), 320-331 (2006) 2. CPN tools. http://www.daimi.au.dk/CPNtools/ 3. Eclipse Org. Eclipse Platform. www.eclipse.org 4. Eclipse Org. Eclipse Modeling Framework. http://www.eclipse.org/emf/ 5. Eclipse Org. Graphical Modeling Framework. http://www.eclipse.org/modeling/gmf/ 6. Folmer, E., Bastiaans, J.: Methods for Design of Semantic Message-Based B2B Interactions Standards. In: Enterprise Interoperability III, pp.183-194. Springer London (2008) 7. Girault, C., Valk, R.: Petri Nets for System Engineering: A Guide to Modeling, Verification, and Applications, Springer-Verlag New York, Inc (2001) 8. Huemer, C., Liegl, P., Motal, T., Schuster, R., Zapletal, M.: The Development Process of the UN/CEFACT Modeling Methodology. In: Int. Conf. on Electronic Commerce 2008 (2008) 9. Java Emitter Templates. http://www.eclipse.org/modeling/m2t/?project=jet 10.Jouault, F, and Kurtev, I: Transforming Models with ATL. In: Satellite Events at the MoDELS 2005. LNCS, vol. 3844, pp 128-138. Springer, Heidelberg (2006) 11.Kramler, K., Kapsammer, E, Kappel. G., Retschitzegger, W.: Towards Using UML 2 for Modelling Web Service Collaboration Protocols. In: First International Conference on Interoperability of Enterprise Software and Applications (2005). 12.OMG. BPMN V1.1 (January 2008), http://www.omg.org/spec/BPMN/1.1/PDF. 13.OMG. MDA Guide V1.0.1 (2003), http://www.omg.org/mda 14.van der Aalst, W.M.P, ter Hofstede, A.H.M., Kiepuszewski, B., Barros, A.P. Workflow Patterns. J. Distributed and Parallel Databases, 14(3), 5--51 (2003) 15.VICS. An Overview of Collaborative Planning, Forecasting and Replenishment (CPFR) http://www.vics.org/docs/committees/cpfr/ 16.Villarreal, P.: Method for the Modeling and Specification of Collaborative Business Processes. PhD Thesis. National Technological University, Santa Fe, Argentina (2005) 17.Villarreal, P., Salomone, E, Chiotti O.: A MDA-based Development Process for Collaborative Business Processes. In: European Workshop on Milestone, Models and Mappings for Model-Driven Architecture (3M4MDA), Bilbao, España (2006) 18.Villarreal, Salomone, Chiotti: MDA Approach for Collaborative Business Processes: Generating Technological Solutions based on Web Services Composition. In: 9th IberoAmerican Workshop of Requirements Engineering and Software Environments (2006) 19.Villarreal, P., Salomone, H.E. and Chiotti, O.: Transforming Collaborative Business Process Models into Web Services Choreography Specifications. In: Lee, J., Shim, J., Lee, S., Bussler, C., (eds.) DEECS 2006, LNCS, vol. 4055, pp. 50-65. Springer, Heidelberg (2006) 20.Villarreal, P., Salomone, H.E. and Chiotti, O.: Modeling and Specifications of Collaborative Business Processes using a MDA Approach and a UML Profile. In: Rittgen, P. (eds): Enterprise Modeling and Computing with UML. Idea Group Inc (2007) 21.Villarreal, P., Roa, J., Salomone, H.E. and Chiotti, O.: Verification of Models in a MDA Approach for Collaborative Business Processes. In: 10th Ibero-American Workshop of Requirements Engineering and Software Environments, Venezuela (2007) 22.Weske, M.: Business Process Management: Concepts, Languages, Architectures. Springer Press, Heidelberg (2007) 23.Zaha, J.M., Barros, A., Dumas, M., ter Hofstede, A.H.M.. Let's Dance: A Language for Service Behavior Modeling. In: 14th Int Con on Cooperative Information Systems, France (2006)