Montero Dea Camera Ready

A METHODOLOGY FRAGMENT FOR

DEVELOPING FAMILIES OF BUSINESS

INFORMATION SYSTEMS###

IMPROVING THE DESIGN OF BUSINESS FAMILIES FOR

SERVICE ORIENTED ARCHITECTURES

ILDEFONSO MONTERO PÉREZ

RESEARCH REPORT

MARCH 17, 2009

Ildefonso

Text Box

BibTex

http://yourtask.webcindario.com/yourtask/doc/montero-papers/montero-dea.bib

A Methodology Fragment for DevelopingFamilies of Business Information Systems

Improving the Design of Business Families for Service OrientedArchitectures.

Ildefonso Montero Pérez, 75760309-B

[email protected]

Supervised by Prof. Dr. Joaquin Peñaand Prof. Dr. Antonio Ruiz-Cortés

Thesis project submitted to the Department of Computer Languagesand Systems of the University of Sevilla in partial fulfilment

of the requirements for the degree of Ph.D. in Computer Engineering.

(Research report)

Support: This work has been partially supported by the EuropeanCommission (FEDER) and Spanish Government under CICYT project Web-Factories (TIN2006-00472) and by the Andalusian Government under projectISABEL (TIC-2533).

This research report has been developed regarding the instructions laidin Chapter I, Article 5, Paragraph 2, of the Doctorate Regulations from theUniversity of Seville. This work implies an estimated effort about 360 hours(12 credits) and it was developed using the structure proposed in the citedregulations.

4

Contents

I Preface

1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Motivating our research with a WSCI example . . . . . . . . . . . . . . . . 5

1.3 Research Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3.1 Business Process Management . . . . . . . . . . . . . . . . . . . . . . . . 7

1.3.2 Software Product Lines and Feature Models . . . . . . . . . . . . 13

1.3.3 Process Family Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.4 Hypothesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.5 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.6 Goals and Structure of this research report . . . . . . . . . . . . . . . . . . . 20

II State of Art

2 Software Product Lines & Business Process Management 252.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

2.2 Process Family Engineering (PFE) . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.2.1 Research Context: the PESOA project . . . . . . . . . . . . . . . . . . 27

2.2.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2.3 Main differences between the SPL and PFE fields . . . . . . . 29

2.2.4 Conceptual Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

2.2.5 The PESOA Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33

2.2.6 Drawbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3 Variability in Business Information System Design . . . . 373.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

ii Contents

3.2 Variability Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39

3.2.1 BPMN Extensions for Dealing with Variability . . . . . . . . . . 39

3.2.2 Basic Variability Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 40

3.2.3 Variability Mechanisms Derived . . . . . . . . . . . . . . . . . . . . . . 41

3.3 Summary of Variability Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

3.4 Variability Binding Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43

III Our Approach

4 Business Family Engineering . . . . . . . . . . . . . . . . . . . . . . . . 474.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2 Business Families and BFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2.1 Rigorous Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

4.2.2 Integration with Process Family Engineering . . . . . . . . . . . 49

4.2.3 Graphical Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49

4.3 Software Process of BFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

5 Business Families Domain Design . . . . . . . . . . . . . . . . . . . 535.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.2 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54

5.2.1 Redefining Feature Models . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.2.2 Feature Model Grammars . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

5.2.3 Mapping a Feature Model to a BPMN Structure . . . . . . . . 60

5.3 Business Family Domain Engineering . . . . . . . . . . . . . . . . . . . . . . . 62

5.3.1 Domain Requirements Engineering . . . . . . . . . . . . . . . . . . . 64

5.3.2 Domain Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66

6 Business Families Choreographies Design . . . . . . . . . . . . 736.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.2 Choreography Modeling in BFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74

6.3 Transformation Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78

IV Contributions

7 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 857.1 Relevant Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

Contents iii

7.1.1 International Conferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

7.1.2 International Workshops . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88

7.1.3 National Workshops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89

7.2 Other Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

7.2.1 Eclipse M2M Transformation Project Contribution . . . . . . 90

7.3 Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

7.4 Future Work . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 978.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98

V Appendix

A Relevant Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101

B Curriculum vitae . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103

C Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

iv Contents

List of Figures

1.1 Case study scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.2 Business Process Model Notation subset . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3 Phases during Choreography Design and Implementation from [61] 12

1.4 Feature Model of our case study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

1.5 Variability aspects defined by the PFE approach . . . . . . . . . . . . . . . . . . 15

1.6 Proposed Holistic Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

1.7 Recommended reading process of this report . . . . . . . . . . . . . . . . . . . . 21

2.1 Process Family Engineering Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 28

2.2 SPL and PFE approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

2.3 Conceptual Model of the PFE approach . . . . . . . . . . . . . . . . . . . . . . . . . 32

2.4 Domain Fragment of the PESOA Process . . . . . . . . . . . . . . . . . . . . . . . . 34

3.1 Reserve Tickets process model using the BPMN extension [51] . . . . . 41

4.1 PEM approach defining a business evolution by F∆ function in t and t+1

50

4.2 Software process of BFE in SPEM notation . . . . . . . . . . . . . . . . . . . . . . . 51

