Defining ATL model to model transformation from mRIs to BPMN

In a previous post we propose an ATL model to model transformation catalog from MultiRole Interaction models ( defined by the UML profile of MaCMAS proposal ) to BPMN. By now, a template pattern for this catalog has been defined, as shown in the following picture.

In this template pattern we define: (i) the input MultiRole Interaction model; (ii) its equivalent in BPMN; and (iii) the ATL code that defines the m2m transformation. A first step for this m2m transformation has been proposed in this paper (in spanish) for modelling business transactions.

BPM'09 CfP - Universität Ulm, Germany

BPM'09 is the 7th Conference on Business Process Management and it is considered the most distinguished specialized forum for researchers in BPM.

Call for papers 

More info ...

Publications

During my research work some preliminary contributions were made. The main purpose of this entry is to provide a brief summary of those contributions.

International Conferences

- From Feature Models to Business Processes: I. Montero, J. Peña, A. Ruiz-Cortés. IEEE International Conference on Services Computing (SSC). 2605–608. Honolulu, HI. 2008
Quality Levels: Acceptance Rate: 18%, IEEE Core: A


- Representing Runtime Variability in Business-Driven Development Systems: I. Montero, J. Peña, A. Ruiz-Cortés. 7th IEEE Int. Conf. on Composition-Based Software Systems (ICCBSS). 228–231. Madrid, Spain. 2008.
Quality Levels: Acceptance Rate: 33%, IEEE Core: B


- Representing Runtime Variability in Business-Driven Development Systems - Poster: I. Montero, J. Peña, A. Ruiz-Cortés. 7th IEEE Int. Conf. on Composition-Based Software Systems (ICCBSS). 241. Madrid, Spain. 2008.
Quality Levels: Acceptance Rate: 33%, IEEE Core: B


International Workshops

- Towards Visualisation and Analysis of Runtime Variability in Execution Time of Business Information Systems based on Product Lines: I. Montero, J. Peña, A. Ruiz-Cortés. 2nd. International Workshop on Variability Modelling of Software-intensive Systems (VAMOS). 151–160. Universität Duisburg-Essen, Germany. 2008.


- Business Family Engineering. Managing The Evolution Of Business-Driven Systems: I. Montero, J. Peña, A. Ruiz-Cortés. IEEE Computer Society 1st International Workshop on Dynamic Software Product Lines (DSPL 2007, Volume 1), in conjunction with SPLC07, 33-40, Kyoto, Japan, 2007.


National Workshops

- Business Family Engineering. Does it make sense?: I. Montero, J. Peña, A. Ruiz-Cortés. Actas de los Talleres de las Jornadas de Ingeniería del Software y Bases de Datos (JISBD). 1er Taller de Procesos de Negocio e Ingeniería del Software (PNIS). II Congreso Español de Informática (CEDI 2007). Pag. 34-40, Zaragoza, España. 2007.

Dealing with Variability on Modeling Choreographies on Business Families

In Service-Oriented Computing (SOC), choreography models are acquiring a special importance. A choreography lists all possible interactions between a set of business partners, together with the behavioral constraints between them. Thus, choreography models represents the observable behaviour of business partners defined by means of interaction contracts. In addition, the introduction of Software Product Lines (SPL) techniques into the development of Business Information Systems (BIS) is expected to become a new development paradigm, of what we call Business Family, maximizing reuse and dealing with variability on business process definitions, including the notion of interacting processes. However, current proposals for modeling these interactions, by means of choreography models, does not provide any support for introducing these variability aspects. The contribution of this work is two-fold: in the one hand, we propose a choreography model based on an UML2 profile used on Agent-Oriented Software Engineering (AOSE) field that makes feasible the variability support; and in the other hand we provide a transformation between this choreography model and BPMN elements for improving the design of business families, by means of the Business Family Engineering (BFE) approach.

The AOSE profile used in this approach is the MaCMAS profile. We define the Order Trip choreography (WSCI specification example) by means of the mRI models provided by means of this AOSE approach, as shown in Figure:


Next, we apply the following model to model transformation catalog (under construction, a final proposal of this catalog will be published):


And finally we obtain the expected results:




Next step is to provide a new transformation rule for obtaining the choreography models proposed by the BPMN 1.2 draft specification:

Tooling Business Family Engineering

Nowadays, we have developed an automated tool support for obtaining the basic structure of a BPMN derived from the commonalities summary into the Business Family Domain Engineering phase. This basic structure is the Core Process Framework. This mapping is based on Automata Theory and Formal Languages, and it has been implemented by means of MDD transformations.

For that purpose, we have performed a transformation between the FeAture Model Analyzer (FAMA) metamodel as source and the Eclipse SOA Tool Platform2 BPMN metamodel as target metamodel using the Atlas Transformation Language (ATL).



Figure presents and screenshot of this tool. It has been published on Eclipse ATL website. ATL code and specification is available in http://www.eclipse.org/m2m/atl/atlTransformations/#FM2BPMN

The transformation was introduced at the following paper:

From Feature Models to Business Processes: I. Montero, J. Peña, A. Ruiz-Cortés. IEEE International Conference on Services Computing (SSC). 2605–608. Honolulu, HI. 2008.

Abstract: The variability level of average-size Business Information Systems (BIS) is highly enough for making the design of this kind of systems a complex task. There is an approach called Process Family Engineering (PFE) that tries to ease the design of BIS using ideas from the Software Product Lines (SPL) field. Roughly speaking, they propose to, first, study the variability of the system without entering into details by means of building a variability model (called feature model), that is used later for building the business process. However, in PFE the process of deriving the business process from the feature model is performed manually.
Authors use feature models with a different meaning that is commonly accepted in SPL. In this paper, we provide a rigorous description for the new meaning of feature models, and a mapping relationship that defines how to use the information in the FM for obtaining the basic structure of the business process. In addition, as a proof of concepts, we have implemented an MDD transformation that provides the expected results.

Quality Levels: Acceptance Rate: 18%, IEEE Core: A

http://portal.acm.org/citation.cfm?id=1444336
http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=4578594

Business Family Engineering Overview (3/3)

The Domain Design activity is focused on performing a variability summary of the set of businesses identified at the previous step and on providing the core architecture of the product line. Figure shows the Domain Design overview.

Business Family Engineering Overview (2/3)

The Domain Requirements Engineering activity is focused on identifying the set of companies and its business processes that would be members of the business family. This step takes into account the traditional requirements elicitation activities of software engineering, and provides as resulting artifact the documents that reflects this elicitation, where it is included the definition of each business process and each company. Thus, the activities of this stage are performed by a Requirement Engineer, role that could be played by an analist, a process engineer, etc.
Figure shows the Domain Requirements Engineering overview.

Business Family Engineering Overview (1/3)

The main motivation of my research is: (i) to propose a methodology based on applying SPL ideas for the systematization of the development of BIS across a several number of businesses that shares common business processes, namely Business Family Engineering (BFE); and (ii) to de¯ne the methodology fragment focused on providing a core architecture of the family, namely Business Family Domain Engineering. For that purpose, this figure shows the software process of
our approach using the SPEM notation (http://www.omg.org/technology/documents/formal/spem.htm)


As shown in Figure, in this software process there are two main activities: (i) Business Family Domain Engineering, where we build the BFE core architecture, namely Core Process Framework, and the Business Family Variaability Summary; and (ii) Business Family Application Engineering, where we obtain specific business information systems, that are described by means of execution languages, such as Business Process Execution Language (BPEL). It is important to say that our scenario is by now limited to binary relationships between features and processes, in other words, a feature can not represent a set of processes.
In addition, we have identified two diferent ways to build a business family: top-down and bottom-up. In the top-down approach, we define the set of businesses and processes from scratch and apply the normal sequence of BFE software process. In bottom-up approach, we can not apply the normal sequence of the software process defined due to we have a set of businesses or processes defined in feature models previously to apply BFE software process. In our research we only focus in top-down.

Next figure describes the Business Family Domain Engineering software process using SPEM. It is composed by three diferent activities: (i) Domain Requirements Engineering, that is focused on capturing the requirements of the problem domain, (ii) Domain Design, that is focused on exploring the variability of the system and providing the core architecture; and (iii) Domain Implementation, that is focused on defining the implementation and test details of the
architecture, such as persistence or presentation layers.