5.1 A feature model, its grammar and its propositional formula representa-tion by Batory [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

5.2 PFE Feature Model and its CFG representation . . . . . . . . . . . . . . . . . . . 57

5.3 PFE Feature Model Grammar Representation Composition . . . . . . . . 58

5.4 Mapping Grammars to Finite State Machines . . . . . . . . . . . . . . . . . . . . 59

5.5 Finite State Machines and its CFG definition . . . . . . . . . . . . . . . . . . . . . 60

5.6 BPMN Gateways and its Finite State Machine equivalence . . . . . . . . . 60

5.7 Feature Model to BPMN Mapping Catalog Proposed . . . . . . . . . . . . . . 61

5.8 Business Family Domain Engineering Overview . . . . . . . . . . . . . . . . . 63

5.9 Domain Requirements Engineering Overview and models obtained 65

vi List of Figures

5.10 Domain Design overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

5.11 Commonalities summary of the case study obtained in Variability Anal-ysis represented using feature modeling . . . . . . . . . . . . . . . . . . . . . . . . . 68

5.12 Variability aspects described by the PFE approach, represented at thederivation stage of Building Core Process Framework . . . . . . . . . . . . . 69

5.13 Overview of Core Process Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 70

5.14 Basic Structure of the Core Process Framework obtained from the deriva-tion process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71

6.1 Order Trip subprocess Choreography Model using BPMN 2.0 . . . . . . 75

6.2 Order Trip Choreography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76

6.3 Data Object Exchange in our Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79

6.4 Data Object Exchange between Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . 80

6.5 Messages Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81

6.6 Collaboration and Behavioral Interface obtained from the Transforma-tion Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82

6.7 ATL definition of mapping between MaCMAS and BPMN . . . . . . . . . 82

7.1 Tool Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90

7.2 Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92

7.3 Total of contributions by defined layers in our holistic framework . . 93

List of Tables

2.1 Mapping between the SPL and PFE fields . . . . . . . . . . . . . . . . . . . . . . . 29

7.1 Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

viii List of Tables

Acknowledgements

Now that this research report comes to an end, it is time to express mygratitude to the people who have supported me along this path that I has juststarted. First of all, I would like to thank to my family and friends for theirsupport when it was so necessary. Thus, I would like to thank to Lucia, for herendless patience and love.

In addition, I would like to thank my research advisors, Joaquin and Anto-nio, for their help and support into my research career.

Finally, I would like also to thank to all my industry and academic col-leagues, whose comments and suggestions improved the contents and pre-sentation of this research report substantially.

x Acknowledgements

Abstract

Service Oriented Architectures (SOA) is a change in the approach for de-veloping solutions and moving from create programs that perform a func-tion for the end user, to think, design and develop interoperable services thatmodel our business and allow us to build applications by composing func-tional parts. In this context, a new paradigm named Business-Driven Devel-opment (BDD) has been arised, in order to provide techniques and methodsto support the analysis, design and implementation of the business processesof a company, as interoperable behavioural interfaces which can be deployedas independent services into an Enterprise Service Bus (ESB) infrastructure.

Current specifications for designing business processes by means of mod-elling techniques and notations, such as Business Process Modeling Notation(BPMN), provides support for the activities defined into the BDD paradigm.However, the variability level of average-size Business Information Systems(BIS) is usually highly enough for making the design of this kind of systemsa complex task. In addition, is a fact that there exists several companies thatshares common business processes, and maximize the level of reuse of theirdefinitions is considered a core need.

Thus, our research hypothesis states that the reuse across businesses bymeans of Software Product Line (SPL) techniques can be exploited. It meansthat is feasible the definition of Business Families. For that purpose, our re-search is focused on providing reference models and technologies that arenecessary to help companies bridge the gap of dealing with variability on thedesign of BIS and to increase the reusability of their business process defini-tions.

In this report, we give an overview of the current state of art of our researchcontext. Results from this analysis motivate our research work, which hasbeen already materialized in several contributions and has been presented inthe research report too.

xii Abstract

Resumen

Las Arquitecturas Orientadas a Servicios (SOA) suponen un cambio en elenfoque para el desarrollo de soluciones y dar el paso de crear programasque realizan una función concreta para el usuario final, a pensar, diseñar ydesarrollar servicios interoperables que modelan nuestro negocio y nos per-miten construir aplicaciones componiendo piezas funcionales. En este contex-to, un nuevo paradigma llamado Desarrollo Guiado por el Negocio (BDD), haaparecido recientemente con el fin de proporcionar técnicas y métodos paradar soporte al análisis, diseño e implementación de los procesos empresar-iales de una empresa, proporcionando interfaces interoperables de compor-tamiento que pueden ser desplegadas como servicios independientes en unainfraestructura basada en un Bus Empresarial de Servicios (ESB).

Las especificaciones actuales para el diseño de procesos de negocio pormedio de técnicas de modelización y anotaciones, como Business ProcessModeling Notation (BPMN), prestan apoyo a las actividades definidas en elparadigma BDD. Sin embargo, la variabilidad implicita en Sistemas de Infor-macion de Negocio (BIS) de granularidad gruesa es por lo general mas quesuficiente para que el diseño de este tipo de sistemas se considere una tareacompleja. Además, es un hecho que pueden existir varias empresas que com-partan procesos de negocio similares, y maximizar el nivel de reutilización desus definiciones se considera una necesidad básica.

Por lo tanto, nuestra hipótesis de investigación sostiene que la reuti-lización, a través de tecnicas del campo de las Lineas de Productos Software(SPL), puede ser explotada. Esto significa que es posible la definición de Famil-ias de Negocio. A tal efecto, nuestra investigación se centra en proporcionarmodelos de referencia y tecnologías necesarias para ayudar a las empresas asuperar la brecha de hacer frente a la variabilidad en el diseño de Sistemas deInformacion de Negocio y para aumentar la reutilización las definiciones delos procesos. En este informe, proporcionamos una visión general del actualestado del arte de nuestro contexto de la investigación. Los resultados de esteanálisis motivan nuestros trabajos de investigación, que ya se ha materializa-do en varias contribuciones y son presentados tambien en este informe.

xiv Resumen

Part I

Preface

Chapter 1

Introduction

O n the one hand, the development of Business Information Systems(BIS) is focused on providing techniques and mechanisms for de-

signing software systems based on the business processes of the companies,defined graphically by means of modeling notations, such as Business ProcessModel Notation (BPMN) [10].

On the other hand, the Software Product Lines (SPL) field systematizes thereuse across the set of similar products that a software company produces. Itimplies a reduction of development times and costs and a quality improve-ment.

In order to increase the process definitions reusability, we propose amethodology based on applying SPL ideas for the systematization of the de-velopment of BIS across a several number of businesses that shares commonbusiness processes. Thus, the contribution of this work is to define and explorethe feasibility and benefits of what we call Business Family Engineering.

In this chapter, we introduce first the motivation of our research work inSections §1.1 and §1.2; the research context in Section §1.3; we enunciate ourresearch methodology in Section §1.5 and our hypothesis and several researchquestions in Section §1.4; and finally, we describe the goals and structure ofthis research report in Section §1.6.

4 Chapter 1. Introduction

1.1 Motivation

The variability level of average-size Business Information Systems (BIS) isusually highly enough for making the design of this kind of systems a complextask. In addition, is a fact that there exists several companies that shares com-mon business processes, and maximize the level of reuse of their definitions isconsidered a core need.

For that purpose, there is an approach, called Process Family Engineer-ing (PFE) [6] (See Section §1.3.3 for more details), that tries to increase thereusability on the development of BIS using ideas from the Software ProductLines (SPL) field [46]. Roughly speaking, the SPL field systematizes the reuseacross the set of similar products that a software company provides. For thatpurpose, this approach requires to describe the products by means of vari-ability models, such as Feature Models (FM), that contains only features andrelationships between them. A feature is considered as a characteristic of thesystem that is observable by the end users. Feature Models describe whichfeatures are present in all the products, called core features, and which not,called variable features. (See Section §1.3.2 for a more detailed description).

In addition, the PFE approach identifies some variability aspects on busi-ness process models, and proposes to extending the standard BPMN for rep-resenting it [32]. However, although the PFE approach is quite valuable, itpresents some drawbacks related with ambiguity and maintenance that aredescribed at Section §1.3.3.

Thus, the main motivation of this research is to provide a methodologythat taking into account the PFE drawbacks makes feasible the possibility ofdevelop families of business information systems. For that purpose, as shownin Chapter §4, we provide a methodology named Business Family Engineer-ing, we define the fragment of this methodology focused on obtaining thecore architecture of the family, namely Business Family Domain Engineeringin Chapter §5, and we explore its feasibility on modeling choreographies inChapter §6. These topics are the focus of our research. In addition, we moti-vate our approach by means of a real-life case study defined in the Web Ser-vice Choreography Interface (WSCI) specification [60]. Finally, as proof ofconcepts, we have developed an Eclipse tool that provides support for one ofthe activities of this methodology fragment. See Chapter §7 for more detailsabout tool support.

As a result of our contributions, we improve the development of businessinformation systems reducing its complexity level in situations where is nec-essary to perform a business family, using our proposed methodology. In ad-

1.2. Motivating our research with a WSCI example 5

dition, since to one of the topics of our approach is focused on providing thecore architecture of the family, we provide to process engineers some artifactsfor improving their activities, such as a business family variability summaryand a core process framework (See Chapter §5 for a more detailed descrip-tion). This artifacts provides a basic structure of the business process modelthat supports the variability aspects identified by the PFE approach, withoutthe need of extending the standard notation of BPMN.

1.2 Motivating our research with a WSCI example

The Web Service Choreography Interface (WSCI) specification [60] pro-vides a comprehensive example that illustrates how to model a scenario thatreflects the real life business process of reserving and booking airline tickets.A derivation of this example, for defining an hotel booking process has beenused for illustrating the Process Family Engineering (PFE) approach in [54].See Section §1.3.3 for more details about the PFE approach. We use the WSCIcase study as starting point for defining how to develop families of businessinformation systems that provides support for any booking process.

The scenario provided by the WSCI specification is the following: there ex-ists three different participants involved into the reserving and booking airlinetickets business process, concretely a Traveler, a Travel Agent, and an AirlineReservation System. Each participant collaborate in the overall process calledPlan&Book, as shown in Figure §1.1. This business process is composed bythe following subprocesses: (i) Order Trip : it defines the steps needed forperforming the submission of the preferred trip plan from the Traveler to theTravel Agent, who evaluates the preferences, and send a possible itinerary tothe Traveler. It is performed by means of a collaboration between the TravelAgent and the Airline Reservation System by means of a business processnamed Verify Seats Availability. This business process is a subprocess of Or-der Trip ; (ii) Cancel Itinerary : it defines the steps needed for canceling theprovided itinerary from the Travel Agent; (iii) Change Itinerary : it definesthe steps needed for performing a submission from the Traveler to the TravelAgent to change the proposed itinerary; and (iv) Reserve Tickets : it definesthe steps needed for reserving the trip related with the proposed itinerary.This business process is decomposed by four subprocesses: Book Tickets, BookSeats (that needs a previous reservation step for the seats performed by otherbusiness process named Reserve Seats), Send Tickets and finally, Send State-ment. This case study provides a complete real life example of reserving andbooking a trip for any possible airline travel agency. We are going to sup-pose that several airline travel agencies, such as Iberia, Ryanair, etc. performs


Traveler Travel Agent

Airline Reservation

System

Plan andBook Trip

WSCIInterface

WSCIInterface

WSCIInterface

I want to travel to Ulm

Figure 1.1: Case study scenario.

this business process. In other words, these travel agencies share the commonbusiness process of Plan&Book. In addition, is feasible that these companiesshare other set of business processes, and also, performs a set of specific pro-cesses from each company.

Taking into account the previous consideration, we are going to extend theWSCI case study providing specific business processes from any possible air-line travel agency. Thus, we introduce the following business processes: (i)Inform : it defines the steps needed to provide to the Traveler and to the TravelAgent the information about flights (delays, connections, etc.) obtained froman Airline Traffic Control System (we have introduced a new participant inaddition); and (ii) Extras : it defines the steps needed to provide to the Trav-eler the information related with some extra services from an airline agency.In this case study, we have decomposed this business process into two sub-processes named: Restaurant and Travel Card, that define the restaurant onfly subprocess and the management of travel cards respectively.

Once the scenario is defined, we have analyzed the feasibility of developa family of airline travel agencies using our approach: Business Family Engi-neering (BFE). Our research motivation address into the following issues, thatare covered in this report:

1.3. Research Context 7

• Increasing the business process definitions reusability for each businessinformation system that provides support for any airline travel agency.Current process engineers redesign each business information systemusing ad hoc techniques to maximize the level of reuse from one productto another. Our approach states that many common business processescan be found, and reuse across businesses by means of Software Prod-uct Line (SPL) techniques can be exploited. See Section §1.3.2 for moreinformation about the SPL field.

• Improving the design of highly variable business process models, alsonamed variant-rich processes, obtaining the basic structure of the busi-ness process (that needs to be completed manually). Nowadays, the de-sign of highly variable business process models is performed extendingthe notation of the business process diagram, for example Business Pro-cess Model Notation (BPMN). It is defined by the PFE approach, that isdetailed in Section §1.3.3

• Visualizing the variability of the business information system. Our ap-proach states that providing a variability summary is feasible and itwould helps to process engineers to identify the core and variable as-sets of the family.

1.3 Research Context

In order to clarify the context of this research, in this section we provide aset of definitions and considerations about (i) Business Process Management(BPM), concretely about designing Business Information Systems (BIS), mod-eling specifications, and choreography models; (ii) the Software Product Line(SPL) field; and (iii) the Process Family Engineering (PFE) approach.

1.3.1 Business Process Management

Weske define in [61] that Business Process Management (BPM) is based onthe observation that each product that a company provides to the market isthe outcome of a number of activities performed. Thus, a first step for defin-ing a Business Process (BP) could be that a BP is considered as a set of theseactivities. In addition, Brown establish, in [12], as a core need that a companymust be able to manage what is called the 3-K :


• Know what you got, roughly speaking, the services that the companyprovides to the market, also named business goals;

• Know who is doing what, in other words, the set of business partnersthat performs several business processes in the company;

• and Know when things change and what it means, which means that thebusiness processes of the company must deal with the implicit variabil-ity of the market, since to companies must adapt to continuous marketchanges.

Taking into account these considerations, a Business Process (BP) is de-fined as a set of well known activities of a company, performed by a set ofbusiness partners (may own the company or not), for realizing a business goal.In addition, the definition of specificic business processes must be able to beadapted when company changes. Business Process Management provides thetechniques and methods to support the analysis, design and implementationof business processes.

Is a fact that most companies, in whichever field, have a software systemthat helps managing all the aspects of the company. Consequently, the Infor-mation Technology (IT) infrastructure that supports it must provide supportfor the techniques and methods defined in BPM. Thus, a new kind of soft-ware system is defined: Business Information Systems (BIS). A BIS is a soft-ware system which is based on a business process design, usually a modelspecification, that is deployed into a process engine that executes it. Thus,the Business-Driven Development (BDD) field is focused on providing tech-niques and mechanisms for defining the development of Business InformationSystems.

Our research work is focused on improving the design of Business Infor-mation Systems when reuse across several businesses can be exploited. Thus,our main research context is the Business-Driven Development (BDD) field.

Once the main research context is defined, we explore the set of modelsneeded for designing a BIS: (i) a business process diagram, which definesa business process by means of several notations, such as Business ProcessModel Notation (BPMN), that is defined in the following subsection; and (ii)a choreography and collaboration models, defined in Section §1.3.1.2.


1.3.1.1 Business Process Modeling and BPMN

Business Process Models are expressed in Business Process Diagrams.Each business process diagram consists of a set of modeling elements. Theseelements allow expressing business processes and are easy to comprehend, sothat process designers can use them without extensive training. Several nota-tions are introduced for defining business process diagrams, such as BusinessProcess Modeling Notation (BPMN) [10], Petri-net based process modelinglanguages [28], UML activity diagrams [1] or event-driven process chains [58].

While these modeling languages focus on different levels of abstraction,ranging from a business level to a more technical level, BPMN aims at sup-porting the complete range of abstraction levels, including business levels andsoftware technology levels. Thus, our research is focused on this notation, butit also can be translated to other one.

Business Process Model Notation (BPMN) is defined by the Object Man-agement Group (OMG) in [10] as a flow chart based notation for definingbusiness processes. BPMN provides (i) a graphical notation based on BusinessProcess Diagram (BPD); and (ii) a formal mapping to an execution language:Business Process Execution Language (BPEL). Figure §1.2 depicts the subsetof the most commonly used BPMN elements. These elements can be groupedby the following categories:

• Swimlanes: a set of symbols that allows us to organize the model. Thisset contains the elements named Pool and Lane, as shown in Figure§1.2.a. A pool represents a participant in a process and acts as a con-tainer of elements. A lane represents a sub-partition of a pool and areused to organize and categorize activities.

• Flow objects: a set of symbols that represents the core elements of a busi-ness process model. Usually this elements are contained in a swimlane.This set contains the elements named Task, Event and Gateway. Figure§1.2.b show these elements. A task, also called activity or sub-process, isthe basic element of a work in an organization, it can be atomic or non-atomic. Event is something that happens in our process that fires theexecution of one or more activities. There exists a lot of events groupedby: start, intermediate or end event, as for example message events, asshown in figure. A gateway is used to control the divergence or con-vergence of flows as logic doors. In our research we focus on three dif-ferent gateways: (i) And : which defines that all the subprocesses con-trolled by this gateway must be completed for performing a task, (ii)Xor : which defines that only one subprocess controlled by this gateway


AA1 A2

Pool

Lane

(A) Swimlanes

A

A

A

Sub-Process

Expanded Sub-Process

Collapsed Sub-ProcessGroup

Start Intermediate End

StartMessage

IntermediateMessage

EndMessage

Tasks

Events

Gateway Gateway XOR

Gateway AND

Gateway OR

Gateways

(B) Flow Objects

(C) Connection Objects

(D) Artifacts

Artifact / Data Object

TextComment /Annotation

Sequence Flow

Message Flow

Association Flow

Figure 1.2: Business Process Model Notation subset.

must be completed for performing a task, and (iii) Or : which defines thatalmost one subprocess controlled by this gateway must be completed forperforming a task. The specification of BPMN does not provide any con-straint about the order of performing this subprocesses in this situations,it can be done as a sequence or parallel.

• Connection objects: a set of symbols that represents the connections be-tween the rest of objects in the model. It often represents the messagesbetween two objects from different swimlanes. Figure §1.2.c depicts thisset, which contains the elements named flows such as, sequences, asso-ciations and messages.

• Artifacts: a set of additional elements that represents information aboutthe model or output artifacts of a process represented in it. This elementsare very useful to represent additional information to the reader of theBPMN, as group, comments or artifacts, also named, data objects gen-erated or consumed by a business process. Figure §1.2.d. show theseelements.

Although BPMN is a graph-based model, it can be defined by mathemat-ical and theoretical foundations and formalisms, such as CSP [62], Petri-nets


[21] or Pi -Calculus [48]. Concretely, in our research we explore the capabilityof BPMN for implementing finite state machine representations.

However, although BPMN is a good choice for modeling business pro-cesses, there exists a several number of proposals which provides very inter-esting additional elements or extensions to the standard notation [6, 49]. Ourresearch explore the feasibility of the current BPMN specification for provid-ing support for variability aspects into the design of business families and thedrawbacks of extending the standard notation.

1.3.1.2 Choreography Models

In the Business Driven-Development (BDD) field, and specially in Service-Oriented Computing (SOC), choreography models are acquiring a special im-portance. A choreography lists all possible interactions between a set of busi-ness partners, together with the behavioral constraints between them [18].Choreography models represents the observable behavior of business part-ners defined by means of interaction contracts. Several industry initiatives arein place for establishing standarized choreographies in particular domains,such as Health Level Seven (HL7) for heath care services †1.

Process choreographies describe the interaction of multiple business pro-cesses and, as such, are an important concept for supporting business-to-business collaboration. Thus, modeling choreographies is considered a coreneed for designing Business Information Systems. The activities needed fordevelop a choreography model are described as follows:

• High-level Structure Design: in this activity the participant roles as wellas their communication structures are identified.

• High-level Behavioral Design: this activity is focused on specifying thegoals, also named milestones, of the collaboration and the order in whichthe goals are reached.

• Collaboration Scenarios: in this activity the high-level choreographiesare refined by introducing dedicated collaboration scenarios that relatethe reaching of goals to the communication between process partici-pants.

• Behavioral Interfaces: from these collaboration scenarios, for each par-ticipant role, a behavioral interface is derived in this activity.

†1http://www.hl7.org/


Domain scoping

Participant identification

Milestone definition

Scenario modelling

Message identification

Choreography definition

Behavioural interface 1

Behavioural interface n

Process orchestration 1

Process orchestration n

Des

ign

Impl

emen

tatio

n

BusinessEngineer

Deve-loper

SystemArchitect

M.

We

ske

: Bus

ine

ss P

roce

ss M

anag

em

ent,

© S

prin

ger-

Ve

rlag

Ber

lin H

eid

elb

erg

2007

Figure 1.3: Phases during Choreography Design and Implementation from[61].

Once the choreography is designed, the behavioral interface of each busi-ness partner can be defined as a process orchestration for implementing thechoreography, using the Web Service Choreography Interface (WSCI) specifi-cation [60] . Figure §1.3 describes the big-picture of the choreography designand implementation phases defined in [61]. Since to our research is focused inthe design of Business Information Systems, in this context, we focus on thechoreography design phase.

However, although choreography modeling is considered a core need inour research context, there not exists an standard notation for that purpose.Latest drafts for BPMN 2.0. specification †2, explores new notations for rep-resenting it, since to some drawbacks has been identified on modeling chore-ographies using the current BPMN specification [20]. In addition, there existsseveral proposals of specific choreography modeling languages such as Let’sDance [64] or BPEL4Chor [19].

†2http://www.omg.org/cgi-bin/doc?bmi/08-09-04


In addition, current proposals for modeling choreographies does not pro-vide any support for introducing variability aspects into the design of busi-ness families. Thus, other contribution of this research work is two-fold. Inthe one hand, we propose a choreography model based on an UML2 pro-file used on Agent-Oriented Software Engineering (AOSE) field that makesfeasible the variability support; and in the other hand we provide a transfor-mation between this choreography model and BPMN elements for improvingthe design of what we call business families, by means of the Business FamilyEngineering approach without extending the current notation of BPMN.

1.3.2 Software Product Lines and Feature Models

Pohl et al. define in [27, 46] that Software Product Line (SPL) develop-ment aims at and achieves pro-active, constructive reuse, based on the ideato develop software products which share a significant amount of character-istics, namely features. Thus, a feature is a characteristic of the system thatis observable by the end user. Roughly speaking, SPL systematizes the reuseacross the set of similar products, defined by means of their features, that asoftware company provides.

The SPL approach is devoted to overcome complexity providing all thetechniques needed for enabling the mass production of software in a certainapplication domain. The variability concept appears in SPL to represent thedifferences and commonalities inside an application domain. Variability isone of the critical aspects of SPL and it must be managed at all the stages ofSPL development. Thus, the software process of SPL is divided into two mainstages: Domain Engineering, which is in charge of providing the reusable coreassets that are exploited during the derivation of products, done at a secondstage named Application Engineering [46].

One of the most accepted techniques to represent the set of products ofan SPL are Feature Models (FM) [16]. The main goal of feature modeling isto identify commonalities and differences among all products of an SPL. Afeature model is a compact representation of all potential products of an SPLshowing a set of features in an hierarchical structure where it is shown whichfeatures are present in a product of the product line. Figure §1.4 shows thefeature model of our case study. A FM establishes a parental relationship be-tween each feature, as shown in Figure §1.4, that can be:

• Mandatory: if a child feature node is defined as mandatory, it must beincluded in every product that contains the parent;


A

B

A

B

Mandatoryrelation

Optionalrelation

A

B2B1 B3

Alternativerelation

A

B2B1 B3

Orrelation

Verify Seats Availability

Change Itinerary

Cancel Itinerary

Reserve Tickets

Reserve Seats

Book Tickets

Order Trip

Airline Travel Agency

Book Seats

Send Tickets

Send Statement

ExtrasInform

RestaurantTravel Card

Figure 1.4: Feature Model of our case study.

• Optional: if a child feature node is defined as optional, it can be includedor not when its father feature appears in a product;

• Alternative: if the relationship between a set of children nodes and theirfather is defined as alternative, only one of the children features couldbe included in every product that contains the parent;

• Or: if the relationship between a set of children nodes and their father isdefined as or, one or more of them could be included in every productthat contains the parent.

Our approach for developing families of business information systems isbased on introducing some SPL techniques. For that purpose, the featuremodel is used in our approach for describing the set of business informa-tion systems that are members of the business family, and for representing thevariability of each business information system. In addition, the introductionof SPL techniques implies a reduction of development times and costs and aquality improvement of the final products.

1.3.3 Process Family Engineering

The Process Family Engineering (PFE) [6] approach explores the idea ofapplying SPL philosophy for managing the variability of business informationsystems. In PFE, feature models are used for representing the set of processescontained into a business. In addition, a business process diagram notation,


Inform<< Abstract >>

Inform by E-Mail

<< VarPoint >><< Default >> Inform by

Intranet

<<VarPoint>>

<<Implementation>><<Implementation >>

(A) Alternative Behavior (B) Parameterization (C) Inheritance (D) Extension Point

Number of Seats > 50


<<Parameterization >>

Send Tickets

Send Tickets and Information

about Trip

<<VarPoint>>

<<Inheritance >>

Book Tickets

Quality Assurance

<<Null>>

<<Extension>>

Figure 1.5: Variability aspects defined by the PFE approach.

such as BPMN, is used for representing an specific process. However, the syn-tax of this notation is redefined for providing support for representing highlyvariable business process models, namely variant-rich business process mod-els [32].

The PFE approach defines a variant-rich business process model as a pro-cess model that represents how to deal with some identified variability as-pects:

• Alternative behaviors: it defines when there exists several differentways for performing an activity into a business process definition. Fig-ure §1.5.a shows an example about a refinement of the Inform businessprocess from the WSCI case study, represented using BPMN. When theAirline Traffic Control System submit some information to the TravelAgencies it could be done by e-mail, publishing the information as anew into the Intranet, etc. As shown, the PFE approach introduces somestereotypes: (i) �Abstract�, for defining the activity that has an al-ternative behavior; (ii) �VarPoint�, for identifying the activities thatimplements each possible behavior, this stereotype sometimes is repre-sented as a puzzle piece into the activity; and (iii) �Implementation�,for describing a new kind of flow not defined in the standard BPMNnotation, that represents that an activity marked as �VarPoint� imple-ments the behavior of other activity marked as �Abstract�. In addi-tion, the default implementation can be provided introducing the stereo-type �Default�.

• Parameterization: it defines that each BPMN attribute can be parameter-ized to support a range of values. Figure §1.5.b shows how to representpossible ranges of the value Number of Seats, into the subprocess Ver-ify Seats Availability from the case study of this paper. This attribute is


marked using a grouping box and associated to other possible values bymeans of a new association flow defined with a new stereotype named�Parameterization�.

• Inheritance: it defines a modification of an existing subprocess byadding or removing elements regarding to specific rules. This allowsfor realizing alternative variation points. As shown in Figure §1.5.c, thebusiness process Send Tickets has been modified to Send Tickets and In-formation about Trip since to the Travel Agency has a contract with sometourism companies for providing information about them when it sendstickets to the Traveler. This situation is marked with a new associationdefined using the stereotype �Inheritance�.

• Extension Points: it defines an optional behavior. Figure §1.5.d depictshow an optional behavior from Book Tickets subprocess could be in-cluded for quality assurance of this activity. This situation is markedusing the stereotype �Extension�.

The main difference between SPL and PFE is that the SPL field provides aset of different products that shares common features, and the PFE approachprovides only one product, which represents a business, that evolves at run-time, and each possible configuration of this business is managed as a productthat contains a subset of processes enabled at a certain moment of the execu-tion. On the one hand, the SPL products are implemented by software arti-facts. For each of them there exists a feature selection phase that generatesthe final products (a set of core and variable features). On the other hand, thePFE products are implemented by processes. For each product, the system canevolve to another product increasing or decreasing the variable set of featuresthus, each product is a software system based on processes.

However, although the PFE approach proposes a methodology for design-ing highly variable business processes, based on overcoming the complexityderived from variability, by means of applying software product lines for man-aging it; this approach presents some drawbacks. For example, the use of fea-ture models and the derivation of business processes from it presents someproblems, such as ambiguity, that has been explored for us in [37]. Anotherconsideration is the need of redefining the BPMN syntax introducing some in-formation about variability which is also present in the feature models, thus,information is duplicated with the obvious problems for maintenance. In ad-dition, there not exists support for this new syntax of BPMN, because it is notan standard notation.

Our approach overcomes the variability of the business information sys-tems using SPL techniques, taking into account the PFE approach ideas and

1.4. Hypothesis 17

without providing extra information to the standard notation used to repre-sent the business process models. In addition, as stated previously, each PFEproduct is considered as an evolving system. Our approach takes into accountthis advantage for representing the evolution of the business information sys-tems of the family.

1.4 Hypothesis

In this section, we state the hypothesis and research questions that moti-vate this research report and our future research in the context of the designof business families. These are:

Hypothesis: Current process engineers redesign each Business Informa-tion System using ad hoc techniques to maximize the level of reuse from oneproduct to another. Our hypothesis states that the reuse across businesses bymeans of Software Product Line (SPL) techniques can be exploited. It meansthat is feasible the definition of Business Families.

Increasing the business process definitions reusability is an active field ofresearch in the Business Driven-Development (BDD) community [3, 14, 26, 32,51, 52]. Our hypothesis raises the following research questions:

• Business Families. Does it makes sense?.A discussion about the advantages and drawbacks of this idea should beprovided. This discussion should include a preliminary definition aboutwhat is considered a business family and its main problems and benefits.

• The Software Product Line (SPL) field has a lot of benefits and BusinessProcess Management too, How many benefits have SPL and BPM to-gether?In order to explore the benefits of our approach, a discussion about theadvantages and drawbacks of both fields and how many benefits havetogether should be provided.

• How many approaches explores the idea of introduce SPL techniques inthe Business-Driven Development (BDD) field?The related work of this topic should be revised, studying the advan-tages and drawbacks of the current proposals and exploring how to in-tegrate them into our approach.


Hypothesis: The design of highly variable business process models of aBusiness Information System, member of a business family, could be partiallysupported by means of an automated treatment.

Nowadays, variability is one of the most active topics in several academicand industry communities [47, 55, 57]. Introducing variability support in theBDD field raises the following research questions:

• What kind of variability aspects can be performed on defining businessprocesses?A preliminary survey about the variability aspects identified on the de-sign of a business process should be defined. This survey should includethe methods and techniques used to define these variability aspects andits advantages and drawbacks.

• How many approaches provides variability support on designing Busi-ness Information Systems (BIS)?The related work of this topic should be revised, studying the advan-tages and drawbacks of the current proposals and exploring how to in-tegrate them into our approach.

• How many kinds of variability are present in the definition of a BIS andhow are them represented?A discussion about how many kinds of variability are present in the def-inition of a BIS should be provided. A company evolves continuously,thus not only static variability should be supported in our approach.In addition, the representation techniques used to describe these kindof variability should be revised. Another important issue is to studythe treatment of these variability definitions (manually or automated)and its main benefits and drawbacks including topics such as variabilityanalysis and visualization.

Hypothesis: Current proposals for modeling choreographies does not pro-vide any support for introducing variability aspects into the design of busi-ness families. Our hypothesis states that defining a choreography model usingAgent-Oriented Software Engineering (AOSE) techniques makes feasible thevariability support and an automated treatment for obtaining collaborationscenarios and behavior interfaces.

Modeling choreographies is one of the most active and recent topics in theBusiness-Driven Development field†3 [19, 20, 23, 64]. Our hypothesis raisesthe following research questions:


1.5. Research Methodology 19

Abstract Layer( Automata Theory and Formal Languages,

Context-Free Grammars, Finite State Machines, …)

Operational Layer( Business Driven Development, Software Product Lines,

Model Driven Development, Agent Oriented Software Engineering)

Implementation Layer(ATL, Eclipse SOA Tool Platform, …)

Characteristic Layer( BPMN, WSCI, BPEL)

Figure 1.6: Proposed Holistic Framework.

• How many current proposals for modeling choreographies deals withvariability aspects?The related work of this topic should be revised, exploring the proposedtechniques for modeling choreographies and its variability support.

• How many current proposals for modeling choreographies provides anautomated treatment for obtaining collaboration scenarios and behaviorinterfaces?The related work of this topic should be revised, describing the benefitsand drawbacks of current notations for designing choreographies andits automated treatment.

1.5 Research Methodology

Our research methodology is based on providing an approach which sat-isfies the following proposed holistic framework. This framework is dividedinto four layers as shown in Figure §1.6. These layers are defined as follows:

• Abstract Layer: this layer provides an abstract and formal definition ofthe core elements of our approach. Concretely, our approach is focusedon the definition of several identified artifacts using several specifica-tions such as, context-free grammars, finite state machines, etc.

• Characteristic Layer: this layer provides several standard specificationsthat must be supported by our approach. It means that all the elements


defined in the abstract layer must have its equivalent representation bymeans of at least one of these considered specifications.

• Operational Layer: this layer provides the set of development paradigmsthat are exploited in our approach. The operational paradigm layer de-pends on the standard specification defined in the previous characteristiclayer used to define some elements of our approach. Our approach mustsatisfy the constraints of these paradigms without adapting or extendingits elements for our purpose.

• Implementation Layer: this layer provides a real implementation of theoperational paradigms used. In this layer a set of implementation tech-niques and software tools are contained. As far as possible, the aimshould be to make use of generic techniques and tools that are not nec-essary to adapt to our needs.

1.6 Goals and Structure of this research report

The goals of this research report are defined as follows:

• Provide a review of the State of Art: Based on the hypothesis and re-search questions presented in Section §1.4, we identify several topicswhose state of the art must be revised.

• Propose an approach for designing business families: Taking into ac-count the main advantages and drawbacks of revised proposals, to pro-vide an approach for making feasible the design of business families isconsidered a goal of this report.

• Overview of our contributions: Although the results of our research arestill in a very preliminary stage we already have made some contribu-tions. Giving a brief overview of them is also one of the goals of thisreport.

• Future work: Conclude this research report with the main conclusionsof this work by means of the answer to the research questions and adissertation about our future work, is a goal of this report.

This research report is structured in four parts: Preface, State of Art, OurApproach, and Contributions. Figure §1.7 depicts the recommended readingprocess of this report.

1.6. Goals and Structure of this research report 21

GoalsMotivationResearch Context Hypothesis

Part 1: Preface

Part 2: State of Art Part 3: Our Approach

Business Family

Engineering

Part 4: Contributions

Relevant Publications

Other Contributions

Future Work

SPL and BPM

Variability in BIS Design

Business Families

Choreographies Definition

Business Families

Domain Design

Figure 1.7: Recommended reading process of this report.

The first part is focused on providing a brief summary about the motiva-tion of our research and the hypothesis and research questions that underlieour work.

In the second part, we review the state of art of our research context. InChapter §2, we explore the current proposals based on the introduction ofSPL ideas into BPM in order to perform a systematic generation and reuse ofbusiness processes across different companies. After that, a summary abouthow many kinds of variability are present in the definition of a BIS is providedin Chapter §3.

The third part is divided into the Chapters §4, §5, and §6. In this part,we provide our approach for performing business families, named Business


Family Engineering (BFE). We focus our efforts on providing a BFE softwareprocess definition for obtaining the core architecture of a business family, andexploring how to deal with variability on choreography modeling of businessfamilies using our approach.

Finally, in the last part, in Chapter §7, we provide a brief description of ourcurrent contributions in this research context and, in addition, we summarizeour main conclusions and describe our future work.

Part II

State of Art

Chapter 2

Software Product Lines & BusinessProcess Management

N owadays, one of the most active topics in the Business Process Man-agement (BPM) research community is exploring how to increase the

reuse of business process definitions. For that purpose, several approaches hasbeen proposed. The main motivation of this chapter is to provide a revision ofthese approaches, concretely exploring those which proposes the use of Soft-ware Product Lines (SPL) techniques.

In Section §2.1, we present a summary of all the proposals that explorethe reuse of business processes. Then, the rest of the chapter focuses on theProcess Family Engineering (PFE) approach, which is the only one that pro-pose the introduction of SPL techniques in the traditional design of BusinessInformation Systems.

26 Chapter 2. Software Product Lines & Business Process Management

2.1 Introduction

The SPL field tries to overcome the growing complexity of current softwareby maximising the level of reuse. Roughly speaking, the software process ofan SPL approach cover is performed in three parallel activities: (i) DomainEngineering : in charge of defining the SPL; (ii) Application Engineering : incharge of deriving an specific product from the definition performed at do-main engineering; and (iii) Product Line Management : devoted to the techni-cal and organizational management of domain and application engineering.See Chapter §1, Section §1.3.2 for a more detailed description about SPL.

In the Business Process Management (BPM) context, and concretely in theBusiness-Driven Development (BDD) field, increasing the level of reuse of thebusiness process definitions is considered a core need. Thus, since to SPLdeals with this issue, several approaches proposes the use of SPL techniquesin order to maximising the reusability of the process definitions.

According to [4], to perform a survey in the software engineering field, wehave to define an analysis framework with the following components:

• Research questions: How many approaches explore the reuse of busi-ness process models? and concretely, How many approaches exploresthe idea of introduce SPL techniques in the Business-Driven Develop-ment (BDD) field? (This last research question has been introduced inChapter §1, Section §1.4)

• Search strategy to select sources:we have searched the bibliography ap-pearing at DBLP, Google Scholar and ISI Web of Knowledge choosingthose papers with a higher number of cites; and finally a

• Catalogue: we classify the approaches in those focused on applying SPLtechniques, and those focused on other fields.

After searching the selected sources, we have found the following propos-als:

• Bayer et al.[6]: proposes the Process Family Engineering (PFE) approachfor modeling variant-rich processes and reuse its definitions into a prod-uct line architecture. This approach has been introduced in Section §1.3.3previously. The PFE approach explores the idea of using feature models(see Section §1.3.2 for a more detailed description about feature models)for managing variability in a business information system context, but

2.2. Process Family Engineering (PFE) 27

the relationship between these feature models and its products, definedby means of business process models, is not clearly defined [37]. In ad-dition, the PFE approach identifies some variability aspects in businessprocess models, and proposes to introduce some stereotypes for rep-resenting it. This redefinition of the syntax implies some maintenancedrawbacks identified in Section §2.2.

• Van der Aalst et al.[26]: proposes an extension of YAWL (Yet AnotherWorkflow Language), named extended workflow-nets (EWF-nets), forperforming configurable and reusable workflow definitions of businessprocesses. YAWL is a workflow modelling language inspired by Petrinets for defining business process models. However, although this ap-proach provides a formalization of EWF-nets for defining possible vari-ations into a workflow, it does not provide support for other notations,such as BPMN. In addition, the application of SPL techniques is not ex-plored

• Ciuksys et al.[14]: proposes an approach to reuse of business processesknowledge at domain engineering. For that purpose, it provides a pro-cess ontology for introducing semantic information into a business pro-cess model. Thus, this approach propose to analyse this semantic in-formation for obtaining a commonality summary, but without defininghow to represent these reusable assets.

Thus, to the best of our knowledge, the PFE approach is the only one thatpropose the introduction of SPL techniques in the traditional design of Busi-ness Information Systems. Taking into account the result of our survey, weare going to describe in the following section the ideas proposed by the PFEapproach.

2.2 Process Family Engineering (PFE)

2.2.1 Research Context: the PESOA project

The Process Family Engineering (PFE) approach was defined in the contextof the PESOA project. PESOA is the acronym of Process Family Engineeringin Service-Oriented Applications, and it is a cooperative research project sup-ported by the german federal ministry of education and research (BMBF).

The PESOA project aims at developing methodologies and techniques formodeling variant-rich processes and in the design and prototypical implemen-


Analysis Design Implementation

Domain Engineering


Application Engineering

Process Family Infrastructure

Figure 2.1: Process Family Engineering Overview.

tation of a Process Family Engineering platform. This project is focused in twodomains: E-Business and automotive †1.

2.2.2 Overview

The Process Family Engineering (PFE) approach is defined as a method-ological foundation for dealing with highly variable business process defini-tions. This methodological foundation consists on: (i) a Conceptual Modelfor variant-rich processes, which defines the conceptual requirements neededfor defining variant-rich processes in the E-Business and automotive domains;and (ii) a process engineering process called the PESOA Process, which pro-vides an approach for developing, using and maintaining families of processesdefined by means of their conceptual model.

Figure §2.1 depicts the overview of the PFE approach. It is composed bytwo activities named Domain and Application Engineering, based on the ac-tivities performed in the SPL field (defined previously in Section §2.1), and ina Process Family Infrastructure, which performs the management of the prod-

†1http://www.pesoa.de


Product Line Engineering (SPL) Process Family Engineering (PFE)

Product Line Infrastructure Process Family Infrastructure

Product Line Artifact Variant-Rich Processes

Artifact Element BIS Definition

Feature Models Variability Models

Table 2.1: Mapping between the SPL and PFE fields.

uct line defined. As shown in Figure, both domain and application engineer-ing activities are composed by three phases, which are defined as follows: (i)Analysis : focused on obtaining the requirements of the process family mem-bers; (ii) Design : focused on the design of the process family members, de-fined as variant-rich processes by means of the conceptual model proposed;and (iii) Implementation : focused on providing an executable definition ofthe variant-rich business processes.

Table §2.1 defines the mapping between the concepts from the SPL fieldand the PFE approach. First, we explore the equivalence between the prod-uct line and the process family infrastructure. Both elements are focused onproviding technical and organizational support of domain and application en-gineering. The difference between them is focused on the products that bothmanage. On the one hand, in the SPL field, the product line artifacts are com-monly software artifacts definitions composed on artifact elements (require-ments, design, code, etc.) and represented by means of feature models. Onthe other hand, in the PFE approach, the artifacts are variant-rich processeswhich are part of a BIS defined by means of variability models (commonlyfeature models too). However, although some equivalence between both re-search fields has been explored, there exists several diferences between themwhich are defined in the following section.

2.2.3 Main differences between the SPL and PFE fields

In the same way that the SPL approach provides all the techniques neededfor enabling the mass production of software in a certain application domain,the PFE approach provides all the techniques needed for enabling the massproduction of processes in a certain business.

However, althougth both fields are similar, the SPL approach produces a


...

Product Line Artifact n

Product Line Artifact 1

Software Product Line

Implemented by

Assets

Select features

Variation

Variation

Core Artifacts

Product 1

Variation

Core Artifacts

Product 2

Variation

Core Artifacts

Product m

...

...

m products; m > 0

Variant Rich Process 1

Process Family Engineering

Implemented by

Variation

Variation

Core Processes

BIS (state 1)

Variation

Core Processes

BIS (state 2)

Variation

Core Processes

BIS (state m)

...

1 product





...

Variant Rich Process n

Select features Select features

Assets

Approaches

Artifacts

Products

Figure 2.2: SPL and PFE approaches.

set of software systems while the PFE approach produces only one BusinessInformation System (BIS), defined by means of variant-rich business processdesigns. These business processes definitions represent all possible states forwhich the BIS can evolve during its activity. Roughly speaking, in PFE, eachproduct represents an evolution of the BIS (at runtime). In this context, theterm product is defined as a set of features that are enabled/disabled at acertain moment, and the term evolution is defined as a transition from oneproduct to another. Although there exists several products, only one softwaresystem is produced by means of the PFE approach: a BIS which evolves atruntime.

Figure §2.2 sketches how SPL and PFE products are generated. In SPL aproduct is composed of a set of common features and a set of variable fea-tures. Common features appears in all products and variable features appearsunder demand of products’s consumers. Observing a certain product of a SPL,although it is described as a set of fixed features, some features can be in usein a certain moment and some not. Thus, in SPL the evolution of the system atruntime is not taken into account in the feature model. In PFE each feature isa process and all of them appear into the product, but at runtime there existsa set of products based on selection of features/processes.

As can be observed in Figure §2.2, where we depict how SPL and PFE prod-ucts are generated, SPL products are implemented by software artifacts thatfor each of them there exists a feature selection phase that generates the final


products (a set of core and variable features). PFE products are implementedby processes that for each of them there exists an evolution in execution timeincrementing or decrementing the variable set of features. Each product is asoftware system based on processes. In addition, as stated previously, PFEconsiders that sometimes a feature represents an activity, sometimes a busi-ness process, but without providing an equivalence definition. Thus, we cansay that in PFE there not exist a mapping relationship between feature modelsand business process models. This ambiguity implies some drawbacks iden-tified in the design phase of PFE that we define in Section §2.2.6.

2.2.4 Conceptual Model

The conceptual model of the PFE approach is devoted to deal with vari-ability in the representation of business processes in the E-Business and theautomotive domain. Roughly speaking, this model contains all the elementsthat can vary in the definition of a BIS in the specified domains. Figure §2.3presents the conceptual model as an UML static structure.

The elements of the conceptual model are defined as follows:

• Process: It is the core element of the model. For each process definitionthe partner who performs the process (attribute Role) and the executionstate of the process (attribute Execution State) must be provided . ThePFE approach states that processes can vary. Regarding our case study(See Section §1.2): Reserve Tickets subprocess could provide support fordifferent mechanisms for paying a reserve. The process Reserve Ticketscontains a variation point that offers three choices to resolve the variabil-ity. Such choices can be: Reserve Tickets with Credit Card, Reserve Tick-ets with Bank Transfer and Reserve Tickets per Telephone. Dependingon the choice selected by the user the Reserve Tickets will be resolved.Thus, it implies that at design time the process engineer should know allthe possible choices or variations of a process. As shown in Figure §2.3,a process is considered as activities and a composition of them specifiedsuch as a Sequence, Parallel, Choice or Iteration

• Input/Output: These elements specify data objects that are gener-ated/consumed in a process. Regarding the example: assuming a clienthas selected to Reserve Tickets with Bank Transfer, the input form mightvary depending on the country where the bank belongs to. For example,American bank codes might differ from the European ones. In addi-tion, the invoices to be generated might have different representationsdepending on where the order is delivered.


RealTime Safety Security

QoS

Non-Functional Properties

*

1

Process

+ Role+ Execution State

CompositeActivity1*

Sequence

Parallel

Choice

Iteration

Control Flow

Input Output

DataSource DataSink

* *1 1

0..*0..*

**

11

0..* 0..*

1 1

Data Flow

Scope * *

0..1 1- acquires

Event*

*- catchesActivity

Exception

- throws *

*

- throws

Variable

1

*

State

1

*

Environment

Figure 2.3: Conceptual Model of the PFE approach.

• Data Source/Data Sink: Data sources produce data used as input, as forexample the return of an invocation to a web service. Data Sink con-sume data produced as outputs, as for example a database that storesresults. In our case study, assuming that the client who has selected toReserve Tickets with Bank Transfer, has an account in an American bank,a data source produced could be the account code in American formatprovided by a third-party web service from his bank. A data sink for ourexample could be a Content-Management System such as Alfresco†2 asa repository where store the invoices.

• Quality of Service: It is focused on providing some non-functional prop-erties in order to improve a concrete business process, as for exampleproviding a security layer on Reserve Tickets with Bank Transfer processusing an standard specification such as WS-Security †3. The proposedconceptual model only takes into account Security, Safety and Real Timeas non-functional properties.

†2http://www.alfresco.com†3http://www.oasis-open.org/committees/wss/


• Scope: It is focused on providing business environments. Roughlyspeaking, it provides some functionalities into the business process de-pending on its attribute Role, as for example a set of permissions de-pending on an authenticated business partner, such as an administrator.Regarding our example, only an authenticated Travel Agent can VerifySeats Availability.

• Variable: A variable is associated to a scope and a set of variables definesa state. Variables hold data of process attributes (inputs, outputs, datasources, data sinks, roles, and nonfunctional properties). In our casestudy, a variable could be a reserved ticket identification number.

• State: A state is a situation during the execution of a process, which ischaracterized by the current variable assignments of its contained pro-cesses. In the conceptual model, this is reflected by the aggregation fromthe state concept to the variable concept, and through the relationshipbetween the scope and the process concepts. For example, in our casestudy the state of a reserving transaction at a given time could be de-scribed by: the process Reserve Tickets, and the payment method BankTransfer.

• Event: An event can be thrown by a data source or a process. In the caseof a data source, an event is thrown, when a special value or thresholddefined for the data source has been reached. Something similar canbe assumed for a process that reaches a certain state. For example, inour case study, the Order Trip process is triggered when is received amessage from a Traveler who wants to travel to an specific destiny. Onespecial kind of event is the exception. An exception can be used to definea possible error in the execution of a process.

Once the elements has been explored, the PFE approach states that the aimof this conceptual model is to provide a metamodel for modeling businessprocesses. For that purpose, this approach explores the use of several model-ing notations such as UML Activity Diagrams or Business Process ModelingNotation (BPMN) extending it depending on their domain needs.

2.2.5 The PESOA Process

This section presents in more detail the PESOA process proposed by thePFE approach. Figure §2.4 presents a product flow view of the domain frag-ment of the PESOA process, which is the focus of our research. (A more de-


Scoping

Domain Scoping Domain Scope

Definition

Product Set

Domain Analysis

Model Features Feature

Model

Identify Processes

Process Requirements

Domain Design

Design Processes Variant Rich

Processes

Variation Points Set

Model Configurations

Domain Implementation

DS Generator

DS Components

Implement DS Components

Configuration Model

Implement DS Generator

Figure 2.4: Domain Fragment of the PESOA Process.

tailed description of the overall PESOA process is provided in [6]). This frag-ment is divided into the following phases:

• Scoping: The main purpose of this process is to provide a requirementscapture of the desired Business Information System. For that purpose,


the process engineer must review into the Process Family Infrastructureavailables reusable definitions, denoted as Product Set in Figure §2.4.As result, process engineers obtain a Domain Scope Definition. The PFEapproach does not provide any element and constraints for documentingthis definition.

• Domain Analysis: The main purpose of this process is to provide a rep-resentation of the desired Business Information System by means of avariability model, such as a feature model. The domain scope definitionis used as input for identifying consists-of relationships among features.Once the feature model is defined, the process engineer must identify theprocesses from this representation in order to provide a business processmodel definition. For that purpose, a process requirements summarymust be provided too.

• Domain Design: The main purpose of this process is to derive a busi-ness process model definition that deals with the variability of the de-sired Business Information System. Thus, process engineers must de-rive this representation from the feature model and the process require-ments obtained in the domain analysis phase. Once this representationis obtained, the variants and variation points of the business processesare identified. Roughly speaking, the process engineer identify the pro-cesses and the choices to resolve its variability as stated in Section §2.2.4.Finally, this set of variation points is used as input for obtaining a con-figuration model for each of the members of the family.

• Domain Implementation: The main purpose of this process is to de-ploying the business process model specifications into a process enginethat executes it and produces the desired Business Information System.For that purpose, the PFE approach proposes the use of domain-specificgenerators and components.

2.2.6 Drawbacks

Although PFE may be the solution to obtain Business Information Systems(BIS) based on variant-rich business process definitions and to manage its evo-lution, the Design step of this approach, concretely the use of feature modelsand the derivation of business processes from it, presents three main draw-backs, defined as follows:

• Ambiguity: PFE uses feature models to show the variability derivedfrom enabling/disabling feature/process; however, given that feature


models are devoted to represent design-time variability and not runtimevariability [25, 38], the approach redefine the semantics of feature mod-els implicitly, but without providing a definition for it.

• Maintenance: PFE extends the notation of BPMN to add informationabout variability which is also present in the feature models, thus, in-formation is duplicated with the obvious problems for maintenance. InChapter §3, we explore this extension and the drawbacks that it implies.

• Manual derivation: the relationship between a feature model and itscorresponding business process is not rigorously defined, and the devel-opment of the business process is performed manually using as inputthe feature model, what makes this activity error-prone and hinders themaintainability of both kind of models.

In addition, as shown in Section §2.2.3, the PFE approach does not providea family of software systems, only one BIS (the final product) which evolvesat runtime. This evolution is managed by means of SPL techniques but PFEdoes not provide any representation for modeling it.

Chapter 3

Variability in Business InformationSystem Design

I n common language use, the term variability refers to the ability or thetendency to change [46]. Thus, variability is one of the critical aspects of

a Software Product Line (SPL) infrastructure and it must be managed at allthe stages of development. Consequently, several approaches explores how tointegrate variability into the Business Process Management (BPM) domain inorder to provide flexible Service-Oriented Architectured (SOA) systems.

The main purpose of this chapter is to provide an study about variabilityinto our research context. Thus, Section §3.1 explore what kind of variabilityaspects can be performed on defining business processes, and how many ap-proaches provides variability support on designing Business Information Sys-tems (BIS). Since to the PFE approach is the only one that covers our needs, weexplore these research questions (proposed in Chapter §1, Section §1.4) withinthe context of that proposal in Sections §3.2 and §3.3. Finally, in Section §3.4,we explore the binding time of identified variability aspects.

38 Chapter 3. Variability in Business Information System Design

3.1 Introduction

Variability is one of the critical aspects of Software Product Lines (SPL). Itmust be managed at all the stages of SPL development, and in every of them,it appears in a polymorphic way which motivates the arising of different kindsof variability. This double facet of variability and its importance in SPL, havepromoted an important amount of research approaches aimed to model andhandle it.

Pohl et al. introduces in [46] all the questions that a well-formed docu-mentation of variability must fulfil. An adequate documentation of variabil-ity definition should at least include all the information needed to answer thefollowing questions:

• What varies?: the variable properties of the different development arti-facts have to be explicitly defined and documented.

• Why does it vary?: all the causes of variability have to be captured andexplicitly defined and documented.

• How does it vary?: documenting all the available choices and linkingthem to domain model elements

• For whom is it defined and documented? to define the audience of avariation point (what varies) and/or its variants (available choices).

Derived from Software Product Lines appears an approach, into theBusiness-Driven Development context, named Process Family Engineering(PFE) [6]. The PFE approach explores how to increase the reusability of theprocess definitions and how to model highly variable business process. Con-sequently, the enterprises benefits would increase since to the reuse and self-automatization in the process design phase will decrease the developmentcosts of Business Information Systems.

Therefore, we conduct an study of defining Variability term, in the do-main of the Process Family Engineering approach. The main purpose of thischapter is to perform survey about the variability aspects identified in this ap-proach. In addition, for each of them, we provide a definition based on Pohlstatements.

3.2. Variability Mechanisms 39

3.2 Variability Mechanisms

Schnieders et al. [51] proposes in the context of the Process Family Engi-neering approach a set of extensions into the current standard specification ofthe Business Process Modeling Notation (BPMN) for dealing with variability.These mechanisms are defined by means of categories of variability mecha-nisms which are defined as follows:

• Basic variability mechanisms: are standalone mechanisms, which doesnot require any other variability mechanisms. Four types of basic vari-ability mechanisms has been identified: encapsulation of varying sub-processes, parameterization, addition/omission/replacement of singleelements, and data type variability.

• Variability mechanisms derived: are derived from the basic variabil-ity mechanisms. This category is divided into variability mechanismsderived by restriction and by combination of other variability mecha-nisms. Inheritance and extension are examples for variability mecha-nisms derived by restriction and Design Patterns an example for a vari-ability mechanism derived by combination.

3.2.1 BPMN Extensions for Dealing with Variability

Before describing the variability mechanisms identified, is necessary toprovide the set of extensions proposed to the standard BPMN for dealing withvariability aspects. Proposed extension [51] is based on to adapt the concept ofa stereotype from the UML2 specification to BPMN. A first approach of theseextensions has been presented in Chapter §1, Section §1.3.3. These extensionsare defined as follows:

• Stereotypes: in order to represent a variant-rich business process a set ofstereotypes has been added to the current notation. Thus, �VarPoint�stereotype identify a business process that can vary to a set of specificprocesses denoted by means of the �Variant� stereotype. For a moredetailed model, a stereotype named �Variable� can be used to denotevariability below the level of detail currently shown. In addition, thestereotype �VarPoint� can be specialized. �Abstract� variation pointrepresents alternative behavior. Thus, it has to be resolved by an specificvariant. �Null� variation point represents optional behavior. It can beresolved by an specific variant. �Alternative� is a short representation


of an abstract variation point with an specific variant which is the defaultresolution to this variation point. An �Optional� variation point is ashort representation of a �Null� variation point a specific variant. Fig-ure §3.1 sketches the Reserve Tickets process from our case study (SeeChapter §1, Section §1.2) modeled using these stereotypes. Thus, Re-serve Tickets has been defined as an �Abstract� variation point withtwo alternatives. On the one hand, a resolution of the process performedby a �default� variant, a refinement of the alternative default vari-ant defined by means of the �Alternative� variation point, and on theother hand, the Reserve Tickets with Bank Transfer process.

• Symbols: �Variant� stereotype can also be expressed graphically asa puzzle-piece like marker at the bottom of business process. ReserveTickets with Bank Transfer is a variant process denoted by means of thissymbol, as shown in Figure §3.1.

• Tagged values: �Variant� stereotype can have the tagged value fea-ture which provides information about the dependency of the subpro-cess variant from a certain feature configuration. Figure §3.1 depicts thatReserve Tickets with Bank Transfer has a tagged value referred to a fea-ture selection, concretely the payment method.

In addition, as shown in Figure §3.1, several extensions has been included,as the stereotypes which specifies the variability mechanism applied, such as�implements�, �inheritance� or �parameterization�, symbols into dataobjects, or dotted flows for specifying associations related with the variabilitymechanism, such as implements or inheritance.

3.2.2 Basic Variability Mechanisms

3.2.2.1 Encapsulation

A BPMN process can hide alternative subprocesses behind an invariantinterface. The interface activity is marked with the �Abstract� stereotype.Possible realizations of the interface are connected using an implements as-sociation. If there exists a default realization, the process can be marked asa �default� variant. This variability mechanisms is shown in Figure §3.1,where Reserve Tickets subprocess acts as interface of two alternative imple-mentations (one of them marked as default). It is a good choice for definingthe business processes as black boxes.

3.2. Variability Mechanisms 41

<< abstract >>Reserve Tickets

Reserve Tickets

<< default >>

Reserve Tickets

{feature: Reserve with Bank Transfer}

Bank Transfer

<< implements >> << implements >>

<< inheritance >>Discount = 3%

Discount = 5%<< parameterization >>

<< VarPoint >> Reserve Tickets has two <<Variants >>. It is defined as an alternative behavior with a default variant

Variability MechanismsTagged value

Symbols

Figure 3.1: Reserve Tickets process model using the BPMN extension [51].

3.2.2.2 Parameterization

Each process attribute can be parameterized to support optional, alterna-tive, or range values. Commonly, this attribute is marked using a groupingbox and associated to other possible values by means of a new associationflow defined with a new stereotype named �Parameterization�. Figure §3.1presents a parameterization of the attribute discount of the process ReserveTickets with Bank Transfer, which means that in some situations the value ofthis attribute can change.

3.2.3 Variability Mechanisms Derived

3.2.3.1 Inheritance

Inheritance adds restrictions to addition/omission/replacement of singleelements. Thus, it modifies an existing subprocess by adding activities. Thisallows for realizing alternative variation points. An association represents in-heritance from the child activity to the parent activity when it is marked withthe �inheritance� stereotype. Reserve Tickets and Reserve Tickets with BankTransfer variants has an inheritance association with the variation point Re-serve Tickets as shown in Figure §3.1.


3.2.3.2 Extension

Extensions and extension points are used to extend an encapsulated sub-system at predefined points, the extension points, by additional optional be-havior selected from a set of possible variants. Thus, extension points use acombination of encapsulation and �Null� processes to realize optional vari-ation points. In addition, an association extends is defined too. Figure §1.5.dfrom Chapter §1, Section §1.3.3 presents an example of an extension modeledby means of this mechanism.

3.3 Summary of Variability Aspects

Regarding our research questions: What kind of variability aspects can beperformed on defining business processes?, and How many approaches pro-vides variability support on designing Business Information Systems (BIS)?,we provide a summary of the variability aspects identified for the only oneapproach which provides variability support on the design of BIS, to the bestof our knowledge, the Process Family Engineering (PFE) approach. This sum-mary is based on Pohl statements of a variability definition presented in Sec-tion §3.1.

• What varies?: Mainly, the elements that varies are, on the one hand, thebehavior of the business processes in function of several conditions, de-noted by means of the choice of several features, and in the other hand,process attributes which can vary depending feature selection too. En-capsulation, Inheritance and Extension mechanisms provides supportfor modeling the flexible behavior of a business process. In addition,Parameterization mechanism provides support for modeling the vari-ability in process attributes.

• Why does it vary?: All the variable elements identified change by meansof features selection at design-time. Roughly speaking, process engi-neers known at design time all the possible choices and they model abusiness process definition that fullfils all the possibilities. In the PFEApplication Engineering phase, its performed the selection and a Busi-ness Information System is provided.

• How does it vary?: Encapsulation mechanisms makes feasible the vari-ability by means of providing an invariant interface definition of a busi-ness process. Each possible variant of the business process is a differentimplementation of its behavior. Inheritance and Extension mechanisms

3.4. Variability Binding Times 43

provides a way to modify elements and/or behaviors by means of the in-troduction of new associations into the current notation. Finally, Param-eterization, provides variability in business process attributes by meansof introducing new elements into the notation too.

• For whom is documented and defined?: All the variability mechanismsare documented for improving the design of the business process mod-els, performed by process engineers.

3.4 Variability Binding Times

Variability binding time term is focused on providing an answer to thequestion: When does an artifact vary?. As shown in Chapter §2, Section §2.2.3,the Process Family Engineering (PFE) approach provides a Business Informa-tion System (BIS) which evolves/vary at runtime. This evolution is managedby means of Software Product Line (SPL) techniques where each product isdefined as a set of features (processes) that are enabled/running at a certainmoment. In addition, the term evolution is defined to denote the changes ortransitions from one product to another.

However, although the PFE approach takes into account this evolution atruntime, the variability mechanisms provided are performed at design-time,since to the PFE approach only take into account the evolutions that can bepredicted at design-time.

Thus, the PFE approach does not provide any representation for runtimevariability and for Predictable and Unpredictable Evolutions. An Unpre-dictable Evolution is defined by means of Unpredictable Triggers. A Triggeracts as stimulus of an evolution from a product to another. An UnpredictableTrigger is defined as something happening in the environment that fires anevolution that cannot be predicted at design time. Thus, a Predictable Trig-ger is defined as a condition that can be defined at design time that fires anevolution.

Runtime variability representations is necessary at the Business-DrivenDevelopment context. Process engineers need to visualise and analyse prop-erties of the business at runtime, for example: how long each product is activeor which is the percentage of benefits obtained in each product at a certainmoment. This kind of evaluation is studied in the Business Process Miningfield [17, 50, 59].


Part III

Our Approach

Chapter 4

Business Family Engineering

T aking into account the main advantages and drawbacks of revised stateof art, to provide an approach for making feasible the design of busi-

ness families is considered a goal of our research. Thus, in this chapter weprovide the big-picture our approach, named Business Family Engineering,which is defined as a systematic methodology for performing families of Busi-ness Information Systems (BIS) focused on increasing the business processdefinitions reusability.

48 Chapter 4. Business Family Engineering

4.1 Introduction

The main purpose of this chapter is to define the main aspects of our pro-posal of a systematic methodology for performing business families, namelyBusiness Family Engineering (BFE). Thus, in Section §4.2, we states the basisof our approach, providing a rigorous description of the main aspects of BFE.

In addition, we explore the integration of our approach with Process Fam-ily Engineering (PFE), and provide a graphical notation for representing thesupported variability of our approach. Finally, in Section §4.3, we present anoverview of the software process of Business Family Engineering using theSPEM notation†1.

4.2 Business Families and BFE

Business Families can be defined as a set of software systems driven bybusiness processes, hereafter Business Information Systems (BIS), where eachproduct of the family has a set of common processes and a set of variableprocesses. Thus, roughly speaking, we define Business Family Engineering asa methodological approach for performing business families.

4.2.1 Rigorous Definition

A first step to a rigorous definition of a business family can be representedas follows: Let BF be a Business Family that contains a set of n > 1 businesses

BF = {B1, B2, ..., Bn}

where each B represents a business. Each business B can be defined bymeans of a BIS that is designed based on a set of processes (denoted with P).Thus, each Bi in BF can be defined as follows:

Bi = {P1, P2, ..., Pk}; k > 0; 1 ≤ i ≤ n

Given this it holds there exists a set of common processes betweenwhichever set of businesses. Let Bi and Bj be two businesses contained inBF where 1 ≤ i, j ≤ n:

Bi ∩ Bj 6= φ

†1http://www.omg.org/technology/documents/formal/spem.htm

4.2. Business Families and BFE 49

Thus, we can say that a business family can be also defined as a set ofcore and variable processes/features. We assume that there exists a binaryrelationship between features and processes, thus a feature must not representa set of processes. Let CF be the set of common processes or features and letVF be the set of variable features,thus BF can be defined as follows:

BF = (CF, VF)

In that way, a business Bi is defined formally as a tuple containing all theCF and a subset of VF denoted as SVF:

Bi = (CF, SVF ∈ VF)

4.2.2 Integration with Process Family Engineering

As defined before, each business contains a set of core processes, CF, anda set of variable processes, VF. However, in Process Family Engineering (PFE)the processes/features appears and disappears at runtime. As shown in Sec-tion §2.2.3, each configuration of the set of processes enabled at certain mo-ment represents a product. Thus, we can say that the CF of a BF are alwaysenabled at runtime, but the set of processes in VF is not fixed at runtime.

Thus, as PFE defines, we can set up a product line that takes into accountthis runtime variability. For formalizing these concepts we should redefineeach business B of a BF as:

B = (CF, SVF ∈ VF, F∆ : t, {Feature× ... × Feature} 7→

7→ {Feature× ... × Feature})

where F∆ is a function that given an instant t transform the set of SVFt intothe new set of variable features of the following time instant t + 1, that is tosay SVFt+1, formally:

F∆(t, SVFt) = SVFt+1 ∈ VF • SVFt 6= SVFt+1

Figure §4.1.a sketches a graphical representation of F∆, where it is repre-sented the transformation of SVFt into SVFt+1. In an instant t there exists anspecific set of SVFt for business B that evolves in instant t + 1 to another dif-ferent set SVFt+1.

4.2.3 Graphical Notation

As shown previously, a business that evolves can be represented by B =

(CF, SVF ∈ VF, F∆). where the evolution is defined by the F∆ function in t.


Features

Instant t

Instant t + 1

SVF t+1

Features

SVF t

B

Business

B

Business

Rigorous Description Product Evolution Model

Business B

...

t + 1

t + k;k > 0...

Feature Model

Business B

Processes

...

CF

VF

Legend

: Core Processes CF

: Variable Processes VF

(A) Rigorous Description

(B) GraphicalNotation

CF + SVF t

CF + SVF t + 1

: Selected Processes SVF

F (t, SVFt) = SVFt+1 ∊∊∊∊ VFF (t, SVFt)• SVFt ≠ SVFt+1

Figure 4.1: PEM approach defining a business evolution by F∆ function in t

and t + 1.

In PFE feature models (FM) are used to represent which features are vari-able and which do not. From this, a the set of common features (CF) and (VF)can be obtained [46]. Thus, CF and VF can be represented by means of a FM.

However, the feature model cannot establish the order of apparition ofbusiness processes, represented as F∆, since to feature models are not devotedfor temporal conditions or variables (t) [25]. For that purpose, we have to adda new model with a graphical notation that represents F∆, the Product Evolu-tion Model, which is defined by means of a BPMN state machine where eachstate represents a product and each evolution between two or more states,is represented by means of a transition that is an application of F∆ function.Figure §4.1.b shows how an evolution of a business is defined by means ofF∆ function in t and t + 1 using BPMN. Notice that it represents an specificgraphical notation for the formal description of our approach, but other nota-tions can be applied.

4.3. Software Process of BFE 51

��

�� !�"�� #��"��

(A) Overview of the software process of Business Family Engineering

�� (B) Business Family Domain Engineering

Figure 4.2: Software process of BFE in SPEM notation.

4.3 Software Process of BFE

As shown in Figure §4.2.a, in BFE software process there are two main ac-tivities: (i) Business Family Domain Engineering, where we build the BFE corearchitecture, namely Core Process Framework, and the Business Family Vari-ability Summary ; and (ii) Business Family Application Engineering, where weobtain specific business information systems, that are described by means ofexecution languages, such as Business Process Execution Language (BPEL).This second stage is out of the scope of our research.

In addition, we have identified two different ways to build a business fam-ily: top-down and bottom-up. In the top-down approach, we define the set ofbusinesses and processes from scratch and apply the normal sequence of BFEsoftware process. In bottom-up approach, we can not apply the normal se-quence of the software process defined since to we have a set of businesses orprocesses defined in feature models previously to apply BFE software process.In our research we only focus in top-down.

Once the BFE big-picture has been defined, in next chapters we propose,first, a concrete definition of the methodology fragment of BFE focused onobtaining the core architecture of a business family, in other words, defininghow to design business families, namely Business Family Domain Engineer-ing shown in Figure §4.2.b, and finally, an approach for dealing with vari-ability on choreography modeling that is integrated into the Business FamilyEngineering approach.


Chapter 5

Business Families Domain Design

I n this chapter we present the methodology fragment of Business FamilyEngineering focused on obtaining the core architecture of a business fam-

ily, namely Business Family Domain Engineering. As a result of this fragment,we improve the development of business information systems reducing itscomplexity level in situations where is necessary to perform a business family,using our proposed methodology. Previously, we introduce in Section §5.2 an-other important contribution that is the basis of this methodology fragment,focused on providing a systematic mapping approach between feature mod-els for representing variability in Business Information Systems to businessprocess models.

Consequently, since to our approach is focused on providing the core ar-chitecture of the family, we provide to process engineers some artifacts forimproving their activities, such as a business family variability summary anda core process framework in Section §5.3. These artifacts provides a basicstructure of the business process model that supports the variability aspectsidentified by the Process Family Engineering approach, without the need ofextending the standard notation of BPMN.

54 Chapter 5. Business Families Domain Design

5.1 Introduction

The main purpose of this chapter is to define the methodology fragment fo-cused on obtaining the core architecture of a business family, namely BusinessFamily Domain Engineering. This methodology fragment is complementedby a proposal for improving the Process Family Engineering Design step. Inthis activity, the use of feature models and the derivation of business processesfrom it presents three main drawbacks: ambiguity, maintenance, and manualderivation, what makes this activity error-prone and hinders the maintainabil-ity of both kind of models, as shown in Chapter §2, Section §2.2.6.

Thus, before defining the Business Family Domain Engineering activities,we present a systematic mapping approach for obtaining a business processmodel from a feature model. This transformation is achieved by: (i) a featuremodel redefinition of its semantic, presented in Section §5.2.1, which is basedon using context-free grammars for describing feature models; and (ii) a trans-formation of this grammar to a finite state machine model, which can be rep-resented by means of a business process model, detailed in Sections §5.2.2 and§5.2.3. Consequently, in Section §5.3 we define the Business Family DomainEngineering activities and integrate this systematic mapping these activitiesproviding support for this methodology fragment.

5.2 Preliminaries

As stated in Chapter §1, Section §1.3.2, a feature is considered as a char-acteristic of the system that is observable to the user. Feature Models (FM)represents all possible products in a Software Product Line (SPL) in terms offeatures.

FMs can be described by propositional formulas and grammars. This rep-resentation is proposed by Batory et al. in [5]. Figure §5.1 shows the corre-spondence of a traditional feature model, a context-free grammar and a propo-sitional formula. It defines a product-line where each application contains afeature q and optionally r, where q is an or feature: almost one of s and tcan be present in an application; and r is an alternative feature: only one of vand w can be present in a member of the family. Thus, since to feature modelsare devoted to represent design-time variability and not runtime variability[25, 38], the Process Family Engineering (PFE) approach redefine the seman-tics of feature models implicitly, but without providing a definition for it. Inthis section, we focus on Batory’s work as start point for redefining feature

5.2. Preliminaries 55

rq

p

s t v w

p : q [r] ;q : a+ ;a : s | t ;r : v | w ;

Feature Model

Grammar

P implies (q or (q and r))q implies ((s or t) and almost1(s,t))r implies (v or w)

Propositional Formula

Figure 5.1: A feature model, its grammar and its propositional formula repre-sentation by Batory [5].

model semantic on Business-Driven Development context. In addition, wepresent our contribution for improving the design of highly variable businessprocess models based on mapping feature models used for representing vari-ability in Business Information Systems to business process models.

5.2.1 Redefining Feature Models

In order to perform a Process Family Engineering (PFE) feature modelgrammar representation, we need to define a new context-free grammar (CFG)taking into account that in SPL it is not necessary to establish the order ofappearance of the features into a family product, but in our context it is rec-ognized as a core need. Process engineers need to perform business processdefinitions which establishes the order that the processes must be performedand its dependencies with others (i.e: subprocess A and B must be done inparallel, and after that, subprocess C must be performed). This kind of infor-mation it is not present into traditional proposals for SPL modeling.

For defining a CFG for PFE feature diagrams, we consider all the productsof each feature model, hereafter named artifacts, as a language which can bedefined by means of a regular expression [29]. Let A be a business processdefined by means of a feature model which establishes a mandatory relation-ship with two subprocesses B1 and B2. Figure §5.2 shows this FM. There existsthree possible alternatives for performing A:


• B1, B2: In order to perform an activity named A, it is necessary to per-form the sequence of subprocesses B1 and B2.

• B2, B1: In order to perform an activity named A, it is necessary to per-form the sequence of subprocesses B2 and B1.

• B1 • B2: In order to perform an activity named A, it is necessary to per-form subprocesses B1 and B2 in parallel.

In addition, PFE considers that sometimes a feature represents an activity,sometimes a business process, but without providing an equivalence defini-tion for both artifacts. Thus, we can say that in PFE there not exist a mappingrelationship between feature models and business process models. In our ap-proach, we are going to take into account the following considerations:

• parent features in a feature model, namely variation points, are consid-ered as complex processes.

• child features in a feature model, namely variants, are considered as sub-processes.

5.2.2 Feature Model Grammars

Once feature models are redefined for BIS context, we are going to reuseBatory’s grammar representation [5] for proposing a new grammar. Thus, asshown on Figure §5.2, the language which defines this artifact is:

La−mand = {b1b2, b2b1, b1 • b2}

Now, consider an artifact with an optional relationship instead of a manda-tory, as shown on Figure §5.2. Let ε an empty set, the language which definesit is:

La−opt = {ε, b1, b2, b1b2, b2b1, b1 • b2}

In addition, if we consider an artifact with an alternative relationship in-stead of an optional, as shown on Figure §5.2, the language which defines itis:

La−alt = {b1, b2}

And finally, if we consider an artifact but with an or relationship instead ofan alternative, as shown on Figure §5.2, the language which defines it is:

La−or = {b1, b2, b1b2, b2b1, b1 • b2}


Regular Expressions

Context- FreeGrammar

B

A

A

B

A

A

B1 B2

A

B1 B2

Man

dato

ryO

ptio

nal

Alte

rnat

ive

Or

Rel

atio

nshi

ps

A

B1 B2

A

B1 B2

Feature S : A;A : a;

A : B;B: b;

$ % &' ( ) * +A : B, B- |B- B,. B,.B- ;B/ : b,;B0 : b-;A : B | ;B : b;

ε

A : B, B- | B- B,. B,.B-. B,. B-. ;B/ : b,;B0 : b-;

ε

A : B,. B- ;B/ : b,;B0 : b-;

A : B, B- | B- B,. B,.B-. B,. B- ;B/ : b,;B0 : b-;

$ % 1' ( ) 2+$ % 1/10 31 01/ 31 /410' ( ) 2,2-52 -2,52 ,62-+$ % 17' ( ) 5 2 +$ % 1/7107 31 071/7 31/410$ % 1/ 31 0' ( )2, 5 2- +$ % 1/107 3101/7 31/410

ε

' ( ) 5 2,5 2-52 ,2-5 2-2,2 ,62- +ε

' ( ) 2,5 2-52 ,2-5 2-2,52 ,62- +

Feature Model

Figure 5.2: PFE Feature Model and its CFG representation.


F

R1 Rn

FM1 FMn

...

F = FM1 FM2 … FMn

A

B CB

D EB

A

C

A

D E

=

F: FeatureRi: RelationshipFMi: Feature ModelDom(Ri): { Mandatory , Optional ,

Alternative, Or }

A: C | B C | C B | C B;B: D E | E D | D E | D | E;C: c; D: d;E: e;

(B) Grammar Representation Composition

(A) Composition by means of the operator

Figure 5.3: PFE Feature Model Grammar Representation Composition.

Thus, a regular expression of these languages can be obtained by means of op-erations of automata and formal languages theory defined in [29]. Let rmand bethe regular expression which defines La−mand, let ropt be which defines La−opt,let ralt be which defines La−alt, and let ror be which defines La−or, they can bedefined as follows:

rmand = b1b2|b2b1|b1 • b2

ropt = b1?b2?|b2?b1?|b1 • b2

ralt = b1|b2

ror = b1b2?|b2b1?|b1 • b2

where ? represents the operator one-or-zero token occurrences defined in [29].

Once regular expressions are obtained, a context-free grammar definitionof these regular expressions can be described. Figure §5.2 sketches the equiv-alence of a feature and its relationships in terms of regular expressions andcontext-free grammars. Parallel definitions are described by means of • char-acter. In addition, as shown in Figure §5.3.a each possible composition be-tween two or more different artifacts is resolved by means of parallel de-compositions. Figure §5.3.b presents an example of this composition whichsketches how a feature model with three different relationships is defined bymeans of a composition of three simplified feature models with only one rela-tionship. Thus, the CFG representation of composed feature model is obtainedby means of applying • operator to three simplified feature models CFG rep-resentations defined previously on Figure §5.2. Obtained CFG for composedfeature model is shown on Figure §5.3.b.


Context - FreeGrammar

a

b

b1

b2

b2

b1

ε

ε

ε

ε

Start

Start q0 q1

q1 q2

q0

q1q2

q3

q6q7

q8

q9

ε

Start q0

q1

q2b

ε

ε q3

εq4

ε

Start q0

q1

q2

ε

ε q3

εb1

q6 q7

b2

q8 q9

b2

q11 q12

b1

q 10

b1

q13

b2

ε ε

ε

ε

ε

ε

q14

Start q0

q2ε q3

εb1

q4 q5

b2ε εq

Start q0

q4

ε q5

εb1

q8 q9

b2

q10 q11

b2

q1 q2

b1

q12

b1

q3

b2

ε ε

ε ε

q11

εε

Finite State Machine Model

Start q0

ε q3ε

S : A;A : a;

A : B;B: b;

A : B8 B9 |B9 B8: B8~B9 ;B; : b8;B< : b9;

A : B | ;B : b;

ε

A : B8 B9 | B9 B8: B8~B9: B8: B9: ;B; : b8;B< : b9;

ε

A : B8: B9 ;B; : b8;B< : b9;

A : B8 B9 | B9 B8: B8~B9: B8: B9 ;B; : b8;B< : b9;

6q

b1~b2q4 5qε ε

b1~b2ε εq q

4 5

b1~b2ε εq q

6 7

Fe

atur

eM

anda

tory

Opt

ion

alA

ltern

ativ

eO

r

Figure 5.4: Mapping Grammars to Finite State Machines.


Start

q1

q2

a

q3q0q

4

d

b c e

Q: {q0,q1,q2,q3,q4}=: {a,b,c,d,e}


Finite State Machine Definition

FSM: {Q,=,A,q0}

Grammar

S: A | B;A: a d;B: b c e;

A: {(q0,a,q1),(q0,b,q2), (q1,d,q4),(q2,c,q3), (q3,e,q4)}

Figure 5.5: Finite State Machines and its CFG definition.

b1

b2

a. Mandatory

b1

b2

b2

b1

ε

ε

ε

ε

Start q0

q1q2

q3

q6q7

q8

q9

ε

Start q0

q1

q2

ε

ε q3

εb1

q6 q7

b2

q8 q9

b2

q11 q12

b1

q 10

b1

q13

b2

ε ε

ε

ε

ε

ε

q14

Start q0

q2ε q3

εb1

q4 q5

b2ε εq Start q0

q4

εq5

εb1

q8 q9

b2

q10 q11

b2

q1 q2

b1

q12

b1

q3

b2

ε ε

ε ε

q

εε

6

b1~b2q4 5qε ε

b1~b2ε εq q

4 5b1~b2ε εq q

6 7

b1

b2

b. Alternative

13

c. Or

b1

b2

b1

b2

d. Optional

Figure 5.6: BPMN Gateways and its Finite State Machine equivalence.

5.2.3 Mapping a Feature Model to a BPMN Structure

Automata and formal languages theory sets the steps needed to obtain aFinite State Machine (FSM) model from a Context Free Grammar (CFG) andviceversa [29]. Applying this mapping we provide a FSM representation ofthe feature model grammars presented previously. Figure §5.4 presents eachfeature model grammar with its FSM correspondence. In addition, Figure §5.5sketches the equivalence between FSMs and its correspondence CFG repre-sentation used for performing this mapping catalog.

In addition, as shown in Figure §5.6, BPMN artifacts can be represented by


A

B

Expanded

B

A

Expanded

A

B2

A

Expanded

B1

B2

A

Expanded

B1

B2

A

Expanded

B1

A

Expanded

B2

B1

B

A

A

B

A

A

B1 B2

A

B1 B2

Feature Model

Man

dato

ryO

ptio

nal

Alte

rnat

ive

Or

Rel

atio

nshi

ps

A

B1 B2

A

B1 B2

Feature

A

Collapsed

Collapsed

A

Collapsed

A

Collapsed

A

Collapsed

A

Collapsed

A

Business Process Model

Figure 5.7: Feature Model to BPMN Mapping Catalog Proposed.


means of FSMs [11]. Consequently, the equivalence based on which artifactsof BPMN can implement the behavior of a FSM has been explored, conclud-ing that representing a FSM by means of BPMN is feasible. Thus, as statedpreviously in Section §1.3.1.1, the specification of BPMN does not provide anyconstraint about the order of performing subprocesses in any situation. In ad-dition, the BPMN gateways defines that the subprocesses contained in it canbe done as a sequence or parallel under several constraints, presented in Sec-tion §1.3.1.1 too. Thus, the BPMN gateways are feasible to be used for imple-menting proposed finite state machines behavior, as shown in Figure §5.7 thatpresents the equivalence between each feature model represented by meansof FSMs and its representation using BPMN.

5.3 Business Family Domain Engineering

Regarding Chapter §4, Section §4.3, in the Business Family Engineering(BFE) software process there are two main activities, that are briefly definedas follows: Business Family Domain Engineering : where we build the BFEcore architecture, namely Core Process Framework, and the Business FamilyVariability Summary ; and Business Family Application Engineering : wherewe obtain specific business information systems, that are described by meansof execution languages, such as Business Process Execution Language (BPEL).

The main purpose of this section is to provide the software process of theBusiness Family Domain Engineering fragment, shown in Figure §5.8.a. Thissoftware process is composed by three different activities:

• Domain Requirements Engineering: focused on capturing the require-ments of the problem domain,

• Domain Design: focused on exploring the variability of the system andproviding the core architecture, and finally

• Domain Implementation: focused on defining the implementation andtest details of the architecture, such as persistence or presentation layers.

The focus of our research is focused on Domain Requirements Engineeringand Domain Design activities, as shown in Figure §5.8.a. These activities willbe defined below and we implement each stage described in our motivatingexample defined in Section §1.2 for illustrating how to obtain the core archi-tecture of a business family by means of the Business Family Domain Engi-neering proposal. A first overview of these activities is shown as a packagediagram representation in Figure §5.8.b.

5.3. Business Family Domain Engineering 63

Domain Design

>?@ABCDEFGBHE@ECIJKCLBCEEHBCLDEFGBHE@ECIJ>?@ABC>EJBLC >?@ABCM@NOE@ECIAIB?C

P?HE QH?REJJSHA@ET?HUVGJBCEJJ SA@BOWXAHBAYBOBIW ZG@@AHW[SEAIGHE\?]EO ^

_EJIPAJEJM@NOE@ECIAIB?C\?]EOJ

QHEJECIAIB?C\?]EOJ

Domain Requirements Engineering

Requirement Engineer(Analist, Process Engineer …)M]ECIB`W KOE@ECIAHW VGJBCEJJQH?REJJEJ KVQJ [ ^M]ECIB`W ZWJIE@ a?AOJ [ ^M]ECIB`W bJE PAJEJ [ ^>E`BCE IcE P?@NACBEJ AC]BIJ VGJBCEJJ QH?REJJEJ [ ^

M]ECIB`W ZIAUEc?O]EHJ [ ^MCIH?]GRE DEFGBHE@ECIXAHBAYBOBIW \ACALE@ECI [ ^aECEHAIE AC KOBRBIAIB?C >?RG@ECI [ ^P?@NACBEJAC] VGJBCEJJQH?REJJEJ>EJRHBNIB?CKVQJ>EJRHBNIB?CZIAUEc?O]EHJ>EJRHBNIB?C a?AOJ\?]EOJbJE PAJE\?]EOJaO?JJAHW ?`_EH@J

SGCRIB?CAODEFGBHE@ECIJ>EJRHBNIB?C d?CeSGCRIB?CAODEFGBHE@ECIJ>EJRHBNIB?C_HAREAYBOBIW\AIHBf

DEFGBHE@ECIJ

VariabilityAnalysis

Process EngineergYIABC P?@@?CAOBIBEJ [ IcHEEJc?O] ^gYIABC P?HE AC]XAHBAYOEDEGJAYOE hJJEIJ >E`BCBIB?C [ ^>E`BCE A XAHBAYBOBIW ZG@@AHW [ ^XAHBAYBIW\?]EO P?@@?CAOBIW\?]EOZAiE hJJEIJ BCI? A DEN?JBI?HW [ ^

Build a Core Process Framework

Process Engineer>E`BCE IcE _HACJ`?H@AIB?C DGOEJ I?h d?CeP?CIEfI SHEE VQ ZNERB`BRAIB?C [ ^>E`BCE IcE P?@N?JBIB?C [ ^gYIABC VAJBR ZIHGRIGHE ?` IcE P?HE [ ^Ki?OGIB?CSEAIGHE\?]EO VAJBR VQ\?` P?HE>E`BCE IcE Ki?OGIB?C ?` IcE SHA@ET?HU [ ^

Focus of our research

(A) Business Family Domain Engineering Overview

(B) Domain Engineering and Domain Design Packages Definition

Figure 5.8: Business Family Domain Engineering Overview.


5.3.1 Domain Requirements Engineering

The Domain Requirements Engineering activity is focused on identifyingthe set of companies and its business processes that would be members ofthe business family. This step takes into account the traditional requirementselicitation activities of software engineering, and provides as resulting artifactthe documents that reflects this elicitation, where it is included the definitionof each business process and each company. Thus, the activities of this stageare performed by a Requirement Engineer, role that could be played by ananalist, a process engineer, etc. Figure §5.9.a shows the Domain RequirementsEngineering overview. In this stage, the Requirement Engineer performs thefollowing activities:

• Define the Companies and its Business Processes: it is focused on ob-taining a first conceptual description about the companies and its busi-ness processes. It could be done using a free textual specification, seeSection §1.2 for an example, or using a workflow representation of eachidentified business process, such as BPMN. This activity generates twodifferent artifacts: (i) the Companies and Business Processes Definition,that contains the description of the problem domain; and (ii) the Glos-sary of Terms, that contains a terminology summary about the problemdomain.

• Identify Elementary Business Processes (EBPs): it is focused on identi-fying the business processes contained into the Companies and BusinessProcesses Definition artifact, that are considered an EBP. Larman definesin [34] that “one task performed by a person in a place, in an instant,in response to an event business, which adds a quantifiable value to thebusiness and leaves the data in a consistent state is an EBP". The objec-tive of this activity is to filter the processes that define tasks at a very lowlevel, namely atomic tasks, as are those who do not concern us. In addi-tion, this activity will filter those activities that require direct interactionof the user with the system. Thus, this activity generates one artifact: theEBPs Definition, that contains the description of each of them.

• Identify System Goals, Use Cases and Stakeholders: these activitiesare focused on defining the system goals, stakeholders and requirements(functional and non-functional). A goal is an objective the system un-der consideration should achieve and a feature is an end-user visiblecharacteristic of a system. There is an overlap between the goal andfeature definitions that motivates that some authors uses feature mod-els, shown in Section §1.3.2, for describing goals [46]. These goals are


jklmnopq rsltlmnuvqwxyomlyy zv{|lyylyrwzy}lpoml n~l �{t�umoly umkony wxyomlyy zv{|lyyly�{t�umolyumk wxyomlyyzv{|lyyly}ly|vo�no{m �{usy�{klsy�yl �uyl�{klsy(A) Domain Requirements Engineering Overview

(B) Goal Model of “Send Tickets”using Tropos

(C) Use Case Model “Search a Ticket”with two variants using Hallmans and

Pohl proposal

TravelAgent

Search aTicket

<<include>>

Search by

Search byCode

Search byAgency

<< variant>>

<< variant>>

Send Tickets

AND

Create Tickets

Search Tickets

AND

FilterTickets

[Max] Performance

AND

+–rwzy}ly|vo�no{m jklmnopq�qynlt�{usy jklmnopq�yl �uylyjklmnopq�nu�l~{sklvyjmnv{kx|l�l�xovltlmy�uvou�osonq�umu�ltlmn

�s{yyuvq {p�lvty�nu�l~{sklvy}ly|vo�no{m�vu|lu�osonq�unvo��lmlvunlum rso|onuno{m}{|xtlmn

�xm|no{mus�l�xovltlmny}ly|vo�no{m �{m��xm|no{mus�l�xovltlmny}ly|vo�no{m

Figure 5.9: Domain Requirements Engineering Overview and models ob-tained.

obtained from the EBPs identified in the previous step, since to the re-alization of a business process covers a set of goals [3]. However, thereexists other goal-oriented representations, such as Tropos [13, 33] or i*models [31], that can be used too, depending on several factors, such astool support or non-functional requirements graphical representation.Figure §5.9.b sketches the goal model of Send Tickets represented us-ing a Tropos model. In addition, the stakeholders and requirements aredefined by means of use cases. Thus, these activities generates the fol-lowing artifacts: (i) Goal Models ; (ii) Use Case Models ; (iii) Functionaland Non-Functional Requirements Descriptions, in a textual represen-tation by means of templates, as shown in [15, 22], and in a graphicalrepresentation using use cases (the Non-Functional Requirements canbe represented using Tropos, as shown in Figure §5.9.b with the Perfor-mance requirement); and (iv) Stakeholder Descriptions, in a textual rep-resentation. In addition, once these artifacts are obtained, these activitiesgenerate a Traceability Matrix between them. This matrix represents atable that correlates requirements with system goals and with businessprocesses. Roughly speaking, this artifact provides a response for thefollowing questions: What requirements fulfill a system goal? and Whatsystem goals are contained into a business process?.

• Introduce Requirement Variability Management: it is focused on in-creasing the reuse of the artifacts obtained at the previous stage. For


that purpose, some requirement variability techniques has been identi-fied. The use of feature models and/or Tropos for defining system goalsprovides the enough support for representing variability in system goals[63]. The aspects that must fulfill any variability representation of a sys-tem goal are: (i) establish a hierarchical view of the goals; (ii) representvariation points; (iii) represent mandatory, optional and alternative rela-tions; and (iv) provides support for dependencies and cardinalities [53].For representing variability in use cases models, there exists several pro-posals that extends the standard notation of use case diagrams, such asproposed by Gomaa [24] or by Hallmans and Pohl [27], or proposes othernotations and languages, such as COVAMOF [56]. Figure §5.9.c showsan use case diagram using the extensions proposed by Hallmans andPohl. In addition, there exists approaches for representing variability inthe textual representation of use cases too, such as proposed by Bertolino[8] or John and Muthig [30]. We propose a combination of feature mod-els for representing variability in system goals and a modification of thetraditional use case representation, in order to specify variabilities. Thiscombination allows to capture variability and essential activities of a do-main with use cases and to detail common and variable characteristicswith feature diagrams. In addition, both techniques has tool support.

• Generate an Elicitation Document: once is enabled the variability sup-port for the artifacts obtained at the previous steps, the last activity isoriented on generating an elicitation document that contains all the arti-facts. This document is defined by the artifact named Requirements, thatrepresents the output of the Domain Requirements Engineering activityas shown in Figure §5.8.b. It contains all the artifacts generated in theprevious steps.

5.3.2 Domain Design

The Domain Design activity is focused on performing a variability sum-mary of the set of businesses identified at the previous step and on providingthe core architecture of the product line. Figure §5.10 shows the Domain De-sign overview. In this stage, the Requirement Engineer performs the follow-ing activities:

• Define a Variability Summary and Obtain Commonalities: these ac-tivities are focused on obtaining a variability summary from the GoalModel artifact, obtained at the Domain Requirements Engineering stage.For that purpose, there exists several ways to perform a variability sum-mary, but in our approach we propose the derivation of feature models


�� ¡¢ £��¡

¤��¥��¢��¦ §��¨ �� ¡��¢ £�� ¨ �� ¡��§�� ¨ ��£��©��¡�� ª¡¡��¡

¨ ��ª¡¡��¡ ��ª¡¡��¡��«� ª¡¡��¡�� ©�¬ ¡��

§�� ¡�¥��¥�� ®� ¨ �� ®� ¤��¡� �� ©��¡ � � ¯ �°¨ ��¦�± �¬�¥��¥�� ¡ �®�¨ �¬ ¡�� ®� ²« �� ®� ³��´ �µ

�¡�¥±¢ � ¨ ��¤��¡� �� ©��¡¨ �¬ ¡�� ¬�¥��¥�� ²« �� ³�� ¢ £��

Figure 5.10: Domain Design overview.

from system goals [3, 46], since to we can analyze them [7] for obtainingthe commonalities summary needed to perform the following phase. Inaddition, with this analysis we can evaluate the percentage or probabil-ity of occurrence of a feature in a product. If this ratio is high, we canconsider that the feature is part of the core. Thus, we introduce an op-tional commonality threshold for introducing some features/processesinto the core of the product line [44]. Figure §1.4 presents the variabilitysummary of the business family of the case study by means of featuremodeling. In addition, the commonalities summary is provided on Fig-ure §5.11.a using feature models too, and introducing Change Itinerary,Reserve Tickets and Cancel Itinerary into the core of the family by meansof a commonality threshold, as shown in Figure §5.11.b. Notice that if wedid not introduce this commonality threshold this processes would notbe into the core architecture of the business family.

• Obtain Core and Variable Reusable Assets Definition: it is focused onobtaining the reusable assets that are the basis of the core architecture.For that purpose, we analyse the Variability Model and CommonalitySummary artifacts, using the operations defined in [7]. The result of thisanalysis provides the set of reusable assets identified as Core and Vari-able features. Once the reusable assets are obtained, we use the Trace-ability Matrix defined at the Requirements artifact, from the Domain Re-quirements Engineering stage, for obtaining the respective equivalencebetween features and business process. Thus, the reusable assets are de-



Change Itinerary

Cancel Itinerary

Reserve Tickets

Reserve Seats

Book Tickets

Order Trip

Book Seats

Send Tickets

Send Statement


CO

MM

ON

ALI

TY (

%)

Threshold = 80%

(A) Commonality Summary of the case study (B) Commonalities of the case study with a threshold = 80%

Figure 5.11: Commonalities summary of the case study obtained in VariabilityAnalysis represented using feature modeling.

fined by means of business process models. These assets are containedinto the generated artifacts Core and Variable Assets.

• Save Assets into a Repository: finally, once the assets are obtained anddefined by means of a business process model, we save these reusableassets into a repository. The URI of this repository is added into theBusiness Family Variability Summary artifact.

• Obtain the Basic Structure of the Core: it is focused on obtaining a basicstructure of a business process model that represents the core architec-ture. It is represented by the Basic BPM of Core artifact. For that pur-pose, we propose a derivation from the feature model that represents theVariabily Model to a business process model. This derivation is basedon Automata Theory and Formal Languages by means of Context-FreeGrammar Representations [29]. The derivation process provides a map-ping between feature models and business process models that improvesthe design step of the PFE approach by means of improving the main-tainability of feature models and BPMN, and eliminating errors derivedfrom manual transformations. In addition, we avoid the need of extend-ing the standard notation of BPMN with information that is present inthe feature model. Theses mapping rules [37] are defined previouslyat Section §5.2. Thus, the variability aspects identified by the PFE ap-proach, described in Section §1.3.3, can be represented by the featuremodel obtained in the previous variability analysis phase. In addition,these aspects can be represented by means of the standard BPMN with-out providing extra information using stereotypes. Figure §5.12 sketches



( Number of Seats > 50 and < 100 )

or ( Number of Seats

> 100 )

Inform

Inform byE-Mail

Inform by Intranet

Inform

Expanded

Inform

Collapsed

Inform by Intranet

Inform by E-Mail

VariationPoint

Variants

Send Tickets

Send Tickets

Send Information about Trip

Send Info ...

Send Tickets

Expanded

Send Tickets

Collapsed

SendTickets

Book Tickets

Expanded

Collapsed

Quality Assurance

Book Tickets

BookTickets

Quality Assurance

VariationPoint

Variants

ExtensionPoint

Figure 5.12: Variability aspects described by the PFE approach, represented atthe derivation stage of Building Core Process Framework.

all the variability aspects described by the PFE approach, using our de-riving approach: (A) Alternative behavior is represented by an alterna-tive relation on the feature model, defined at Section §1.3.2, where theparent feature is considered the variation point, and the children areconsidered variants [46]; and a gateway Xor of BPMN, which definesthat only one subprocess controlled by this gateway, Inform by e-mailor Inform by Intranet, must be completed for performing the subprocessInform ; (B) Parameterization is resolved by rewriting the condition foraccepting several value ranges; (C) Inheritance is defined by means of anOr relation on the feature model, defined at Section §1.3.2, and a gate-way Or of BPMN, which defines that almost one subprocess controlledby this gateway, Send Tickets and Send Information about Trip, must becompleted for performing the process Send Tickets ; and finally, (D) Ex-tension Points is defined by means of an optional relation at the featuremodel, defined at Section §1.3.2, and an Xor gateway of BPMN with anempty option.

The derivation process requires that the feature model is expressedthrough an specific characterization based on a merge operation betweenthe Commonality Summary and the Variability Model, since to we con-sider the Core Assets as children nodes into to Commonality Summaryfeature model, and the Variable Assets as the variation points of the vari-ability feature model branches that are not contained into the Common-ality Summary. This artifact represents a basic structure of the reusableassets of the business family. In the SPL field the assets are software ar-tifacts. In a business family, the assets are business processes that aredefined by means of their respective process models represented usingBPMN. Figure §5.13.a sketches an overview of the Core Process Frame-work. Each business process contained into the commonality summary


(B) Overview of Non-Overlap Composition between Plan&Book (Core) and Inform

Reusable AssetsRepository

companies.iberia.processes.variable.Inform.bpmn

(A) Overview of Core Process Framework

Plan&Book

Inform

Figure 5.13: Overview of Core Process Framework.

is a considered as a component into the framework. In our case studythe processes named Order Trip, Change Itinerary, Reserve Tickets andCancel Itinerary are the core processes that composes the activity namedPlan&Book. In addition, this framework provides the enough linking ar-eas for adapting specific business process from concretes companies, forexample introducing into an instance of the framework the business pro-cess Inform from Iberia. Figure §5.14 presents the basic structure of theCore Process Framework of our case study in BPMN, obtained from thederivation process.

• Define the Transformation Rules to a Non-Context Free BP Specifica-tion: it is focused on providing the rules needed to build a non-contextfree business process specification. These rules need to be performedmanually by the process engineer. The identified rules are the following:(i) introduce the guards into the gateways that defines the conditions;(ii) identify loops and multiple instances of a subprocess; (iii) introducestart and finalization specific events (message, timer, etc.); (iv) introduceexception handling; and (v) introduce the stakeholders whose are iden-tified at the Requirements Capture stage. This activity generates the ar-tifact that contains these rules, namely Transformation Rules.

• Define the Composition: it is focused on providing the mechanismsneeded to perform a composition of reusable assets into the Core Pro-cess Framework. A composition between two or more business pro-cess models define the order of the execution of each business pro-


Change Itinerary

Cancel Itinerary

Book Tickets

Book Seats

Send Tickets

Send Statement

Verify Seats Availaibility

Airl

ine

Tra

vel A

genc

y

Plan&Book (Core)

Figure 5.14: Basic Structure of the Core Process Framework obtained from thederivation process.

cess to be composed. Notice that we must usually preserve the or-der of execution of each business process model to be composed.We have determined that there exists two different types of businessprocess models composition: Non-Overlap Composition and OverlapComposition. On the one hand, a Non-Overlap Composition is de-fined as a composition between two or more business process mod-els that do not consume or generate any needed artifact for other.Roughly speaking, these business processes could be considered asindependent processes that do not collaborate with anyone, but allthese processes need to be performed for performing a concrete ac-tivity. Figure §5.13.b sketches an example of a Non-Overlap Compo-sition between the Plan&Book process and the Inform process, iden-tified by means of an URL from the reusable assets repository (i.e:companies.iberia.processes.variable.Inform.bpmn). Onthe other hand, an Overlap Composition is defined as a composition be-tween two or more business process models that collaborates betweenthem, in terms of generating and consuming some artifacts betweenthem that rules the dependency from other to perform its activities. Thistype of composition can only be done manually. Nowadays, one of thetopics of our research is focused on providing algorithms for assistingthese kinds of composition and for checking the consistency of the com-posed business process models. For that purpose, we take the algorithms


presented in [43] as starting point for this future work.

• Define the Evolution of the Framework: it is focused on defining theevolving behavior of the Core Process Framework. Roughly speaking,we can consider the Core Process Framework as an evolving system,defining these evolutions as each addition or reduction of some businessprocess models into the core architecture by means of the compositionsdefined at the previous step. Thus, the main difference between the pro-cess framework provided by the PFE approach and our Core ProcessFramework is that PFE defines only one product (core architecture) notvariable, and our approach provides a variable core architecture man-aged as a set of products using SPL techniques. For that purpose, in or-der to represent this variability is needed to define other mechanisms fordescribing the evolving behavior of the architecture. We have exploredthe feasibility of several SPL techniques in [38], and we consider thatthe variability of this architecture can be supported by means of featuremodeling techniques. Thus, this activity generates the artifact that rep-resents these evolutions, namely Evolution Feature Model or ProductEvolution Model (PEM), which provides enough support for analysisand visualisation of runtime variability [40].

Chapter 6

Business Families ChoreographiesDesign

P rocess choreographies describe the interaction of multiple business pro-cesses and, as such, are an important concept for supporting Business-

to-Business (B2B) collaborations. Thus, modeling choreographies is consid-ered a core need for designing Business Information Systems.

In this chapter, a preliminary proposal for modeling choreographies in thecontext of Business Family Engineering (BFE) is defined. Our approach is fo-cused, on the one hand, on propose a choreography model based on an UML2profile used on the Agent-Oriented Software Engineering (AOSE) field thatmakes feasible the variability support. Section §6.2 presents our proposedmodel. On the other hand, in Section §6.3, we provide a transformation be-tween this choreography model and BPMN elements for improving the designof business families. As result of our contribution, we obtain a representationof collaboration scenarios and behavioral interfaces automatically, that can beimplemented by means of the Web Service Choreography Interface (WSCI)specification.

74 Chapter 6. Business Families Choreographies Design

6.1 Introduction

As shown in Chapter §1, Section §1.3.1.2, in the Business Driven-Development (BDD) field, and specially in Service-Oriented Computing(SOC), choreography models are acquiring a special importance. A choreogra-phy lists all possible interactions between a set of business partners, togetherwith the behavioral constraints between them. Thus, choreography modelsrepresents the observable behavior of business partners defined by means ofinteraction 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 BusinessFamily, maximizing reuse and dealing with variability on business processdefinitions, including the notion of interacting processes.

However, current proposals for modeling these interactions, by means ofchoreography models, does not provide any support for introducing thesevariability 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 variabil-ity support, shown in Section §6.2; and in the other hand, in Section §6.3, weprovide a transformation between this choreography model and BPMN ele-ments for improving the design of business families, by means of the BusinessFamily Engineering (BFE) approach.

6.2 Choreography Modeling in BFE

Modeling choreographies is considered a core need for designing BusinessInformation Systems (BIS). However, there not exists an standard notationfor that purpose. Latest drafts for BPMN 2.0. specification †1, explores newnotations for representing it, since to some drawbacks has been identified onmodeling choreographies using the current BPMN specification [20]. A draftspecification model based on Decker et al. works [18–20] has been proposed ofBPMN 2.0. It has not been included on lastest BPMN 1.x official specifications.

Figure §6.1 sketches the Order Trip subprocess choreography model usingthe proposed models in BPMN 2.0. It represents a collaboration between threedifferent participants named: Traveler, Travel Agent and Airline ReservationSystem. The initiator partner of each collaboration is denoted by means of agray-colored background. In addition, each of them specify the message send


6.2. Choreography Modeling in BFE 75

Travel Agent

Traveler

TravelRequest

Travel Agent

Traveler

HandlePreferencies


Give meyour preferencies

Cheapest price

Airline Reservation

System

Travel AgentVerify SeatsAvaliability

Search seatsfor trip andpreferences

Travel Agent

Traveler

TripRequest

Here is your trip

Figure 6.1: Order Trip subprocess Choreography Model using BPMN 2.0.

to the other partner. The Order Trip subprocess is composed by means offour activities, previously identified by the process engineer as an ElementaryBusiness Process (EBP) [34] and four use cases in the Domain RequirementsEngineering activity defined in Chapter §5, Section §5.3.1. Concretely, usecases are: Travel Request, Handle Preferences, Trip Request and Verify SeatsAvailability, identified too as another EBP.

However, although this notation is valuable, it is not currently consideredpart of the BPMN specification. In addition, there not exists any approach thatdeals with variability aspects on choreography modeling, needed for perform-ing business families.

In Business Family Engineering (BFE), each member of the family is avariant-rich BIS. Thus, regarding the activities needed for develop a choreog-raphy model, described Chapter §1, Section §1.3.1.2, we must define a chore-ography model that makes feasible to deal with this variability support. Ourproposed model is only focused on:

• High-level Structure Design: in this activity the participant roles as wellas their communication structures are identified. These participants hasbeen previously identified in the Domain Requirements Engineering ac-tivities.

• High-level Behavioral Design: this activity is focused on specifying thegoals, also named milestones of the collaboration and the order in whichthe goals are reached. These goals has been previously identified as fea-tures in the Domain Requirements Engineering activities by the processengineer too.


Order TripGoal: Manage a preferred trip request

Pattern : Collaboration

In: Data: Out:

Traveler

Airline TravelAgency

Traveler

Airline TravelAgency

1..*

1..*

Travel Agent

Travel Agent

1..*

Role Goal : Planning on taking a tripTravel Request Goal : Requesting a travelHandle Preferencies Goal : Submitting trip preferenciesTrip Request Goal : Analysingtravel agent plan

Traveler

itinerary : Titinerarypreferencies : TPreferencies

validateTravel (travel:Ttravel): boolean

Role Goal : Provide a travel planTravel Request Goal : Receiving a travel requestHandle Preferencies Goal : Requesting trip preferenciesTrip Request Goal : Providing a travel planVerify Seats Availability : Requesting seats

Travel Agent

Role Goal : Provide a reservation serviceVerify Seats Availability : Verifying submitted seats

Airline Reservation System

verifySeats(nSeats : Integer , itinerary : Titinerary , preferencies : Tpreferencies ): Collection[Tseats]

<< environment >>

createTravel (itinerary : Titinerary , preferencies : Tpreferencies , seats: Collection[Tseats]): Travel

Travel RequestGoal: Manage a travel request


In: Data: Out:Traveler.itinerary

Traveler. msg1

TravelAgent:msg1

Traveler

1..*

Travel Agent

1..*

HandlePreferencies

Traveler. msg2

Goal : Manage a preferencies request

Pattern : CollaborationIn: Data: Out:

Traveler.preferencies

Traveler

1..*

Travel Agent

1..*

Trip Request

Travel Agent: msg3

In:

1..*

Traveler

Goal : Manage a trip request


Data:TravelAgent.travel

Out:

Travel Agent

1..*


Goal: Verify seats availabilityfor a preferred plan


In: Data: Out:

Travel Agent

1..*

Airline Reservation

System

1..*

TravelAgent:msg2

TravelAgent:data

<< environment >>

TravelAgent:data

ARS.Seats

Figure 6.2: Order Trip Choreography.

6.2. Choreography Modeling in BFE 77

Once these designs has been performed, our proposed model allows toprovide automatically the collaboration scenario and the behavioral interfacefor each participant in BPMN, needed to represent a choreography and to im-plement it into a WSCI specification:

We propose a choreography model based on an UML2 profile used onAgent-Oriented Software Engineering (AOSE) field. The AOSE profile used inthis approach is the MaCMAS/UML profile [41]. MaCMAS is a methodologythat has been developed to deal with complex Software Systems, also namedMulti-Agent Software Systems (MAS). A MAS organization can be observedfrom two viewpoints:

• Acquaintance point of view: shows the organization as the set of inter-action relationships between the roles played by agents

• Structural point of view: shows agents as artifacts that belong to sub-organizations, groups, teams. In this view agents are also structured intohierarchical structures showing the social structure of the system.

To the best of our knowledge, this is the only modeling approach able torepresent variability aspects introducing Software Product Line (SPL) tech-niques, such as combining it with feature modeling [44], without extendingcurrent notations, such as i* [63]. In addition, preliminary works has been pre-sented introducing this model into the Business-Driven Development (BDD)field [9, 23] but without providing a complete transformation catalog betweenthis model and BPMN.

Thus, we define the Order Trip choreography by means of the models pro-vided by means of this AOSE approach, as shown in Figure §6.2. Once thechoreography model is defined by means of this profile, MaCMAS/UML pro-vides a representation of the static interaction relationships between roles inthe system and the knowledge processed by them. This interaction is definedby means of multi-Role Interactions (mRI) models defined in [42]. These mRIsare used to abstract the acquaintance relationships amongst roles in the sys-tem. As mRIs allow abstract representation of interactions, we can use thesemodels at whatever level of abstraction we desire. At top of Figure §6.2, weprovide a high abstraction mRI model of Order Trip subprocess, and at bottomof same figure we provide a more detailed mRI model of the same subprocessproviding the mRIs of Travel Request, Handle Preferences, Trip Request andVerify Seats Availability. In addition, this profile provides support for identi-fying the goal of each partner, defined by means of the Role Goal attributes,and the point of view of the behavioral interface by means of the stereotype�environment�.


6.3 Transformation Catalog

Our transformation approach between choreography models described us-ing MaCMAS and BPMN is focused on providing a catalog composed in threecategories:

• Data Objects Exchange in our Pool: focused on techniques for modelingthe exchange of data objects between the processes of a concrete pool.Figure §6.3 sketches the catalog proposed for this category.

• Data Objects Exchange between Pools: focused on techniques for mod-eling the exchange of data objects between several pools. Figure §6.4sketches the catalog proposed for this category.

• Message Exchange: focused on techniques for modeling the exchangeof messages between pools. Figure §6.5 sketches the catalog proposedfor this category.

Applying this catalog to the Order Process choreography model we obtainthe behavioral interface presented in Figure §6.6.b. Note that this is a prelimi-nary first step and the state of our research in this context is not enough maturefor providing a collaboration scenario, such as presented in Figure §6.6.a, butseveral mapping relationships has been detected and the definition of theserelations is considered a future work in our research. In addition, providinga tool support for this transformation, as proof of concepts, is considered an-other open issue into our research work as shown in Figure §6.7. Variabilitysupport is inherited from agents methodologies and several composition tech-niques for runtime variability has been identified in [42]. For each evolutionof the business information system, a composition between the choreographymodel of the core process framework and the added/deleted subprocessesmust be performed for obtaining a new WSCI implementation for this prod-uct. Defining this process is considered a future work of our research too.

6.3. Transformation Catalog 79

mRI Model Business Process Model

A

Y

data

... ...

A

Data: Out:

Goal:Pattern: Collaboration

Role Goal : A Goal:B Goal:

Y1..* Y

In:Y.data

B

Data:

Goal:Pattern: CollaborationIn:

Y.data

1..*Y

Out:

B...


A

Y

... ...

data

A

Data: Out:


Y.data

Role Goal : A Goal :

Y

1..* Y

Figure 6.3: Data Object Exchange in our Pool.


A

Y

data

... ...

A

Data: Out:


Role Goal : A Goal:B Goal:

Y1..* Y

In:Y.data

B

Data:


Y.data

1..*Y

Out:

B ...



A

Data:

Goal:

Pattern: Collaboration

X

1..*X

X.data

In:

Role Goal : A Goal:

Out:

<< environment >>

A ......

X

in

data

X.in

Role Goal: B Goal:

X1..* X << environment >>

in

X

Figure 6.4: Data Object Exchange between Pools.

6.3. Transformation Catalog 81


A

Data: Out:

Goal:

Pattern: Collaboration

X

X

1..*X

X.in X.data

in

data

A

In:

A

Data: Out:


Role Goal : A Goal:

Y

Y

1..*


X<< environment >>

1..* X

X

SendA

In:Y.out

Y

out

<< environment >>

A

Data: Out:


Role Goal : A Goal:

Y

Y

1..*


X<< environment >>

1..* X

X

in

data

SendA

In:X.in X.data Y.out

Y

out

Figure 6.5: Messages Exchange.


TravelRequest

Traveler

Trav

el A

gent

Itinerary


Give me your

preferencies CheapestPrice

Preferencies

Handle Preferencies

Verify SeatsAvailability

Airline Reservation System

Search seatsfor trip and preferences

DataSeats

Trip Request

Travel

Here is your trip

Travel Agent

Traveler

Travel Request

Handle Preferencies

Airline Reservation

System

Verify SeatsAvailability

TripRequest

(A) Collaboration Scenario of Order Trip subprocess from our case study

(B) Behavioural interface for Travel Agent

Figure 6.6: Collaboration and Behavioral Interface obtained from the Transfor-mation Catalog.


A

Y

... ...

dataA

Data: Out:


Y.data

Role Goal : A Goal:

Y1..*

Y

rule DataFlowPattern1 {from m: macmas!MultiRoleInteraction (m.dataFlowPattern 1()) ;to d:bpmn!DataObject ( name <- m.out.name ), b:bpmn!Activity( name <- m.name, ) a:bpmn!Association ( source <- b, target <- d )}

module mRIModel2BPMcreate OUT : bpmn IN : macmas---- helper function macmas !MultiRoleInteraction dataFlowPattern 1() : Boolean-- @description : Returns a boolean value true is the MultiRoleInteraction produces a data output--helper context macmas!MultiRoleInteraction def : dataFlowPattern1() : Boolean =

if self.out .type.toString() = ‘data’ then true else false endif ;

Figure 6.7: ATL definition of mapping between MaCMAS and BPMN.

Part IV

Contributions

Chapter 7

Contributions

D uring our research work and before writing this report some prelim-inary contribution were made. The main purpose of this chapter is

to provide a brief description of those contributions.

Section §7.1 summarises the relevant publications grouped by the con-text of the conference where they were presented. For each one, its abstract,quality level of the conference and citations are provided. Additionally, inSection §7.2, other contributions are described. Concretely, a Model Driven-Development (MDD) transformation that was implemented as a proof of con-cepts of this research work, that is available into the context of the EclipseM2M Transformation Project†1. Finally, in Section §7.3, we provide a sum-mary of our contributions classified according to the year of publication andthe topic, and our future work in Section §7.4.

†1http://www.eclipse.org/m2m

86 Chapter 7. Contributions

7.1 Relevant Publications

7.1.1 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 [37].

Abstract: The variability level of average-size Business Information Sys-tems (BIS) is highly enough for making the design of this kind of sys-tems a complex task. There is an approach called Process Family Engi-neering (PFE) that tries to ease the design of BIS using ideas from theSoftware Product Lines (SPL) field. Roughly speaking, they propose to,first, study the variability of the system without entering into details bymeans of building a variability model (called feature model), that is usedlater for building the business process. However, in PFE the process ofderiving the business process from the feature model is performed man-ually. Authors use feature models with a different meaning that is com-monly accepted in SPL. In this paper, we provide a rigorous descriptionfor the new meaning of feature models, and a mapping relationship thatdefines how to use the information in the FM for obtaining the basicstructure of the business process. In addition, as a proof of concepts, wehave implemented an MDD transformation that provides the expectedresults.

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

• Representing Runtime Variability in Business-Driven DevelopmentSystems: I. Montero, J. Peña, A. Ruiz-Cortés. 7th IEEE Int. Conf.on Composition-Based Software Systems (ICCBSS). 228–231. Madrid,Spain. 2008 [38].

Abstract: Business-Driven Development(BDD) is a research field thatprovides techniques and mechanisms for designing software systemsstarting from the business processes of the companies. Companies arein continuous evolution to adapt to market changes, thus, current pro-cess engineers redesign the processes every time that is needed using adhoc techniques. This situation motivates that these changes, called run-time variability, must be managed. Some authors have used SoftwareProduct Lines (SPL) ideas to manage it. Current approaches for docu-menting runtime variability in SPL and BDD, proposes different modelrepresentations. Unfortunately, we have determined that the expressive-

7.1. Relevant Publications 87

ness level in BDD is not adequate, and that SPL solutions needs for adap-tation to BDD context for describing under which circumstances a busi-ness evolves. In this paper, we present a model for representing runtimevariability in BDD systems. The main contributions of this proposal are:(i) it presents the enough expressiveness level for representing runtimevariability; and (ii) process engineers can represent and understand un-der which events a business evolves and how this evolution is managed,which is not present in current approaches. We call this approach Prod-uct Evolution Model (PEM).

Quality Levels: Acceptance Rate: 33%, IEEE Core: B

Citations:

� Modeling the Variability Space of Self-Adaptive Applications: G.Perrouin, F. Chauvel, J. DeAntoni, J. Jézéequel. IEEE Computer So-ciety 2nd International Workshop on Dynamic Software ProductLines (DSPL 2008, Volume 2), in conjunction with SPLC08, 15–22,Limerick, Ireland, 2008.

• Representing Runtime Variability in Business-Driven DevelopmentSystems - Poster: I. Montero, J. Peña, A. Ruiz-Cortés. 7th IEEE Int. Conf.on Composition-Based Software Systems (ICCBSS). 241. Madrid, Spain.2008. [39].

Abstract: Current approaches for documenting runtime variability inSoftware Product Lines (SPL) and Business Driven-Development, pro-poses different model representations. Unfortunately, we have deter-mined that the expressiveness level in BDD is not adequate, and thatSPL solutions needs for adaptation to BDD context for describing un-der which circumstances a business evolves. In this panel, we presenta model for representing runtime variability in BDD systems. The maincontributions of this proposal are: (i) it presents the enough expressive-ness level for representing runtime variability; and (ii) process engineerscan represent and understand under which events a business evolvesand how this evolution is managed, which is not present in current ap-proaches. We call this approach Product Evolution Model (PEM).

Quality Levels: Acceptance Rate: 33%, IEEE Core: B


7.1.2 International Workshops

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

Abstract: There is a set of techniques that build Business InformationSystems (BIS) deploying business processes of the company directly ona process engine. Business processes of companies are continuouslychanging in order to adapt to changes in the environment. This kind ofvariability appears at runtime, when a business subprocess is enabledor disabled. To the best of our knowledge, there exists only one ap-proach able to represent properly runtime variability of BIS using Soft-ware Product Lines (SPL), namely, Product Evolution Model (PEM). Thisapproach manages the variability by means of a SPL where each prod-uct represents a possible evolution of the system. However, althoughthis approach is quite valuable, it does not provide process engineerswith the proper support for improving the processes by visualising andanalysing execution-time (non-design) properties taking advantage ofthe benefits provided by the use of SPL. In this paper, we present ourfirst steps towards solving this problem. The contribution of this paperis twofold: on the one hand, we provide a visualisation dashboard forexecution-traces based on the use of UML 2.0 timing diagrams, that usesthe PEM approach; on the other hand, we provide a conceptual frame-work that shows a roadmap of the future research needed for analysingexecution-time properties of this kind of systems. Thus, due the use ofSPL, our approach opens the possibility for evaluating specific condi-tions and properties of a business process that current approaches donot cover.

Citations:

� From Static to Dynamic Software Product Lines: K. Schmid, H.Eichelberger. IEEE Computer Society 2nd International Workshopon Dynamic Software Product Lines (DSPL 2008, Volume 2), in con-junction with SPLC08, Limerick, Ireland, 2008.

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

7.1. Relevant Publications 89

2007 [36].

Abstract: Nowadays most companies in whichever field have a soft-ware system that helps managing all the aspects of the company, fromthe strategic management to daily activities. Companies are in continu-ous evolution to adapt to market changes, and consequently, the Infor-mation Technology (IT) infrastructure that supports it must also evolve.Thus, software companies are currently supporting this evolution withad hoc techniques. We think that, as it is being done for traditional soft-ware systems (non-oriented to business process) in the software prod-uct line (SPL) field, institutionalized techniques for performing a sys-tematic reuse of business processes across different businesses can beintroduced. In this paper, we propose to adapt SPL techniques, orientedto reuse software, to Business-Driven Development (BDD), oriented toreuse processes, across different businesses; we call this proposal Busi-ness Family Engineering (BFE). We present a first approach to build aSPL of BDD systems that evolves at runtime.

7.1.3 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 delSoftware y Bases de Datos (JISBD). 1er Taller de Procesos de Negocioe Ingeniería del Software (PNIS). II Congreso Español de Informática(CEDI 2007). Pag. 34-40, Zaragoza, España. 2007 [35].

Abstract: Nowadays most companies in whichever field have a soft-ware system that helps managing all the aspects of the company, fromthe strategic management to daily activities. Companies are in continu-ous evolution to adapt to market changes, and consequently, the Infor-mation Technology (IT) infrastructure that supports it must also evolve.Thus, software companies are currently supporting this evolution withad hoc techniques. We think that, as it is being done for traditional soft-ware systems (non-oriented to business process) in the software prod-uct line (SPL) field, institutionalized techniques for performing a sys-tematic reuse of business processes across different businesses can beintroduced. In this paper, we explore the feasibility of adapting SPLtechniques, oriented to reuse software, to Business-Driven Development(BDD), oriented to reuse processes, across different businesses; we callthis approach Business Family Engineering (BFE). As a result of ourstudy, we show some of the problems we have identified and some ofthe key aspects needed to enable this new field.


Figure 7.1: Tool Support.

7.2 Other Contributions

7.2.1 Eclipse M2M Transformation Project Contribution

The Eclipse Model to Model (M2M) Transformation project†2 is focusedon providing a framework for Model-Driven Development (MDD) model tomodel transformation languages. Nowadays, there exist three transformationengines that are developed in the scope of this project. One of this transforma-tion engines is the ATLAS Transformation Language (ATL) †3.

We have performed a transformation between the FeAture Model Ana-lyzer (FAMA) †4 metamodel as source and the Eclipse SOA Tool Platform2BPMN metamodel †5 as target metamodel using the ATL language. Figure

†2http://www.eclipse.org/m2m†3http://www.eclipse.org/m2m/atl†4http://www.isa.us.es/fama†5http://www.eclipse.org/stp

7.3. Summary of Contributions 91

Context No Publications DBLP

International Conference 3 3

National Conference 0 0

International Workshop 2 1

National Workshop 1 0

Other 1 0

Table 7.1: Summary of Contributions.

§7.1 presents an screenshot of this contribution. It has been published on theEclipse ATL Transformation Scenarios zoo. ATL code and specification is de-scribed in the following research report:

• ATL Transformation: Feature Models for representing runtime vari-ability in BIS to Business Process Model Notation. I. Montero, J. Peña,A. Ruiz-Cortés. ISA Research Group Report, 2008.

Abstract: The FM to BPMN example describes a transformation froma feature model for representing runtime variability in business infor-mation systems created using FAMA (FeAture Model Analyzer) into abusiness process model diagram represented by means of BPMN meta-model provided by the Eclipse STP (SOA Tool Platform) project.

Eclipse URL:http://www.eclipse.org/m2m/atl/atlTransformations/#FM2BPMN

ISA Research Group URL:http://www.isa.us.es/index.php?module=52&action=singlenews&idN=8

Screencast:http://www.isa.us.es/uploads/screencasts/demo.htm

7.3 Summary of Contributions

A summary of our contributions is presented in Table §7.1. Rows show thedifferent research contexts in which our contributions were presented. The


Implementation Layer

- Tool support (ATL, Eclipse SOA Tool Platform)

- UML 2.1 Timming Diagrams

Operational Layer

- Business Driven Development

- Software Product Lines

- Model Driven Development

- Agent Oriented Software Engineering

Abstract Layer

- Automata Theory and Formal Languages

Characteristic Layer

- BPMN

- WSCI

2007 2008 2009

SCC’ 08 BPM’ 09

VAMOS’ 08

ICCBSS’08

ICCBSS’08

SCC’ 08

BPM’ 09

ICCBSS’08

BPM’ 09

SCC’ 08

PNIS’07

PNIS’07

DSPL’07

DSPL’07

SCC’ 08

1 International Workshop1 National Workshop

VAMOS’ 08

2 International Conferences1 International Workshop

1 International Conference

Figure 7.2: Summary of Contributions.

number of publications in each context is showed in the second column. Fi-nally, the last column show the number of these contributions which are pre-sented in an DBLP listed conference.Finally, a more detailed summary of our contributions is presented in Figure§7.2. It classifies our contributions according to the year of publication (verti-cally) and the topic (horizontally). For each publication, an small circle (dottedlines means a publication under construction) is presented together with theacronyms of the paper.

7.4 Future Work

Taking into account our proposed holistic research framework defined inChapter §1, Section §1.5, we provide, in Figure §7.3, a brief summary aboutthe number of contributions that explores at least one of the defined layers.Our efforts in future work, must be focused on providing a formal definitionof our approach supported by terms identified in the abstract layer of ourframework.

7.4. Future Work 93

Abstract Layer( Automata Theory and Formal Languages,

Context-Free Grammars, Finite State Machines, …)

Operational Layer( Business Driven Development, Software Product Lines,

Model Driven Development, Agent Oriented Software Engineering)

Implementation Layer(ATL, Eclipse SOA Tool Platform, …)

Characteristic Layer( BPMN, WSCI, BPEL)

2 contributions published, 1 contribution under construction



1 contribution published

Figure 7.3: Total of contributions by defined layers in our holistic framework.

Regarding our hypothesis and research questions, we must conclude thefollowing issues for future work:

• Business Families. Does it makes sense? : The answer is that businessfamilies are feasible. Its main benefit is that software companies that pro-vide BDD solutions, can reuse process in a systematic way, thus reducingcosts (in time and money) and improving the quality of their products,since they are tested for several clients. We explore this topic in [35],thus, this issue is closed, but we are planning to elevate this discussionto higher research communities, as for example the BPM conference†6.

• The Software Product Line (SPL) field has a lot of benefits and BusinessProcess Management too, How many benefits have SPL and BPM to-gether? : Nowadays, we have explored in [36] and [38] that the mainbenefits of SPL and BPM together are focused on increasing the reusabil-ity level of the business process definitions, and in addition, providing amodel for representing runtime variability in BIS. Future work plannedfor this issue is focused on formalizing our proposal for representingruntime variability in BIS, and integrating it into proposals for improv-ing the development of self-adaptative applications, such as [45].

• How many approaches explores the idea of introduce SPL techniquesin the Business-Driven Development (BDD) field? : We have identifiedsome approaches that explores how to increase the reusability of busi-ness process definitions, but, to the best of our knowledge, there ex-ists only one approach, called Process Family Engineering (PFE), which

†6http://www.bpm2009.org


propose the use of SPL techniques. We have explored this approach inseveral contributions [35, 36, 38, 40], and an improvement of its designphase has been proposed in [37]. Once this issue is closed, a surveyshould be performed and submitted to an international conference orjournal as future work.

• What kind of variability aspects can be performed on defining businessprocesses? : On exploring the PFE approach, we have explored the vari-ability aspects identified by this approach. However, although this pro-posal provides a concrete set of variability aspects, some activities suchas requirements engineering in the context of Business-Driven Develop-ment are not taking into account. Our future work is to identify newvariability aspects and clasify them in order to provide a best support ofthem by means of our approach.

• How many approaches provides variability support on designing Busi-ness Information Systems (BIS)? : Nowadays, to the best of our knowl-edge, only PFE provides variability support. In addition, a proposalwhich describes the feasibility of the equivalence between feature mod-els and business process modes is explored [3]. We have proposed an au-tomated transformation between both models, based on several abstractfoundations, such as automata theory and formal languages in [37]. Inaddition, this issue is covered in this research report. Thus, it is closed.

• How many kinds of variability are present in the definition of a BIS andhow are them represented? : We have identified at least two kinds ofvariability, static and dynamic variability, also named design-time andruntime variability. Current approaches for supporting variability in thedefinition of BIS, only takes into account the static variability. We haveproposed a model for representing runtime variability without extend-ing the standard BPMN notation in [38], and our future work is to inte-grate it into our approach. In addition, we have proposed too, a visual-isation technique of this kind of variability and a research roadmap foran analysis framework in [40]. These proposals are in a very preliminarstage, and they should be revised and refined as future work.

• How many current proposals for modeling choreographies deals withvariability aspects? : To the best of our knowledge, there not exists anyapproach for modeling choreographies that deals with variability as-pects. We take [23] as starting point of our research. A proposal for achoreography model for designing business families and for integratingit into our approach is one of our most recent open issues.

• How many current proposals for modeling choreographies provides anautomated treatment for obtaining collaboration scenarios and behav-

7.4. Future Work 95

ior interfaces? : Current proposals does not provide support for an au-tomated transformation from a choreography model to a collaborationscenario and behaviour interfaces. Thus, due to we take [23] as startingpoint for defining a choreography model, and it is based on an UML2.0profile defined by its metamodel, Model-Driven Development (MDD)techniques should be applied for obtaining the desired target models. Inaddition, resulting models must not present any known drawbacks inchoreography modeling defined in [20].


Chapter 8

Conclusions

T his research report represents a preliminary study about how to de-velop families of Business Information Systems (BIS) in the context of

the Service-Oriented Computing (SOC) field. With this purpose, in Chapter§1, we have presented first our research context and our hypothesis and re-search questions that drives our research. In Chapters §2 and §3, we have re-vised the state of the art in the context of our research, concretely, the introduc-tion of Software Product Lines (SPL) techniques into the Business-Driven De-velopment field, and the variability modeling of business process designs. Af-ter that, we provide our preliminary proposals for performing families of Busi-ness Information Systems, what we call Business Family Engineering (BFE), inChapters §4, §5 and §6 ; and finally, we provide a brief description of our re-search contributions and future work in Chapter §7. Thus, the main purposeof this chapter is to clarify our conclusions.

98 Chapter 8. Conclusions

8.1 Conclusions

This research report states that for increasing the business process defini-tions reusability and improving the design of Business Information Systems(BIS) is feasible by means of defining a Software Line Infrastructure. We sum-marise the main contributions of our research as follows:

• Business Families and Business Family Engineering: we propose anew concept into the Business-Driven Development (BDD) context fo-cused on define a set of Business Information Systems (BIS) which sharescommon business processes definitions. The main conclusion is thatbusiness families are feasible and it provides several advantages to im-prove the process engineers activities [35, 36]. In addition, we define amethodology for performing business families named Business FamilyEngineering.

• Variability Modeling of Business Information Systems: we provide toprocess engineers several techniques and models for representing (staticand dynamic - also named runtime ) variability in Business InformationSystems without the need of extending current standard notations [37,38]. In addition, our proposal makes feasible to visualise and analysevariability in this context [40].

• From Feature Models to Business Processes: we improve the designstep of the Process Family Engineering (PFE) approach, providing asystematic transformation between feature models and business processdefinitions in BPMN. As proof of concepts, we develop this transforma-tions by means of Model-Driven Development (MDD) tools, and it hasbeen included into an official Eclipse project repository.

• Dealing with Variability on Choreography Modeling: we propose achoreography modeling technique based on an UML profile from theAgent-Oriented Software Engineering (AOSE) field, that makes feasibleto deal with the implicit variability of business families. In addition, apreliminary transformation catalog between this model and BPMN in or-der to obtain collaboration scenarios and behavioral interfaces has beenproposed.

Our future work must be focused, on the one hand, into the open issues iden-tified in previous chapter, concretely on Section §7.4, and on the other hand,on to remark our novel position on providing a methodology fragment thatmakes feasible the development of families of Business Information Systemsinto the Service-Oriented Computing context.

Part IV

Appendix

Appendix A

Relevant Publications

I n this appendix, we present two published contributions that provides ourfirst steps to represent variability in Business Information Systems (BIS)

and to improve the Process Family Engineering (PFE) approach. In addition,we provide another paper under construction which define the methodologyfragment of Business Family Engineering (BFE).

The first paper has been published in the proceedings of the IEEE Confer-ence on Services Computing (SCC 2008). This conference has been ranked inthe A category in the CORE ranking. The second paper has been publishedin the proceedings of the Seventh International Conference on Composition-Based Software Systems (ICCBSS 2008). This conference has been ranked inthe B category in the CORE ranking. Finally, last paper is under construction,and is planned to be sent to the International Conference on Business ProcessManagement (BPM). This conference has been ranked in the A category in theCORE ranking.

From Feature Models to Business Processes∗

Ildefonso Montero, Joaquín Peña, Antonio Ruiz-CortésDepr Lenguajes y Sistemas Informáticos. University of Seville. Spain

{monteroperez, joaquinp, aruiz}@us.es

Abstract

The variability level of average-size Business Informa-tion Systems (BIS) is highly enough for making the designof this kind of systems a complex task. There is an approachcalled Process Family Engineering (PFE) that tries to easethe design of BIS using ideas from the Software ProductLines (SPL) field. Roughly speaking, they propose to, first,study the variability of the system without entering into de-tails by means of building a variability model (called featuremodel), that is used later for building the business process.

However, in PFE the process of deriving the businessprocess from the feature model is performed manually. Au-thors use feature models with a different meaning that iscommonly accepted in SPL. In this paper, we provide a rig-orous description for the new meaning of feature models,and a mapping relationship that defines how to use the in-formation in the FM for obtaining the basic structure of thebusiness process. In addition, as a proof of concepts, wehave implemented an MDD transformation that providesthe expected results.

1 Introduction

The development of Business Information Systems (BIS)is focused on providing techniques and mechanisms for de-signing software systems based on the business processesof the companies, defined graphically by means of busi-ness process modeling notations, such as Business Pro-cess Model Notation (BPMN) [4]. The variability level ofaverage-size BIS is usually highly enough for making thedesign of this kind of systems a complex task.

Software Product Lines (SPL) systematizes the reuseacross the set of similar products that a software companyprovides. For that purpose, this approach requires to de-

∗This work has been partially supported by the European Commission(FEDER) and Spanish Government under CICYT project Web-Factories(TIN2006-00472), Andalusian Government project ISABEL (TIC-2533),and under a scholarship from the Education and Universities Spanish Gov-ernment Secretariat given to the author Ildefonso Montero.

RequirementsCapture

Representing Variability by

Feature Modelling

Derive manually a Business Process

Model

Deploy Business Process Model into a process

engine

Requirements Feature Model Business Process Model Business Information

SystemOur approach


Automatic Derivation of

Business Process Models

Design

Basic Structure of a


Figure 1. Overview of the PFE approach formodeling BIS and our approach

scribe the products by means of variability models, such asFeature Models (FM), that contains only features and rela-tionships between them. A feature is considered as a char-acteristic of the system that is observable by the end users.Feature Models describe which features are present in allthe products, called core features, and which not, calledvariable features.

Schnieders et al. propose a methodology for designinghighly variable business processes [9]. It is based on over-coming the complexity derived from variability, by meansof applying software product lines for managing it. Thismethodology, called Process Family Engineering (PFE),presents three steps for modeling variant-rich BIS, as shownin Figure 1, namely: (i) Analysis, which is focused on per-forming a requirements capture that covers the user needsand describes the variability using feature models; (ii) De-sign, which is focused on deriving manually a business pro-cess model from a feature model that represents its variabil-ity; and finally (iii) Implementation, which is focused on de-ploying the business process model specification into a pro-cess engine that executes it and produces a BIS. Thus, PFEreduces the complexity derived from variability by meansof studying features models that do not provide details onhow each process is performed.In addition, PFE considersthat sometimes a feature represents an activity, sometimesa business process, but without providing an equivalencedefinition. Thus, we can say that in PFE there not exist a

Ildefonso

Text Box

BibTex

http://yourtask.webcindario.com/yourtask/doc/montero-papers/montero-scc08.bib

mapping relationship between feature models and businessprocess models (see Section 2).

However, although PFE may be the solution to man-age the evolution of the business process of a company,the Design step of this approach, concretely the use of fea-ture models and the derivation of business processes fromit, presents three main drawbacks, which are the focus ofthis paper. First, ambiguity: PFE uses feature models toshow the variability derived from enabling/disabling fea-ture/process; however, given that feature models are de-voted to represent design-time variability and not runtimevariability [8][6], the approach redefine the semantics offeature models implicitly, but without providing a defini-tion for it. Second, maintenance: PFE extends the nota-tion of BPMN to add information about variability whichis also present in the feature models, thus, informationis duplicated with the obvious problems for maintenance.Third, manual derivation: the relationship between a fea-ture model and its corresponding business process is notrigorously defined, and the development of the businessprocess is performed manually using as input the featuremodel, what makes this activity error-prone and hinders themaintainability of both kind of models.

Thus, the main motivation of this paper is to improve thedesign step for modeling highly variant-rich business pro-cess models proposed by PFE. For that purpose, we providea rigorous description for the new meaning of feature mod-els, presented in Section 2, and mapping relationship thatclearly defines how to use the information in the FM for ob-taining the basic structure of the BP (that needs to be com-pleted manually), detailed in Section 3. As shown in Figure1, the derivation of the basic structure of a business pro-cess model from a feature model will be done automatically.This transformation is achieved by redefining the seman-tics of feature models (FM) using context-free grammars,a transformation of this grammar to a finite state machinemodel, and a representation of these state machines usingbusiness process models. Figure 2.a sketches the overviewof this systematic mapping. In addition, as proof of con-cepts, we also provide an implementation, by means of aMDD transformation, of the mapping between feature mod-els and business process models using Atlas TransformationLanguage(ATL)1. Figure 2.b presents the overview of thisimplementation.

As a result of our contributions, we improve the designof complex business process models. Concretely, we im-prove the Design step of the PFE approach by means of im-proving the maintainability of feature models and BPMNsince we provide an automatic mapping that can reduce er-rors derived from manual transformations. In addition, weavoid the need of extending the standard notation of BPMNwith information that is present in the feature model.

1http://www.eclipse.org/m2m/atl/

Source Model Target Model

CFG FSM

Automata Theory and Formal Languages

Source Model Target Model

FM Metamodel

BPMNMetamodel

Metametamodel

conforms to

conforms to conforms to

conforms to

conforms to

a. Our systematic mapping approach b. Our mapping prototype based on MDD Model to Model transformation

.xmi .xmi

.km3 .km3

.ecore

Figure 2. Overview of our approach and ourfirst prototype for automated mapping

2 Definition of a New Semantic for FeatureModels

In order to perform a Process Family Engineering (PFE)feature model grammar representation, we need to define anew Context-Free Grammar (CFG) taking into account thatin SPL it is not needed to establish the order of appearanceof the features into a family product, but in our context it isrecognized as a core need. Process engineers need to per-form business process definitions which establish the orderthat the processes must be performed and its dependencieswith others (i.e: subprocess A and B must be done in paral-lel, and after that, subprocess C must be performed).

For defining this mapping between FM and business pro-cess, we have considered that:

• parent features in a feature model, namely variationpoints, are considered as complex processes.

• child features in a feature model, namely variants, areconsidered as subprocesses.

In order to rigorously define the new semantics, we reuseBatory’s grammar representation of FM [3] as starting pointfor proposing a new grammar. The redefinition is shown inFigure 3. From this grammar, a regular expression of theselanguages can be obtained by means of operations of au-tomata and formal languages theory defined in [7]. Figure3 sketches also the equivalence of a feature and its relation-ships in terms of regular expressions (Notice that parallelexecution of features are represented by means of • char-acter). In addition, each possible composition between twoor more different artifacts is resolved by means of paralleldecompositions. Figure 4 presents an example of this com-position which sketches how a feature model with three dif-ferent relationships is defined by means of a composition ofthree simplified feature models with only one relationship.Thus, the CFG representation of composed feature model is


A

B

Expanded

B

A

Expanded

A

B2

A

Expanded

B1

B2

A

Expanded

B1

B2

A

Expanded

B1

A

Expanded

B2

B1

a

b

b1

b2

b2

b1

ε

ε

ε

ε

Start

Start q0 q1

q1 q2

q0

q1q2

q3

q6q7

q8

q9

ε

Start q0

q1

q2b

ε

ε q3

εq4

ε

Start q0

q1

q2

ε

ε q3

εb1

q6 q7

b2

q8 q9

b2

q11 q12

b1

q 10

b1

q13

b2

ε ε

ε

ε

ε

ε

q14

Start q0

q2ε q3

εb1

q4 q5

b2ε ε

q

Start q0

q4

ε q5

εb1

q8 q9

b2

q10 q11

b2

q1 q2

b1

q12

b1

q3

b2

ε ε

ε ε

q11

εε

B

A

A

B

A

A

B1 B2

A

B1 B2

Feature Model

Man

dato

ryO

ptio

nal

Alte

rnat

ive

Or

Rel

atio

nsh

ips

A

B1 B2

A

B1 B2


Start q0

ε q3ε

Feature

A

Collapsed

Collapsed

A

Collapsed

A

Collapsed

ACollapsed

A

Collapsed

A 6q

b1~b2q4 5qε ε

b1~b2ε ε

q q4 5

b1~b2ε ε

q q6 7

Business Process ModelFeature Model Finite State Machine Model

Rel

atio

nsh

ips

Co

mp

osi

tio

n

F

R1 Rn

FM1 FMn

...

Business Process ModelFeature Model Finite State Machine Model

FMn

FM1

...F

F: FeatureRi: RelationshipFMi: Feature Model

Dom(Ri): { Mandatory , Optional, Alternative, Or }

ε

ε

ε

ε

Start q0

q1

qn

q2

ε ε

FM1

FM2

FMn

... ...

...

...

......

...

...

Figure 5. Feature Model to BPMN Mapping and Composition Catalog Proposed

obtained by means of applying • operator to three simplifiedfeature models CFG representations defined previously.

3 Mapping a Feature Model to a BPMNStructure

Automata and formal languages theory sets the stepsneeded to obtain a Finite State Machine (FSM) model froma Context Free Grammar (CFG) and viceversa[7]. Apply-ing this mapping we provide a FSM representation of thefeature model grammars presented previously.

In addition, BPMN can be represented by means ofFSMs[5]. In this approach, the equivalence based on whichartifacts of BPMN can implement the behavior of a FSMhas been explored, concluding that representing a FSM bymeans of BPMN is feasible.

The BPMN specification does not provide any constraintabout the order of performing subprocesses in any situation.In addition, the BPMN gateways defines that the subpro-cesses contained in it can be done as a sequence or parallelunder several constraints. Thus, the BPMN gateways arefeasible to be used for implementing proposed finite statemachines behavior, as shown in Figure 5 that presents theequivalence between each of FSMs and its representationusing BPMN.

As stated previously, we have developed a proof of con-cepts of the mapping by means of MDD. For that purposewe have developed a prototype using the FeAture Model An-alyzer (FAMA) metamodel as source and the Eclipse SOATool Platform2 BPMN metamodel as target metamodel us-ing an Atlas Transformation Language (ATL) transforma-

2http://www.eclipse.org/stp

tion. It has been published on Eclipse ATL website.3.

4 Related Work

According to [2], to perform a survey in the softwareengineering field, we have to define an analysis frame-work with the following components:(i) research questions:How is performed the mapping between feature diagramsand business process models?, and How is documentedvariability in a BIS context?; (ii) a search strategy to se-lect sources: we have searched the bibliography at DBLP,Google Scholar, and ISI Web of Knowledge choosing pa-pers with a higher number of cites; and finally (iii) a cat-alogue: we classify the approaches in those focused onthe mapping between feature models and business processmodels, and those focused on variability representation.

After searching the selected sources, we have found onlyone proposal that cover our first research question: How isperformed the mapping between feature diagrams and busi-ness process models?. Bae et al. [1] proposes a method forderiving a feature model from a business process model inorder to provide a process family based on obtaining an in-termediate use case representation of the business process.Each feature is considered as a group of use cases, whichare associated to perform an specific business activity. Themethod proposed considers that a set of subprocesses isequivalent to an specific feature. In addition, transforma-tion is performed manually.

On the other hand, regarding to our second researchquestion: How is documented variability in a BIS context?only Process Family Engineering (PFE) [9] explores the

3ATL code and specification is available inhttp://www.eclipse.org/m2m/atl/atlTransformations/#FM2BPMN.

Regular Expressions

Context- FreeGrammar

B

A

A

B

A

A

B1 B2

A

B1 B2

Man

dato

ryO

ptio

nal

Alte

rnat

ive

Or

Rel

atio

nsh

ips

A

B1 B2

A

B1 B2

Feature S : A;

A : a;

A : B;

B: b;

r = a

L = { a }

A : B1 B2

|B2 B1

| B1.B2

;

B1 : b1;

B2 : b2;

A : B

|

;

B : b;

ε

A : B1 B2

| B2 B1

| B1.B2

| B1

| B2

|

;

B1 : b1;

B2 : b2;

ε

A : B1

| B2

;

B1 : b1;

B2 : b2;

A : B1 B2

| B2 B1

| B1.B2

| B1

| B2

;

B1 : b1;

B2 : b2;

r = b

L = { b}

r = b1b2 |

b 2b1 |

b 1.b2

L = { b1b2,

b 2b1,

b 1.b2}

r = b?

L = { , b }

r = b1?b2? |

b 2?b1? |

b1.b2

r = b1 |

b 2

L = {b1 , b2 }

r = b1b2? |

b2b1? |

b1.b2

ε

L = { , b1, b2,

b 1b2, b2b1

b 1.b2 }

ε

L = { b1, b2,

b 1b2, b2b1,

b 1.b2 }

Feature Model

Figure 3. PFE Feature Model and its CFG rep-resentation

idea of using feature models for managing variability ina BIS context, but the relationship between these featuremodels and its products, defined by means of business pro-cess models, is not clearly defined as stated in Section 1.

5 Conclusions

We have explored the Process Family Engineering (PFE)approach for managing the complexity derived from model-ing variant-rich business process models. Thus, we have de-tected some drawbacks in one of the steps of this modelingmethodology, concretely on design phase, identifying am-biguities, maintenance problems and activities performedmanually which can be performed automatically. The mainmotivation of this paper is to solve the identified problems.For that purpose, as shown in Figure 5 in Section 3, we pro-vide a mapping from feature models for representing vari-ability in BIS, whose semantic is significantly different thantraditional, to basic structures of business process models,represented using BPMN. The main advantages of our ap-proach are: (i) it is defined as a systematic process, (ii) it

provides a maintenance improvement, and (iii) it defines anF

R1 Rn

FM1 FMn

...

F = FM1 FM2 … FMn

A

B CB

D EB

A

C

A

D E

=

F: FeatureRi: RelationshipFMi: Feature Model

Dom(Ri): { Mandatory , Optional, Alternative, Or }

A: C | B C | C B | C B;B: D E | E D | D E | D | E;C: c; D: d;E: e;

Grammar Representation Composition

Figure 4. PFE FM Grammar RepresentationComposition

automatic mapping which maximizes quality level and min-imizes error rate.

References

[1] J. Bae and S. Kang. A method to generate a feature modelfrom a business process model for business applications. InCIT ’07: Proc. of 7th IEEE Int. Conf. on Computer and Infor-mation Technology (CIT 2007), pages 879–884, Washington,DC, USA, 2007. IEEE Computer Society.

[2] L. Barachisio, V. Cardoso, E. Santana, and S. Lemos. Asystematic review on domain analysis tools. In Proceedingsof the International Symposium on Empirical Software Engi-neering and Measurement. ESEM07., 2007.

[3] D. Batory. Feature models, grammars, and propositional for-mulas. In J. H. Obbink and K. Pohl, editors, SPLC, vol-ume 3714 of Lecture Notes in Computer Science, pages 7–20.Springer, 2005.

[4] BPMI. Business process modeling notation BPMN version1.0 - may 3, 2004. OMG.

[5] E. Börger and B. Thalheim. A Semantical Framework forBusiness Process Modeling. With an Application to BPMN.not published. 2007.

[6] H. Gomaa. Feature dependent coordination and adaptationof component-based software architectures. In WCAT ’07:4th Workshop on Coordination and Adaptation Techniques forSoftware Entities, 2007.

[7] J. Hopcroft and J. Ullman. Introduction to Automata The-ory, Languages, and Computation. Addison-Wesley, Read-ing, Massachusetts, 1979.

[8] I. Montero, J. Peña, and A. Ruiz-Cortés. Representing Run-time Variability in Business-Driven Development systems. InProc. of the 7th Int. Conf. on Composition-Based SoftwareSystems (ICCBSS08), 2008.

[9] A. Schnieders and F. Puhlmann. Variability mechanisms ine-business process families. In Proceedings of BIS ’06: Busi-ness Information Systems, 2006.

Representing Runtime Variability in Business-Driven Development Systems∗

Ildefonso Montero, Joaquín Peña, Antonio Ruiz-CortésDepartamento de Lenguajes y Sistemas Informáticos

Av. Reina Mercedes s/n, 41012 Seville (Spain)University of Seville

{monteroperez, joaquinp, aruiz}@us.es

Abstract

Business-Driven Development(BDD) is a research fieldthat provides techniques and mechanisms for designingsoftware systems starting from the business processes of thecompanies. Companies are in continuous evolution to adaptto market changes, thus, current process engineers redesignthe processes every time that is needed using ad hoc tech-niques. This situation motivates that these changes, calledruntime variability, must be managed. Some authors haveused Software Product Lines (SPL) ideas to manage it.

Current approaches for documenting runtime variabilityin SPL and BDD, proposes different model representations.Unfortunately, we have determined that the expressivenesslevel in BDD is not adequate, and that SPL solutions needsfor adaptation to BDD context for describing under whichcircumstances a business evolves.

In this paper, we present a model for representing run-time variability in BDD systems. The main contributionsof this proposal are: (i) it presents the enough expressive-ness level for representing runtime variability; and (ii) pro-cess engineers can represent and understand under whichevents a business evolves and how this evolution is man-aged, which is not present in current approaches. We callthis approach Product Evolution Model (PEM).

1 Introduction

Business-Driven Development (BDD) is a research fieldthat provides techniques and mechanisms for designingsoftware systems starting from the business processes of thecompanies. Nowadays, BDD systems supports most of theactivities of a company due to it improves their daily work

∗This work has been partially supported by the European Commission(FEDER) and Spanish Government under CICYT project Web-Factories(TIN2006-00472) and under a scholarship from the Education and Univer-sities Spanish Government Secretariat given to the author Ildefonso Mon-tero.

and their strategic management. Thus, Information Tech-nology (IT) infrastructure must evolve to adapt companiesto the continuous evolution of markets. Currently this evo-lution is supported by ad hoc techniques to maximize thelevel or reuse from one version to another, redesign the pro-cesses every time that is needed. It motivates that runtimevariability support in business processes is needed.

Software Product Lines (SPL) systematizes the reuseacross the set of similar products that a software companyprovides. A. Schnieders et al. explores the idea of apply-ing (SPL) techniques to BDD in an approach called Pro-cess Family Engineering (PFE) [7]. Basically, PFE followsthe SPL philosophy for managing the variability of the busi-ness process of an unique business, thus, managing only onesoftware system. That is to say, each product in PFE rep-resents an evolution of the process (at runtime). However,although PFE may be the solution to manage the evolutionof the business process of a company, proposed models, fea-ture models, are not expressive enough for documenting thisevolution because they are devoted to design time.

In addition, runtime variability has been also analyzed inthe SPL field: J. Bosch et al. in feature models [4], and H.Gomaa et al. in software components-based architecturesdesign [3][2]. Although these proposals presents valuablesolutions for other contexts, they need for integration andextensions in the BDD context.

The main motivation of this paper is that analyzed ap-proaches in BDD does not provide the expressiveness levelneeded for representing runtime variability. In addition,current approaches does not take into account that processengineers must document, in their business process defini-tions, a clear description about under which circumstancessome processes are in use and which do not at runtime; andhow these processes are performed in a business evolution(a parallel collaboration between processes, a sequence,etc).

Our approach integrates quoted approaches for model-ing runtime variability in BDD systems oriented providinga set of artifacts able to represent properly runtime evolu-

Ildefonso

Text Box

BibTex

http://yourtask.webcindario.com/yourtask/doc/montero-papers/montero-iccbss08.bib

tions and trigger events that implies these changes into thebusiness process of a company. For that purpose, we pro-vide an abstract formal description of business evolutionsand a proposal for representing it based on Business ProcessModel Notation (BPMN) [1]. The main benefits of our ap-proach are that it provides the enough expressiveness levelfor representing runtime variability in BDD systems, andthat events or conditions that fires business evolutions canbe observed and analyzed by process engineers.

This paper is structured as follows: Section 2 presentsthe background information needed to understand our ap-proach; Section 3 presents our approach for modeling run-time variability in BDD systems, called Product EvolutionModel; Section 4 presents the related work and motivationof our work; and finally, in the last section, we draw themain conclusions of our approach.

2 Preliminaries

2.1 Software Product Lines and FeatureModels

Software Product Lines (SPL) systematizes the reuseacross the set of similar products that a software companyproduces. The main goal of SPL is obtaining a reductionof the overall development costs and times for the productsderived from the product line. In SPL a product is com-posed of a set of common features and a set of variable fea-tures. Common features appear in all products and variablefeatures appear under demand of consumer’s products. Ob-serving a certain product of an SPL, although it is describedas a set of fixed features, some features can be in use in acertain moment and some not. This is called runtime vari-ability.

Feature Models (FM) are one of the most used artifactsfor modeling variability, that is, specifying which featuresare common and which are variable. A FM represents allpossible products in an SPL in terms of features. There ex-ists several notations of FM, such as FODA [5], or J. Bosch[4]. A FM establishes a parental relationship between eachfeature, as shown in Figure 1, that can be: (i) Mandatory:if a child feature node is defined as mandatory, it must beincluded in every product that contains the parent; (ii) Op-tional: if a child feature node is defined as optional, it can beincluded or not when its father feature appears in a product;(iii) Alternative: if the relationship between a set of childrennodes and their father is defined as alternative, only one ofthe children features could be included in every father fea-ture products; and (iv) Or: if the relationship between aset of children nodes and their father is defined as or, oneor more of them could be included in every father featureproducts. In addition to the parental relations between fea-tures, a FM can also contain cross-tree constraints between

Services

Fast-Food Restaurant

Serve

Establishment

Cafeteria

Cook

Birthday´s party

Serve FastServe Normal

Delivery

: Core Features CF

: Variable Features VF

A

B

A

B

Mandatoryrelation

Optionalrelation

A

B1 B2

Alternativerelation

A BRequires constraint

A BExcludes constraint

A

B1 B2

Orrelation

Auto

Figure 1. Case Study: Fast Food Restaurant

couples of features. These are: (i) Requires: If a feature Arequires a feature B, the inclusion of A in a product impliesthe inclusion of B in such product; and (ii) Excludes: if afeature A excludes a feature B, both features can not be partof the same product.

2.2 Process Family Engineering

Process Family Engineering (PFE) [7] explores the ideaof applying SPL philosophy for managing the evolution ofBDD systems. PFE uses FM for representing the set of pro-cesses contained into a business, and BPMN for represent-ing an specific process. In PFE, we obtain only one softwaresystem that evolves at runtime, where the features are pro-cesses. Every process evolution represents a product thatcontains a subset of features, but the PFE system containsall the features.

The main difference between SPL and PFE is that SPLprovides a set of different products that shares common fea-tures, and PFE provides only one product, which representsa business, that evolves at runtime, and each possible con-figuration of this business is managed as a product that con-tains a subset of features (processes) enabled at a certainmoment of the execution. Thus, given that FM are devotedto design time, the main problem of PFE is that this ap-proach uses FM for managing runtime properties.

3 Product Evolution Model

In this section, we present an abstract formal descriptionof Product Evolution Model and a proposal for representingit by means of an extension of BPMN using stereotypes. Wealso include a case study to illustrate our approach.

3.1 Rigorous Description

Let B be a business. Each business can be defined as aset of processes (denoted with P ). Thus, B can be definedas follows:

B = {P1, P2, ..., Pk}; k > 0; 1 ≤ i ≤ n

Processes

Instant t

Instant t + 1

SVF t+1

Processes

SVF t

B

Business

B

Business

Formal Definition Process Evolution Model

Business B

...

t + 1

F (t, SVFt)

t + k;k > 0...

Feature Model

Business B

Processes

... F (t, SVFt)

CF

VF

Legend

: Core Processes CF

: Variable Processes VF

Figure 2.a. Formal Description

Figure 2.b. Graphical Notation

CF + SVF t

CF + SVF t + 1

Figure 2. PEM approach defining a businessevolution by F∆ function in t and t + 1.

. . .Serve in

Cafeteria and Establishment

10:00 am( t +1 )

Fas

t-fo

od r

esta

uran

t

Serve inEstablishment

F ( t, ServeInCafeteria)SVF t+1 : SVF t+2 : ServeInAuto

F ( t + 1, )

Serve in Auto and

Establishment. . .

Cafeteria Service close at 10:00 am

11:20 am( t +2 ) A client has arrived

to Auto-Service

Figure 3. Fast-food restaurant Product Evolu-tion Model BPMN Compositions

Let CF be the set of common processes or features andlet VF be the set of variable features, thus B is defined for-mally as a tuple containing all the CF and a subset of V Fdenoted as SV F :

B = (CF, SV F ∈ V F )

As shown before, in PFE, each configuration of the set ofprocesses enabled at certain moment represents a product.Thus, we can say that the CF of a B are always enabledat runtime, but the set of processes in V F is not fixed atruntime.

Thus, we can set up a product line that takes into accountthis runtime variability. For formalizing these concepts weshould redefine each business B as:

B = (CF, SV F ∈ V F, F∆ :

: t, {Feature × ... × Feature} �→�→ {Feature × ... × Feature})

where F∆ is a function that given a time instant t, trans-forms the set of SV Ft into the new set of variable featuresof the following time instant t + 1, that is to say SV Ft+1,formally:

F∆(t, SV Ft) = SV Ft+1 ∈ V F

•SV F t �= SV F t+1

Figure 2.a sketches a graphical representation of F∆,where it is represented the transformation of SV Ft intoSV Ft+1. In an instant t there exists an specific set of SV Ft

for business B that evolves in instant t + 1 to another dif-ferent set SV Ft+1.

3.2 Graphical Notation

As shown previously, a business that evolves can be rep-resented by B = (CF, SV F ∈ V F, F∆). where the evolu-tion is defined by the F∆ function in t.

In PFE feature models (FM) are used to represent whichfeatures are variable and which do not. From this, a the setof common features (CF ) and (V F ) can be obtained [6].Thus, CF and V F can be represented by means of a FM.

However, the feature model cannot establish the orderof apparition of business processes, represented as F∆, dueto feature models are not devoted for temporal conditionsor variables (t) [2]. For that purpose, we have to add anew model with a graphical notation that represents F∆,the Product Evolution Model, which is defined by means ofa BPMN state machine where each state represents a prod-uct and each evolution between two or more states, is repre-sented by means of a transition that is an application of F∆

function. Figure 2.b shows how an evolution of a businessis defined by means of F∆ function in t and t + 1 usingBPMN. Notice that it represents an specific graphical no-tation for the formal description of our approach, but othernotations can be applied.

To show our approach we use a fast-food restaurantcase study. Figure 1 depicts a simplified set of processescontained into a fast-food restaurant, where Serve Normal,Serve Fast and Serve in Establishment are CF , and the restof processes are V F . In Figure 3, we present the PEM ofour case study. Each process contains a BPMN model thatrepresents how all processes are performed. It defines theconfiguration of the business at runtime and shows that, inevery runtime instant t, there exists a different SV F se-lected which represents an evolution of the system. In thisexample, on a time instant t the restaurant open its cafeteriaservice, thus, there exists in parallel two different processes:Serve in Cafeteria and Serve in Establishment Normal/Fast(CF ). When the restaurant close its cafeteria service ontime instant t + 1, let us say 10:00 AM, F∆ function is ap-plied and an evolution is done to another state composedonly by CF processes. After that, the restaurant opens itsAuto-Service, due to a client has arrived with his car, and anew evolution is applied for t + 2 time instant.

Firefox

Plugin

Flash Java WebsiteDebugger

runtime

Feature

External Feature

or specialization

Figure 4. J. Bosch approach

Beeper

MicrowaveControl

<< optional >>

BeeperComponent<< output component >>

IBeeper<< interface >>

{feature = Beeper}

+ initialize()+ beep()

......

MicrowaveSystem

ControlSystem

...

...

<< kernel >><< control component >>

Feature model viewComponent model viewState machine view

Active

Passivating

Passive

Inactive

Waiting for Acknowledgement

Passivate[Processing Transaction]

Reactivate

Passivate[Waiting forNeighbor

Response]

TransactionStarted

TransactionAborted

Passive Acknowledgement from all Neighbors

TransactionEnded *

TransactionEnded **

* At least one neighbor active** All neighbors passive

Activate

Figure 5. Gomaa approach

4 Related work and motivation

As shown in Section 2, FM are one of the most used ar-tifacts for modeling variability. Unfortunately, as shown by[2], FM are devoted to design variability, and not for run-time variability. To the best of our knowledge, there existsonly two approaches for documenting runtime variabilityin SPL field. On the one hand, J. Bosch et al. [4] intro-duces an extension of FM for representing runtime vari-ability. Bosch’s notation syntax is slightly different fromFODA’s or FORM’s notation. It introduces a new kind offeature, called external feature, represented by dashed rect-angles, for representing features that varies at runtime. Fig-ure 4 depicts an example of a feature model in this notationthat represents Firefox plugin support. As can be observed,time instants and conditions or constraints to enable/disableWebsite Debugger plugin, as for example concrete websitedomains, can not be represented with this approach.

On the other hand, H. Gomaa et al. [3][2] propose aset of models for representing runtime variability based onevolutionary reconfigurable software architectures. The dif-ferent versions of an evolutionary system are considered asoftware product line, where each version of the system is aSPL member and the reconfiguration is defined by an statemachine that, for each component, represents the steps thathas to be performed to evolve from a normal operation stateto an inactive state. Once inactive, the component can beremoved and replaced with a different version. Figure 5 de-picts trigger events in the state machine.

Given this state, the motivation of this paper is that therenot exists any approach that provides an appropriate model-

ing support for runtime variability for BDD systems. Boschapproach represents a first step toward enabling runtimevariability support for feature models, but unfortunately itit does not associate any additional information about whenor how some features can be in use at runtime and which donot (it does not take into account F∆). Gomaa proposal is asolution to manage the evolution of software systems basedon architectural reconfiguration patterns and SPL ideas, butit is focused in the context of software components archi-tectures, instead of BDD systems. In addition, FM doesnot represent how enable/disable features at runtime (F∆ ispartially supported but it is not associated with any FM).Process engineers must see processes that are added or re-moved from their business design instead of software com-ponents reconfigurations at a lower and concrete softwaredevelopment levels. Finally Schnieders proposal, PFE, usesFM for managing runtime evolution, which are devoted todesign time.

5 Conclusions

We propose a new approach for modeling runtime vari-ability in BDD systems, called Product Evolution Model.The main advantages over current solutions are that our pro-posal provides to process engineers an enough expressiveset of models which are able to represent and understand:(i) under which trigger events or business policies a busi-ness evolves and (ii) how is managed this evolution.

References

[1] BPMI. Business process modeling notation BPMN version1.0 - may 3, 2004. OMG.

[2] H. Gomaa. Feature dependent coordination and adaptationof component-based software architectures. In WCAT ’07:Proceedings of the 4th Workshop on Coordination and Adap-tation Techniques for Software Entities, 2007.

[3] H. Gomaa and M. Hussein. Model-based software design andadaptation. In ICSEW ’07: Proceedings of the 29th Interna-tional Conference on Software Engineering Workshops, 2007.

[4] J. V. Gurp, J. Bosch, and M. Svahnberg. On the notion of vari-ability in software product lines. In WICSA ’01: Proceedingsof the Working IEEE/IFIP Conference on Software Architec-ture (WICSA’01), 2001.

[5] K. Kang, S. Cohen, J. hess, W. Novak, and S. Peterson.Feature-oriented domain analysis FODA feasibility study.CMU/SEI-90-TR-21. Technical report, Carnegie Mellon Uni-versity. SEI, 1990.

[6] K. Pohl, G. Böckle, and F. van der Linden. Software ProductLine Engineering: Foundations, Principles and Techniques.Springer, September 2005.

[7] A. Schnieders and F. Puhlmann. Variability mechanisms ine-business process families. In Proceedings of BIS ’06: Busi-ness Information Systems, 2006.

Obtaining the Core Architecture of Business

Information Systems Families.?

Ildefonso Montero, Joaquin Pena, and Antonio Ruiz-Cortes

Departamento de Lenguajes y Sistemas InformaticosAv. Reina Mercedes s/n, 41012 Seville (Spain)

University of Seville{monteroperez, joaquinp, aruiz}@us.es

Abstract. On the one hand, the development of Business Information

Systems (BIS) is focused on providing techniques and mechanisms fordesigning software systems based on the business processes of the com-panies. On the other hand, the Software Product Lines (SPL) field sys-tematizes the reuse across the set of similar products that a softwarecompany produces. It implies a reduction of development times and costsand a quality improvement.In order to increase the process definitions reusability, in this paper, wepropose a methodology based on applying SPL ideas for the systemati-zation of the development of BIS across a several number of businessesthat shares common business processes. Thus, the contribution of thiswork is to define and explore the feasibility and benefits of what we callBusiness Family Engineering (BFE), providing its software process anddescribing the steps needed to build the BFE core architecture, namelyBusiness Family Domain Engineering.

Keywords: Business Family Engineering (BFE), BFE Domain Engineer-ing, Process Family Engineering, Software Product Lines, Variability of ProcessModels, Core Architecture, BPMN.

1 Introduction

The development of Business Information Systems (BIS) is focused on providingtechniques and mechanisms for designing software systems based on the businessprocesses of the companies, defined graphically by means of business processmodeling notations, such as Business Process Model Notation (BPMN) [5]. Thevariability level of average-size BIS is usually highly enough for making thedesign of this kind of systems a complex task. In addition, is a fact that there

? This work has been partially supported by the European Commission (FEDER)and Spanish Government under CICYT project Web-Factories (TIN2006-00472),Andalusian Government project ISABEL (TIC-2533), and under a scholarship fromthe Education and Universities Spanish Government Secretariat given to the authorIldefonso Montero.

Ildefonso

Text Box

Draft Version. Under construction

Ildefonso

Text Box

BibTex

http://yourtask.webcindario.com/yourtask/doc/montero-papers/montero-bpm.bib

2 Ildefonso Montero, Joaquin Pena, and Antonio Ruiz-Cortes

exists several companies that shares common business processes, and maximizethe level of reuse of their definitions is considered a core need.

For that purpose, there is an approach, called Process Family Engineering(PFE) [3] (See Section 3.2 for more details), that tries to increase the reusabilityon the development of BIS using ideas from the Software Product Lines (SPL)field [22]. Roughly speaking, the SPL field systematizes the reuse across the setof similar products that a software company provides. For that purpose, thisapproach requires to describe the products by means of variability models, suchas Feature Models (FM), that contains only features and relationships betweenthem. A feature is considered as a characteristic of the system that is observ-able by the end users. Feature Models describe which features are present in allthe products, called core features, and which not, called variable features. (SeeSection 3.1 for a more detailed description).

In addition, the PFE approach identifies some variability aspects on businessprocess models, and proposes to extending the standard BPMN for representingit [31]. However, although the PFE approach is quite valuable, it presents somedrawbacks related with ambiguity and maintenance that are described at Section3.2.

Thus, the main motivation of this paper is to provide a methodology thattaking into account the PFE drawbacks makes feasible the possibility of developfamilies of business information systems. For that purpose, as shown in Section4, we provide a methodology named Business Family Engineering, and we definethe fragment of this methodology focused on obtaining the core architecture ofthe family, namely Business Family Domain Engineering, that is the focus of thispaper. In addition, we motivate our approach by means of a real-life case studydefined in the Web Service Choreography Interface (WSCI) specification [24].Finally, as proof of concepts, we have developed an Eclipse tool that providessupport for one of the activities of this methodology fragment. See Section 5 formore details about tool support.

As a result of our contributions, we improve the development of businessinformation systems reducing its complexity level in situations where is neededto perform a business family, using our proposed methodology. In addition, dueto our approach is focused on providing the core architecture of the family, weprovide to process engineers some artifacts for improving their activities, such asa business family variability summary and a core process framework (See Section4 for a more detailed description). This artifacts provides a basic structure ofthe business process model that supports the variability aspects identified by thePFE approach, without the need of extending the standard notation of BPMN.

2 Motivating BFE with a WSCI case study

The Web Service Choreography Interface (WSCI) specification [24] provides acomprehensive example that illustrates how to model a scenario that reflects thereal life business process of reserving and booking airline tickets. A derivation ofthis example, for defining an hotel booking process has been used for illustrating

Obtaining the Core Architecture of Business Information Systems Families. 3

the Process Family Engineering (PFE) approach in [23]. See Section 3.2 formore details about the PFE approach. We use the WSCI case study as startingpoint for defining how to develop families of business information systems thatprovides support for any booking process.

The scenario provided by the WSCI specification is the following: there ex-ists three different participants involved into the reserving and booking airlinetickets business process, concretely a Traveler, a Travel Agent, and an AirlineReservation System. Each participant collaborate in the overall process calledPlan&Book. This business process is composed by the following subprocesses:(i) Order Trip: it defines the steps needed for performing the submission of thepreferred trip plan from the Traveler to the Travel Agent, who evaluates thepreferences, and send a possible itinerary to the Traveler. It is performed bymeans of a collaboration between the Travel Agent and the Airline ReservationSystem by means of a business process named Verify Seats Availability. Thisbusiness process is a subprocess of Order Trip; (ii) Cancel Itinerary: it definesthe steps needed for canceling the provided itinerary from the Travel Agent; (iii)Change Itinerary: it defines the steps needed for performing a submission fromthe Traveler to the Travel Agent to change the proposed itinerary; and (iv) Re-serve Tickets : it defines the steps needed for reserving the trip related with theproposed itinerary. This business process is decomposed by four subprocesses:Book Tickets, Book Seats (that needs a previous reservation step for the seatsperformed by other business process named Reserve Seats), Send Tickets andfinally, Send Statement.

This case study provides a complete real life example of reserving and book-ing a trip for any possible airline travel agency. We are going to suppose thatseveral airline travel agencies, such as Iberia, Ryanair, etc. performs this busi-ness process. In other words, these travel agencies share the common businessprocess of Plan&Book. In addition, is feasible that these companies share otherset of business processes, and also, performs a set of specific processes from eachcompany.

Taking into account the previous consideration, we are going to extend theWSCI case study providing specific business processes from any possible airlinetravel agency. Thus, we introduce the following business processes: (i) Inform:it defines the steps needed to provide to the Traveler and to the Travel Agentthe information about flights (delays, connections, etc.) obtained from an Air-line Traffic Control System (we have introduced a new participant in addition);and (ii) Extras : it defines the steps needed to provide to the Traveler the in-formation related with some extra services from an airline agency. In this casestudy, we have decomposed this business process into two subprocesses named:Restaurant and Travel Card, that define the restaurant on fly subprocess andthe management of travel cards respectively.

Once the scenario is defined, we have analyzed the feasibility of develop afamily of airline travel agencies using our approach: Business Family Engineering(BFE). The scenario motivates that BFE is feasible addressing into the followingissues, that are covered in the paper:


– Increasing the business process definitions reusability for each business infor-mation system that provides support for any airline travel agency. Currentprocess engineers redesign each business information system using ad hoctechniques to maximize the level of reuse from one product to another. Ourapproach states that many common business processes can be found, andreuse across businesses by means of Software Product Line (SPL) techniquescan be exploited. See Section 3.1 for more information about the SPL field.

– Improving the design of highly variable business process models, also namedvariant-rich processes, obtaining the basic structure of the business process(that needs to be completed manually). Nowadays, the design of highly vari-able business process models is performed extending the notation of thebusiness process diagram, for example Business Process Model Notation(BPMN). It is defined by the PFE approach, that is detailed in Section3.2

– Visualizing the variability of the business information system. Our approachstates that providing a variability summary is feasible and it would helps toprocess engineers to identify the core and variable assets of the family.

3 Background Information

In order to clarify the context of this paper, in this section we provide a set ofdefinitions and considerations about the Software Product Line (SPL) field andthe Process Family Engineering (PFE) approach.

3.1 Software Product Lines and Feature Models

Pohl et al. define in [9,22] that Software Product Line (SPL) development aimsat and achieves pro-active, constructive reuse, based on the idea to developsoftware products which share a significant amount of characteristics, namelyfeatures. Thus, a feature is a characteristic of the system that is observable bythe end user. Roughly speaking, SPL systematizes the reuse across the set ofsimilar products, defined by means of their features, that a software companyprovides.

The SPL approach is devoted to overcome complexity providing all the tech-niques needed for enabling the mass production of software in a certain applica-tion domain. The variability concept appears in SPL to represent the differencesand commonalities inside an application domain. Variability is one of the criticalaspects of SPL and it must be managed at all the stages of SPL development.Thus, the software process of SPL is divided into two main stages: DomainEngineering, which is in charge of providing the reusable core assets that areexploited during the derivation of products, done at a second stage named Ap-plication Engineering [22].

One of the most accepted techniques to represent the set of products ofan SPL are Feature Models (FM) [7]. The main goal of feature modeling is toidentify commonalities and differences among all products of an SPL. A feature


A

B

A

B

Mandatoryrelation

Optionalrelation

A

B2B1 B3

Alternativerelation

A

B2B1 B3

Orrelation


Change Itinerary

Cancel Itinerary

Reserve Tickets

Reserve Seats

Book Tickets

Order Trip


Book Seats

Send Tickets

Send Statement

ExtrasInform

RestaurantTravel Card

Fig. 1. Feature Model of our case study

model is a compact representation of all potential products of an SPL showing aset of features in an hierarchical structure where it is shown which features arepresent in a product of the product line. Figure 1 shows the feature model ofour case study. A FM establishes a parental relationship between each feature,as shown in Figure 1, that can be:

– Mandatory: if a child feature node is defined as mandatory, it must beincluded in every product that contains the parent;

– Optional: if a child feature node is defined as optional, it can be includedor not when its father feature appears in a product;

– Alternative: if the relationship between a set of children nodes and theirfather is defined as alternative, only one of the children features could beincluded in every product that contains the parent;

– Or: if the relationship between a set of children nodes and their father isdefined as or, one or more of them could be included in every product thatcontains the parent.

Our approach for developing families of business information systems is basedon introducing some SPL techniques. For that purpose, the feature model is usedin our approach for describing the set of business information systems that aremembers of the business family, and for representing the variability of eachbusiness information system. In addition, the introduction of SPL techniquesimplies a reduction of development times and costs and a quality improvementof the final products.

3.2 Process Family Engineering

The Process Family Engineering (PFE) [3] approach explores the idea of apply-ing SPL philosophy for managing the variability of business information systems.In PFE, feature models are used for representing the set of processes containedinto a business. In addition, a business process diagram notation, such as BPMN,is used for representing an specific process. However, the syntax of this notation


Inform<< Abstract >>

Inform by E-Mail

<< VarPoint >><< Default >> Inform by

Intranet

<<VarPoint>>

<<Implementation>><<Implementation >>




<<Parameterization >>

Send Tickets

Send Tickets and Information

about Trip

<<VarPoint>>

<<Inheritance >>

Book Tickets

Quality Assurance

<<Null>>

<<Extension>>

Fig. 2. Variability aspects defined by the PFE approach

is redefined for providing support for representing highly variable business pro-cess models, namely variant-rich business process models [31].

The PFE approach defines a variant-rich business process model as a processmodel that represents how to deal with some identified variability aspects:

– Alternative behaviors: it defines when there exists several different waysfor performing an activity into a business process definition. Figure 2.a showsan example about a refinement of the Inform business process from theWSCI case study, represented using BPMN. When the Airline Traffic Con-trol System submit some information to the Travel Agencies it could bedone by e-mail, publishing the information as a new into the Intranet, etc.As shown, the PFE approach introduces some stereotypes: (i) �Abstract�,for defining the activity that has an alternative behavior; (ii) �VarPoint�,for identifying the activities that implements each possible behavior, thisstereotype sometimes is represented as a puzzle piece into the activity;and (iii) �Implementation�, for describing a new kind of flow not de-fined in the standard BPMN notation, that represents that an activitymarked as �VarPoint� implements the behavior of other activity markedas �Abstract�. In addition, the default implementation can be providedintroducing the stereotype �Default�.

– Parameterization: it defines that each BPMN attribute can be parameter-ized to support a range of values. Figure 2.b shows how to represent possibleranges of the value Number of Seats, into the subprocess Verify Seats Avail-ability from the case study of this paper. This attribute is marked usinga grouping box and associated to other possible values by means of a newassociation flow defined with a new stereotype named �Parameterization�.

– Inheritance: it defines a modification of an existing subprocess by addingor removing elements regarding to specific rules. This allows for realizingalternative variation points. As shown in Figure 2.c, the business processSend Tickets has been modified to Send Tickets and Information about Tripdue to the Travel Agency has a contract with some tourism companies forproviding information about them when it sends tickets to the Traveler.This situation is marked with a new association defined using the stereotype�Inheritance�.


– Extension Points: it defines an optional behavior. Figure 2.d depicts howan optional behavior from Book Tickets subprocess could be included forquality assurance of this activity. This situation is marked using the stereo-type �Extension�.

The main difference between SPL and PFE is that the SPL field provides aset of different products that shares common features, and the PFE approachprovides only one product, which represents a business, that evolves at runtime,and each possible configuration of this business is managed as a product thatcontains a subset of processes enabled at a certain moment of the execution. Onthe one hand, the SPL products are implemented by software artifacts. For eachof them there exists a feature selection phase that generates the final products(a set of core and variable features). On the other hand, the PFE products areimplemented by processes. For each product, the system can evolve to anotherproduct increasing or decreasing the variable set of features thus, each productis a software system based on processes.

However, although the PFE approach proposes a methodology for designinghighly variable business processes, based on overcoming the complexity derivedfrom variability, by means of applying software product lines for managing it;this approach presents some drawbacks. For example, the use of feature modelsand the derivation of business processes from it presents some problems, such asambiguity, that has been explored for us in [11]. Another consideration is the needof redefining the BPMN syntax introducing some information about variabilitywhich is also present in the feature models, thus, information is duplicated withthe obvious problems for maintenance. In addition, there not exists support forthis new syntax of BPMN, due to it is not an standard notation.

Our approach overcomes the variability of the business information systemsusing SPL techniques, taking into account the PFE approach ideas and with-out providing extra information to the standard notation used to represent thebusiness process models. In addition, as stated previously, each PFE product isconsidered as an evolving system. Our approach takes into account this advan-tage for representing the evolution of the business information systems of thefamily.

4 Obtaining the Core Architecture of a Business Family

The main motivation of this paper is: (i) to propose a methodology based onapplying SPL ideas for the systematization of the development of BIS acrossa several number of businesses that shares common business processes, namelyBusiness Family Engineering (BFE); and (ii) to define the methodology fragmentfocused on providing a core architecture of the family, namely Business FamilyDomain Engineering. For that purpose, Figure 3 shows the software process ofour approach using the SPEM notation1.

1 http://www.omg.org/technology/documents/formal/spem.htm


��

�� (A) Overview of the software process of

Business Family Engineering

�� !�"� #

$��!�"��!�"��

Focus of this paper

(B) Business Family Domain Engineering

Fig. 3. Software process of BFE in SPEM notation

As shown in Figure 3.a, in this software process there are two main activ-ities: (i) Business Family Domain Engineering, where we build the BFE corearchitecture, namely Core Process Framework, and the Business Family Vari-ability Summary; and (ii) Business Family Application Engineering, where weobtain specific business information systems, that are described by means ofexecution languages, such as Business Process Execution Language (BPEL). Asstated previously, this second stage is out of the scope of this paper.

It is important to say that our scenario is by now limited to binary relation-ships between features and processes, in other words, a feature can not representa set of processes.

In addition, we have identified two different ways to build a business fam-ily: top-down and bottom-up. In the top-down approach, we define the set ofbusinesses and processes from scratch and apply the normal sequence of BFEsoftware process. In bottom-up approach, we can not apply the normal sequenceof the software process defined due to we have a set of businesses or processes de-fined in feature models previously to apply BFE software process. In this paperwe only focus in top-down.

Figure 3.b describes the Business Family Domain Engineering software pro-cess using SPEM. It is composed by three different activities: (i) Domain Re-quirements Engineering, that is focused on capturing the requirements of theproblem domain, (ii) Domain Design, that is focused on exploring the variabilityof the system and providing the core architecture; and (iii) Domain Implemen-tation, that is focused on defining the implementation and test details of thearchitecture, such as persistence or presentation layers.

4.1 Domain Requirements Engineering

The Domain Requirements Engineering activity is focused on identifying the setof companies and its business processes that would be members of the businessfamily. This step takes into account the traditional requirements elicitation ac-tivities of software engineering, and provides as resulting artifact the documentsthat reflects this elicitation, where it is included the definition of each businessprocess and each company. Thus, the activities of this stage are performed by a


%&'()*+, -.'/'()01,234*('44 5167'44'4-2548'+*(' )9' :6/;0(*'4 0(&*)4 234*('44 5167'44'4:6/;0(*'40(& 234*('445167'44'48'471*;)*6( <60.4=6&'.4>4' :04'=6&'.4(A) Domain Requirements Engineering Overview

(B) Goal Model of “Send Tickets”using Tropos

(C) Use Case Model “Search a Ticket”with two variants using Hallmans and

Pohl proposal

TravelAgent

Search aTicket

<<include>>

Search by

Search byCode

Search byAgency

<< variant>>

<< variant>>

Send Tickets

AND

Create Tickets

Search Tickets

AND

FilterTickets

[Max] Performance

AND

+–-2548'471*;)*6( %&'()*+,?,4)'/<60.4 %&'()*+,>4' :04'4%&'()*+,?)0@'96.&'14%()16&37'A'B3*1'/'(4C01*0D*.*),=0(0E'/'()

<.64401, 6+F'1/4?)0@'96.&'148'471*;)*6(F107'0D*.*),=0)1*G<'('10)'0( -.*7*)0)*6(8673/'()

H3(7)*6(0.A'B3*1'/'()48'471*;)*6( I6(JH3(7)*6(0.A'B3*1'/'()48'471*;)*6(

Fig. 4. Domain Requirements Engineering Overview and models obtained

Requirement Engineer, role that could be played by an analist, a process engi-neer, etc. Figure 4.a shows the Domain Requirements Engineering overview. Inthis stage, the Requirement Engineer performs the following activities:

– Define the Companies and its Business Processes: it is focused onobtaining a first conceptual description about the companies and its businessprocesses. It could be done using a free textual specification, see Section 2for an example, or using a workflow representation of each identified businessprocess, such as BPMN. This activity generates two different artifacts: (i) theCompanies and Business Processes Definition, that contains the descriptionof the problem domain; and (ii) the Glossary of Terms, that contains aterminology summary about the problem domain.

– Identify Elementary Business Processes (EBPs): it is focused on iden-tifying the business processes contained into the Companies and BusinessProcesses Definition artifact, that are considered an EBP. Larman definesin [1] that “one task performed by a person in a place, in an instant, in re-sponse to an event business, which adds a quantifiable value to the businessand leaves the data in a consistent state is an EBP”. The objective of thisactivity is to filter the processes that define tasks at a very low level, namelyatomic tasks, as are those who do not concern us. In addition, this activitywill filter those activities that require direct interaction of the user with thesystem. Thus, this activity generates one artifact: the EBPs Definition, thatcontains the description of each of them.

– Identify System Goals, Use Cases and Stakeholders: these activi-ties are focused on defining the system goals, stakeholders and requirements(functional and non-functional). A goal is an objective the system under con-sideration should achieve and a feature is an end-user visible characteristic of


a system. There is an overlap between the goal and feature definitions thatmotivates that some authors uses feature models, shown in Section 3.1, fordescribing goals [22]. These goals are obtained from the EBPs identified inthe previous step, due to the realization of a business process covers a set ofgoals [21]. However, there exists other goal-oriented representations, such asTropos [13,14] or i* models [16], that can be used too, depending on severalfactors, such as tool support or non-functional requirements graphical rep-resentation. Figure 4.b sketches the goal model of Send Tickets representedusing a Tropos model. In addition, the stakeholders and requirements aredefined by means of use cases. Thus, these activities generates the follow-ing artifacts: (i) Goal Models ; (ii) Use Case Models ; (iii) Functional andNon-Functional Requirements Descriptions, in a textual representation bymeans of templates, as shown in [19,20], and in a graphical representationusing use cases (the Non-Functional Requirements can be represented us-ing Tropos, as shown in Figure 4.b with the Performance requirement); and(iv) Stakeholder Descriptions, in a textual representation. In addition, oncethese artifacts are obtained, these activities generate a Traceability Matrixbetween them. This matrix represents a table that correlates requirementswith system goals and with business processes. Roughly speaking, this ar-tifact provides a response for the following questions: What requirementsfulfill a system goal? and What system goals are contained into a businessprocess?.

– Introduce Requirement Variability Management: it is focused on in-creasing the reuse of the artifacts obtained at the previous stage. For thatpurpose, some requirement variability techniques has been identified. Theuse of feature models and/or Tropos for defining system goals provides theenough support for representing variability in system goals [15]. The aspectsthat must fulfill any variability representation of a system goal are: (i) estab-lish a hierarchical view of the goals; (ii) represent variation points, definedat Section 3; (iii) represent mandatory, optional and alternative relations;and (iv) provides support for dependencies and cardinalities [18]. For rep-resenting variability in use cases models, there exists several proposals thatextends the standard notation of use case diagrams, such as proposed byGomaa [26] or by Hallmans and Pohl [9], or proposes other notations andlanguages, such as COVAMOF [27]. Figure 4.c shows an use case diagramusing the extensions proposed by Hallmans and Pohl. In addition, there ex-ists approaches for representing variability in the textual representation ofuse cases too, such as proposed by Bertolino [30] or John and Muthig [28].We propose a combination of feature models for representing variability insystem goals and a modification of the traditional use case representation, inorder to specify variabilities. This combination allows to capture variabilityand essential activities of a domain with use cases and to detail common andvariable characteristics with feature diagrams. In addition, both techniqueshas tool support.

– Generate an Elicitation Document: once is enabled the variability sup-port for the artifacts obtained at the previous steps, the last activity is


KLMNOL P QPRNPSNTNUVWXYYPRVZ[PT\][^LT\_RP`LPSNTNUV]PURNa bSUPNOc[YY[OPTNUNL\QPRNPSNTNUV][^LT c[YY[OPTNUNL\WXYYPRVbSUPNO c[RLPO^ QPRNPSTLdLX\PSTL e\\LU\

c[RLe\\LU\ QPRNPSTLe\\LU\WPfL e\\LU\NOU[ P dLg[\NU[RV

bSUPNO hP\N`WURX`UXRL[M UiL c[RLKLMNOL UiL _RPO\M[RYPUN[OdXTL\ U[ P j[Okc[OULaUhl WgL`NMN`PUN[OKLMNOL\ UiLc[Yg[\NUN[OKLMNOL UiL mf[TXUN[O[M UiL nRPYLo[RphP\N`hl] [M c[RL_RPO\M[RYPUN[OdXTL\

c[Yg[\NUN[OWgL`NMN`PUN[Omf[TXUN[OnLPUXRL ][^LTFig. 5. Domain Design overview

oriented on generating an elicitation document that contains all the arti-facts. This document is defined by the artifact named Requirements, thatrepresents the output of the Domain Requirements Engineering activity asshown in Figure 3.b. It contains all the artifacts generated in the previoussteps.

4.2 Domain Design

The Domain Design activity is focused on performing a variability summary ofthe set of businesses identified at the previous step and on providing the corearchitecture of the product line. Figure 5 shows the Domain Design overview.In this stage, the Requirement Engineer performs the following activities:

– Define a Variability Summary and Obtain Commonalities: these ac-tivities are focused on obtaining a variability summary from the Goal Modelartifact, obtained at the Domain Requirements Engineering stage. For thatpurpose, there exists several ways to perform a variability summary, but inour approach we propose the derivation of feature models from system goals[22,21], due to we can analyze them [4] for obtaining the commonalities sum-mary needed to perform the following phase. In addition, with this analysiswe can evaluate the percentage or probability of occurrence of a feature ina product. If this ratio is high, we can consider that the feature is part ofthe core. Thus, we introduce an optional commonality threshold for intro-ducing some features/processes into the core of the product line [12]. Figure1 presents the variability summary of the business family of the case studyby means of feature modeling. In addition, the commonalities summary isprovided on Figure 6.a using feature models too, and introducing ChangeItinerary, Reserve Tickets and Cancel Itinerary into the core of the familyby means of a commonality threshold, as shown in Figure 6.b. Notice that



Change Itinerary

Cancel Itinerary

Reserve Tickets

Reserve Seats

Book Tickets

Order Trip

Book Seats

Send Tickets

Send Statement


CO

MM

ON

ALI

TY (

%)

Threshold = 80%

(A) Commonality Summary of the case study (B) Commonalities of the case study with a threshold = 80%

Fig. 6. Commonalities summary of the case study obtained in Variability Analysisrepresented using feature modeling

if we did not introduce this commonality threshold this processes would notbe into the core architecture of the business family.

– Obtain Core and Variable Reusable Assets Definition: it is focusedon obtaining the reusable assets that are the basis of the core architec-ture. For that purpose, we analyse the Variability Model and CommonalitySummary artifacts, using the operations defined in [4]. The result of thisanalysis provides the set of reusable assets identified as Core and Variablefeatures. Once the reusable assets are obtained, we use the Traceability Ma-trix defined at the Requirements artifact, from the Domain RequirementsEngineering stage, for obtaining the respective equivalence between featuresand business process. Thus, the reusable assets are defined by means of busi-ness process models. These assets are contained into the generated artifactsCore and Variable Assets.

– Save Assets into a Repository: finally, once the assets are obtained anddefined by means of a business process model, we save these reusable assetsinto a repository. The URI of this repository is added into the BusinessFamily Variability Summary artifact.

– Obtain the Basic Structure of the Core: it is focused on obtaining abasic structure of a business process model that represents the core architec-ture. It is represented by the Basic BPM of Core artifact. For that purpose,we propose a derivation from the feature model that represents the VariabilyModel to a business process model. This derivation is based on AutomataTheory and Formal Languages by means of Context-Free Grammar Repre-sentations [10]. The derivation process provides a mapping between featuremodels and business process models that improves the design step of thePFE approach by means of improving the maintainability of feature modelsand BPMN, and eliminating errors derived from manual transformations. Inaddition, we avoid the need of extending the standard notation of BPMNwith information that is present in the feature model. The mapping rulesare defined at [11]. Thus, the variability aspects identified by the PFE ap-



( Number of Seats > 50 and < 100 )

or ( Number of Seats

> 100 )

Inform

Inform byE-Mail

Inform by Intranet

Inform

Expanded

Inform

Collapsed

Inform by Intranet

Inform by E-Mail

VariationPoint

Variants

Send Tickets

Send Tickets

Send Information about Trip

Send Info ...

Send Tickets

Expanded

Send Tickets

Collapsed

SendTickets

Book Tickets

Expanded

Collapsed

Quality Assurance

Book Tickets

BookTickets

Quality Assurance

VariationPoint

Variants

ExtensionPoint

Fig. 7. Variability aspects described by the PFE approach, represented at the deriva-tion stage of Building Core Process Framework

proach, described in Section 3.2, can be represented by the feature modelobtained in the previous variability analysis phase. In addition, these aspectscan be represented by means of the standard BPMN without providing extrainformation using stereotypes. Figure 7 sketches all the variability aspectsdescribed by the PFE approach, using our deriving approach: (A) Alterna-tive behavior is represented by an alternative relation on the feature model,defined at Section 3.1, where the parent feature is considered the variationpoint, and the children are considered variants [22]; and a gateway Xor ofBPMN, which defines that only one subprocess controlled by this gateway,Inform by e-mail or Inform by Intranet, must be completed for performingthe subprocess Inform; (B) Parameterization is resolved by rewriting thecondition for accepting several value ranges; (C) Inheritance is defined bymeans of an Or relation on the feature model, defined at Section 3.1, and agateway Or of BPMN, which defines that almost one subprocess controlledby this gateway, Send Tickets and Send Information about Trip, must becompleted for performing the process Send Tickets ; and finally, (D) Exten-sion Points is defined by means of an optional relation at the feature model,defined at Section 3.1, and an Xor gateway of BPMN with an empty option.The derivation process requires that the feature model is expressed throughan specific characterization based on a merge operation between the Com-monality Summary and the Variability Model, due to we consider the CoreAssets as children nodes into to Commonality Summary feature model, andthe Variable Assets as the variation points of the variability feature modelbranches that are not contained into the Commonality Summary. This arti-fact represents a basic structure of the reusable assets of the business family.In the SPL field the assets are software artifacts. In a business family, theassets are business processes that are defined by means of their respectiveprocess models represented using BPMN. Figure 8 sketches an overview ofthe Core Process Framework. Each business process contained into the com-monality summary is a considered as a component into the framework. Inour case study the processes named Order Trip, Change Itinerary, ReserveTickets and Cancel Itinerary are the core processes that composes the ac-


Airline Travel AgenciesCore Process Framework

Specific Business Process

BP

MN

Reu

sabl

e A

sset

s

Order Trip

Reserve TicketsChange Itinerary

Cancel Itinerary

Inform (from Iberia)

Fig. 8. Overview of Core Process Framework

tivity named Plan&Book. In addition, this framework provides the enoughlinking areas for adapting specific business process from concretes compa-nies, for example introducing into an instance of the framework the businessprocess Inform from Iberia. Figure 9 presents the basic structure of the CoreProcess Framework of our case study in BPMN, obtained from the derivationprocess.

– Define the Transformation Rules to a Non-Context Free BP Spec-ification: it is focused on providing the rules needed to build a non-contextfree business process specification. These rules need to be performed manu-ally by the process engineer. The identified rules are the following: (i) intro-duce the guards into the gateways that defines the conditions; (ii) identifyloops and multiple instances of a subprocess; (iii) introduce start and finaliza-tion specific events (message, timer, etc.); (iv) introduce exception handling;and (v) introduce the stakeholders whose are identified at the RequirementsCapture stage. This activity generates the artifact that contains these rules,namely Transformation Rules.

– Define the Composition: it is focused on providing the mechanisms neededto perform a composition of reusable assets into the Core Process Frame-work. A composition between two or more business process models definethe order of the execution of each business process to be composed. Noticethat we must usually preserve the order of execution of each business processmodel to be composed. We have determined that there exists two differenttypes of business process models composition: Non-Overlap Composition andOverlap Composition. On the one hand, a Non-Overlap Composition is de-fined as a composition between two or more business process models thatdo not consume or generate any needed artifact for other. Roughly speak-ing, these business processes could be considered as independent processesthat do not collaborate with anyone, but all these processes need to be per-formed for performing a concrete activity. Figure 8.c sketches an example ofa Non-Overlap Composition between the Plan&Book process and the Informprocess, identified by means of an URL from the reusable assets repository


Change Itinerary

Cancel Itinerary

Book Tickets

Book Seats

Send Tickets

Send Statement

Verify Seats Availaibility

Airl

ine

Tra

vel A

genc

y

Plan&Book (Core)

Fig. 9. Basic Structure of the Core Process Framework obtained from the derivationprocess

(i.e: companies.iberia.processes.variable.Inform.bpmn). On the otherhand, an Overlap Composition is defined as a composition between two ormore business process models that collaborates between them, in terms ofgenerating and consuming some artifacts between them that rules the de-pendency from other to perform its activities. This type of composition canonly be done manually. Nowadays, one of the topics of our research is fo-cused on providing algorithms for assisting these kinds of composition andfor checking the consistency of the composed business process models. Forthat purpose, we take the algorithms presented in [25] as starting point forthis future work.

– Define the Evolution of the Framework: it is focused on defining theevolving behavior of the Core Process Framework. Roughly speaking, we canconsider the Core Process Framework as an evolving system, defining theseevolutions as each addition or reduction of some business process models intothe core architecture by means of the compositions defined at the previousstep. Thus, the main difference between the process framework provided bythe PFE approach and our Core Process Framework is that PFE defines onlyone product (core architecture) not variable, and our approach provides avariable core architecture managed as a set of products using SPL techniques.For that purpose, in order to represent this variability is needed to defineother mechanisms for describing the evolving behavior of the architecture.We have explored the feasibility of several SPL techniques in [17], and weconsider that the variability of this architecture can be supported by meansof feature modeling techniques. Thus, this activity generates the artifact thatrepresents these evolutions, namely Evolution Feature Model.


Fig. 10. Tool Support

5 Tooling Business Family Domain Engineering

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

For that purpose, we have performed a transformation between the FeAtureModel Analyzer (FAMA) [29] metamodel as source and the Eclipse SOA ToolPlatform2 BPMN metamodel as target metamodel using the Atlas Transforma-tion Language (ATL). Figure 10 presents and screenshot of this tool. It has beenpublished on Eclipse ATL website. ATL code and specification is available inhttp://www.eclipse.org/m2m/atl/atlTransformations/#FM2BPMN.

6 Related Work

According to [2], to perform a survey in the software engineering field, we haveto define an analysis framework with the following components:(i) research ques-tions : How many approaches explore the reuse of business process models?; (ii)a search strategy to select sources: we have searched the bibliography appearing

2 http://www.eclipse.org/stp


at DBLP, Google Scholar and ISI Web of Knowledge choosing those papers witha higher number of cites; and finally (iii) a catalogue: we classify the approachesin those focused on applying SPL techniques, and those focused on other fields.

After searching the selected sources, we have found the following proposals:(i) Bayer et al. [3] proposes the Process Family Engineering (PFE) approach formodeling variant-rich processes and reuse its definitions into a product line archi-tecture. This approach is introduced in Section 3.2. The PFE approach exploresthe idea of using feature models for managing variability in a business infor-mation system context, but the relationship between these feature models andits products, defined by means of business process models, is not clearly defined[11]. In addition, the PFE approach identifies some variability aspects in businessprocess models, and proposes to introduce some stereotypes for representing it.This redefinition of the syntax implies some maintenance drawbacks identifiedin Section 3.2; (ii) Van der Aalst et al. [8] proposes an extension of YAWL (YetAnother Workflow Language), named extended workflow-nets (EWF-nets), forperforming configurable and reusable workflow definitions of business processes.YAWL is a workflow modelling language inspired by Petri nets for defining busi-ness process models. However, although this approach provides a formalizationof EWF-nets for defining possible variations into a workflow, it does not pro-vide support for other notations, such as BPMN. In addition, the application ofSPL techniques is not explored; and (iii) Ciuksys et al. [6] proposes an approachto reuse of business processes knowledge at domain engineering. For that pur-pose, it provides a process ontology for introducing semantic information intoa business process model. Thus, this approach propose to analyse this semanticinformation for obtaining a commonality summary, but without defining how torepresent these reusable assets.

7 Conclusions and Future Work

We have explored the current reusability techniques of business process modelsacross several companies that shares a set of common processes. Thus, we havedetected that some Software Product Line (SPL) techniques can be exploited forincreasing the business process definitions reusability, and in addition improvingthe design of highly variable business process models. The main motivation ofthis paper is to provide a methodology that taking into account this techniquesmakes feasible the possibility of develop families of business information systems.For that purpose, as shown in Section 4, we provide a methodology namedBusiness Family Engineering, and we define the fragment of this methodologyfocused on obtaining the core architecture of the family, namely Business FamilyDomain Engineering. The activities proposed at this stage has been performed ina real-life case study defined in the Web Service Choreography Interface (WSCI)specification. In addition, as proof of concepts, we have developed an Eclipsetool that provides support for this methodology fragment.

The main research lines of the future work derived from this paper are thefollowing: (i) providing a rigorous description of the activities of Business Fam-


ily Application Engineering; (ii) exploring how to provide support into the CoreProcess Framework for concrete participants; (iii) defining the composition al-gorithms between business processes into the Core Process Framework ; and (iv)tooling the Business Family Engineering approach.

References

1. C. Larman. UML and Patterns. An Introduction to Object-Oriented Analysis andDesign and Unified Process. Second Edition. Prentice-Hall.

2. L. Barachisio, V. Cardoso, E. Santana, and S. Lemos. A Systematic Review on Do-main Analysis Tools. In Proceedings of the International Symposium on EmpiricalSoftware Engineering and Measurement. ESEM07, 2007.

3. J. Bayer, W. Buhl, C. Giese, T. Lehner, A. Ocampo, F. Puhlmann, E. Richter,A. Schnieders, J. Weiland, and M. Weske. Process Family Engineering. ModelingVariant-Rich Processes. PESOA-Report No. 18/2005.

4. D. Benavides, A. Ruiz-Cortes, and P. Trinidad. Automated Reasoning on FeatureModels. LNCS, Advanced Information Systems Engineering: 17th InternationalConference, CAiSE 2005, 3520:491-503, 2005.

5. BPMI. Business Process Modeling Notation BPMN Version 1.0 - may 3, 2004.OMG.

6. D. Ciuksys and A. Caplinskas. Ontology-based Approach to Reuse of BusinessProcess Knowledge. Informacijos Mosklai ISSN:1392-0561, (42-43):168-174, 2007

7. K. Czarnecki and M. Antkiewicz. Mapping Features to Models: A Template Ap-proach Based on Superimposed Variants. Generative Programming and Compo-nent Engineering, (422-437). 2005.

8. F. Gottschalk, W. van der Aalst, M. Jansen-Vullers, and M. L. Rosa. Configurableworkflow models. BETA Working paper 222, Eindhoven University of Technology,The Netherlands, June 2007.

9. G. Halmans and K. Pohl. Communicating the Variability of a Software-ProductFamily to Customers. Inform., Forsch. Entwickl., 18(3-4):113-131, 2004.

10. J. Hopcroft and J. Ullman. Introduction to Automata Theory, Languages, andComputation. Addison-Wesley, Reading, Massachusetts, 1979.

11. I. Montero, J. Pena, and A. Ruiz-Cortes. Improving the Design of Highly Variant-Rich Business Process Models (Under Review). In Proceedings of IEEE Inter-national Conference on Services Computing (SCC08), 2008. Draft version at:http://www.isa.us.es/uploads/tools/fm2bpmn/doc/draft.pdf

12. J. Pena, M. Hinchey, A. Ruiz-Cortes, and P. Trinidad. Building the Core Architec-ture of a NASA Multiagent System Product Line. In 7th International Workshopon Agent Oriented Software Engineering 2006, Hakodate, Japan, May, 2006. LNCS.

13. J. Castro, M. Kolp, J. Mylopoulos Towards Requirements-Driven Software Devel-opment Methodology: The Tropos Project, Information Systems, June 2002.

14. A. Lapouchnian, Y. Yu, and J. Mylopoulos. Requirements-Driven Design and Con-figuration Management of Business Processes. Proceeding of 5th InternationalConference on Business Process Management (BPM 2007), Brisbane, Australia,September 24-28, LNCS Vol. 4714, pp. 246-261, Springer-Verlag, 2007.

15. Y. Yu, A. Lapouchnian, S. Liaskos J. Mylopoulos, J.C.S.P. Leite. From Goals toHigh-Variability Software Design. (To appear) In Proc. 17th International Sym-posium on Methodologies for Intelligent Systems (ISMIS 2008), Toronto, Canada,May 20-23, 2008, pp. 1-16. Invited Paper.


16. AK. Ghose, G. Koliadis, A. Vranesevic, M. Bhuiyan, and A. Krishna. Combining i*and BPMN for Business Process Model Lifecycle Management. Proceedings of theBPM 2006 Workshop on Grid and Peer-to-Peer based Workflows, Lecture Notesin Computing Science, 2007.

17. I. Montero, J. Pena, and A.Ruiz-Cortes. Representing Runtime Variability inBusiness-Driven Development Systems. Proceedings of the 7th International Con-ference on Composition-based Software Systems. 228-231. ICCBSS 2008.

18. P. Schobbens, P. Heymans, and J. Trigaux. Feature Diagrams: A Survey and aFormal Semantics. Proceedings of the 14th IEEE International Requirements En-gineering Conference (RE 2006).

19. A. Cockburn. Structuring use cases with goals. Journal of Object-Oriented Pro-gramming, 1997.

20. A. Duran. Un Entorno Metodologico de Ingenieria de Requisitos para Sistemas deInformacion. PhD dissertation, University of Seville, 2000.

21. J. Bae and S. Kang. A Method to Generate a Feature Model from a Business Pro-cess Model for Business Applications. Proceedings of the 7th IEEE InternationalConference on Computer and Information Technology (CIT 2007).

22. K. Pohl, G. Bockle, and F. van der Linden. Software Product Line Engineering:Foundations, Principles and Techniques. Springer, September 2005.

23. J. Schulz-Hofen and S. Golega. Generating Web Applications from Process Models.In ICWE ’06: Workshop proceedings of the sixth international conference on Webengineering, page 6, New York, NY, USA, 2006. ACM.

24. W3C. Web service choreography interface (WSCI) 1.0, nov. 2002.http://www.w3.org/tr/wsci.

25. J. Pena, R. Corchuelo and J.L. Arjona. Towards Interaction Protocol Operationsfor Large Multi-agent Systems. Proceedings of FAABS’02, volume 2699 of LNAI,pages 79-91, MD, USA, 2002. Springer-Verlag.

26. H. Gomaa. Modeling Software Product Lines with UML. Proceedings of the SecondInternational Workshop on Software Product Lines: Economics, Architectures andImplications (2001)

27. M. Sinnema, S. Deelstra, J. Nijhuis, and J. Bosch. COVAMOF: A Framework forModeling Variability in Software Product Families, volume 3154. Lecture Notes inComputer Science, January 2004.

28. I. John and D. Muthig. Tailoring use cases for product line modeling. Proceedingsof the International Workshop on Requirements Engineering for Product Lines.September 2002.

29. D. Benavides, S. Segura, P. Trinidad, and A. Ruiz-Cortes. FAMA: Tooling a Frame-work for the Automated Analysis of Feature Models, Proceeding of the First In-ternational Workshop on Variability Modelling of Software-intensive Systems (VA-MOS) 2007.

30. A. Bertolino, A. Fantechi, S. Gnesi, G. Lami, and A. Maccari. Use Case Descriptionof Requirements for Product Lines. In Proceedings of the International Workshopon Requirements Engineering for Product Lines. September 2002.

31. A. Schnieders and F. Puhlmann. Variability Mechanisms in E-business ProcessFamilies. Proceedings of 9th International Conference on Business InformationSystems BIS 2006.

Appendix B

Curriculum vitae

T he Curriculum vitae of the author of this research report is enclosedin the following in Spanish. Further information can be provided at

request if necessary.

Situación Profesional Actual

Puesto: Analista, Consultor. Empresa u Organismo: Ingeniería e Integración Avanzadas (Ingenia). Fecha de Inicio: Abril de 2008. Descripción: Asesoramiento, consultoría y coordinación en el proceso de implantación de sistemas de Tramitación Electrónica en la Consejería de Empleo de la Junta de Andalucía. También he trabajado en el análisis funcional del proyecto: LibrAE (LibreA / LibrEx) Junta de Andalucía y Junta de Extremadura y como analista programador en los proyectos para la Administración pública ATIPES (Actuaciones Territoriales Integrales Preferentes para el Empleo) - Cliente: Servicio Andaluz de Empleo y SIVAS (Sistema Interno de Vigilancia del Área de Salud) - Cliente: Consejería de Empleo.

Actividades Anteriores de Carácter Científico Profesional

Becario FPI Ministerio de Educación y Ciencia Becario FPI Ministerio de Educación y Ciencia. Departamento de Lenguajes y Sistemas Informáticos de la Universidad de Sevilla. Fecha de Inicio: Agosto 2007. Analista Programador Analista Programador. Dynagent Software SL. Sevilla. Fecha de Inicio: Febrero 2007. Programador Junior Programador Junior. Soltel Soluciones Informáticas SL. Sevilla. Outsourcing en la UTE Tecnológica formada por Accenture y Sadiel para el desarrollo de los sistemas comerciales de Endesa. Fecha de Inicio: Septiembre 2006. Personal Investigador Personal Investigador del Proyecto: TIN2006-00472. Departamento de Lenguajes y Sistemas Informáticos Universidad de Sevilla. Fecha de Inicio: Julio de 2007. Becario Becario de Apoyo Adscrito al proyecto MCYT TIC2003-02737-C. Departamento de Lenguajes y Sistemas Informáticos. Fecha de Inicio: Septiembre de 2006. Redactor de contenidos Redactor de contenidos Freelance. Portalmundos.com. Fecha de Inicio: Diciembre de 2006.

Becario Fidetia Soltel Soluciones Informáticas SL. Sevilla. Outsourcing en la UTE Tecnológica formada por Accenture y Sadiel para el desarrollo de los sistemas comerciales de Endesa. Fecha de Inicio: Marzo de 2006. Formador Tecnofor Sur. Cádiz. Impartición de cursos de informática a empleados de la empresa La Bazán, San Fernando, Cádiz. Fecha de Inicio: Febrero de 2006. Becario de Colaboración Departamento de Ciencias de la Computación e Inteligencia Artificial. Universidad de Sevilla. Fecha de Inicio: Noviembre de 2005. Otros Becario del Secretariado de Acceso y Orientación del Vicerrectorado de Alumnos de la Universidad de Cádiz. Cádiz. Fecha de Inicio: Septiembre de 2003. Becario del Vicerrectorado de Alumnos de la Universidad de Cádiz. Cádiz. Fecha de Inicio: Octubre de 2002.

Formación Académica

Postgrado Doctorado en Tecnología e Ingeniería del Software (Cursando actualmente) Segundo Ciclo Ingeniero Informático por la Universidad de Sevilla. Junio de 2006. Primer Ciclo Ingeniero Técnico en Informática de Gestión por la Universidad de Cádiz. Junio de 2004.

Formación Complementaria

Acreditación de Nivel de Lengua Inglesa B2 según el Marco de Referencia Europeo del Vicerrectorado de Extensión Universitaria de la Universidad de Cádiz. Junio de 2004. Curso: “Enterprise Architect”. Deisser Formacion. Noviembre de 2008. Duración: 3 días. Curso: “Aleman Básico”. Grupo Fexmsa. Noviembre de 2008. Duración: 60h.

Curso: “Gestion de la Calidad”. Asistencia IDEAL. Noviembre de 2008. Duración: 60h. Curso: “Dirección y Desarrollo de Equipos de Trabajo”. Asistencia IDEAL. Diciembre de 2008. Duración: 60h. Curso: “Gestion de Empresas”. Asistencia IDEAL. Diciembre de 2008. Duración: 60h. Curso de Verano de la Universidad de Cádiz: “Accesibilidad en la Web”. Vicerrectorado de Extensión Universitaria de la Universidad de Cádiz. Agosto de 2004. Duración: 3 días. Curso: “Programación páginas web: JavaScript”. Junta de Andalucía. Consejería de Empleo. Servicio Andaluz de Empleo y SU&MA Consultores SL. Duración: 14/03/2006 a 21/04/2006. 50h. Curso: “La Edición Multimedia en Internet”. Junta de Andalucía. Consejería de Empleo. Servicio Andaluz de Empleo y Santillana Formación SL. Duración: 19/04/2004 a 15/06/2004. 210h. Curso: “Introducción a ASP .NET”. Junta de Andalucía. Consejería de Empleo. Servicio Andaluz de Empleo y Formación Digital SL. Duración: 13/03/2006 a 28/04/2006. 40h. Curso: “Diseño e Implementación de Bases de Datos Relacionales”. Ministerio de Industria, Turismo y Comercio. Forintel. Inated. Duración: Enero de 2007. 30h Curso: “XML”. Ministerio de Industria, Turismo y Comercio. Forintel. Inated. Duración: Marzo de 2007. 30h Curso: “Java”. Ministerio de Industria, Turismo y Comercio. Forintel. Inated. Duración: Marzo de 2007. 30h Curso: “Linux”. Ministerio de Industria, Turismo y Comercio. Forintel. Inated. Duración: Febrero de 2007. 30h Curso: “JavaScript”. Ministerio de Industria, Turismo y Comercio. Forintel. Inated. Duración: Marzo de 2007. 30h Curso: “Programación Avanzada de Sitios Web”. Ministerio de Industria, Turismo y Comercio. Forintel. Inated. Duración: Febrero de 2007. 50h Curso: “PHP y MySQL”. Ministerio de Industria, Turismo y Comercio. Forintel. Inated. Duración: Enero de 2007. 50h Curso: “Protección de Datos de Carácter Personal”. Ministerio de Industria, Turismo y Comercio. Forintel. Inated. Duración: Noviembre de 2006. 50h Curso: “Oracle 9.i”. Ministerio de Industria, Turismo y Comercio. Forintel. Inated. Duración: Noviembre de 2006. 50h

Curso: “Creación de Sitios Web”. Ministerio de Industria, Turismo y Comercio. Forintel. Inated. Duración: Enero de 2007. 30h Curso: “Configuración de Servidores Windows”. Ministerio de Industria, Turismo y Comercio. Forintel. Inated. Duración: Marzo de 2007. 50h Curso: “Accesibilidad Web”. Ministerio de Industria, Turismo y Comercio. Forintel. Fundetel. Duración: 40h Curso: “Java”. Ministerio de Industria, Turismo y Comercio. Forintel. Inated. Duración: Marzo de 2007. 50h Seminario “Las Ventajas del Software Libre en el Ámbito Empresarial”. Confederación de Empresarios de la provincia de Cádiz. Marzo de 2004. Duración: 3h. Seminario “Linux”. Forinsur S.L. Centro de Formación. Mayo de 2004. Duración: 3h. Seminario “Diseño de páginas web” Forinsur S.L. Centro de Formación. Mayo de 2004. Duración:3h. Seminario “Flash”. Forinsur S.L. Centro de Formación. Mayo de 2004. Duración 3h. II Ciclo de Conferencias de Estadística Aplicada. Departamento de Estadística e Investigación Operativa de la Universidad de Cádiz. Marzo de 2000. Duración: 2 días. Microtaller: “Técnicas de Entrevista de Selección”. Vicerrectorado de Alumnos de la Universidad de Cádiz. Febrero de 2002. Duración: 1h.

Ayudas y Becas

Becario FPI Ministerio de Educación y Ciencia. Departamento de Lenguajes y Sistemas Informáticos de la Universidad de Sevilla. Fecha de Inicio: Agosto de 2007 Becario adscrito al proyecto MCYT TIC2003-02737-C. Departamento de Lenguajes y Sistemas Informáticos. Fecha de Inicio: Septiembre de 2006. Becario Fidetia. Soltel Soluciones Informáticas SL. Sevilla. Outsourcing en la UTE Tecnológica formada por Accenture y Sadiel para el desarrollo de los sistemas comerciales de Endesa. Fecha de Inicio: Marzo de 2006 Becario de Colaboración. Departamento de Ciencias de la Computación e Inteligencia Artificial. Universidad de Sevilla. Fecha de Inicio: Noviembre de 2005 Becario del Secretariado de Acceso y Orientación del Vicerrectorado de Alumnos de la Universidad de Cádiz. Cádiz. Fecha de Inicio: Septiembre de 2003.

Becario del Vicerrectorado de Alumnos de la Universidad de Cádiz. Cádiz. Fecha de Inicio: Octubre de 2002.

Participación en Proyectos de Investigación

Proyecto: Ingeniería de Sistemas Abiertos Basada en Líneas de productos (ISABEL) Financiación: Consejería de Innovación Ciencia y Empresa de la Junta de Andalucía, Ministerio de Ciencia y Tecnología Participantes: Universidad de Sevilla, Universidad Politécnica de Valencia, Universidad de Loyola (EEUU), Universidad del Ulster EPOS: Isotrol, Telvent, Ingenia, Hospital Universitario Virgen del Rocío. Duración: 2008-2011 Responsable: Antonio Ruiz Cortés (Universidad de Sevilla) Número total de participantes: 18 Presupuesto: 410.421 € Proyecto: WEB-FACTORIES. Fábricas Software para Sistemas con Arquitectura Orientada a Servicios Web. Financiación: Ministerio de Ciencia y Tecnología (TIN2006-00472). Participantes: Universidad de Sevilla y Universidad de Huelva. EPOS: XimetriX network Thoughts, Telvent Interactiva S.A, Acromática S.L, Isotrol, Laboratorio de Ingeniería del Software de la NASA y Consejería de Innovación Ciencia y Empresa de la Junta de Andalucía. Duración: 2007-2009 Responsable: Antonio Ruiz Cortés (Universidad de Sevilla) Número total de participantes: 16 Presupuesto: 229.200 € Proyecto: AGILWEB. Desarrollo de aplicaciones basadas en servicios Web. Financiación: Ministerio de Ciencia y Tecnología. TIC2003-02737-C02-01 Participantes: Universidad de Sevilla y Universidad de Castilla-La Mancha. Duración: 2003-2006 Responsable: Miguel Toro Bonilla (Universidad de Sevilla) Número total de participantes: 12 Presupuesto: 191.200 €

Contribuciones a Congresos y Conferencias Científicas

Contribuciones a congresos Congresos indexados del tercio superior de CiteSeerX, CORE o CSCR, o con índice de aceptación inferior al 33%

I. Montero, J. Peña, A. Ruiz-Cortés, "From Features Models To Business Processes", IEEE Conference on Services Computing (SSC), 2: 605-608, July, 2008. [CORE: A]

Congresos indexados del tercio medio de CiteSeerX, CORE o CSCR, o con actas publicadas por Springer, IEEE o ACM

I. Montero, J. Peña, A. Ruiz-Cortés, "Representing Runtime Variability in Business-Driven Development Systems - Poster", 7th Int. Conf. on Composition-Based Software Systems (ICCBSS), pp. 241, February, 2008. [CORE: B]

I. Montero, J. Peña, A. Ruiz-Cortés, "Representing Runtime Variability in Business-Driven Development Systems", 7th. Int. Conf. on Composition-Based Software Systems (ICCBSS08), pp. 228-231, February, 2008. [CORE: B]

CITADO EN

G.Perrouin, F. Chauvel, J. deAntoni, J. Jézéequel. "Modeling the Variability Space of Self-Adaptive Applications". IEEE Computer Society 2nd International Workshop on Dynamic Software Product Lines (DSPL 2008, Volume 2), in conjunction with SPLC08, pp.15–22, Limerick, Ireland, 2008.

Otras contribuciones a congresos y talleres de trabajo internacionales I. Montero, J. Peña, A. Ruiz-Cortés, "Towards Visualisation and Analysis of Runtime Variability in Execution Time of Business-Driven Development Systems", 2nd. International Workshop on Variability Modelling of Software-intensive Systems (VAMOS), pp. 151-160, January, 2008.

CITADO EN

K. Schmid, H.Eichelberger. "From Static to Dynamic Software Product Lines" IEEE Computer Society 2nd International Workshop on Dynamic Software Product Lines (DSPL 2008, Volume 2), in conjunction with SPLC08, Limerick, Ireland, 2008.

I. Montero, J. Peña, A. Ruiz-Cortés, "Business Family Engineering. Managing The Evolution Of Business-Driven Development Systems", SPLC International Workshop on Dynamic Software Product Line (DSPL), pp. 33-40, September, 2007.

Otras contribuciones a congresos y talleres de trabajo nacionales I. Montero, J. Peña, A. Ruiz-Cortés, "Business Family Engineering. Does it make sense?", I JISBD Taller sobre Procesos de Negocio e Ingeniería del Software (PNIS), pp. 34-40, September, 2007.

I. Montero, "An Open-Source Framework to Develop Web Solutions based on Software Product Lines". I International Conference of Free Libre Open Source Systems. Jerez de La Frontera, España. FLOSSIC (2006). pp. 133-140

Experiencia Docente

Curso Académico: 2007-2008 Asignatura: Ingeniería del Software de Gestión II Titulación: Ingeniería Técnica en Informática de Gestión. Universidad de Sevilla Curso: 3 Nº Créditos Impartidos: 0,8 Curso Académico: 2007-2008 Asignatura: Ingeniería del Software de Gestión I Titulación: Ingeniería Técnica en Informática de Gestión. Universidad de Sevilla Curso: 2 Nº Créditos Impartidos: 0,2

Otros Méritos

Implementación y publicación en el repositorio del proyecto ATL de Eclipse de un conjunto de transformaciones basadas en técnicas MDA. Disponibles en: http://www.eclipse.org/m2m/atl/atlTransformations/#FM2BPMN Miembro del comité organizador de la conferencia: International Conference of Free Libre Open Source Systems. Jerez de La Frontera, España. FLOSSIC (2006). Edición del libro de actas de la conferencia: International Conference of Free Libre Open Source Systems. Jerez de La Frontera, España. FLOSSIC (2006). M. Palomo, I. Montero. Programación en PHP a partir de ejemplos. Apuntes de la asignatura: Programación en Internet de Ingeniería Técnica de Informática de Gestión de la Universidad de Cádiz.

Certificación de alumno monitor de clases prácticas de la asignatura “Introducción a la Inteligencia Artificial” de la Universidad de Cádiz, Curso 2002/03 Impartición de seminario “Diseño en CLIPS de Sistemas Expertos basados en reglas”. Curso 2002/03. Duración: 20h. Departamento de Lenguajes y Sistemas Informáticos de la Universidad de Cádiz Impartición de seminario “Diseño y Aplicación del Lenguaje CLIPS para la generación de Sistemas Expertos basados en Reglas”. Curso 2003/04. Duración: 20h. Departamento de Lenguajes y Sistemas Informáticos de la Universidad de Cádiz

Impartición de seminario “Documentar variabilidad de requisitos en fábricas software”. Curso 2006/07. Departamento de Lenguajes y Sistemas Informáticos de la Universidad de Sevilla.

Referencias Web

Listado de publicaciones del DBLP Bibliography Server http://www.informatik.uni-trier.de/~ley/db/indices/a-tree/m/Montero:Ildefonso.html

Ficha personal en el sistema SISIUS (Sistema de Información sobre Investigación - Universidad de Sevilla). Contiene información acerca de grupos de investigación, proyectos y publicaciones http://investigacion.us.es/sisius/sis_showpub.php?idpers=12508

Listado de publicaciones dentro del grupo de Ingenieria del Software Aplicada http://www.isa.us.es/modules/publications/init.php?idAuthor=17 Blog de resultados obtenidos y publicaciones, con respecto a mi investigación en el campo del modelado de procesos de negocio. http://bpm-research.blogspot.com

102 Appendix B. Curriculum vitae

Appendix C

Bibliography

[1] Unified Modeling Language. 2.1.1 edition, feb 2007. Object Management Group(OMG).

[2] G. Alonso, P. Dadam, and M. Rosemann, editors. Business Process Management,5th International Conference, BPM 2007, Brisbane, Australia, September 24-28,2007, Proceedings, volume 4714 of Lecture Notes in Computer Science. Springer,2007.

[3] J. Bae and S. Kang. A method to generate a feature model from a business pro-cess model for business applications. In CIT ’07: Proceedings of the 7th IEEEInternational Conference on Computer and Information Technology (CIT 2007),pages 879–884, Washington, DC, USA, 2007. IEEE Computer Society.

[4] L. Barachisio, V. Cardoso, E. Santana, and S. Lemos. A systematic review ondomain analysis tools. In Proceedings of the International Symposium on Em-pirical Software Engineering and Measurement. ESEM07., 2007.

[5] D. Batory. Feature models, grammars, and propositional formulas. In J. H. Ob-bink and K. Pohl, editors, SPLC, volume 3714 of Lecture Notes in ComputerScience, pages 7–20. Springer, 2005.

[6] J. Bayer, W. Buhl, C. Giese, T. Lehner, A. Ocampo, F. Puhlmann, E. Richter,A. Schnieders, J. Weiland, and M. Weske. Process family engineering. model-ing variant-rich processes. Technical report.

[7] D. Benavides, A. Ruiz-Cortés, and P. Trinidad. Automated reasoning on featuremodels. LNCS, Advanced Information Systems Engineering: 17th InternationalConference, CAiSE 2005, 3520:491–503, 2005.

[8] A. Bertolino, A. Fantechi, S. Gnesi, G. Lami, and A. Maccari. Use case descriptionof requirements for product lines. In Proceedings of the International Workshopon Requirements Engineering for Product Lines 2002 - REPL’02, pages 12–18,2002.

[9] J. Bocanegra, J. Peña, and A. Ruiz-Cortés. Una aproximación mda para mode-lar transacciones de negocio a nivel cim. In V JISBD Taller sobre Desarrollo deSoftware Dirigido por Modelos (DSDM), pages 82–91, Gijón. Spain, Oct 2008.

[10] BPMI. Business Process Modeling Notation BPMN version 1.0 - may 3, 2004.Object Management Group (OMG).

104 Bibliography

[11] E. Börger and B. Thalheim. A Semantical Framework for Busi-ness Process Modeling. With an Application to BPMN. Available athttp://www.di.unipi.it/ boerger/CourseMaterial/Bpmn.pdf. 2007.

[12] A. Brown. Practical Approaches to Delivering Service-Oriented Solutions: TheRole of Software Architects and Architecture in a SOA World. In 7th. Int. Conf.on Composition-Based Software Systems (ICCBSS08), page 16, Madrid, Spain,Feb 2008. IEEE Computer Society Press.

[13] J. Castro, M. Kolp, and J. Mylopoulos. Towards requirements-driven informa-tion systems engineering: The tropos project, 2002.

[14] D. Ciuksys and A. Caplinskas. Ontology-based approach to reuse of businessprocess knowledge. Informacijos Mosklai ISSN:1392-0561, (42-43):168–174, 2007.

[15] A. Cockburn. Structuring use cases with goals. Journal of Object-Oriented Pro-gramming, 1997.

[16] K. Czarnecki and M. Antkiewicz. Mapping Features to Models: A TemplateApproach Based on Superimposed Variants. 2005.

[17] A. K. A. de Medeiros, C. Pedrinaci, W. M. P. van der Aalst, J. Domingue, M. Song,A. Rozinat, B. Norton, and L. Cabral. An outlook on semantic business processmining and monitoring. In R. Meersman, Z. Tari, and P. Herrero, editors, OTMWorkshops (2), volume 4806 of Lecture Notes in Computer Science, pages 1244–1255. Springer, 2007.

[18] G. Decker, O. Kopp, F. Leymann, K. Pfitzner, and M. Weske. Modeling servicechoreographies using bpmn and bpel4chor. In Z. Bellahsene and M. Léonard,editors, CAiSE, volume 5074 of Lecture Notes in Computer Science, pages 79–93. Springer, 2008.

[19] G. Decker, O. Kopp, F. Leymann, and M. Weske. BPEL4Chor: Extending BPELfor Modeling Choreographies. In ICWS, pages 296–303. IEEE Computer Society,2007.

[20] G. Decker and M. Weske. Local Enforceability in Interaction Petri Nets. InAlonso et al. [2], pages 305–319.

[21] R. M. Dijkman, M. Dumas, and C. Ouyang. Formal Semantics and AutomatedAnalysis of BPMN Process Models. Preprint:7115, Queensland University ofTechnology, April 2007.

[22] A. Durán. A Methodological Framework for Requirements Engineering of In-formation Systems (in Spanish). PhD thesis, University of Seville, 2000.

[23] J. Fabra, J. Pena, A. Ruiz-Cortés, and J. Ezpeleta. Enabling the Evolution ofService-Oriented Solutions Using an UML2 Profile and a Reference Petri NetsExecution Platform. In ICIW ’08: Proceedings of the 2008 Third InternationalConference on Internet and Web Applications and Services, pages 198–204,Washington, DC, USA, 2008. IEEE Computer Society.

[24] H. Gomaa. Modeling software product lines with uml. In Proceedings of theSecond International Workshop on Software Product Lines: Economics, Archi-tectures and Implications, pages 27–31, 2001.

[25] H. Gomaa. Feature dependent coordination and adaptation of component-basedsoftware architectures. In WCAT ’07: Proceedings of the 4th Workshop on Co-ordination and Adaptation Techniques for Software Entities, 2007.

Bibliography 105

[26] F. Gottschalk, W. van der Aalst, M. Jansen-Vullers, and M. L. Rosa. Configurableworkflow models. BETA Working paper 222, Eindhoven University of Technol-ogy, The Netherlands, June 2007.

[27] G. Halmans and K. Pohl. Communicating the variability of a software-productfamily to customers. Inform., Forsch. Entwickl., 18(3-4):113–131, 2004.

[28] A. Hofstede and W. van der Alst. Workflow Patterns: On the Expressive Powerof (Petri-Net-Based) Workflow Languages. Technical report.

[29] J. Hopcroft and J. Ullman. Introduction to Automata Theory, Languages, andComputation. Addison-Wesley, Reading, Massachusetts, 1979.

[30] I. John and D. Muthig. Tailoring use cases for product line modeling. In Pro-ceedings of the International Worksho on Requirements Engineering for ProductLines (REPL’02), September 2002.

[31] G. Koliadis, A. Vranesevic, M. Bhuiyan, A. Krishna, and A. K. Ghose. Combining* and bpmn for business process model lifecycle management. In J. Eder andS. Dustdar, editors, Business Process Management Workshops, volume 4103 ofLecture Notes in Computer Science, pages 416–427. Springer, 2006.

[32] A. Koschmider and A. Oberweis. How to detect semantic business processmodel variants? In SAC ’07: Proceedings of the 2007 ACM symposium onApplied computing, pages 1263–1264, New York, NY, USA, 2007. ACM.

[33] A. Lapouchnian, Y. Yu, and J. Mylopoulos. Requirements-driven design andconfiguration management of business processes. In Alonso et al. [2], pages246–261.

[34] C. Larman. Applying UML and Patterns: An Introduction to Object-OrientedAnalysis and Design and the Unified Process (2nd Edition). Prentice Hall PTR,2 edition, July 2001.

[35] I. Montero, J. Peña, and A. Ruiz-Cortés. Business family engineering. does itmake sense? In I JISBD Taller sobre Procesos de Negocio e Ingeniería del Soft-ware (PNIS), pages 34–40, Zaragoza, Spain, Sep 2007.

[36] I. Montero, J. Peña, and A. Ruiz-Cortés. Business family engineering. managingthe evolution of business-driven. In SPLC International Workshop on DynamicSoftware Product Line (DSPL), pages 33–40, Kyoto, Japan, Sep 2007.

[37] I. Montero, J. Peña, and A. Ruiz-Cortés. From Features Models To BusinessProcesses. In IEEE Conference on Services Computing (SSC), volume 2, pages605–608, Honolulu, HI, Jul 2008. IEEE Computer Society Press.

[38] I. Montero, J. Peña, and A. Ruiz-Cortés. Representing Runtime Variability inBusiness-Driven Development systems. In Proceedings of the Seventh Interna-tional Conference on Composition-Based Software Systems (ICCBSS08), 2008.

[39] I. Montero, J. Peña, and A. Ruiz-Cortés. Representing runtime variability inbusiness-driven development systems - poster. In 7th Int. Conf. on Composition-Based Software Systems (ICCBSS), page 241, Madrid, Spain, Feb 2008. IEEEComputer Society Press.

[40] I. Montero, J. Peña, and A. Ruiz-Cortés. Towards visualisation and analysis ofruntime variability in execution time of business-driven development systems.In 2nd. International Workshop on Variability Modelling of Software-intensiveSystems (VAMOS), pages 151–160, Universität Duisburg-Essen, Germany, Jan2008. ICB Research Report No 22.

106 Bibliography

[41] J. Peña. On Improving The Modelling Of Complex Acquaintance OrganisationsOf Agents. A Method Fragment For The Analysis Phase. PhD thesis, Universityof Seville, 2005.

[42] J. Peña, R. Corchuelo, and J. Arjona. Towards a top down approach for mas pro-tocol descriptions. In ZOCO: Métodos y Herramientas para el Comercio Elec-trónico, pages 91–102, San Lorenzo del Escorial, Spain, 2002.

[43] J. Peña, R. Corchuelo, and J. L. Arjona. Towards Interaction Protocol Operationsfor Large Multi-agent Systems. In Proceedings of FAABS’02, volume 2699 ofLNAI, pages 79–91, MD, USA, 2002. Springer–Verlag.

[44] J. Peña, M. G. Hinchey, and P. T. A. Ruiz-Cortés. Building the core architecture ofa nasa multiagent system product line. In 7th International Workshop on AgentOriented Software Engineering 2006, Hakodate, Japan, May, 2006. LNCS.

[45] G. Perrouin, F. Chauvel, J. DeAntoni, and J.-M. Jézéquel. Modeling the vari-ability space of self-adaptive applications. In S. Thiel and K. Pohl, editors, 2ndDynamic Software Product Lines Workshop (SPLC 2008, Volume 2), pages 15–22, Limerick, Ireland, Sept. 2008. IEEE Computer Society.

[46] K. Pohl, G. Böckle, and F. van der Linden. Software Product Line Engineering:Foundations, Principles and Techniques. Springer, September 2005.

[47] K. Pohl and A. Metzger. Variability Management in Software Product Line Engi-neering. In ICSE ’06: Proceeding of the 28th international conference on Softwareengineering. ACM Press, 2006.

[48] F. Puhlmann. On the Suitability of the Pi-Calculus for Business Process Man-agement. In Technologies for Business Information Systems. Berlin, Springer-Verlag. 2007.

[49] A. Rodríguez, E. Fernández-Medina, and M. Piattini. Towards cim to pim trans-formation: From secure business processes defined in bpmn to use-cases. InAlonso et al. [2], pages 408–415.

[50] A. Rozinat, A. A. de Medeiros, C. Günther, A. Weijters, and W. van der Aalst. Theneed for a process mining evaluation framework in research and practice. In Pro-ceedings of the Third International Workshop on Business Process Intelligence.(pp. 73-78). Brisbane, Australia: Queensland University of Technology.(2007).

[51] A. Schnieders and F. Puhlmann. Variability mechanisms in e-business processfamilies. In Proceedings of BIS ’06: Business Information Systems, 2006.

[52] A. Schnieders and F. Puhlmann. Variability Mechanisms in E-Business ProcessFamilies. In H. C. M. Witold Abramowicz, editor, 9th International Conferenceon Business Information Systems (BIS 2006), May 31 - June 2, 2006, Klagenfurt,Austria, pages 583–601. Springer-Verlag, 2006.

[53] A. Schnieders and F. Puhlmann. Variability modeling and product derivationin e-business process families. In Technologies for Information Systems, pages63–74. Springer, 2007.

[54] P.-Y. Schobbens, P. Heymans, and J.-C. Trigaux. Feature diagrams: A survey anda formal semantics. re, 0:139–148, 2006.

[55] J. Schulz-Hofen and S. Golega. Generating web applications from process mod-els. In ICWE ’06: Workshop proceedings of the sixth international conference onWeb engineering, page 6, New York, NY, USA, 2006. ACM.

[56] M. Sinnema, S. Deelstra, J. Nijhuis, and J. Bosch. COVAMOF: A Framework forModeling Variability in Software Product Families. 2004.

Bibliography 107

[57] M. Sinnema, S. Deelstra, J. Nijhuis, and J. Bosch. COVAMOF: A Framework forModeling Variability in Software Product Families. In Proceedings of the ThirdSoftware Product Line Conference (SPLC04), San Diego, CA, 2004.

[58] J. C. Trigaux and P. Heymans. Modelling Variability Requirements in SoftwareProduct Lines: a comparative Survey. Technical report, University of Namur –Computer Science Institute, November 2003.

[59] W. van der Aalst. Formalization and Verification of Event-Driven ProcessChains. Technical report.

[60] W. M. P. van der Aalst, H. A. Reijers, A. J. M. M. Weijters, B. F. van Dongen,A. K. A. de Medeiros, M. Song, and H. M. W. Verbeek. Business process mining:An industrial application. Inf. Syst., 32(5):713–732, 2007.

[61] W3C. Web service choreography interface (WSCI) 1.0, nov. 2002. www.w3.org/tr/wsci.

[62] M. Weske. Business Process Management: Concepts, Languages, Architectures.Springer Verlag, first edition, November 2007.

[63] P. Y. Wong and J. Gibbons. A Process Semantics for BPMN. Submitted forpublication. Available at http://web.comlab.ox.ac.uk/oucl/work/peter.wong/pub/bpmnsem.pdf. 2007.

[64] Y. Yu, A. Lapouchnian, S. Liaskos, J. Mylopoulos, and J. C. S. P. Leite. Fromgoals to high-variability software design. In A. An, S. Matwin, Z. W. Ras, andD. Slezak, editors, ISMIS, volume 4994 of Lecture Notes in Computer Science,pages 1–16. Springer, 2008.

[65] J. M. Zaha, A. P. Barros, M. Dumas, and A. H. M. ter Hofstede. Let’s Dance: ALanguage for Service Behavior Modeling. In R. Meersman and Z. Tari, editors,OTM Conferences (1), volume 4275 of Lecture Notes in Computer Science, pages145–162. Springer, 2006.

108 Bibliography

This document was typeset on // using RC–BOOK α. for LATEX2ε.Should you want to use this document class, please send mail to

[email protected].