This research report presents a methodology for developing families of business information systems. The methodology aims to improve the design of business families for service-oriented architectures. The report introduces the concept of business family engineering and describes a software process for developing business families. It defines how to model variability in business families using feature models and how to design the domain and choreographies of business families. The goal is to provide a holistic approach for systematically developing multiple business information systems that share common processes and functionalities.

1. A M ETHODOLOGY F RAGMENT FOR
D EVELOPING FAMILIES OF B USINESS
I NFORMATION S YSTEMS
I MPROVING THE D ESIGN OF B USINESS FAMILIES FOR
S ERVICE O RIENTED A RCHITECTURES
I LDEFONSO M ONTERO P ÉREZ
RESEARCH REPORT
M ARCH 17, 2009
BibTex

3. A Methodology Fragment for Developing
Families of Business Information Systems
Improving the Design of Business Families for Service Oriented
Architectures.
Ildefonso Montero Pérez, 75760309-B
monteroperez@us.es
Supervised by Prof. Dr. Joaquin Peña
and Prof. Dr. Antonio Ruiz-Cortés
Thesis project submitted to the Department of Computer Languages
and Systems of the University of Sevilla in partial fulfilment
of the requirements for the degree of Ph.D. in Computer Engineering.
(Research report)

5. Support: This work has been partially supported by the European
Commission (FEDER) and Spanish Government under CICYT project Web-
Factories (TIN2006-00472) and by the Andalusian Government under project
ISABEL (TIC-2533).
This research report has been developed regarding the instructions laid
in Chapter I, Article 5, Paragraph 2, of the Doctorate Regulations from the
University of Seville. This work implies an estimated effort about 360 hours
(12 credits) and it was developed using the structure proposed in the cited
regulations.

6. 4

7. Contents
I Preface
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.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 25
2.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 . . . . 37
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

8. 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 . . . . . . . . . . . . . . . . . . . . . . . . 47
4.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 . . . . . . . . . . . . . . . . . . . 53
5.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 . . . . . . . . . . . . 73
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.2 Choreography Modeling in BFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.3 Transformation Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
IV Contributions
7 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
7.1 Relevant Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86

9. 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 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
8.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
V Appendix
A Relevant Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
B Curriculum vitae . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
C Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105

10. iv Contents

11. 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

12. 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 the
derivation 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

13. List of Tables
2.1 Mapping between the SPL and PFE fields . . . . . . . . . . . . . . . . . . . . . . . 29
7.1 Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91

14. viii List of Tables

15. Acknowledgements
Now that this research report comes to an end, it is time to express my
gratitude to the people who have supported me along this path that I has just
started. First of all, I would like to thank to my family and friends for their
support when it was so necessary. Thus, I would like to thank to Lucia, for her
endless 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.

16. x Acknowledgements

17. 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 that
model 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 methods
to support the analysis, design and implementation of the business processes
of a company, as interoperable behavioural interfaces which can be deployed
as 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 systems
a complex task. In addition, is a fact that there exists several companies that
shares common business processes, and maximize the level of reuse of their
definitions is considered a core need.
Thus, our research hypothesis states that the reuse across businesses by
means of Software Product Line (SPL) techniques can be exploited. It means
that is feasible the definition of Business Families. For that purpose, our re-
search is focused on providing reference models and technologies that are
necessary to help companies bridge the gap of dealing with variability on the
design 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 research
context. Results from this analysis motivate our research work, which has
been already materialized in several contributions and has been presented in
the research report too.

18. xii Abstract

19. Resumen
Las Arquitecturas Orientadas a Servicios (SOA) suponen un cambio en el
enfoque para el desarrollo de soluciones y dar el paso de crear programas
que realizan una función concreta para el usuario final, a pensar, diseñar y
desarrollar 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), ha
aparecido recientemente con el fin de proporcionar técnicas y métodos para
dar 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 una
infraestructura basada en un Bus Empresarial de Servicios (ESB).
Las especificaciones actuales para el diseño de procesos de negocio por
medio de técnicas de modelización y anotaciones, como Business Process
Modeling Notation (BPMN), prestan apoyo a las actividades definidas en el
paradigma BDD. Sin embargo, la variabilidad implicita en Sistemas de Infor-
macion de Negocio (BIS) de granularidad gruesa es por lo general mas que
suficiente para que el diseño de este tipo de sistemas se considere una tarea
compleja. Además, es un hecho que pueden existir varias empresas que com-
partan procesos de negocio similares, y maximizar el nivel de reutilización de
sus 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 proporcionar
modelos de referencia y tecnologías necesarias para ayudar a las empresas a
superar la brecha de hacer frente a la variabilidad en el diseño de Sistemas de
Informacion de Negocio y para aumentar la reutilización las definiciones de
los procesos. En este informe, proporcionamos una visión general del actual
estado del arte de nuestro contexto de la investigación. Los resultados de este
análisis motivan nuestros trabajos de investigación, que ya se ha materializa-
do en varias contribuciones y son presentados tambien en este informe.

20. xiv Resumen

21. Part I
Preface

23. 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 Process
Model Notation (BPMN) [10].
On the other hand, the Software Product Lines (SPL) field systematizes the
reuse across the set of similar products that a software company produces. It
implies a reduction of development times and costs and a quality improve-
ment.
In order to increase the process definitions reusability, we propose a
methodology based on applying SPL ideas for the systematization of the de-
velopment of BIS across a several number of businesses that shares common
business processes. Thus, the contribution of this work is to define and explore
the feasibility and benefits of what we call Business Family Engineering.
In this chapter, we introduce first the motivation of our research work in
Sections §1.1 and §1.2; the research context in Section §1.3; we enunciate our
research methodology in Section §1.5 and our hypothesis and several research
questions in Section §1.4; and finally, we describe the goals and structure of
this research report in Section §1.6.

24. 4 Chapter 1. Introduction
1.1 Motivation
The variability level of average-size Business Information Systems (BIS) is
usually highly enough for making the design of this kind of systems a complex
task. 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 is
considered 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 the
reusability on the development of BIS using ideas from the Software Product
Lines (SPL) field [46]. Roughly speaking, the SPL field systematizes the reuse
across the set of similar products that a software company provides. For that
purpose, this approach requires to describe the products by means of vari-
ability models, such as Feature Models (FM), that contains only features and
relationships between them. A feature is considered as a characteristic of the
system that is observable by the end users. Feature Models describe which
features 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, it
presents some drawbacks related with ambiguity and maintenance that are
described at Section §1.3.3.
Thus, the main motivation of this research is to provide a methodology
that taking into account the PFE drawbacks makes feasible the possibility of
develop families of business information systems. For that purpose, as shown
in Chapter §4, we provide a methodology named Business Family Engineer-
ing, we define the fragment of this methodology focused on obtaining the
core architecture of the family, namely Business Family Domain Engineering
in Chapter §5, and we explore its feasibility on modeling choreographies in
Chapter §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 of
concepts, we have developed an Eclipse tool that provides support for one of
the activities of this methodology fragment. See Chapter §7 for more details
about tool support.
As a result of our contributions, we improve the development of business
information systems reducing its complexity level in situations where is nec-
essary to perform a business family, using our proposed methodology. In ad-

25. 1.2. Motivating our research with a WSCI example 5
dition, since to one of the topics of our approach is focused on providing the
core architecture of the family, we provide to process engineers some artifacts
for improving their activities, such as a business family variability summary
and a core process framework (See Chapter §5 for a more detailed descrip-
tion). This artifacts provides a basic structure of the business process model
that supports the variability aspects identified by the PFE approach, without
the 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 that
reflects the real life business process of reserving and booking airline tickets.
A derivation of this example, for defining an hotel booking process has been
used 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 WSCI
case study as starting point for defining how to develop families of business
information 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 airline
tickets business process, concretely a Traveler, a Travel Agent, and an Airline
Reservation System. Each participant collaborate in the overall process called
Plan&Book, as shown in Figure §1.1. This business process is composed by
the following subprocesses: (i) Order Trip : it defines the steps needed for
performing the submission of the preferred trip plan from the Traveler to the
Travel Agent, who evaluates the preferences, and send a possible itinerary to
the Traveler. It is performed by means of a collaboration between the Travel
Agent and the Airline Reservation System by means of a business process
named Verify Seats Availability. This business process is a subprocess of Or-
der Trip ; (ii) Cancel Itinerary : it defines the steps needed for canceling the
provided itinerary from the Travel Agent; (iii) Change Itinerary : it defines
the steps needed for performing a submission from the Traveler to the Travel
Agent to change the proposed itinerary; and (iv) Reserve Tickets : it defines
the steps needed for reserving the trip related with the proposed itinerary.
This business process is decomposed by four subprocesses: Book Tickets, Book
Seats (that needs a previous reservation step for the seats performed by other
business process named Reserve Seats ), Send Tickets and finally, Send State-
ment. This case study provides a complete real life example of reserving and
booking 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

26. 6 Chapter 1. Introduction
I want to travel to Ulm
Traveler Travel Agent
WSCI WSCI
Interface Interface
Plan and
Book Trip
WSCI
Interface
Airline
Reservation
System
Figure 1.1: Case study scenario.
this business process. In other words, these travel agencies share the common
business process of Plan&Book. In addition, is feasible that these companies
share 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 the
WSCI 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 Travel
Agent the information about flights (delays, connections, etc.) obtained from
an Airline Traffic Control System (we have introduced a new participant in
addition); 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 on
fly subprocess and the management of travel cards respectively.
Once the scenario is defined, we have analyzed the feasibility of develop
a family of airline travel agencies using our approach: Business Family Engi-
neering (BFE). Our research motivation address into the following issues, that
are covered in this report:

27. 1.3. Research Context 7
• Increasing the business process definitions reusability for each business
information system that provides support for any airline travel agency.
Current process engineers redesign each business information system
using ad hoc techniques to maximize the level of reuse from one product
to another. Our approach states that many common business processes
can be found, and reuse across businesses by means of Software Prod-
uct Line (SPL) techniques can be exploited. See Section §1.3.2 for more
information about the SPL field.
• Improving the design of highly variable business process models, also
named 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 extending
the notation of the business process diagram, for example Business Pro-
cess Model Notation (BPMN). It is defined by the PFE approach, that is
detailed 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 it
would 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 a
set 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 on
the observation that each product that a company provides to the market is
the 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 these
activities. In addition, Brown establish, in [12], as a core need that a company
must be able to manage what is called the 3-K :

28. 8 Chapter 1. Introduction
• Know what you got, roughly speaking, the services that the company
provides to the market, also named business goals;
• Know who is doing what, in other words, the set of business partners
that performs several business processes in the company;
• and Know when things change and what it means, which means that the
business processes of the company must deal with the implicit variabil-
ity of the market, since to companies must adapt to continuous market
changes.
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 of
business partners (may own the company or not), for realizing a business goal.
In addition, the definition of specificic business processes must be able to be
adapted when company changes. Business Process Management provides the
techniques and methods to support the analysis, design and implementation
of business processes.
Is a fact that most companies, in whichever field, have a software system
that helps managing all the aspects of the company. Consequently, the Infor-
mation Technology (IT) infrastructure that supports it must provide support
for 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 model
specification, 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 Information
Systems.
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 models
needed for designing a BIS: (i) a business process diagram, which defines
a business process by means of several notations, such as Business Process
Model Notation (BPMN), that is defined in the following subsection; and (ii)
a choreography and collaboration models, defined in Section §1.3.1.2.

29. 1.3. Research Context 9
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. These
elements allow expressing business processes and are easy to comprehend, so
that process designers can use them without extensive training. Several nota-
tions are introduced for defining business process diagrams, such as Business
Process Modeling Notation (BPMN) [10], Petri-net based process modeling
languages [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 and
software technology levels. Thus, our research is focused on this notation, but
it 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 defining
business processes. BPMN provides (i) a graphical notation based on Business
Process Diagram (BPD); and (ii) a formal mapping to an execution language:
Business Process Execution Language (BPEL). Figure §1.2 depicts the subset
of the most commonly used BPMN elements. These elements can be grouped
by the following categories:
• Swimlanes: a set of symbols that allows us to organize the model. This
set 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 are
used 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, is
the 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 the
execution of one or more activities. There exists a lot of events grouped
by: start, intermediate or end event, as for example message events, as
shown 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

30. 10 Chapter 1. Introduction
A
A1 A2 A Sequence
Flow
Sub-Process Start Intermediate End Message
Flow
A
Association
Start Intermediate End Flow
Message MessageMessage
(C) Connection Objects
Expanded Sub-Process Events
A
Gateway Gateway Group
Collapsed Sub-Process XOR
Tasks Artifact /
Data Object
Lane Gateway Gateway
AND OR Comment /
Text
Pool Annotation
Gateways
(A) Swimlanes (B) Flow Objects (D) Artifacts
Figure 1.2: Business Process Model Notation subset.
must be completed for performing a task, and (iii) Or : which defines that
almost one subprocess controlled by this gateway must be completed for
performing 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 messages
between two objects from different swimlanes. Figure §1.2.c depicts this
set, which contains the elements named flows such as, sequences, asso-
ciations and messages.
• Artifacts: a set of additional elements that represents information about
the model or output artifacts of a process represented in it. This elements
are very useful to represent additional information to the reader of the
BPMN, as group, comments or artifacts, also named, data objects gen-
erated or consumed by a business process. Figure §1.2.d. show these
elements.
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

31. 1.3. Research Context 11
[21] or Pi -Calculus [48]. Concretely, in our research we explore the capability
of 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]. Our
research explore the feasibility of the current BPMN specification for provid-
ing support for variability aspects into the design of business families and the
drawbacks 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 are
in 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 core
need for designing Business Information Systems. The activities needed for
develop a choreography model are described as follows:
• High-level Structure Design: in this activity the participant roles as well
as their communication structures are identified.
• High-level Behavioral Design: this activity is focused on specifying the
goals, also named milestones, of the collaboration and the order in which
the goals are reached.
• Collaboration Scenarios: in this activity the high-level choreographies
are refined by introducing dedicated collaboration scenarios that relate
the 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.
†1
http://www.hl7.org/

32. 12 Chapter 1. Introduction
Domain scoping
Participant
Milestone definition
identification
M. Weske: Business Process Management,
© Springer-Verlag Berlin Heidelberg 2007
Business Scenario modelling
Engineer
Design
System Message Choreography
Architect identification definition
Implementation
Deve- Behavioural Behavioural
loper interface 1 interface n
Process Process
orchestration 1 orchestration n
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 the
choreography, using the Web Service Choreography Interface (WSCI) specifi-
cation [60] . Figure §1.3 describes the big-picture of the choreography design
and implementation phases defined in [61]. Since to our research is focused in
the design of Business Information Systems, in this context, we focus on the
choreography design phase.
However, although choreography modeling is considered a core need in
our 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 exists
several proposals of specific choreography modeling languages such as Let’s
Dance [64] or BPEL4Chor [19].
†2
http://www.omg.org/cgi-bin/doc?bmi/08-09-04

33. 1.3. Research Context 13
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. In
the one hand, we propose a choreography model based on an UML2 pro-
file used on Agent-Oriented Software Engineering (AOSE) field that makes
feasible the variability support; and in the other hand we provide a transfor-
mation between this choreography model and BPMN elements for improving
the design of what we call business families, by means of the Business Family
Engineering 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 idea
to develop software products which share a significant amount of character-
istics, namely features. Thus, a feature is a characteristic of the system that
is observable by the end user. Roughly speaking, SPL systematizes the reuse
across the set of similar products, defined by means of their features, that a
software company provides.
The SPL approach is devoted to overcome complexity providing all the
techniques needed for enabling the mass production of software in a certain
application domain. The variability concept appears in SPL to represent the
differences and commonalities inside an application domain. Variability is
one of the critical aspects 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: Domain Engineering, which is in charge of providing the reusable core
assets that are exploited during the derivation of products, done at a second
stage named Application Engineering [46].
One of the most accepted techniques to represent the set of products of
an SPL are Feature Models (FM) [16]. The main goal of feature modeling is
to identify commonalities and differences among all products of an SPL. A
feature model is a compact representation of all potential products of an SPL
showing a set of features in an hierarchical structure where it is shown which
features are present in a product of the product line. Figure §1.4 shows the
feature 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 be
included in every product that contains the parent;

34. 14 Chapter 1. Introduction
A A
Airline Travel
Agency
B B
Mandatory Optional
relation relation
A Change Reserve Cancel
Inform Extras Order Trip
Itinerary Tickets Itinerary
B1 B2 B3
Alternative
relation Travel Verify Seats Book Reserve Send Send
Restaurant
Card Availability Tickets Seats Tickets Statement
A
B1 B2 B3
Book Seats
Or
relation
Figure 1.4: Feature Model of our case study.
• Optional: if a child feature node is defined as optional, it can be included
or not when its father feature appears in a product;
• Alternative: if the relationship between a set of children nodes and their
father is defined as alternative, only one of the children features could
be included in every product that contains the parent;
• Or: if the relationship between a set of children nodes and their father is
defined as or, one or more of them could be included in every product
that contains the parent.
Our approach for developing families of business information systems is
based on introducing some SPL techniques. For that purpose, the feature
model is used in our approach for describing the set of business informa-
tion systems that are members of the business family, and for representing the
variability of each business information system. In addition, the introduction
of SPL techniques implies a reduction of development times and costs and a
quality improvement of the final products.
1.3.3 Process Family Engineering
The Process Family Engineering (PFE) [6] approach explores the idea of
applying SPL philosophy for managing the variability of business information
systems. In PFE, feature models are used for representing the set of processes
contained into a business. In addition, a business process diagram notation,

35. 1.3. Research Context 15
Number of Seats <<VarPoint >> <<Null>>
<< Abstract >> > 100 Send Tickets Book Tickets
Inform
<<Parameterization >>
<<Implementation >> <<Implementation >>
Number of Seats > 50 <<Inheritance >>
<<Extension>>
<< VarPoint >> <<VarPoint >>
<< Default >> Inform by
Inform by Send Tickets
Intranet and Information
E-Mail Quality
about Trip
Assurance
(A) Alternative Behavior (B) Parameterization (C) Inheritance (D) Extension Point
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 highly
variable 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 different
ways for performing an activity into a business process definition. Fig-
ure §1.5.a shows an example about a refinement of the Inform business
process from the WSCI case study, represented using BPMN. When the
Airline Traffic Control System submit some information to the Travel
Agencies it could be done 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 al-
ternative behavior; (ii) VarPoint , for identifying the activities that
implements 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 BPMN
notation, 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 represent
possible ranges of the value Number of Seats, into the subprocess Ver-
ify Seats Availability from the case study of this paper. This attribute is

36. 16 Chapter 1. Introduction
marked using a grouping box and associated to other possible values by
means of a new association flow defined with a new stereotype named
Parameterization .
• Inheritance: it defines a modification of an existing subprocess by
adding or removing elements regarding to specific rules. This allows
for realizing alternative variation points. As shown in Figure §1.5.c, the
business process Send Tickets has been modified to Send Tickets and In-
formation about Trip since to the Travel Agency has a contract with some
tourism companies for providing 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 §1.5.d depicts
how an optional behavior from Book Tickets subprocess could be in-
cluded for quality assurance of this activity. This situation is marked
using the stereotype Extension .
The main difference between SPL and PFE is that the SPL field provides a
set of different products that shares common features, and the PFE approach
provides only one product, which represents a business, that evolves at run-
time, and each possible configuration of this business is managed as a product
that 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 generates
the final products (a set of core and variable features). On the other hand, the
PFE products are implemented by processes. For each product, the system can
evolve to another product increasing or decreasing the variable set of features
thus, 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 complexity
derived 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 some
problems, such as ambiguity, that has been explored for us in [37]. Another
consideration 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 not
an standard notation.
Our approach overcomes the variability of the business information sys-
tems using SPL techniques, taking into account the PFE approach ideas and

37. 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 PFE
product is considered as an evolving system. Our approach takes into account
this 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 design
of 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 one
product to another. Our hypothesis states that the reuse across businesses by
means of Software Product Line (SPL) techniques can be exploited. It means
that is feasible the definition of Business Families.
Increasing the business process definitions reusability is an active field of
research 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 be
provided. This discussion should include a preliminary definition about
what is considered a business family and its main problems and benefits.
• The Software Product Line (SPL) field has a lot of benefits and Business
Process Management too, How many benefits have SPL and BPM to-
gether?
In order to explore the benefits of our approach, a discussion about the
advantages and drawbacks of both fields and how many benefits have
together should be provided.
• How many approaches explores the idea of introduce SPL techniques in
the 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.

38. 18 Chapter 1. Introduction
Hypothesis: The design of highly variable business process models of a
Business Information System, member of a business family, could be partially
supported by means of an automated treatment.
Nowadays, variability is one of the most active topics in several academic
and industry communities [47, 55, 57]. Introducing variability support in the
BDD field raises the following research questions:
• What kind of variability aspects can be performed on defining business
processes?
A preliminary survey about the variability aspects identified on the de-
sign of a business process should be defined. This survey should include
the methods and techniques used to define these variability aspects and
its 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 and
how 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 kind
of variability should be revised. Another important issue is to study
the treatment of these variability definitions (manually or automated)
and its main benefits and drawbacks including topics such as variability
analysis 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 using
Agent-Oriented Software Engineering (AOSE) techniques makes feasible the
variability support and an automated treatment for obtaining collaboration
scenarios and behavior interfaces.
Modeling choreographies is one of the most active and recent topics in the
Business-Driven Development field†3 [19, 20, 23, 64]. Our hypothesis raises
the following research questions:
†3
http://www.omg.org/cgi-bin/doc?bmi/08-09-04

39. 1.5. Research Methodology 19
Implementation Layer
(ATL, Eclipse SOA Tool Platform, …)
Operational Layer
( Business Driven Development, Software Product Lines,
Model Driven Development, Agent Oriented Software Engineering)
Characteristic Layer
( BPMN, WSCI, BPEL)
Abstract Layer
( Automata Theory and Formal Languages,
Context-Free Grammars, Finite State Machines, …)
Figure 1.6: Proposed Holistic Framework.
• How many current proposals for modeling choreographies deals with
variability aspects?
The related work of this topic should be revised, exploring the proposed
techniques for modeling choreographies and its variability support.
• How many current proposals for modeling choreographies provides an
automated treatment for obtaining collaboration scenarios and behavior
interfaces?
The related work of this topic should be revised, describing the benefits
and drawbacks of current notations for designing choreographies and
its 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 divided
into four layers as shown in Figure §1.6. These layers are defined as follows:
• Abstract Layer: this layer provides an abstract and formal definition of
the core elements of our approach. Concretely, our approach is focused
on 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 specifications
that must be supported by our approach. It means that all the elements

40. 20 Chapter 1. Introduction
defined in the abstract layer must have its equivalent representation by
means of at least one of these considered specifications.
• Operational Layer: this layer provides the set of development paradigms
that are exploited in our approach. The operational paradigm layer de-
pends on the standard specification defined in the previous characteristic
layer used to define some elements of our approach. Our approach must
satisfy the constraints of these paradigms without adapting or extending
its elements for our purpose.
• Implementation Layer: this layer provides a real implementation of the
operational paradigms used. In this layer a set of implementation tech-
niques and software tools are contained. As far as possible, the aim
should 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 topics
whose 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 is
considered a goal of this report.
• Overview of our contributions: Although the results of our research are
still 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 this
report.
• Future work: Conclude this research report with the main conclusions
of this work by means of the answer to the research questions and a
dissertation about our future work, is a goal of this report.
This research report is structured in four parts: Preface, State of Art, Our
Approach, and Contributions. Figure §1.7 depicts the recommended reading
process of this report.

41. 1.6. Goals and Structure of this research report 21
Part 1: Preface
Research
Motivation Hypothesis Goals
Context
Part 2: State of Art Part 3: Our Approach
Business
SPL and BPM Family
Engineering
Variability in
Business
BIS Design
Families
Domain Design
Part 4: Contributions
Relevant Business
Publications Families
Choreographies
Definition
Other
Contributions
Future Work
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 underlie
our work.
In the second part, we review the state of art of our research context. In
Chapter §2, we explore the current proposals based on the introduction of
SPL ideas into BPM in order to perform a systematic generation and reuse of
business processes across different companies. After that, a summary about
how many kinds of variability are present in the definition of a BIS is provided
in 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

42. 22 Chapter 1. Introduction
Family Engineering (BFE). We focus our efforts on providing a BFE software
process definition for obtaining the core architecture of a business family, and
exploring how to deal with variability on choreography modeling of business
families using our approach.
Finally, in the last part, in Chapter §7, we provide a brief description of our
current contributions in this research context and, in addition, we summarize
our main conclusions and describe our future work.

43. Part II
State of Art

45. Chapter 2
Software Product Lines & Business
Process 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 has
been proposed. The main motivation of this chapter is to provide a revision of
these 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 explore
the reuse of business processes. Then, the rest of the chapter focuses on the
Process Family Engineering (PFE) approach, which is the only one that pro-
pose the introduction of SPL techniques in the traditional design of Business
Information Systems.

46. 26 Chapter 2. Software Product Lines & Business Process Management
2.1 Introduction
The SPL field tries to overcome the growing complexity of current software
by maximising the level of reuse. Roughly speaking, the software process of
an SPL approach cover is performed in three parallel activities: (i) Domain
Engineering : in charge of defining the SPL; (ii) Application Engineering : in
charge 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 the
Business-Driven Development (BDD) field, increasing the level of reuse of the
business process definitions is considered a core need. Thus, since to SPL
deals with this issue, several approaches proposes the use of SPL techniques
in order to maximising the reusability of the process definitions.
According to [4], to perform a survey in the software engineering field, we
have 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 explores
the idea of introduce SPL techniques in the Business-Driven Develop-
ment (BDD) field? (This last research question has been introduced in
Chapter §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 choosing
those papers with a higher number of cites; and finally a
• Catalogue: we classify the approaches in those focused on applying SPL
techniques, 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) approach
for modeling variant-rich processes and reuse its definitions into a prod-
uct line architecture. This approach has been introduced in Section §1.3.3
previously. 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

47. 2.2. Process Family Engineering (PFE) 27
the relationship between these feature models and its products, defined
by means of business process models, is not clearly defined [37]. In ad-
dition, the PFE approach identifies some variability aspects in business
process models, and proposes to introduce some stereotypes for rep-
resenting it. This redefinition of the syntax implies some maintenance
drawbacks identified in Section §2.2.
• Van der Aalst et al.[26]: proposes an extension of YAWL (Yet Another
Workflow Language ), named extended workflow-nets (EWF-nets), for
performing configurable and reusable workflow definitions of business
processes. YAWL is a workflow modelling language inspired by Petri
nets 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 processes
knowledge 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 defining
how to represent these reusable assets.
Thus, to the best of our knowledge, the PFE approach is the only one that
propose the introduction of SPL techniques in the traditional design of Busi-
ness Information Systems. Taking into account the result of our survey, we
are going to describe in the following section the ideas proposed by the PFE
approach.
2.2 Process Family Engineering (PFE)
2.2.1 Research Context: the PESOA project
The Process Family Engineering (PFE) approach was defined in the context
of the PESOA project. PESOA is the acronym of Process Family Engineering
in 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 for
modeling variant-rich processes and in the design and prototypical implemen-

48. 28 Chapter 2. Software Product Lines & Business Process Management
Domain Engineering
Analysis Design Implementation
Process Family
Infrastructure
Analysis Design Implementation
Application Engineering
Figure 2.1: Process Family Engineering Overview.
tation of a Process Family Engineering platform. This project is focused in two
domains: 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 Model
for variant-rich processes, which defines the conceptual requirements needed
for 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 processes
defined by means of their conceptual model.
Figure §2.1 depicts the overview of the PFE approach. It is composed by
two activities named Domain and Application Engineering, based on the ac-
tivities performed in the SPL field (defined previously in Section §2.1), and in
a Process Family Infrastructure, which performs the management of the prod-
†1
http://www.pesoa.de

49. 2.2. Process Family Engineering (PFE) 29
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 of
the variant-rich business processes.
Table §2.1 defines the mapping between the concepts from the SPL field
and the PFE approach. First, we explore the equivalence between the prod-
uct line and the process family infrastructure. Both elements are focused on
providing technical and organizational support of domain and application en-
gineering. The difference between them is focused on the products that both
manage. 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. On
the other hand, in the PFE approach, the artifacts are variant-rich processes
which are part of a BIS defined by means of variability models (commonly
feature models too). However, although some equivalence between both re-
search fields has been explored, there exists several diferences between them
which 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 needed
for enabling the mass production of software in a certain application domain,
the PFE approach provides all the techniques needed for enabling the mass
production of processes in a certain business.
However, althougth both fields are similar, the SPL approach produces a

50. 30 Chapter 2. Software Product Lines & Business Process Management
Approaches
Software Process Family
Product Line Engineering
Implemented by Implemented by
Assets Assets
Product Line Artifact 1 Variant Rich Process 1
Artifacts
Product Line Artifact 2 Variant Rich Process 2
Product Line Artifact 3 Variant Rich Process 3
... ...
Product Line Artifact n Variant Rich Process n
Select features
...
Select features Select features
Products
BIS (state 1) BIS (state 2) BIS (state m)
Product 1 Product 2 Product m
Core Processes Core Processes Core Processes
Core Artifacts Core Artifacts Core Artifacts ...
... Variation Variation
Variation Variation
Variation Variation
Variation Variation
m products; m > 0 1 product
Figure 2.2: SPL and PFE approaches.
set of software systems while the PFE approach produces only one Business
Information System (BIS), defined by means of variant-rich business process
designs. These business processes definitions represent all possible states for
which the BIS can evolve during its activity. Roughly speaking, in PFE, each
product represents an evolution of the BIS (at runtime). In this context, the
term product is defined as a set of features that are enabled/disabled at a
certain moment, and the term evolution is defined as a transition from one
product to another. Although there exists several products, only one software
system is produced by means of the PFE approach: a BIS which evolves at
runtime.
Figure §2.2 sketches how SPL and PFE products are generated. In SPL a
product is composed of a set of common features and a set of variable fea-
tures. Common features appears in all products and variable features appears
under 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 use
in a certain moment and some not. Thus, in SPL the evolution of the system at
runtime is not taken into account in the feature model. In PFE each feature is
a process and all of them appear into the product, but at runtime there exists
a 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 that
for each of them there exists a feature selection phase that generates the final

51. 2.2. Process Family Engineering (PFE) 31
products (a set of core and variable features). PFE products are implemented
by processes that for each of them there exists an evolution in execution time
incrementing or decrementing the variable set of features. Each product is a
software system based on processes. In addition, as stated previously, PFE
considers that sometimes a feature represents an activity, sometimes a busi-
ness process, but without providing an equivalence definition. Thus, we can
say that in PFE there not exist a mapping relationship between feature models
and 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 the
automotive domain. Roughly speaking, this model contains all the elements
that can vary in the definition of a BIS in the specified domains. Figure §2.3
presents 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 definition
the partner who performs the process (attribute Role ) and the execution
state of the process (attribute Execution State ) must be provided . The
PFE approach states that processes can vary. Regarding our case study
(See Section §1.2): Reserve Tickets subprocess could provide support for
different mechanisms for paying a reserve. The process Reserve Tickets
contains 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. Depending
on the choice selected by the user the Reserve Tickets will be resolved.
Thus, it implies that at design time the process engineer should know all
the possible choices or variations of a process. As shown in Figure §2.3,
a process is considered as activities and a composition of them specified
such 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 client
has selected to Reserve Tickets with Bank Transfer, the input form might
vary 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 representations
depending on where the order is delivered.

52. 32 Chapter 2. Software Product Lines & Business Process Management
Environment Non-Functional Properties
State RealTime Safety Security
1
*
Variable QoS
*
* Control Flow
1 - acquires
0..1 1
1 CompositeActivity Sequence
1
Scope
Process *
* * + Role
+ Execution State Parallel
- throws
- catches
* 1 1
Activity
* Choice
Event
* Data Flow
0..* 0..*
* * Iteration
Input Output 1
0..*
1
0..*
Exception
* *
1 1
- throws * DataSource DataSink
Figure 2.3: Conceptual Model of the PFE approach.
• Data Source/Data Sink: Data sources produce data used as input, as for
example the return of an invocation to a web service. Data Sink con-
sume data produced as outputs, as for example a database that stores
results. In our case study, assuming that the client who has selected to
Reserve Tickets with Bank Transfer, has an account in an American bank,
a data source produced could be the account code in American format
provided by a third-party web service from his bank. A data sink for our
example could be a Content-Management System such as Alfresc o†2 as
a 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 example
providing a security layer on Reserve Tickets with Bank Transfer process
using an standard specification such as WS-Security †3 . The proposed
conceptual model only takes into account Security, Safety and Real Time
as non-functional properties.
†2
http://www.alfresco.com
†3
http://www.oasis-open.org/committees/wss/

53. 2.2. Process Family Engineering (PFE) 33
• Scope: It is focused on providing business environments. Roughly
speaking, 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 Verify
Seats Availability.
• Variable: A variable is associated to a scope and a set of variables defines
a state. Variables hold data of process attributes (inputs, outputs, data
sources, data sinks, roles, and nonfunctional properties). In our case
study, a variable could be a reserved ticket identification number.
• State: A state is a situation during the execution of a process, which is
characterized by the current variable assignments of its contained pro-
cesses. In the conceptual model, this is reflected by the aggregation from
the state concept to the variable concept, and through the relationship
between the scope and the process concepts. For example, in our case
study the state of a reserving transaction at a given time could be de-
scribed by: the process Reserve Tickets, and the payment method Bank
Transfer.
• Event: An event can be thrown by a data source or a process. In the case
of a data source, an event is thrown, when a special value or threshold
defined for the data source has been reached. Something similar can
be assumed for a process that reaches a certain state. For example, in
our case study, the Order Trip process is triggered when is received a
message from a Traveler who wants to travel to an specific destiny. One
special kind of event is the exception. An exception can be used to define
a possible error in the execution of a process.
Once the elements has been explored, the PFE approach states that the aim
of this conceptual model is to provide a metamodel for modeling business
processes. For that purpose, this approach explores the use of several model-
ing notations such as UML Activity Diagrams or Business Process Modeling
Notation (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 the
PFE 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-

54. 34 Chapter 2. Software Product Lines & Business Process Management
Scoping
Product Set
Domain
Scoping
Domain Scope
Definition
Domain Analysis
Model
Features Feature
Model
Identify Process
Processes Requirements
Domain Design
Design
Processes Variant Rich
Processes
Variation
Points Set
Model Configuration
Configurations Model
Domain Implementation
Implement DS
Generator DS Generator
Implement DS DS
Components Components
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 requirements
capture of the desired Business Information System. For that purpose,

55. 2.2. Process Family Engineering (PFE) 35
the process engineer must review into the Process Family Infrastructure
availables reusable definitions, denoted as Product Set in Figure §2.4.
As result, process engineers obtain a Domain Scope Definition. The PFE
approach does not provide any element and constraints for documenting
this definition.
• Domain Analysis: The main purpose of this process is to provide a rep-
resentation of the desired Business Information System by means of a
variability model, such as a feature model. The domain scope definition
is used as input for identifying consists-of relationships among features.
Once the feature model is defined, the process engineer must identify the
processes from this representation in order to provide a business process
model definition. For that purpose, a process requirements summary
must 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 representation
is obtained, the variants and variation points of the business processes
are 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 engine
that executes it and produces the desired Business Information System.
For that purpose, the PFE approach proposes the use of domain-specific
generators 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 models
and the derivation of business processes from it, presents three main draw-
backs, defined as follows:
• Ambiguity: PFE uses feature models to show the variability derived
from enabling/disabling feature/process; however, given that feature

56. 36 Chapter 2. Software Product Lines & Business Process Management
models are devoted to represent design-time variability and not runtime
variability [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 information
about variability which is also present in the feature models, thus, in-
formation is duplicated with the obvious problems for maintenance. In
Chapter §3, we explore this extension and the drawbacks that it implies.
• Manual derivation: the relationship between a feature model and its
corresponding business process is not rigorously defined, and the devel-
opment of the business process is performed manually using as input
the feature model, what makes this activity error-prone and hinders the
maintainability of both kind of models.
In addition, as shown in Section §2.2.3, the PFE approach does not provide
a family of software systems, only one BIS (the final product) which evolves
at runtime. This evolution is managed by means of SPL techniques but PFE
does not provide any representation for modeling it.

57. Chapter 3
Variability in Business Information
System Design
I n common language use, the term variability refers to the ability or the
tendency to change [46]. Thus, variability is one of the critical aspects of
a Software Product Line (SPL) infrastructure and it must be managed at all
the stages of development. Consequently, several approaches explores how to
integrate variability into the Business Process Management (BPM) domain in
order to provide flexible Service-Oriented Architectured (SOA) systems.
The main purpose of this chapter is to provide an study about variability
into our research context. Thus, Section §3.1 explore what kind of variability
aspects 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, we
explore these research questions (proposed in Chapter §1, Section §1.4) within
the 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.

58. 38 Chapter 3. Variability in Business Information System Design
3.1 Introduction
Variability is one of the critical aspects of Software Product Lines (SPL). It
must 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 kinds
of variability. This double facet of variability and its importance in SPL, have
promoted an important amount of research approaches aimed to model and
handle 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 the
following 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 and
explicitly defined and documented.
• How does it vary?: documenting all the available choices and linking
them to domain model elements
• For whom is it defined and documented? to define the audience of a
variation point (what varies) and/or its variants (available choices).
Derived from Software Product Lines appears an approach, into the
Business-Driven Development context, named Process Family Engineering
(PFE) [6]. The PFE approach explores how to increase the reusability of the
process 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 development
costs 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 this
chapter 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 Pohl
statements.

59. 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 of
the 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 does
not 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 single
elements, and data type variability.
• Variability mechanisms derived: are derived from the basic variabil-
ity mechanisms. This category is divided into variability mechanisms
derived 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 to
provide the set of extensions proposed to the standard BPMN for dealing with
variability aspects. Proposed extension [51] is based on to adapt the concept of
a stereotype from the UML2 specification to BPMN. A first approach of these
extensions has been presented in Chapter §1, Section §1.3.3. These extensions
are defined as follows:
• Stereotypes: in order to represent a variant-rich business process a set of
stereotypes has been added to the current notation. Thus, VarPoint
stereotype identify a business process that can vary to a set of specific
processes denoted by means of the Variant stereotype. For a more
detailed model, a stereotype named Variable can be used to denote
variability below the level of detail currently shown. In addition, the
stereotype VarPoint can be specialized. Abstract variation point
represents alternative behavior. Thus, it has to be resolved by an specific
variant. Null variation point represents optional behavior. It can be
resolved by an specific variant. Alternative is a short representation

60. 40 Chapter 3. Variability in Business Information System Design
of an abstract variation point with an specific variant which is the default
resolution to this variation point. An Optional variation point is a
short representation of a Null variation point a specific variant. Fig-
ure §3.1 sketches the Reserve Tickets process from our case study (See
Chapter §1, Section §1.2) modeled using these stereotypes. Thus, Re-
serve Tickets has been defined as an Abstract variation point with
two alternatives. On the one hand, a resolution of the process performed
by a default variant, a refinement of the alternative default vari-
ant defined by means of the Alternative variation point, and on the
other hand, the Reserve Tickets with Bank Transfer process.
• Symbols: Variant stereotype can also be expressed graphically as
a puzzle-piece like marker at the bottom of business process. Reserve
Tickets with Bank Transfer is a variant process denoted by means of this
symbol, 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 that
Reserve 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 data
objects, or dotted flows for specifying associations related with the variability
mechanism, 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 invariant
interface. 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 as
a 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 defining
the business processes as black boxes.

61. 3.2. Variability Mechanisms 41
<< VarPoint >> Reserve Tickets has two
<<Variants >>. It is defined as an alternative
behavior with a default variant
Variability Mechanisms << abstract >>
Reserve Tickets Tagged value Discount
= 5%
<< parameterization >>
<< implements >> << implements >>
Discount = 3%
<< inheritance >>
<< default >> {feature: Reserve with Bank Transfer}
Reserve Tickets Reserve Tickets Bank Transfer
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 grouping
box and associated to other possible values by means of a new association
flow defined with a new stereotype named Parameterization . Figure §3.1
presents a parameterization of the attribute discount of the process Reserve
Tickets with Bank Transfer, which means that in some situations the value of
this attribute can change.
3.2.3 Variability Mechanisms Derived
3.2.3.1 Inheritance
Inheritance adds restrictions to addition/omission/replacement of single
elements. Thus, it modifies an existing subprocess by adding activities. This
allows for realizing alternative variation points. An association represents in-
heritance from the child activity to the parent activity when it is marked with
the inheritance stereotype. Reserve Tickets and Reserve Tickets with Bank
Transfer variants has an inheritance association with the variation point Re-
serve Tickets as shown in Figure §3.1.

62. 42 Chapter 3. Variability in Business Information System Design
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 a
combination of encapsulation and Null processes to realize optional vari-
ation points. In addition, an association extends is defined too. Figure §1.5.d
from Chapter §1, Section §1.3.3 presents an example of an extension modeled
by means of this mechanism.
3.3 Summary of Variability Aspects
Regarding our research questions: What kind of variability aspects can be
performed 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 one
approach which provides variability support on the design of BIS, to the best
of 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, the
behavior 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 support
for 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 means
of features selection at design-time. Roughly speaking, process engi-
neers known at design time all the possible choices and they model a
business process definition that fullfils all the possibilities. In the PFE
Application 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 different
implementation of its behavior. Inheritance and Extension mechanisms

63. 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 means
of introducing new elements into the notation too.
• For whom is documented and defined?: All the variability mechanisms
are 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 the
question: 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 managed
by means of Software Product Line (SPL) techniques where each product is
defined as a set of features (processes) that are enabled/running at a certain
moment. In addition, the term evolution is defined to denote the changes or
transitions from one product to another.
However, although the PFE approach takes into account this evolution at
runtime, the variability mechanisms provided are performed at design-time,
since to the PFE approach only take into account the evolutions that can be
predicted at design-time.
Thus, the PFE approach does not provide any representation for runtime
variability and for Predictable and Unpredictable Evolutions. An Unpre-
dictable Evolution is defined by means of Unpredictable Triggers. A Trigger
acts as stimulus of an evolution from a product to another. An Unpredictable
Trigger is defined as something happening in the environment that fires an
evolution 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 an
evolution.
Runtime variability representations is necessary at the Business-Driven
Development context. Process engineers need to visualise and analyse prop-
erties of the business at runtime, for example: how long each product is active
or which is the percentage of benefits obtained in each product at a certain
moment. This kind of evaluation is studied in the Business Process Mining
field [17, 50, 59].

64. 44 Chapter 3. Variability in Business Information System Design

65. Part III
Our Approach

67. Chapter 4
Business Family Engineering
T aking into account the main advantages and drawbacks of revised state
of 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 we
provide 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 process
definitions reusability.

68. 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, namely
Business Family Engineering (BFE). Thus, in Section §4.2, we states the basis
of 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 the
supported variability of our approach. Finally, in Section §4.3, we present an
overview of the software process of Business Family Engineering using the
SPEM notation†1 .
4.2 Business Families and BFE
Business Families can be defined as a set of software systems driven by
business processes, hereafter Business Information Systems (BIS), where each
product of the family has a set of common processes and a set of variable
processes. Thus, roughly speaking, we define Business Family Engineering as
a methodological approach for performing business families.
4.2.1 Rigorous Definition
A first step to a rigorous definition of a business family can be represented
as 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 by
means 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 between
whichever set of businesses. Let Bi and Bj be two businesses contained in
BF where 1 ≤ i, j ≤ n:
Bi ∩ Bj = φ
†1
http://www.omg.org/technology/documents/formal/spem.htm

69. 4.2. Business Families and BFE 49
Thus, we can say that a business family can be also defined as a set of
core and variable processes/features. We assume that there exists a binary
relationship between features and processes, thus a feature must not represent
a set of processes. Let CF be the set of common processes or features and let
VF 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 the
CF 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, and
a 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 always
enabled 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 account
this runtime variability. For formalizing these concepts we should redefine
each business B of a BF as:
B = (CF, SVF ∈ VF, F∆ : t, {Feature × ... × Feature} →
→ {Feature × ... × Feature})
where F∆ is a function that given an instant t transform the set of SVFt into
the new set of variable features of the following time instant t + 1, that is to
say SVFt+1, formally:
F∆(t, SVFt) = SVFt+1 ∈ VF • SVFt = 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 an
specific 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.

70. 50 Chapter 4. Business Family Engineering
Feature Model Rigorous Description Product Evolution Model
Instant t Business B
Business B SVF t
B
...
Business
CF +
CF SVF t
Features
t+ 1
F (t, SVFt) = SVFt+1 ∊ VF
... • SVFt ≠ SVFt+1 F (t, SVFt)
Instant t + 1
VF CF +
Processes
SVF t+1 SVF t + 1
t + k;
Legend ... k >0
B
: Core Processes CF Business
: Variable Processes VF
: Selected Processes SVF Features
(A) Rigorous (B) Graphical
Description Notation
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 of
business processes, represented as F∆, since to feature models are not devoted
for temporal conditions or variables (t) [25]. For that purpose, we have to add
a 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 each
state 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 of
F∆ function in t and t + 1 using BPMN. Notice that it represents an specific
graphical notation for the formal description of our approach, but other nota-
tions can be applied.

71. 4.3. Software Process of BFE 51
©¡ ©©¡ §¤ ©£ ©¡¤¨¤ §¦¦
§¤¨ ¦¥4 §3 ©©¡§¤©£ ©¡© ©¡¥% # § ¥¦ ¦£© © ©¡¥% ¡¥
¡¨£¡5( ¦¡¨ © 2¥1¡¦¥
© ©¡¥% ¡¥ §¤¨¤ §¤4¡'
2¥1¡¦¥
¨¤¤ ¤¥ ¡¥ # ¤£
©¨ §¡¦¡¥¤£¢¡
¡¥£¨ ©¤© §0 2¥1¡¦¥ © ©¡¥%
¤¦ © ©¡ §¤©£ ¤¦ ©©¡ §¤ ©£
) §¤¥¡¡ §¤) §( §¤ ¦' §¤¨¤0
) §¤¥¡¡ §¤) §(
¤¦ © ©¡ §¤ ©£
¤¦ © ©¡§¤ ©£ ¥ ¦¦£ ¨¤¤¤¥
¥ ¦¦£ ¨¤¤ ¤¥ $ ¡# ! ¡¥£¨¡
(A) Overview of the software process of (B) Business Family Domain Engineering
Business Family 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 core
architecture, namely Core Process Framework, and the Business Family Vari-
ability Summary ; and (ii) Business Family Application Engineering, where we
obtain specific business information systems, that are described by means of
execution languages, such as Business Process Execution Language (BPEL).
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 of
businesses and processes from scratch and apply the normal sequence of BFE
software process. In bottom-up approach, we can not apply the normal se-
quence of the software process defined since to we have a set of businesses or
processes defined in feature models previously to apply BFE software process.
In our research we only focus in top-down.
Once the BFE big-picture has been defined, in next chapters we propose,
first, a concrete definition of the methodology fragment of BFE focused on
obtaining the core architecture of a business family, in other words, defining
how 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 Family
Engineering approach.

72. 52 Chapter 4. Business Family Engineering

73. Chapter 5
Business Families Domain Design
I n this chapter we present the methodology fragment of Business Family
Engineering 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 its
complexity 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 business
process models.
Consequently, since to our approach is focused on providing the core ar-
chitecture of the family, we provide to process engineers some artifacts for
improving their activities, such as a business family variability summary and
a core process framework in Section §5.3. These artifacts provides a basic
structure of the business process model that supports the variability aspects
identified by the Process Family Engineering approach, without the need of
extending the standard notation of BPMN.

74. 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 Business
Family Domain Engineering. This methodology fragment is complemented
by a proposal for improving the Process Family Engineering Design step. In
this activity, the use of feature models and the derivation of business processes
from it presents three main drawbacks: ambiguity, maintenance, and manual
derivation, 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 process
model from a feature model. This transformation is achieved by: (i) a feature
model redefinition of its semantic, presented in Section §5.2.1, which is based
on 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 Domain
Engineering activities and integrate this systematic mapping these activities
providing 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 of
features.
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 a
feature q and optionally r, where q is an or feature: almost one of s and t
can be present in an application; and r is an alternative feature: only one of v
and w can be present in a member of the family. Thus, since to feature models
are 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. In
this section, we focus on Batory’s work as start point for redefining feature

75. 5.2. Preliminaries 55
p
q r
s t v w
Feature Model
p : q [r] ; P implies (q or (q and r))
q : a+ ; q implies ((s or t) and
a : s | t ; almost1(s,t))
r : v | w ; r implies (v or w)
Grammar 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, we
present our contribution for improving the design of highly variable business
process 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 model
grammar 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 of
appearance 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 process
definitions which establishes the order that the processes must be performed
and its dependencies with others (i.e: subprocess A and B must be done in
parallel, 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 products
of each feature model, hereafter named artifacts, as a language which can be
defined by means of a regular expression [29]. Let A be a business process
defined 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 exists
three possible alternatives for performing A:

76. 56 Chapter 5. Business Families Domain Design
• 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 mapping
relationship 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 reuse
Batory’s grammar representation [5] for proposing a new grammar. Thus, as
shown 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 defines
it 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 it
is:
La−alt = {b1, b2}
And finally, if we consider an artifact but with an or relationship instead of
an alternative, as shown on Figure §5.2, the language which defines it is:
La−or = {b1, b2, b1b2, b2b1, b1 • b2}

77. Figure 5.2: PFE Feature Model and its CFG representation.
E H
D G
; B :b
E TD
; B :b
C P P
SD E SE D B2 B1
P P P P
;
E SE SD
F P PA @ 9
D
B
Or
F H RG
E D I I
B
F Q G H A
D E U I I
.B B
Q H G
U I I 76
E D
B |B
B A:B
E H
D G
B2 B1
B :b ;
E SD
B :b ;
C P PA @ 9
H
;
E I
F Q G A
Alternative
D I76
B
A:B
E H
D G
B :b ;
B :b ;
E TD
C P P
;
D E SE D
F P P P P
B2 B1
ε
E SE SD S
F P P A @9
ε
D
B
F H RG
I I
B
E D Q G H
F U IU I A
D E Q H G
B .B
U IU I 7 6
E D
|B B
A:B B
Optional
Relationships
B : b; B
S
;
CP A @9
ε
UI 7 6
A
|ε
A:B
E H
E TD
D G
; B :b
C P P B2 B1
SD E
P P
; B :b
SE D
E D P PA @9
;
H RG
F I I
D E Q G H
.B B
A
I I
E D Q H G
B |B
B A:B I I 76
Mandatory
B
CP A @ 9
B: b;
I76 A
A : B;
C BA @ 9 A Feature
A : a;
S : A; 876
Grammar Expressions
Context- Free Regular
Feature Model
57 5.2. Preliminaries

78. 58 Chapter 5. Business Families Domain Design
F
A
R1 Rn
A A B
... B C
=
FM1 FMn D E B C D E
F = FM1 FM2 … FMn A: C | B C | C B | C B;
F: Feature B: D E | E D | D E | D | E;
Ri: Relationship C: c;
FMi: Feature Model D: d;
Dom(Ri): { Mandatory , Optional , E: e;
Alternative, Or }
(A) Composition by means of (B) Grammar Representation
the operator Composition
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 be
the 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 be
defined 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 definition
of these regular expressions can be described. Figure §5.2 sketches the equiv-
alence of a feature and its relationships in terms of regular expressions and
context-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 which
sketches how a feature model with three different relationships is defined by
means of a composition of three simplified feature models with only one rela-
tionship. Thus, the CFG representation of composed feature model is obtained
by means of applying • operator to three simplified feature models CFG rep-
resentations defined previously on Figure §5.2. Obtained CFG for composed
feature model is shown on Figure §5.3.b.

79. 5.2. Preliminaries 59
Context - Free
Grammar
Finite State Machine Model
S : A;
Feature
q0 a q1
A : a;
Start
A : B; ε b ε
B: b; Start q0 q1 q2 q3
Mandatory
A:B B ε b1 q2
b2
q3 ε
q1
|B B
V W
B ~B
W V
ε
q5 ε q9
X
V W b1~b2
; Start q0 q4
B :b ;
B :b ; ε q8 ε
Y V
b2 b1
` W
q6 q7
A:B ε q1 ε
|ε
; ε b ε
B : b; Start q0 q2 q3 q4
Optional
ε q1 ε
A:B B ε
V W
ε
|B B
b1
q2 q3
B ~B
W V
ε εq
X
B
V W
b1~b2 q5
X
Start q0 q4 14
B
V
X
W ε b2 ε
X
ε q6 q7
; ε ε
B :b ; q8
b2
q9
b1
q10
B :b ;
Y V
` W
ε b1 b2 ε
q11
q12 q13
A:B ε q2
b1
q3 ε
Alternative
B
V
X
;
W
Start q0 q
q6
B :b ;
Y V ε b2 ε
B :b ;
` W
q4 q5
ε b1 b2 ε
A:B B
V W
q1 q2 q3
|B B ε b1 ε
B ~B
W V
X q4 q5
B ε
V W
X
ε
Or
b1~b2 q7 q11
B
V
X Start q0 q6
; ε ε
W
b2
q8 q9
B :b ;
B :b ; ε
Y V
` W b2 b1 ε
q10 q11
q12
Figure 5.4: Mapping Grammars to Finite State Machines.

80. 60 Chapter 5. Business Families Domain Design
a d
q1
b c e
Start q0 q2 q3 q4
Finite State Machine Model
a
FSM: {Q, ,A,q0}
Q: {q0,q1,q2,q3,q4 }
a
: {a,b,c,d,e}
A: {(q0,a,q1),(q0 ,b,q2), S: A | B;
(q1,d,q4),(q2 ,c,q3), A: a d;
(q3,e,q4)} B: b c e;
Finite State
Grammar
Machine Definition
Figure 5.5: Finite State Machines and its CFG definition.
b1 b1 b1
b1
b2 b2
b2 b2
ε ε
ε b1 b2 ε q1
q1 q2 q3
ε b2 ε ε b1 ε
b1 q3 ε ε q2 q3
q1 q2 ε b1 ε b1
q2 q3 q4 q5 ε b1~b2 εq
ε ε ε q0 q4 q5
q5 ε q9
Start 14
b1~b2 b1~b2
Start q0 q4 Start q0 q6 Start q0 q6 q7 q13 ε b2 ε
ε b2 ε ε b2 ε q6 q7
ε q8 ε
q4 q5 q8 q9
q6
b2
q7
b1 ε b2 b1 ε
ε b2 b1 ε q8 q9 q10
q q q12
ε
10 11
q11
b1
q12
b2 ε
q13
a. Mandatory b. Alternative c. Or 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 a
Finite State Machine (FSM) model from a Context Free Grammar (CFG) and
viceversa [29]. Applying this mapping we provide a FSM representation of
the feature model grammars presented previously. Figure §5.4 presents each
feature model grammar with its FSM correspondence. In addition, Figure §5.5
sketches 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

81. 5.2. Preliminaries 61
Feature Model Business Process Model
Feature A A
A A A
Collapsed B
B Expanded
Mandatory
A A A B1
Collapsed
B1 B2 B2
Expanded
A A A
Collapsed
B
Relationships
B
Expanded
A A
Optional
Collapsed
A
B1
B1 B2
B2
Expanded
A A B1
Alternative
A
Collapsed
B1 B2 B2
Expanded
A A B1
A
Collapsed
Or
B1 B2 B2
Expanded
Figure 5.7: Feature Model to BPMN Mapping Catalog Proposed.

82. 62 Chapter 5. Business Families Domain Design
means of FSMs [11]. Consequently, the equivalence based on which artifacts
of 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 stated
previously in Section §1.3.1.1, the specification of BPMN does not provide any
constraint about the order of performing subprocesses in any situation. In ad-
dition, the BPMN gateways defines that the subprocesses contained in it can
be 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 that
presents the equivalence between each feature model represented by means
of 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 defined
as follows: Business Family Domain Engineering : where we build the BFE
core architecture, namely Core Process Framework, and the Business Family
Variability Summary ; and Business Family Application Engineering : where
we obtain specific business information systems, that are described by means
of execution languages, such as Business Process Execution Language (BPEL).
The main purpose of this section is to provide the software process of the
Business Family Domain Engineering fragment, shown in Figure §5.8.a. This
software 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 and
providing the core architecture, and finally
• Domain Implementation: focused on defining the implementation and
test details of the architecture, such as persistence or presentation layers.
The focus of our research is focused on Domain Requirements Engineering
and Domain Design activities, as shown in Figure §5.8.a. These activities will
be defined below and we implement each stage described in our motivating
example 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 package
diagram representation in Figure §5.8.b.

83. Figure 5.8: Business Family Domain Engineering Overview.
(B) Domain Engineering and Domain Design Packages Definition
irc€ –c yi“c ’ ir qseiƒ yi“c ’ yi“c ’
’† ‚fte† gcfsqyc iu ‡sfye gc ddc€ ‡sf‰efre ˆ
” ‘ …rc„i derƒ i ™s –c gcfsqyc iu i ™s i gf–ib ” ‘ ‡rcsftcxi h e cs gf tsit th i ie
” ‘ gcfsf gf–ib tsi tth iy‰e tqih
” ‘ gcfsf tcx dc€ i ™s i gf–ib iy‰efr e ˆ “ ge irc€ gfes‰g
” ‘ gcfse‚f–f‚ix † iirƒ sfis gc€e gcd h
cs tiyqh gcfse drc–t ger• i ™s i gf–ib ” “yc ™tiir ™s ‘ tifsfye gcd dc€ gfes‰g
” ‘ irc€ i ™s –c irqs‚qrs ‚fte† gfes‰g ” ‘ ‡r e ddq ‡sfyf‰efr e ˆ e i gf–ib
Process Engineer Process Engineer
Framework Analysis
Build a Core Process Variability
Domain Design
tyi“c ’ ffrse ’ gcfsxfr‚tib
it e€ it˜ ‡sfyf‰ei‚ er• tri“yc ™i…es
” ‘ s gi dq‚cb gcfsesf‚fyu ge iseri gi—
” ‘ s gi div e ge ’ ‡sfyf‰efr e ˆ
tyi“c ’ gcfsxfr‚tib s gi dirfqpih i‚ q“crs gw
t dri•
tyec— t†u
–c ‡re ttcy— ” ‘ tri“ yc ™i…es ‡–fs gi“w
” ‘ ti te€ i t˜ ‡–fs gi“w
gcfsxfr‚tib
gcfsxfr‚ tib gcfsxfr‚ tib ti t ti‚cr ” ‘ tyec— dist‡ ‡–fs gi“w
ts gi dir fqpih ts gi dirfqpihtti gftq† “ ge ” ‘ t†u ti tti‚cr
tti gftq† ‡r es gi diyu ‡–fs gi“w
ye gcfs‚ gqƒ e gcd ye gcfs‚ gqƒ tif gex dc€
” ‘ tit ti‚cr t ti gft q† tsf
“ ge tif gexdc€ i ™s i gf–ib
ts gi dirfqpih (Analist, Process Engineer …)
Requirement Engineer
Engineering
Domain Requirements
(A) Business Family Domain Engineering Overview
” yi“c ’ irqseiƒ‘
‡r e ddq ‡sfyf‰efre ˆ Focus of our research
‡yfdeƒ t ti gft q†
tyi“c ’
gcfses gi diyxdw
v gfrii gfv gu
gcfses gi diyx dw gvftib ts gidirfqpi h
gfe dcb gfe dcb gfe dcb
tyi“c ’ …rc„i derƒ
ti te€ gcfses gi tir tti‚cr irc€ ts gi dirfqpih
sti•
63 5.3. Business Family Domain Engineering

84. 64 Chapter 5. Business Families Domain Design
5.3.1 Domain Requirements Engineering
The Domain Requirements Engineering activity is focused on identifying
the set of companies and its business processes that would be members of
the business family. This step takes into account the traditional requirements
elicitation activities of software engineering, and provides as resulting artifact
the documents that reflects this elicitation, where it is included the definition
of each business process and each company. Thus, the activities of this stage
are performed by a Requirement Engineer, role that could be played by an
analist, a process engineer, etc. Figure §5.9.a shows the Domain Requirements
Engineering overview. In this stage, the Requirement Engineer performs the
following 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, see
Section §1.2 for an example, or using a workflow representation of each
identified business process, such as BPMN. This activity generates two
different 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 problem
domain.
• Identify Elementary Business Processes (EBPs): it is focused on identi-
fying the business processes contained into the Companies and Business
Processes Definition artifact, that are considered an EBP. Larman defines
in [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 the
business 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 low
level, namely atomic tasks, as are those who do not concern us. In addi-
tion, this activity will filter those activities that require direct interaction
of the user with the system. Thus, this activity generates one artifact: the
EBPs Definition, that contains the description of each of them.
• Identify System Goals, Use Cases and Stakeholders: these activities
are 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 visible
characteristic of a system. There is an overlap between the goal and
feature definitions that motivates that some authors uses feature mod-
els, shown in Section §1.3.2, for describing goals [46]. These goals are

85. 5.3. Business Family Domain Engineering 65
p{ qvuyy{s
y tvl‹ 
su m{on| mx m{Ž su m{on| mx
qvun ml tlsr qpon mlkj k mu ylo mu€t{ l ~n wmopol}
l yn mltlvo x‡l† yn mltlvox‡l†
ylyyl|{vz yyl moyxw ylyyl|{vz yyl moyx yn m{on€ov| yl} m{on€ov|yl} Send
yzwr Tickets
[Max] Performance
ylo mu€t{ AND
yyl moyxw k mu AND – AND
ylyyl|{vz +
m{on€ov|yl} yzwr y su { Create Search Filter
m{on€ov| yl} yslk{ ‚ Tickets Tickets Tickets
qpon mlkj
tlnyq„
y s u{  (B) Goal Model of “Send Tickets”
qnoso‰ul|uv‹ qpon mlkj lyu lyƒ
ylyu lyƒ yslk{ ‚ using Tropos
Œovnu ‚
qpon mlkj
variant
yvlks{ ~l…un„ yvlks{ ~l…un„ Travel Search by
m{on€ov|yl} Agent Code
include
Search a Search
lnuvl ml Ticket by variant
m{onuno| osrmu l| xk{vn mj Search by
n mltx|{} y mltlvox‡l† Agency
qnoso‰u ovu ˆ
n mltlŠu mu ‚ (C) Use Case Model “Search a Ticket”
with two variants using Hallmans and
(A) Domain Requirements Engineering Overview Pohl proposal
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, there
exists other goal-oriented representations, such as Tropos [13, 33] or i*
models [31], that can be used too, depending on several factors, such as
tool 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 are
defined by means of use cases. Thus, these activities generates the fol-
lowing artifacts: (i) Goal Models ; (ii) Use Case Models ; (iii) Functional
and Non-Functional Requirements Descriptions, in a textual represen-
tation by means of templates, as shown in [15, 22], and in a graphical
representation using use cases (the Non-Functional Requirements can
be 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 activities
generate a Traceability Matrix between them. This matrix represents a
table that correlates requirements with system goals and with business
processes. Roughly speaking, this artifact provides a response for the
following questions: What requirements fulfill a system goal? and What
system 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

86. 66 Chapter 5. Business Families Domain Design
that purpose, some requirement variability techniques has been identi-
fied. The use of feature models and/or Tropos for defining system goals
provides 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) represent
variation 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 as
proposed by Gomaa [24] or by Hallmans and Pohl [27], or proposes other
notations and languages, such as COVAMOF [56]. Figure §5.9.c shows
an use case diagram using the extensions proposed by Hallmans and
Pohl. In addition, there exists approaches for representing variability in
the 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 the
traditional use case representation, in order to specify variabilities. This
combination allows to capture variability and essential activities of a do-
main with use cases and to detail common and variable characteristics
with 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 is
oriented on generating an elicitation document that contains all the arti-
facts. This document is defined by the artifact named Requirements, that
represents the output of the Domain Requirements Engineering activity
as shown in Figure §5.8.b. It contains all the artifacts generated in the
previous 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 providing
the 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 Goal
Model 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

87. 5.3. Business Family Domain Engineering 67
¥ “ ¡• ­
‘— ¨ ’ ¢±­
¡ ™ • Ÿ ” “š• ž— ’¡”•—¤
¡™‘£ ¢ ¡‘™©
¥“¡•­ ”“•š˜§
‘—š¥ —šœ
‘— ¨ ‘ ®š ’
›š“™“˜•“—• –
™‘£ ¢ ‘— ¨ ‘™˜• “—• –
¡š‘ ¡¡ª ¡š‘¡¡ª ” “š•ž— ’¡ ”•—¤ ‘®š ‘”“’‘
›š“™“˜•“—• – • ‘ ”“’‘ ¡‘“š“™• ” žž ¨ š¦‘š” ¨° ” ¯ • š ¡‘™©
›—•žžœ ” “š•¥ “’“¥‘¬œ ±­
›—• žžœ
‘ ®š ¡‘”“’‘
”“•š˜§ ” “š“¡ ¬ž ¨
¡‘“š“™• ” žž ¨
” “š™ «² ‘®š ‘”“’‘
‘— ¨ ”“•š˜§ µ— ´‘ž•—³ ‘ ®š ’
›š“™“˜•‘¥•—¤ ‘™˜•“—• – £ ”• ¡š‘¡¡ª ‘ «• œ ” “š“ ¡ ¬ž ¨
¦“—š• ¢ ¡š‘¡ ¡ª ‘™˜• ¡‘© ›— š“ ¡ ¬‘© • š ”“ ” “š•¥“’“¥‘¬œ
” “š™ «²
™‘£ ¢ ‘—š•‘³
Figure 5.10: Domain Design overview.
from system goals [3, 46], since to we can analyze them [7] for obtaining
the commonalities summary needed to perform the following phase. In
addition, 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 can
consider that the feature is part of the core. Thus, we introduce an op-
tional commonality threshold for introducing some features/processes
into the core of the product line [44]. Figure §1.4 presents the variability
summary of the business family of the case study by means of feature
modeling. 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 means
of a commonality threshold, as shown in Figure §5.11.b. Notice that if we
did not introduce this commonality threshold this processes would not
be into the core architecture of the business family.
• Obtain Core and Variable Reusable Assets Definition: it is focused on
obtaining the reusable assets that are the basis of the core architecture.
For that purpose, we analyse the Variability Model and Commonality
Summary artifacts, using the operations defined in [7]. The result of this
analysis 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 equivalence
between features and business process. Thus, the reusable assets are de-

88. 68 Chapter 5. Business Families Domain Design
Airline Travel Threshold = 80%
Agency
COMMONALITY (%)
Change Reserve Cancel
Order Trip
Itinerary Tickets Itinerary
Verify Seats Book Reserve Send Send
Availability Tickets Seats Tickets Statement
Book
Seats
(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 Variability
Analysis represented using feature modeling.
fined by means of business process models. These assets are contained
into the generated artifacts Core and Variable Assets.
• Save Assets into a Repository: finally, once the assets are obtained and
defined by means of a business process model, we save these reusable
assets into a repository. The URI of this repository is added into the
Business Family Variability Summary artifact.
• Obtain the Basic Structure of the Core: it is focused on obtaining a basic
structure 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 the
Variabily Model to a business process model. This derivation is based
on Automata Theory and Formal Languages by means of Context-Free
Grammar Representations [29]. The derivation process provides a map-
ping between feature models and business process models that improves
the design step of the PFE approach by means of improving the main-
tainability of feature models and BPMN, and eliminating errors derived
from manual transformations. In addition, we avoid the need of extend-
ing the standard notation of BPMN with information that is present in
the feature model. Theses mapping rules [37] are defined previously
at Section §5.2. Thus, the variability aspects identified by the PFE ap-
proach, described in Section §1.3.3, can be represented by the feature
model 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

89. 5.3. Business Family Domain Engineering 69
Variation Variation Send
Inform
Tickets
Extension Book
Point Point Point Tickets
( Number of Seats
Variants Inform by Inform by Send Send
Intranet
50 and 100 ) Variants Tickets
Quality
E-Mail Information Assurance
or about Trip
( Number of Seats
Inform 100 )
Inform Inform by Send Book
E-Mail Send Send Book
Tickets Tickets
Collapsed Tickets Tickets Tickets
Collapsed Collapsed
Inform by
Send Quality
Intranet
Info ... Assurance
Expanded Expanded Expanded
(A) Alternative Behavior (B) Parameterization (C) Inheritance (D) Extension Point
Figure 5.12: Variability aspects described by the PFE approach, represented at
the 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 the
parent feature is considered the variation point, and the children are
considered variants [46]; and a gateway Xor of BPMN, which defines
that only one subprocess controlled by this gateway, Inform by e-mail
or Inform by Intranet, must be completed for performing the subprocess
Inform ; (B) Parameterization is resolved by rewriting the condition for
accepting several value ranges; (C) Inheritance is defined by means of an
Or relation on the feature model, defined at Section §1.3.2, and a gate-
way Or of BPMN, which defines that almost one subprocess controlled
by this gateway, Send Tickets and Send Information about Trip, must be
completed for performing the process Send Tickets ; and finally, (D) Ex-
tension Points is defined by means of an optional relation at the feature
model, defined at Section §1.3.2, and an Xor gateway of BPMN with an
empty option.
The derivation process requires that the feature model is expressed
through an specific characterization based on a merge operation between
the Commonality Summary and the Variability Model, since to we con-
sider the Core Assets as children nodes into to Commonality Summary
feature 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 reusable
assets of the business family. In the SPL field the assets are software ar-
tifacts. In a business family, the assets are business processes that are
defined by means of their respective process models represented using
BPMN. Figure §5.13.a sketches an overview of the Core Process Frame-
work. Each business process contained into the commonality summary

90. 70 Chapter 5. Business Families Domain Design
companies.iberia.processes.
variable.Inform.bpmn
Reusable Assets
Repository
Inform
PlanBook
(A) Overview of Core Process Framework (B) Overview of Non-Overlap Composition
between PlanBook (Core) and Inform
Figure 5.13: Overview of Core Process Framework.
is a considered as a component into the framework. In our case study
the processes named Order Trip, Change Itinerary, Reserve Tickets and
Cancel Itinerary are the core processes that composes the activity named
PlanBook. In addition, this framework provides the enough linking ar-
eas for adapting specific business process from concretes companies, for
example introducing into an instance of the framework the business pro-
cess Inform from Iberia. Figure §5.14 presents the basic structure of the
Core Process Framework of our case study in BPMN, obtained from the
derivation 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-context
free business process specification. These rules need to be performed
manually 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) introduce
start and finalization specific events (message, timer, etc.); (iv) introduce
exception 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 mechanisms
needed 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-

91. 5.3. Business Family Domain Engineering 71
PlanBook
Change
(Core) Itinerary
Cancel
Itinerary
Airline Travel Agency
Book
Tickets
Book
Seats
Send
Tickets
Send
Statement
Verify Seats
Availaibility
Figure 5.14: Basic Structure of the Core Process Framework obtained from the
derivation 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 business
process models composition: Non-Overlap Composition and Overlap
Composition. 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 as
independent processes that do not collaborate with anyone, but all
these 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 PlanBook 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). On
the other hand, an Overlap Composition is defined as a composition be-
tween two or more business process models that collaborates between
them, in terms of generating and consuming some artifacts between
them that rules the dependency from other to perform its activities. This
type of composition can only be done manually. Nowadays, one of the
topics of our research is focused on providing algorithms for assisting
these kinds of composition and for checking the consistency of the com-
posed business process models. For that purpose, we take the algorithms

92. 72 Chapter 5. Business Families Domain Design
presented in [43] as starting point for this future work.
• Define the Evolution of the Framework: it is focused on defining the
evolving 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 business
process models into the core architecture by means of the compositions
defined at the previous step. Thus, the main difference between the pro-
cess framework provided by the PFE approach and our Core Process
Framework is that PFE defines only one product (core architecture) not
variable, 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 for
describing the evolving behavior of the architecture. We have explored
the feasibility of several SPL techniques in [38], and we consider that
the variability of this architecture can be supported by means of feature
modeling techniques. Thus, this activity generates the artifact that rep-
resents these evolutions, namely Evolution Feature Model or Product
Evolution Model (PEM), which provides enough support for analysis
and visualisation of runtime variability [40].

93. Chapter 6
Business Families Choreographies
Design
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 the
context of Business Family Engineering (BFE) is defined. Our approach is fo-
cused, on the one hand, on propose a choreography model based on an UML2
profile used on the Agent-Oriented Software Engineering (AOSE) field that
makes feasible the variability support. Section §6.2 presents our proposed
model. On the other hand, in Section §6.3, we provide a transformation be-
tween this choreography model and BPMN elements for improving the design
of business families. As result of our contribution, we obtain a representation
of collaboration scenarios and behavioral interfaces automatically, that can be
implemented by means of the Web Service Choreography Interface (WSCI)
specification.

94. 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, together
with the behavioral constraints between them. Thus, choreography models
represents the observable behavior of business partners defined by means of
interaction contracts. In addition, the introduction of Software Product Lines
(SPL) techniques into the development of Business Information Systems (BIS)
is expected to become a new development paradigm, of what we call Business
Family, maximizing reuse and dealing with variability on business process
definitions, including the notion of interacting processes.
However, current proposals for modeling these interactions, by means of
choreography models, does not provide any support for introducing these
variability aspects. The contribution of this work is two-fold: in the one hand,
we propose a choreography model based on an UML2 profile used on Agent-
Oriented Software Engineering (AOSE) field that makes feasible the variabil-
ity support, shown in Section §6.2; and in the other hand, in Section §6.3, we
provide a transformation between this choreography model and BPMN ele-
ments for improving the design of business families, by means of the Business
Family Engineering (BFE) approach.
6.2 Choreography Modeling in BFE
Modeling choreographies is considered a core need for designing Business
Information Systems (BIS). However, there not exists an standard notation
for that purpose. Latest drafts for BPMN 2.0. specification †1 , explores new
notations for representing it, since to some drawbacks has been identified on
modeling choreographies using the current BPMN specification [20]. A draft
specification model based on Decker et al. works [18–20] has been proposed of
BPMN 2.0. It has not been included on lastest BPMN 1.x official specifications.
Figure §6.1 sketches the Order Trip subprocess choreography model using
the proposed models in BPMN 2.0. It represents a collaboration between three
different participants named: Traveler, Travel Agent and Airline Reservation
System. The initiator partner of each collaboration is denoted by means of a
gray-colored background. In addition, each of them specify the message send
†1
http://www.omg.org/cgi-bin/doc?bmi/08-09-04

95. 6.2. Choreography Modeling in BFE 75
I want to Cheapest Search seats
travel to Ulm price for trip and
preferences
Traveler Traveler Travel Agent Traveler
Travel Handle Verify Seats Trip
Avaliability
Request Preferencies Request
Travel Agent Travel Agent Airline Travel Agent
Reservation
System
Give me Here is
your preferencies 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 of
four activities, previously identified by the process engineer as an Elementary
Business Process (EBP) [34] and four use cases in the Domain Requirements
Engineering activity defined in Chapter §5, Section §5.3.1. Concretely, use
cases are: Travel Request, Handle Preferences, Trip Request and Verify Seats
Availability, identified too as another EBP.
However, although this notation is valuable, it is not currently considered
part of the BPMN specification. In addition, there not exists any approach that
deals with variability aspects on choreography modeling, needed for perform-
ing business families.
In Business Family Engineering (BFE), each member of the family is a
variant-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. Our
proposed model is only focused on:
• High-level Structure Design: in this activity the participant roles as well
as their communication structures are identified. These participants has
been previously identified in the Domain Requirements Engineering ac-
tivities.
• High-level Behavioral Design: this activity is focused on specifying the
goals, also named milestones of the collaboration and the order in which
the goals are reached. These goals has been previously identified as fea-
tures in the Domain Requirements Engineering activities by the process
engineer too.

96. 76 Chapter 6. Business Families Choreographies Design
Travel Agent
Airline Travel
Agency
Travel Agent
Airline Travel
Agency
Order Trip 1..*
1..* Goal: Manage a preferred
trip request
Pattern: Collaboration
In: Data: Out:
Traveler
Traveler
1..*
Travel Request
environment
Goal: Manage a travel request
Traveler
Traveler Pattern: Collaboration
Role Goal: Planning on
In: Data: Out:
taking a trip
1..* Traveler. Traveler. Travel
Travel Request Goal : msg1 itinerary Agent:
Requesting a travel msg1
Handle Preferencies Goal: 1..*
Submitting trip preferencies
Trip Request Goal : Analysing
travel agent plan Handle Travel Agent
Travel
Traveler Preferencies
itinerary : Titinerary Agent
preferencies : TPreferencies Goal: Manage a preferencies Travel Agent
1..* request 1..*
validateTravel (travel:Ttravel): Pattern: Collaboration Role Goal: Provide a travel
boolean In: Data: Out: plan
Traveler. Traveler. Travel Travel Request Goal :
Traveler msg2 preferencies Agent:
Receiving a travel request
data
Travel Handle Preferencies Goal:
Agent Requesting trip preferencies
Trip Request Goal : Providing a
travel plan
Trip Request Verify Seats Availability :
1..* 1..*
Goal: Manage a trip request Requesting seats
Pattern: Collaboration
createTravel (itinerary :
In: Data: Out: Titinerary , preferencies :
Travel Travel
environment Agent: Agent.
Tpreferencies , seats:
Airline msg3 travel Travel Collection[Tseats]): Travel
Reservation System Airline Agent
Reservation
Role Goal: Provide a System
reservation service
Verify Seats Availability :
Verify Seats
Verifying submitted seats Availability 1..*
1..* Goal: Verify seats availability
verifySeats(nSeats : Integer , for a preferred plan
itinerary : Titinerary , Pattern: Collaboration
preferencies : Tpreferencies ): In: Travel Data: Out:
Collection[Tseats] Agent: Travel ARS.
msg2 Agent: Seats
data
Figure 6.2: Order Trip Choreography.

97. 6.2. Choreography Modeling in BFE 77
Once these designs has been performed, our proposed model allows to
provide automatically the collaboration scenario and the behavioral interface
for 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 on
Agent-Oriented Software Engineering (AOSE) field. The AOSE profile used in
this approach is the MaCMAS/UML profile [41]. MaCMAS is a methodology
that has been developed to deal with complex Software Systems, also named
Multi-Agent Software Systems (MAS). A MAS organization can be observed
from 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 into
hierarchical structures showing the social structure of the system.
To the best of our knowledge, this is the only modeling approach able to
represent variability aspects introducing Software Product Line (SPL) tech-
niques, such as combining it with feature modeling [44], without extending
current 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 between
this 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 the
choreography model is defined by means of this profile, MaCMAS/UML pro-
vides a representation of the static interaction relationships between roles in
the system and the knowledge processed by them. This interaction is defined
by means of multi-Role Interactions (mRI) models defined in [42]. These mRIs
are used to abstract the acquaintance relationships amongst roles in the sys-
tem. As mRIs allow abstract representation of interactions, we can use these
models at whatever level of abstraction we desire. At top of Figure §6.2, we
provide a high abstraction mRI model of Order Trip subprocess, and at bottom
of same figure we provide a more detailed mRI model of the same subprocess
providing the mRIs of Travel Request, Handle Preferences, Trip Request and
Verify 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 .

98. 78 Chapter 6. Business Families Choreographies Design
6.3 Transformation Catalog
Our transformation approach between choreography models described us-
ing MaCMAS and BPMN is focused on providing a catalog composed in three
categories:
• Data Objects Exchange in our Pool: focused on techniques for modeling
the 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.4
sketches the catalog proposed for this category.
• Message Exchange: focused on techniques for modeling the exchange
of messages between pools. Figure §6.5 sketches the catalog proposed
for this category.
Applying this catalog to the Order Process choreography model we obtain
the 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 mature
for providing a collaboration scenario, such as presented in Figure §6.6.a, but
several mapping relationships has been detected and the definition of these
relations is considered a future work in our research. In addition, providing
a 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. Variability
support is inherited from agents methodologies and several composition tech-
niques for runtime variability has been identified in [42]. For each evolution
of the business information system, a composition between the choreography
model of the core process framework and the added/deleted subprocesses
must be performed for obtaining a new WSCI implementation for this prod-
uct. Defining this process is considered a future work of our research too.

99. 6.3. Transformation Catalog 79
mRI Model Business Process Model
Y
Role Goal:
A Goal:
data
1..* Y
A
Y
Goal: ... A ...
Pattern: Collaboration
In: Data: Out:
Y.data
mRI Model Business Process Model
A
Goal:
Pattern: Collaboration
In: Data: Out:
Y.data
1..* Y
data
Y
Role Goal:
Y
A Goal:
B Goal:
... A ...
B
...
Y
1..*
B
Goal:
Pattern: Collaboration
In: Data: Out:
Y.data
Figure 6.3: Data Object Exchange in our Pool.

100. 80 Chapter 6. Business Families Choreographies Design
mRI Model Business Process Model
environment
X
Role Goal:
A Goal:
X ... A ...
1..*
A
Goal:
data
Pattern: Collaboration
in
In: Data: Out:
X.data
X
mRI Model Business Process Model
A
Goal:
Pattern: Collaboration
In: Data: Out:
Y.data
X
1..* Y
Y
in
Role Goal:
A Goal:
B Goal: data
Y
Y
1..*
B ... A ...
B ...
Goal:
Pattern: Collaboration
In: Data: Out:
X.in Y.data
1..* X environment
X
Role Goal:
B Goal:
Figure 6.4: Data Object Exchange between Pools.

101. 6.3. Transformation Catalog 81
mRI Model Business Process Model
environment
X
X
1..* A
A
Goal:
data
Pattern: Collaboration
in
In: Data: Out:
X.in X.data X
Y
Role Goal:
A Goal:
A Y
Goal: Send
Y
Pattern: Collaboration 1..* A
In: Data: Out:
Y.out
out
1..* X
environment
X X
Role Goal:
A Goal:
Y
Role Goal:
A Goal:
A Y
Goal:
Send
Y
Pattern: Collaboration 1..* A
In: Data: Out:
X.in X.data Y.out
data out
1..* X in
environment
X X
Role Goal:
A Goal:
Figure 6.5: Messages Exchange.

102. 82 Chapter 6. Business Families Choreographies Design
Travel
Request
Handle
Airline Reservation System
Preferencies Traveler
Data
Search seats Seats
for trip and preferences
Verify Seats
Travel Agent
Availability
Travel Handle Verify Seats Trip
Travel Request Preferencies Availability Request
Agent
Airline
Here is
Reservation Give
your trip
System Itinerary me your Preferencies Travel
I want to preferencies
Cheapest
travel to Ulm Price
Trip
Request Traveler
(A) Collaboration Scenario of Order Trip (B) Behavioural interface for Travel Agent
subprocess from our case study
Figure 6.6: Collaboration and Behavioral Interface obtained from the Transfor-
mation Catalog.
mRI Model Business Process Model
Y A
Role Goal: Y data
1..* Goal:
A Goal:
Pattern: Collaboration
Y
In: Data: Out:
... A ...
Y.data
module mRIModel2BPM
create 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: dataFlowPattern 1() : Boolean =
if self.out .type.toString() = ‘data’ then true else false endif ;
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 )
}
Figure 6.7: ATL definition of mapping between MaCMAS and BPMN.

103. Part IV
Contributions

105. 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, in
Section §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 Eclipse
M2M Transformation Project†1 . Finally, in Section §7.3, we provide a sum-
mary of our contributions classified according to the year of publication and
the topic, and our future work in Section §7.4.
†1
http://www.eclipse.org/m2m

106. 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 the
Software Product Lines (SPL) field. Roughly speaking, they propose to,
first, study the variability of the system without entering into details by
means of building a variability model (called feature model), that is used
later for building the business process. However, in PFE the process of
deriving the business process from the feature model is performed man-
ually. Authors use feature models with a different meaning that is com-
monly accepted in SPL. In this paper, we provide a rigorous description
for the new meaning of feature models, and a mapping relationship that
defines how to use the information in the FM for obtaining the basic
structure of the business process. In addition, as a proof of concepts, we
have implemented an MDD transformation that provides the expected
results.
Quality Levels: Acceptance Rate: 18%, IEEE Core: A
• Representing Runtime Variability in Business-Driven Development
Systems: I. Montero, J. Peña, A. Ruiz-Cortés. 7th IEEE Int. Conf.
on Composition-Based Software Systems (ICCBSS). 228–231. Madrid,
Spain. 2008 [38].
Abstract: Business-Driven Development(BDD) is a research field that
provides techniques and mechanisms for designing software systems
starting from the business processes of the companies. Companies are
in continuous evolution to adapt to market changes, thus, current pro-
cess engineers redesign the processes every time that is needed using ad
hoc techniques. This situation motivates that these changes, called run-
time variability, must be managed. Some authors have used Software
Product Lines (SPL) ideas to manage it. Current approaches for docu-
menting runtime variability in SPL and BDD, proposes different model
representations. Unfortunately, we have determined that the expressive-

107. 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 runtime
variability in BDD systems. The main contributions of this proposal are:
(i) it presents the enough expressiveness level for representing runtime
variability; 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 Product
Lines (DSPL 2008, Volume 2), in conjunction with SPLC08, 15–22,
Limerick, Ireland, 2008.
• Representing Runtime Variability in Business-Driven Development
Systems - Poster: I. Montero, J. Peña, A. Ruiz-Cortés. 7th IEEE Int. Conf.
on Composition-Based Software Systems (ICCBSS). 241. Madrid, Spain.
2008. [39].
Abstract: Current approaches for documenting runtime variability in
Software 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 that
SPL solutions needs for adaptation to BDD context for describing un-
der which circumstances a business evolves. In this panel, we present
a model for representing runtime variability in BDD systems. The main
contributions of this proposal are: (i) it presents the enough expressive-
ness level for representing runtime variability; and (ii) process engineers
can represent and understand under which events a business evolves
and 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

108. 88 Chapter 7. Contributions
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 on
Variability 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 Information
Systems (BIS) deploying business processes of the company directly on
a process engine. Business processes of companies are continuously
changing in order to adapt to changes in the environment. This kind of
variability appears at runtime, when a business subprocess is enabled
or 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). This
approach manages the variability by means of a SPL where each prod-
uct represents a possible evolution of the system. However, although
this approach is quite valuable, it does not provide process engineers
with the proper support for improving the processes by visualising and
analysing execution-time (non-design) properties taking advantage of
the benefits provided by the use of SPL. In this paper, we present our
first steps towards solving this problem. The contribution of this paper
is twofold: on the one hand, we provide a visualisation dashboard for
execution-traces based on the use of UML 2.0 timing diagrams, that uses
the PEM approach; on the other hand, we provide a conceptual frame-
work that shows a roadmap of the future research needed for analysing
execution-time properties of this kind of systems. Thus, due the use of
SPL, our approach opens the possibility for evaluating specific condi-
tions and properties of a business process that current approaches do
not cover.
Citations:
From Static to Dynamic Software Product Lines: K. Schmid, H.
Eichelberger. IEEE Computer Society 2nd International Workshop
on 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 Computer
Society 1st International Workshop on Dynamic Software Product Lines
(DSPL 2007, Volume 1), in conjunction with SPLC07, 33-40, Kyoto, Japan,

109. 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, from
the 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 with
ad 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 be
introduced. In this paper, we propose to adapt SPL techniques, oriented
to reuse software, to Business-Driven Development (BDD), oriented to
reuse processes, across different businesses; we call this proposal Busi-
ness Family Engineering (BFE). We present a first approach to build a
SPL 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 del
Software y Bases de Datos (JISBD). 1er Taller de Procesos de Negocio
e Ingeniería del Software (PNIS). II Congreso Español de Informática
(CEDI 2007). Pag. 34-40, Zaragoza, España. 2007 [35].
Abstract: Nowadays most companies in whichever field have a soft-
ware system that helps managing all the aspects of the company, from
the 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 with
ad 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 be
introduced. In this paper, we explore the feasibility of adapting SPL
techniques, oriented to reuse software, to Business-Driven Development
(BDD), oriented to reuse processes, across different businesses; we call
this approach Business Family Engineering (BFE). As a result of our
study, we show some of the problems we have identified and some of
the key aspects needed to enable this new field.

110. 90 Chapter 7. Contributions
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 focused
on providing a framework for Model-Driven Development (MDD) model to
model transformation languages. Nowadays, there exist three transformation
engines 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 Platform2
BPMN metamodel †5 as target metamodel using the ATL language. Figure
†2
http://www.eclipse.org/m2m
†3
http://www.eclipse.org/m2m/atl
†4
http://www.isa.us.es/fama
†5
http://www.eclipse.org/stp

111. 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 the
Eclipse 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 from
a feature model for representing runtime variability in business infor-
mation systems created using FAMA (FeAture Model Analyzer) into a
business 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=52action=singlenewsidN=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 the
different research contexts in which our contributions were presented. The

112. 92 Chapter 7. Contributions
2007 2008 2009
Implementation Layer
SCC’ 08 BPM’ 09
- Tool support (ATL, Eclipse SOA Tool Platform)
VAMOS’ 08
- UML 2.1 Timming Diagrams
Operational Layer PNIS’07 DSPL’07 ICCBSS’08
- Business Driven Development
PNIS’07 DSPL’07 VAMOS’ 08 ICCBSS’08
- Software Product Lines
SCC’ 08
- Model Driven Development
BPM’ 09
- Agent Oriented Software Engineering
Characteristic Layer
ICCBSS’08 SCC’ 08
- BPMN
BPM’ 09
- WSCI
Abstract Layer
SCC’ 08
- Automata Theory and Formal Languages
1 International Workshop 2 International Conferences 1 International Conference
1 National Workshop 1 International Workshop
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 (dotted
lines means a publication under construction) is presented together with the
acronyms of the paper.
7.4 Future Work
Taking into account our proposed holistic research framework defined in
Chapter §1, Section §1.5, we provide, in Figure §7.3, a brief summary about
the number of contributions that explores at least one of the defined layers.
Our efforts in future work, must be focused on providing a formal definition
of our approach supported by terms identified in the abstract layer of our
framework.

113. 7.4. Future Work 93
2 contributions published,
1 contribution under construction
Implementation Layer 5 contributions published,
(ATL, Eclipse SOA Tool Platform, …) 1 contribution under construction
2 contributions published,
Operational Layer 1 contribution under construction
( Business Driven Development, Software Product Lines,
Model Driven Development, Agent Oriented Software Engineering) 1 contribution published
Characteristic Layer
( BPMN, WSCI, BPEL)
Abstract Layer
( Automata Theory and Formal Languages,
Context-Free Grammars, Finite State Machines, …)
Figure 7.3: Total of contributions by defined layers in our holistic framework.
Regarding our hypothesis and research questions, we must conclude the
following issues for future work:
• Business Families. Does it makes sense? : The answer is that business
families are feasible. Its main benefit is that software companies that pro-
vide BDD solutions, can reuse process in a systematic way, thus reducing
costs (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 discussion
to higher research communities, as for example the BPM conference†6 .
• The Software Product Line (SPL) field has a lot of benefits and Business
Process Management too, How many benefits have SPL and BPM to-
gether? : Nowadays, we have explored in [36] and [38] that the main
benefits of SPL and BPM together are focused on increasing the reusabil-
ity level of the business process definitions, and in addition, providing a
model for representing runtime variability in BIS. Future work planned
for this issue is focused on formalizing our proposal for representing
runtime 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 techniques
in the Business-Driven Development (BDD) field? : We have identified
some 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
†6
http://www.bpm2009.org

114. 94 Chapter 7. Contributions
propose the use of SPL techniques. We have explored this approach in
several contributions [35, 36, 38, 40], and an improvement of its design
phase has been proposed in [37]. Once this issue is closed, a survey
should be performed and submitted to an international conference or
journal as future work.
• What kind of variability aspects can be performed on defining business
processes? : 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 such
as requirements engineering in the context of Business-Driven Develop-
ment are not taking into account. Our future work is to identify new
variability aspects and clasify them in order to provide a best support of
them 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 proposal
which 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 abstract
foundations, such as automata theory and formal languages in [37]. In
addition, 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 and
how are them represented? : We have identified at least two kinds of
variability, static and dynamic variability, also named design-time and
runtime variability. Current approaches for supporting variability in the
definition of BIS, only takes into account the static variability. We have
proposed 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 for
an analysis framework in [40]. These proposals are in a very preliminar
stage, and they should be revised and refined as future work.
• How many current proposals for modeling choreographies deals with
variability aspects? : To the best of our knowledge, there not exists any
approach for modeling choreographies that deals with variability as-
pects. We take [23] as starting point of our research. A proposal for a
choreography model for designing business families and for integrating
it into our approach is one of our most recent open issues.
• How many current proposals for modeling choreographies provides an
automated treatment for obtaining collaboration scenarios and behav-

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

116. 96 Chapter 7. Contributions

117. 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), in
Chapters §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 purpose
of this chapter is to clarify our conclusions.

118. 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 a
new concept into the Business-Driven Development (BDD) context fo-
cused on define a set of Business Information Systems (BIS) which shares
common business processes definitions. The main conclusion is that
business families are feasible and it provides several advantages to im-
prove the process engineers activities [35, 36]. In addition, we define a
methodology for performing business families named Business Family
Engineering.
• Variability Modeling of Business Information Systems: we provide to
process engineers several techniques and models for representing (static
and dynamic - also named runtime ) variability in Business Information
Systems without the need of extending current standard notations [37,
38]. In addition, our proposal makes feasible to visualise and analyse
variability in this context [40].
• From Feature Models to Business Processes: we improve the design
step of the Process Family Engineering (PFE) approach, providing a
systematic transformation between feature models and business process
definitions in BPMN. As proof of concepts, we develop this transforma-
tions by means of Model-Driven Development (MDD) tools, and it has
been included into an official Eclipse project repository.
• Dealing with Variability on Choreography Modeling: we propose a
choreography modeling technique based on an UML profile from the
Agent-Oriented Software Engineering (AOSE) field, that makes feasible
to deal with the implicit variability of business families. In addition, a
preliminary transformation catalog between this model and BPMN in or-
der to obtain collaboration scenarios and behavioral interfaces has been
proposed.
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 that
makes feasible the development of families of Business Information Systems
into the Service-Oriented Computing context.

119. Part IV
Appendix

121. Appendix A
Relevant Publications
I n this appendix, we present two published contributions that provides our
first 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 methodology
fragment 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 in
the A category in the CORE ranking. The second paper has been published
in the proceedings of the Seventh International Conference on Composition-
Based Software Systems (ICCBSS 2008). This conference has been ranked in
the B category in the CORE ranking. Finally, last paper is under construction,
and is planned to be sent to the International Conference on Business Process
Management (BPM). This conference has been ranked in the A category in the
CORE ranking.

122. BibTex
From Feature Models to Business Processes∗
Ildefonso Montero, Joaquín Peña, Antonio Ruiz-Cortés
Depr Lenguajes y Sistemas Informáticos. University of Seville. Spain
{monteroperez, joaquinp, aruiz}@us.es
Abstract Analysis Design Implementation
Deploy Business
Representing Derive manually a
Requirements Process Model
Variability by Business Process
The variability level of average-size Business Informa- Capture
Feature Modelling Model
into a process
engine
tion Systems (BIS) is highly enough for making the design
Requirements Feature Model Business Process Model
of this kind of systems a complex task. There is an approach Business
Information
System
called Process Family Engineering (PFE) that tries to ease Our approach Automatic Basic
Derivation of Structure of a
the design of BIS using ideas from the Software Product Business Business
Process
Process Models Model
Lines (SPL) field. Roughly speaking, they propose to, first,
Design
study the variability of the system without entering into de-
tails by means of building a variability model (called feature
model), that is used later for building the business process. Figure 1. Overview of the PFE approach for
However, in PFE the process of deriving the business modeling BIS and our approach
process from the feature model is performed manually. Au-
thors use feature models with a different meaning that is
commonly accepted in SPL. In this paper, we provide a rig-
scribe the products by means of variability models, such as
orous description for the new meaning of feature models,
Feature Models (FM), that contains only features and rela-
and a mapping relationship that defines how to use the in-
tionships between them. A feature is considered as a char-
formation in the FM for obtaining the basic structure of the
acteristic of the system that is observable by the end users.
business process. In addition, as a proof of concepts, we
Feature Models describe which features are present in all
have implemented an MDD transformation that provides
the products, called core features, and which not, called
the expected results.
variable features.
Schnieders et al. propose a methodology for designing
highly variable business processes [9]. It is based on over-
1 Introduction coming the complexity derived from variability, by means
of applying software product lines for managing it. This
The development of Business Information Systems (BIS) methodology, called Process Family Engineering (PFE),
is focused on providing techniques and mechanisms for de- presents three steps for modeling variant-rich BIS, as shown
signing software systems based on the business processes in Figure 1, namely: (i) Analysis, which is focused on per-
of the companies, defined graphically by means of busi- forming a requirements capture that covers the user needs
ness process modeling notations, such as Business Pro- and describes the variability using feature models; (ii) De-
cess Model Notation (BPMN) [4]. The variability level of sign, which is focused on deriving manually a business pro-
average-size BIS is usually highly enough for making the cess model from a feature model that represents its variabil-
design of this kind of systems a complex task. ity; and finally (iii) Implementation, which is focused on de-
Software Product Lines (SPL) systematizes the reuse ploying the business process model specification into a pro-
across the set of similar products that a software company cess engine that executes it and produces a BIS. Thus, PFE
provides. For that purpose, this approach requires to de- reduces the complexity derived from variability by means
of studying features models that do not provide details on
∗ This work has been partially supported by the European Commission
how each process is performed.In addition, PFE considers
(FEDER) and Spanish Government under CICYT project Web-Factories
(TIN2006-00472), Andalusian Government project ISABEL (TIC-2533),
that sometimes a feature represents an activity, sometimes
and under a scholarship from the Education and Universities Spanish Gov- a business process, but without providing an equivalence
ernment Secretariat given to the author Ildefonso Montero. definition. Thus, we can say that in PFE there not exist a

123. mapping relationship between feature models and business conforms to
.ecore
process models (see Section 2). Metametamodel
However, although PFE may be the solution to man- Automata Theory and Formal Languages
conforms to conforms to
FM .km3 BPMN .km3
age the evolution of the business process of a company, CFG FSM Metamodel Metamodel
the Design step of this approach, concretely the use of fea- conforms to conforms to
ture models and the derivation of business processes from .xmi .xmi
it, presents three main drawbacks, which are the focus of
this paper. First, ambiguity: PFE uses feature models to
Source Model Target Model Source Model Target Model
show the variability derived from enabling/disabling fea-
b. Our mapping prototype based on MDD
ture/process; however, given that feature models are de- a. Our systematic mapping approach
Model to Model transformation
voted to represent design-time variability and not runtime
variability [8][6], the approach redefine the semantics of Figure 2. Overview of our approach and our
feature models implicitly, but without providing a defini- first prototype for automated mapping
tion for it. Second, maintenance: PFE extends the nota-
tion of BPMN to add information about variability which
is also present in the feature models, thus, information
is duplicated with the obvious problems for maintenance. 2 Definition of a New Semantic for Feature
Third, manual derivation: the relationship between a fea- Models
ture model and its corresponding business process is not
rigorously defined, and the development of the business In order to perform a Process Family Engineering (PFE)
process is performed manually using as input the feature feature model grammar representation, we need to define a
model, what makes this activity error-prone and hinders the new Context-Free Grammar (CFG) taking into account that
maintainability of both kind of models. in SPL it is not needed to establish the order of appearance
Thus, the main motivation of this paper is to improve the of the features into a family product, but in our context it is
design step for modeling highly variant-rich business pro- recognized as a core need. Process engineers need to per-
cess models proposed by PFE. For that purpose, we provide form business process definitions which establish the order
a rigorous description for the new meaning of feature mod- that the processes must be performed and its dependencies
els, presented in Section 2, and mapping relationship that with others (i.e: subprocess A and B must be done in paral-
clearly defines how to use the information in the FM for ob- lel, and after that, subprocess C must be performed).
taining the basic structure of the BP (that needs to be com- For defining this mapping between FM and business pro-
pleted manually), detailed in Section 3. As shown in Figure cess, we have considered that:
1, the derivation of the basic structure of a business pro-
cess model from a feature model will be done automatically. • parent features in a feature model, namely variation
This transformation is achieved by redefining the seman- points, are considered as complex processes.
tics of feature models (FM) using context-free grammars,
a transformation of this grammar to a finite state machine • child features in a feature model, namely variants, are
model, and a representation of these state machines using considered as subprocesses.
business process models. Figure 2.a sketches the overview
of this systematic mapping. In addition, as proof of con- In order to rigorously define the new semantics, we reuse
Batory’s grammar representation of FM [3] as starting point
cepts, we also provide an implementation, by means of a
MDD transformation, of the mapping between feature mod- for proposing a new grammar. The redefinition is shown in
Figure 3. From this grammar, a regular expression of these
els and business process models using Atlas Transformation
languages can be obtained by means of operations of au-
Language(ATL)1. Figure 2.b presents the overview of this
implementation. tomata and formal languages theory defined in [7]. Figure
3 sketches also the equivalence of a feature and its relation-
As a result of our contributions, we improve the design
ships in terms of regular expressions (Notice that parallel
of complex business process models. Concretely, we im-
execution of features are represented by means of • char-
prove the Design step of the PFE approach by means of im-
acter). In addition, each possible composition between two
proving the maintainability of feature models and BPMN
or more different artifacts is resolved by means of parallel
since we provide an automatic mapping that can reduce er-
decompositions. Figure 4 presents an example of this com-
rors derived from manual transformations. In addition, we
position which sketches how a feature model with three dif-
avoid the need of extending the standard notation of BPMN
ferent relationships is defined by means of a composition of
with information that is present in the feature model.
three simplified feature models with only one relationship.
1 http://www.eclipse.org/m2m/atl/ Thus, the CFG representation of composed feature model is

124. Feature Model Finite State Machine Model Business Process Model Feature Model Finite State Machine Model Business Process Model
Feature Start q0 a q1 ε q2
b1
q3 ε A A
A A B1
Alternative
A
q Collapsed
Start q0 q6
A A A ε ε B2
ε q1 b
q2 ε q3 B B1 B2 q4
b2
q5
Start q0 Collapsed
Relationships
Expanded
B Expanded
ε ε
Mandatory
b1 b2
q1 q2 q3
ε b1 q2
b2
q3 ε
q1 A A B1 ε b1 ε A A B1
A A q4 q5
ε
q5 ε q9
b1~b2 Collapsed
Start q0 q4 ε b1~b2 ε Collapsed
q11
Or
Start q0 q6 q7
B2 B2
B1 B2 B1 B2 ε ε
q8 ε
ε b2 b1 b2
q6 q7 Expanded q8 q9 Expanded
ε b2 b1 ε
A ε q1 ε A A q10
q11
q12
Collapsed
ε b ε
B Start q0 q2 q3 q4
B Feature Model Finite State Machine Model Business Process Model
Relationships
Expanded
ε ε F
q1 A A
ε b1 ε Collapsed R1 Rn ε ε
Optional
q2 q3 ... q1 ... FM1 ...
A B1 F FM1
ε εq
Composition
b1~b2
Start q0 q4 q5 14 FM1 FM n ε ε ...
ε b2 ε Start q0 q2 ... FM2 ...
B1 B2 q6 q7 B2 ... ... FMn
ε
F: Feature ε ε
b2 b1 ε Expanded
Ri: Relationship qn ... FMn ...
q8 q9 q10 FMi: Feature Model
Dom(Ri): { Mandatory ,
ε b1 b2 ε Optional,
q11 q12 q13 Alternative,
Or }
Figure 5. Feature Model to BPMN Mapping and Composition Catalog Proposed
obtained by means of applying • operator to three simplified tion. It has been published on Eclipse ATL website.3 .
feature models CFG representations defined previously.
4 Related Work
3 Mapping a Feature Model to a BPMN
Structure According to [2], to perform a survey in the software
engineering field, we have to define an analysis frame-
work with the following components:(i) research questions:
Automata and formal languages theory sets the steps
How is performed the mapping between feature diagrams
needed to obtain a Finite State Machine (FSM) model from
and business process models?, and How is documented
a Context Free Grammar (CFG) and viceversa[7]. Apply-
variability in a BIS context?; (ii) a search strategy to se-
ing this mapping we provide a FSM representation of the
lect sources: we have searched the bibliography at DBLP,
feature model grammars presented previously.
Google Scholar, and ISI Web of Knowledge choosing pa-
In addition, BPMN can be represented by means of
pers with a higher number of cites; and finally (iii) a cat-
FSMs[5]. In this approach, the equivalence based on which
alogue: we classify the approaches in those focused on
artifacts of BPMN can implement the behavior of a FSM
the mapping between feature models and business process
has been explored, concluding that representing a FSM by
models, and those focused on variability representation.
means of BPMN is feasible.
After searching the selected sources, we have found only
The BPMN specification does not provide any constraint
one proposal that cover our first research question: How is
about the order of performing subprocesses in any situation.
performed the mapping between feature diagrams and busi-
In addition, the BPMN gateways defines that the subpro-
ness process models?. Bae et al. [1] proposes a method for
cesses contained in it can be done as a sequence or parallel
deriving a feature model from a business process model in
under several constraints. Thus, the BPMN gateways are
order to provide a process family based on obtaining an in-
feasible to be used for implementing proposed finite state
termediate use case representation of the business process.
machines behavior, as shown in Figure 5 that presents the
Each feature is considered as a group of use cases, which
equivalence between each of FSMs and its representation
are associated to perform an specific business activity. The
using BPMN.
method proposed considers that a set of subprocesses is
As stated previously, we have developed a proof of con- equivalent to an specific feature. In addition, transforma-
cepts of the mapping by means of MDD. For that purpose tion is performed manually.
we have developed a prototype using the FeAture Model An- On the other hand, regarding to our second research
alyzer (FAMA) metamodel as source and the Eclipse SOA question: How is documented variability in a BIS context?
Tool Platform2 BPMN metamodel as target metamodel us- only Process Family Engineering (PFE) [9] explores the
ing an Atlas Transformation Language (ATL) transforma-
3 ATL code and specification is available in
2 http://www.eclipse.org/stp http://www.eclipse.org/m2m/atl/atlTransformations/#FM2BPMN.

125. Regular Context- Free
Feature Model Expressions Grammar provides a maintenance improvement, and (iii) it defines an
a=r S : A; F F: Feature
Feature A } a{ = L A : a; Ri: Relationship
FMi: Feature Model
A R1 Rn
b=r A : B; ... Dom(Ri): { Mandatory ,
}b { = L B: b; Optional,
Alternative,
B FM1 FMn Or }
Mandatory
A:B
2 1 B
F = FM1 FM2 … FMn
| 2b 1b = r
A | 1b 2 b |B
1 2 B
2b. 1 b B
2 1 | .B
,2b 1b { = L ; A
B1 B2
,1b2 b B :b
1 1 ; A A B
}2b.1 b
B :b
2 2 ; B C
=
A:B D E B C D E
A ?b = r
ε
}b , {=L |ε
;
B B : b;
Relationships
A: C | B C | C B | C B;
B: D E | E D | D E | D | E;
Optional
A:B B2 1 C: c;
D: d;
| ? 2b?1 b = r |B B1 2
A E: e;
| ?1b? 2 b B .B
2 1 |
2b. 1b B 1 | Grammar Representation
ε
,2 b ,1b , { = L B 2 | Composition
B1 B2 1b2b ,2 b1 b ε
|
} 2b .1 b ;
B :b ;
1 1
B :b ;
2 2 Figure 4. PFE FM Grammar Representation
A:B 1 Composition
Alternative
A | 1b = r
2b B
2 |
} 2b , 1b { = L ;
B1 B2 B :b ;
1 1
B :b ;
2 2
A:B 2 1 B automatic mapping which maximizes quality level and min-
| ? 2b 1b = r |B 1 2 B
A | ? 1b 2 b
2 b. 1 b
B
B
2 1 |
1 |
.B imizes error rate.
Or
,2 b , 1b { = L B 2 |
B1 B2 ,1b2b ,2 b 1 b
} 2 b. 1 b ;
B :b ;
1
B :b
2
1
2 ; References
[1] J. Bae and S. Kang. A method to generate a feature model
Figure 3. PFE Feature Model and its CFG rep-
from a business process model for business applications. In
resentation
CIT ’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. A
idea of using feature models for managing variability in systematic review on domain analysis tools. In Proceedings
a BIS context, but the relationship between these feature of the International Symposium on Empirical Software Engi-
neering and Measurement. ESEM07., 2007.
models and its products, defined by means of business pro-
[3] D. Batory. Feature models, grammars, and propositional for-
cess models, is not clearly defined as stated in Section 1. 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 version
5 Conclusions 1.0 - may 3, 2004. OMG.
[5] E. Börger and B. Thalheim. A Semantical Framework for
Business Process Modeling. With an Application to BPMN.
not published. 2007.
We have explored the Process Family Engineering (PFE) [6] H. Gomaa. Feature dependent coordination and adaptation
approach for managing the complexity derived from model- of component-based software architectures. In WCAT ’07:
ing variant-rich business process models. Thus, we have de- 4th Workshop on Coordination and Adaptation Techniques for
tected some drawbacks in one of the steps of this modeling Software Entities, 2007.
methodology, concretely on design phase, identifying am- [7] J. Hopcroft and J. Ullman. Introduction to Automata The-
biguities, maintenance problems and activities performed ory, Languages, and Computation. Addison-Wesley, Read-
manually which can be performed automatically. The main ing, Massachusetts, 1979.
[8] I. Montero, J. Peña, and A. Ruiz-Cortés. Representing Run-
motivation of this paper is to solve the identified problems.
time Variability in Business-Driven Development systems. In
For that purpose, as shown in Figure 5 in Section 3, we pro- Proc. of the 7th Int. Conf. on Composition-Based Software
vide a mapping from feature models for representing vari- Systems (ICCBSS08), 2008.
ability in BIS, whose semantic is significantly different than [9] A. Schnieders and F. Puhlmann. Variability mechanisms in
traditional, to basic structures of business process models, e-business process families. In Proceedings of BIS ’06: Busi-
represented using BPMN. The main advantages of our ap- ness Information Systems, 2006.
proach are: (i) it is defined as a systematic process, (ii) it

126. BibTex
Representing Runtime Variability in Business-Driven Development Systems∗
Ildefonso Montero, Joaquín Peña, Antonio Ruiz-Cortés
Departamento de Lenguajes y Sistemas Informáticos
Av. Reina Mercedes s/n, 41012 Seville (Spain)
University of Seville
{monteroperez, joaquinp, aruiz}@us.es
Abstract and their strategic management. Thus, Information Tech-
nology (IT) infrastructure must evolve to adapt companies
Business-Driven Development(BDD) is a research field to the continuous evolution of markets. Currently this evo-
that provides techniques and mechanisms for designing lution is supported by ad hoc techniques to maximize the
software systems starting from the business processes of the level or reuse from one version to another, redesign the pro-
companies. Companies are in continuous evolution to adapt cesses every time that is needed. It motivates that runtime
to market changes, thus, current process engineers redesign variability support in business processes is needed.
the processes every time that is needed using ad hoc tech- Software Product Lines (SPL) systematizes the reuse
niques. This situation motivates that these changes, called across the set of similar products that a software company
runtime variability, must be managed. Some authors have provides. A. Schnieders et al. explores the idea of apply-
used Software Product Lines (SPL) ideas to manage it. ing (SPL) techniques to BDD in an approach called Pro-
Current approaches for documenting runtime variability cess Family Engineering (PFE) [7]. Basically, PFE follows
in SPL and BDD, proposes different model representations. the SPL philosophy for managing the variability of the busi-
Unfortunately, we have determined that the expressiveness ness process of an unique business, thus, managing only one
level in BDD is not adequate, and that SPL solutions needs software system. That is to say, each product in PFE rep-
for adaptation to BDD context for describing under which resents an evolution of the process (at runtime). However,
circumstances a business evolves. although PFE may be the solution to manage the evolution
In this paper, we present a model for representing run- of the business process of a company, proposed models, fea-
time variability in BDD systems. The main contributions ture models, are not expressive enough for documenting this
of this proposal are: (i) it presents the enough expressive- evolution because they are devoted to design time.
ness level for representing runtime variability; and (ii) pro- In addition, runtime variability has been also analyzed in
cess engineers can represent and understand under which the SPL field: J. Bosch et al. in feature models [4], and H.
events a business evolves and how this evolution is man- Gomaa et al. in software components-based architectures
aged, which is not present in current approaches. We call design [3][2]. Although these proposals presents valuable
this approach Product Evolution Model (PEM). solutions for other contexts, they need for integration and
extensions in the BDD context.
The main motivation of this paper is that analyzed ap-
1 Introduction proaches in BDD does not provide the expressiveness level
needed for representing runtime variability. In addition,
Business-Driven Development (BDD) is a research field current approaches does not take into account that process
that provides techniques and mechanisms for designing engineers must document, in their business process defini-
software systems starting from the business processes of the tions, a clear description about under which circumstances
companies. Nowadays, BDD systems supports most of the some processes are in use and which do not at runtime; and
activities of a company due to it improves their daily work how these processes are performed in a business evolution
(a parallel collaboration between processes, a sequence,
∗ This work has been partially supported by the European Commission
etc).
(FEDER) and Spanish Government under CICYT project Web-Factories
(TIN2006-00472) and under a scholarship from the Education and Univer-
Our approach integrates quoted approaches for model-
sities Spanish Government Secretariat given to the author Ildefonso Mon- ing runtime variability in BDD systems oriented providing
tero. a set of artifacts able to represent properly runtime evolu-

127. : Core Features CF
tions and trigger events that implies these changes into the Fast-Food Restaurant
: Variable Features VF
business process of a company. For that purpose, we pro- Serve
vide an abstract formal description of business evolutions Cook
Services
and a proposal for representing it based on Business Process Serve Normal Serve Fast
Mandatory Optional Alternative Or
Model Notation (BPMN) [1]. The main benefits of our ap- relation relation
A A
relation
A
relation
A
Establishment Delivery
proach are that it provides the enough expressiveness level B B B1 B2 B1 B2 Auto Cafeteria
for representing runtime variability in BDD systems, and A B
Requires constraint
A B
Excludes constraint
Birthday´s party
that events or conditions that fires business evolutions can
be observed and analyzed by process engineers.
Figure 1. Case Study: Fast Food Restaurant
This paper is structured as follows: Section 2 presents
the background information needed to understand our ap-
proach; Section 3 presents our approach for modeling run- couples of features. These are: (i) Requires: If a feature A
time variability in BDD systems, called Product Evolution requires a feature B, the inclusion of A in a product implies
Model; Section 4 presents the related work and motivation the inclusion of B in such product; and (ii) Excludes: if a
of our work; and finally, in the last section, we draw the feature A excludes a feature B, both features can not be part
main conclusions of our approach. of the same product.
2 Preliminaries 2.2 Process Family Engineering
2.1 Software Product Lines and Feature Process Family Engineering (PFE) [7] explores the idea
Models of applying SPL philosophy for managing the evolution of
BDD systems. PFE uses FM for representing the set of pro-
Software Product Lines (SPL) systematizes the reuse cesses contained into a business, and BPMN for represent-
across the set of similar products that a software company ing an specific process. In PFE, we obtain only one software
produces. The main goal of SPL is obtaining a reduction system that evolves at runtime, where the features are pro-
of the overall development costs and times for the products cesses. Every process evolution represents a product that
derived from the product line. In SPL a product is com- contains a subset of features, but the PFE system contains
posed of a set of common features and a set of variable fea- all the features.
tures. Common features appear in all products and variable The main difference between SPL and PFE is that SPL
features appear under demand of consumer’s products. Ob- provides a set of different products that shares common fea-
serving a certain product of an SPL, although it is described tures, and PFE provides only one product, which represents
as a set of fixed features, some features can be in use in a a business, that evolves at runtime, and each possible con-
certain moment and some not. This is called runtime vari- figuration of this business is managed as a product that con-
ability. tains a subset of features (processes) enabled at a certain
Feature Models (FM) are one of the most used artifacts moment of the execution. Thus, given that FM are devoted
for modeling variability, that is, specifying which features to design time, the main problem of PFE is that this ap-
are common and which are variable. A FM represents all proach uses FM for managing runtime properties.
possible products in an SPL in terms of features. There ex-
ists several notations of FM, such as FODA [5], or J. Bosch 3 Product Evolution Model
[4]. A FM establishes a parental relationship between each
feature, as shown in Figure 1, that can be: (i) Mandatory:
if a child feature node is defined as mandatory, it must be In this section, we present an abstract formal description
included in every product that contains the parent; (ii) Op- of Product Evolution Model and a proposal for representing
tional: if a child feature node is defined as optional, it can be it by means of an extension of BPMN using stereotypes. We
included or not when its father feature appears in a product; also include a case study to illustrate our approach.
(iii) Alternative: if the relationship between a set of children
nodes and their father is defined as alternative, only one of 3.1 Rigorous Description
the children features could be included in every father fea-
ture products; and (iv) Or: if the relationship between a Let B be a business. Each business can be defined as a
set of children nodes and their father is defined as or, one set of processes (denoted with P ). Thus, B can be defined
or more of them could be included in every father feature as follows:
products. In addition to the parental relations between fea-
tures, a FM can also contain cross-tree constraints between B = {P1 , P2 , ..., Pk }; k 0; 1 ≤ i ≤ n

128. Feature Model Formal Definition Process Evolution Model
Instant t Business B
Business B SVF t
F∆ (t, SV Ft ) = SV Ft+1 ∈ V F
•SV F t = SV F t+1
B
...
Business
CF +
CF SVF t
Processes
t+1 Figure 2.a sketches a graphical representation of F∆ ,
...
F (t, SVFt) F (t, SVFt)
where it is represented the transformation of SV Ft into
SV Ft+1 . In an instant t there exists an specific set of SV Ft
Instant t + 1
VF CF +
Processes
SVF t+1 SVF t + 1
...
t + k;
k0
for business B that evolves in instant t + 1 to another dif-
ferent set SV Ft+1 .
B
Legend Business
: Core Processes CF
: Variable Processes VF Processes
Figure 2.a. Formal Figure 2.b. Graphical 3.2 Graphical Notation
Description Notation
As shown previously, a business that evolves can be rep-
Figure 2. PEM approach defining a business resented by B = (CF, SV F ∈ V F, F∆ ). where the evolu-
evolution by F∆ function in t and t + 1. tion is defined by the F∆ function in t.
In PFE feature models (FM) are used to represent which
features are variable and which do not. From this, a the set
of common features (CF ) and (V F ) can be obtained [6].
F ( t, ServeInCafeteria) F ( t + 1, )
Fast-food restaurant
SVF t+1 : SVF t+2 : ServeInAuto
...
Serve in
Cafeteria and
Serve in
Serve in
Auto and ...
Thus, CF and V F can be represented by means of a FM.
Establishment Establishment Establishment
However, the feature model cannot establish the order
10:00 am
( t +1 )
11:20 am
( t +2 ) A client has arrived of apparition of business processes, represented as F∆ , due
Cafeteria Service close at 10:00 am to Auto-Service
to feature models are not devoted for temporal conditions
or variables (t) [2]. For that purpose, we have to add a
Figure 3. Fast-food restaurant Product Evolu- new model with a graphical notation that represents F∆ ,
tion Model BPMN Compositions the Product Evolution Model, which is defined by means of
a BPMN state machine where each state represents a prod-
uct and each evolution between two or more states, is repre-
Let CF be the set of common processes or features and sented by means of a transition that is an application of F∆
let VF be the set of variable features, thus B is defined for- function. Figure 2.b shows how an evolution of a business
mally as a tuple containing all the CF and a subset of V F is defined by means of F∆ function in t and t + 1 using
denoted as SV F : BPMN. Notice that it represents an specific graphical no-
tation for the formal description of our approach, but other
B = (CF, SV F ∈ V F ) notations can be applied.
To show our approach we use a fast-food restaurant
As shown before, in PFE, each configuration of the set of case study. Figure 1 depicts a simplified set of processes
processes enabled at certain moment represents a product. contained into a fast-food restaurant, where Serve Normal,
Thus, we can say that the CF of a B are always enabled Serve Fast and Serve in Establishment are CF , and the rest
at runtime, but the set of processes in V F is not fixed at of processes are V F . In Figure 3, we present the PEM of
runtime. our case study. Each process contains a BPMN model that
Thus, we can set up a product line that takes into account represents how all processes are performed. It defines the
this runtime variability. For formalizing these concepts we configuration of the business at runtime and shows that, in
should redefine each business B as: every runtime instant t, there exists a different SV F se-
lected which represents an evolution of the system. In this
B = (CF, SV F ∈ V F, F∆ : example, on a time instant t the restaurant open its cafeteria
service, thus, there exists in parallel two different processes:
: t, {F eature × ... × F eature} → Serve in Cafeteria and Serve in Establishment Normal/Fast
→ {F eature × ... × F eature}) (CF ). When the restaurant close its cafeteria service on
time instant t + 1, let us say 10:00 AM, F∆ function is ap-
where F∆ is a function that given a time instant t, trans- plied and an evolution is done to another state composed
forms the set of SV Ft into the new set of variable features only by CF processes. After that, the restaurant opens its
of the following time instant t + 1, that is to say SV Ft+1 , Auto-Service, due to a client has arrived with his car, and a
formally: new evolution is applied for t + 2 time instant.

129. Feature ing support for runtime variability for BDD systems. Bosch
Firefox
External Feature
approach represents a first step toward enabling runtime
variability support for feature models, but unfortunately it
Plugin or specialization
it does not associate any additional information about when
runtime
or how some features can be in use at runtime and which do
Website
not (it does not take into account F∆ ). Gomaa proposal is a
Flash Java
Debugger
solution to manage the evolution of software systems based
Figure 4. J. Bosch approach on architectural reconfiguration patterns and SPL ideas, but
it is focused in the context of software components archi-
State machine view Component model view Feature model view
tectures, instead of BDD systems. In addition, FM does
Activate
kernel
control component
MicrowaveControl
not represent how enable/disable features at runtime (F∆ is
Active Reactivate
Passivate
Microwave
System
partially supported but it is not associated with any FM).
[Waiting for
Passivate
[Processing
Neighbor
Response] ... ... ... Process engineers must see processes that are added or re-
Transaction]
Waiting for
Acknowledgement
optional
output component
BeeperComponent
ControlSystem moved from their business design instead of software com-
Passivating Transaction
Started
...
ponents reconfigurations at a lower and concrete software
Transaction Transaction
Ended *
Transaction
Passive
Aborted Beeper
development levels. Finally Schnieders proposal, PFE, uses
Ended **
Passive Acknowledgement
from all Neighbors
interface
IBeeper FM for managing runtime evolution, which are devoted to
{feature = Beeper}
Inactive + initialize() design time.
+ beep()
* At least one neighbor active
** All neighbors passive
5 Conclusions
Figure 5. Gomaa approach
We propose a new approach for modeling runtime vari-
4 Related work and motivation 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 expressive
As shown in Section 2, FM are one of the most used ar-
set of models which are able to represent and understand:
tifacts for modeling variability. Unfortunately, as shown by
(i) under which trigger events or business policies a busi-
[2], FM are devoted to design variability, and not for run-
ness evolves and (ii) how is managed this evolution.
time variability. To the best of our knowledge, there exists
only two approaches for documenting runtime variability
in SPL field. On the one hand, J. Bosch et al. [4] intro- References
duces an extension of FM for representing runtime vari-
ability. Bosch’s notation syntax is slightly different from [1] BPMI. Business process modeling notation BPMN version
FODA’s or FORM’s notation. It introduces a new kind of 1.0 - may 3, 2004. OMG.
feature, called external feature, represented by dashed rect- [2] H. Gomaa. Feature dependent coordination and adaptation
angles, for representing features that varies at runtime. Fig- of component-based software architectures. In WCAT ’07:
ure 4 depicts an example of a feature model in this notation Proceedings of the 4th Workshop on Coordination and Adap-
tation Techniques for Software Entities, 2007.
that represents Firefox plugin support. As can be observed,
[3] H. Gomaa and M. Hussein. Model-based software design and
time instants and conditions or constraints to enable/disable adaptation. In ICSEW ’07: Proceedings of the 29th Interna-
Website Debugger plugin, as for example concrete website tional Conference on Software Engineering Workshops, 2007.
domains, can not be represented with this approach. [4] J. V. Gurp, J. Bosch, and M. Svahnberg. On the notion of vari-
On the other hand, H. Gomaa et al. [3][2] propose a ability in software product lines. In WICSA ’01: Proceedings
set of models for representing runtime variability based on of the Working IEEE/IFIP Conference on Software Architec-
evolutionary reconfigurable software architectures. The dif- ture (WICSA’01), 2001.
ferent versions of an evolutionary system are considered a [5] K. Kang, S. Cohen, J. hess, W. Novak, and S. Peterson.
software product line, where each version of the system is a Feature-oriented domain analysis FODA feasibility study.
SPL member and the reconfiguration is defined by an state CMU/SEI-90-TR-21. Technical report, Carnegie Mellon Uni-
versity. SEI, 1990.
machine that, for each component, represents the steps that
[6] K. Pohl, G. Böckle, and F. van der Linden. Software Product
has to be performed to evolve from a normal operation state Line Engineering: Foundations, Principles and Techniques.
to an inactive state. Once inactive, the component can be Springer, September 2005.
removed and replaced with a different version. Figure 5 de- [7] A. Schnieders and F. Puhlmann. Variability mechanisms in
picts trigger events in the state machine. e-business process families. In Proceedings of BIS ’06: Busi-
Given this state, the motivation of this paper is that there ness Information Systems, 2006.
not exists any approach that provides an appropriate model-

130. Draft Version. Under construction
BibTex
Obtaining the Core Architecture of Business
Information Systems Families.
Ildefonso Montero, Joaquin Pe˜ a, and Antonio Ruiz-Cort´s
n e
Departamento de Lenguajes y Sistemas Inform´ticos
a
Av. 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 for
designing 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 software
company produces. It implies a reduction of development times and costs
and a quality improvement.
In order to increase the process definitions reusability, in this paper, we
propose a methodology based on applying SPL ideas for the systemati-
zation of the development of BIS across a several number of businesses
that shares common business processes. Thus, the contribution of this
work is to define and explore the feasibility and benefits of what we call
Business Family Engineering (BFE), providing its software process and
describing the steps needed to build the BFE core architecture, namely
Business Family Domain Engineering.
Keywords: Business Family Engineering (BFE), BFE Domain Engineer-
ing, Process Family Engineering, Software Product Lines, Variability of Process
Models, Core Architecture, BPMN.
1 Introduction
The development of Business Information Systems (BIS) is focused on providing
techniques and mechanisms for designing software systems based on the business
processes of the companies, defined graphically by means of business process
modeling notations, such as Business Process Model Notation (BPMN) [5]. The
variability level of average-size BIS is usually highly enough for making the
design 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 from
the Education and Universities Spanish Government Secretariat given to the author
Ildefonso Montero.

131. 2 Ildefonso Montero, Joaquin Pe˜a, and Antonio Ruiz-Cort´s
n e
exists several companies that shares common business processes, and maximize
the 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 reusability
on the development of BIS using ideas from the Software Product Lines (SPL)
field [22]. Roughly speaking, the SPL field systematizes the reuse across the set
of similar products that a software company provides. For that purpose, this
approach requires to describe the products by means of variability models, such
as Feature Models (FM), that contains only features and relationships between
them. 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 all
the products, called core features, and which not, called variable features. (See
Section 3.1 for a more detailed description).
In addition, the PFE approach identifies some variability aspects on business
process models, and proposes to extending the standard BPMN for representing
it [31]. However, although the PFE approach is quite valuable, it presents some
drawbacks related with ambiguity and maintenance that are described at Section
3.2.
Thus, the main motivation of this paper is to provide a methodology that
taking into account the PFE drawbacks makes feasible the possibility of develop
families of business information systems. For that purpose, as shown in Section
4, we provide a methodology named Business Family Engineering, and we define
the fragment of this methodology focused on obtaining the core architecture of
the family, namely Business Family Domain Engineering, that is the focus of this
paper. In addition, we motivate our approach by means of a real-life case study
defined in the Web Service Choreography Interface (WSCI) specification [24].
Finally, as proof of concepts, we have developed an Eclipse tool that provides
support for one of the activities of this methodology fragment. See Section 5 for
more details about tool support.
As a result of our contributions, we improve the development of business
information systems reducing its complexity level in situations where is needed
to perform a business family, using our proposed methodology. In addition, due
to our approach is focused on providing the core architecture of the family, we
provide to process engineers some artifacts for improving their activities, such as
a business family variability summary and a core process framework (See Section
4 for a more detailed description). This artifacts provides a basic structure of
the business process model that supports the variability aspects identified by the
PFE 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 a
comprehensive example that illustrates how to model a scenario that reflects the
real life business process of reserving and booking airline tickets. A derivation of
this example, for defining an hotel booking process has been used for illustrating

132. Obtaining the Core Architecture of Business Information Systems Families. 3
the Process Family Engineering (PFE) approach in [23]. See Section 3.2 for
more details about the PFE approach. We use the WSCI case study as starting
point for defining how to develop families of business information 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 airline
tickets business process, concretely a Traveler, a Travel Agent, and an Airline
Reservation System. Each participant collaborate in the overall process called
PlanBook. This business process is composed by the following subprocesses:
(i) Order Trip: it defines the steps needed for performing the submission of the
preferred trip plan from the Traveler to the Travel Agent, who evaluates the
preferences, and send a possible itinerary to the Traveler. It is performed by
means of a collaboration between the Travel Agent and the Airline Reservation
System by means of a business process named Verify Seats Availability. This
business process is a subprocess of Order Trip; (ii) Cancel Itinerary: it defines
the steps needed for canceling the provided itinerary from the Travel Agent; (iii)
Change Itinerary: it defines the steps needed for performing a submission from
the 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 the
proposed itinerary. This business process is decomposed by four subprocesses:
Book Tickets, Book Seats (that needs a previous reservation step for the seats
performed by other business process named Reserve Seats), Send Tickets and
finally, 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 that
several airline travel agencies, such as Iberia, Ryanair, etc. performs this busi-
ness process. In other words, these travel agencies share the common business
process of PlanBook. In addition, is feasible that these companies share other
set of business processes, and also, performs a set of specific processes from each
company.
Taking into account the previous consideration, we are going to extend the
WSCI case study providing specific business processes from any possible airline
travel agency. Thus, we introduce the following business processes: (i) Inform:
it defines the steps needed to provide to the Traveler and to the Travel Agent
the 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 case
study, we have decomposed this business process into two subprocesses named:
Restaurant and Travel Card, that define the restaurant on fly subprocess and
the management of travel cards respectively.
Once the scenario is defined, we have analyzed the feasibility of develop a
family of airline travel agencies using our approach: Business Family Engineering
(BFE). The scenario motivates that BFE is feasible addressing into the following
issues, that are covered in the paper:

133. 4 Ildefonso Montero, Joaquin Pe˜a, and Antonio Ruiz-Cort´s
n e
– Increasing the business process definitions reusability for each business infor-
mation system that provides support for any airline travel agency. Current
process engineers redesign each business information system using ad hoc
techniques to maximize the level of reuse from one product to another. Our
approach states that many common business processes can be found, and
reuse across businesses by means of Software Product Line (SPL) techniques
can be exploited. See Section 3.1 for more information about the SPL field.
– Improving the design of highly variable business process models, also named
variant-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 the
business process diagram, for example Business Process Model Notation
(BPMN). It is defined by the PFE approach, that is detailed in Section
3.2
– Visualizing the variability of the business information system. Our approach
states that providing a variability summary is feasible and it would helps to
process 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 of
definitions and considerations about the Software Product Line (SPL) field and
the 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 aims
at and achieves pro-active, constructive reuse, based on the idea to develop
software products which share a significant amount of characteristics, namely
features. Thus, a feature is a characteristic of the system that is observable by
the end user. Roughly speaking, SPL systematizes the reuse across the set of
similar products, defined by means of their features, that a software company
provides.
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 differences
and commonalities inside an application domain. Variability is one of the critical
aspects 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: Domain
Engineering, which is in charge of providing the reusable core assets that are
exploited 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 of
an SPL are Feature Models (FM) [7]. The main goal of feature modeling is to
identify commonalities and differences among all products of an SPL. A feature

134. Obtaining the Core Architecture of Business Information Systems Families. 5
A A
Airline Travel
Agency
B B
Mandatory Optional
relation relation
A Change Reserve Cancel
Inform Extras Order Trip
Itinerary Tickets Itinerary
B1 B2 B3
Alternative
relation Travel Verify Seats Book Reserve Send Send
Restaurant
Card Availability Tickets Seats Tickets Statement
A
B1 B2 B3
Book Seats
Or
relation
Fig. 1. Feature Model of our case study
model is a compact representation of all potential products of an SPL showing a
set of features in an hierarchical structure where it is shown which features are
present in a product of the product line. Figure 1 shows the feature model of
our 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 be
included in every product that contains the parent;
– Optional: if a child feature node is defined as optional, it can be included
or not when its father feature appears in a product;
– Alternative: if the relationship between a set of children nodes and their
father is defined as alternative, only one of the children features could be
included in every product that contains the parent;
– Or: if the relationship between a set of children nodes and their father is
defined as or, one or more of them could be included in every product that
contains the parent.
Our approach for developing families of business information systems is based
on introducing some SPL techniques. For that purpose, the feature model is used
in our approach for describing the set of business information systems that are
members of the business family, and for representing the variability of each
business information system. In addition, the introduction of SPL techniques
implies a reduction of development times and costs and a quality improvement
of 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 contained
into 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

135. 6 Ildefonso Montero, Joaquin Pe˜a, and Antonio Ruiz-Cort´s
n e
Number of Seats VarPoint Null
Abstract 100 Send Tickets Book Tickets
Inform
Parameterization
Implementation Implementation
Number of Seats 50 Inheritance
Extension
VarPoint VarPoint
Default Inform by
Inform by Send Tickets
Intranet and Information
E-Mail Quality
about Trip
Assurance
(A) Alternative Behavior (B) Parameterization (C) Inheritance (D) Extension Point
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 process
model that represents how to deal with some identified variability aspects:
– Alternative behaviors: it defines when there exists several different ways
for performing an activity into a business process definition. Figure 2.a shows
an example about a refinement of the Inform business process from the
WSCI case study, represented using BPMN. When the Airline Traffic Con-
trol System submit some information to the Travel Agencies it could be
done 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, this
stereotype 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 activity
marked as VarPoint implements the behavior of other activity marked
as Abstract . In addition, the default implementation can be provided
introducing 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 possible
ranges of the value Number of Seats, into the subprocess Verify Seats Avail-
ability from the case study of this paper. This attribute is marked using
a grouping box and associated to other possible values by means of a new
association flow defined with a new stereotype named Parameterization .
– Inheritance: it defines a modification of an existing subprocess by adding
or removing elements regarding to specific rules. This allows for realizing
alternative variation points. As shown in Figure 2.c, the business process
Send Tickets has been modified to Send Tickets and Information about Trip
due to the Travel Agency has a contract with some tourism companies for
providing information about them when it sends tickets to the Traveler.
This situation is marked with a new association defined using the stereotype
Inheritance .

136. Obtaining the Core Architecture of Business Information Systems Families. 7
– Extension Points: it defines an optional behavior. Figure 2.d depicts how
an optional behavior from Book Tickets subprocess could be included for
quality 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 a
set of different products that shares common features, and the PFE approach
provides only one product, which represents a business, that evolves at runtime,
and each possible configuration of this business is managed as a product that
contains a subset of processes enabled at a certain moment of the execution. On
the one hand, the SPL products are implemented by software artifacts. For each
of 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 are
implemented by processes. For each product, the system can evolve to another
product increasing or decreasing the variable set of features thus, each product
is a software system based on processes.
However, although the PFE approach proposes a methodology for designing
highly variable business processes, based on overcoming the complexity derived
from variability, by means of applying software product lines for managing it;
this approach presents some drawbacks. For example, the use of feature models
and the derivation of business processes from it presents some problems, such as
ambiguity, that has been explored for us in [11]. Another consideration is the need
of redefining the BPMN syntax introducing some information about variability
which is also present in the feature models, thus, information is duplicated with
the obvious problems for maintenance. In addition, there not exists support for
this new syntax of BPMN, due to it is not an standard notation.
Our approach overcomes the variability of the business information systems
using SPL techniques, taking into account the PFE approach ideas and with-
out providing extra information to the standard notation used to represent the
business process models. In addition, as stated previously, each PFE product is
considered as an evolving system. Our approach takes into account this advan-
tage for representing the evolution of the business information systems of the
family.
4 Obtaining the Core Architecture of a Business Family
The main motivation of this paper is: (i) to propose a methodology based on
applying SPL ideas for the systematization of the development of BIS across
a several number of businesses that shares common business processes, namely
Business Family Engineering (BFE); and (ii) to define the methodology fragment
focused on providing a core architecture of the family, namely Business Family
Domain Engineering. For that purpose, Figure 3 shows the software process of
our approach using the SPEM notation1 .
1
http://www.omg.org/technology/documents/formal/spem.htm

137. 8 Ildefonso Montero, Joaquin Pe˜a, and Antonio Ruiz-Cort´s
n e
¢¥6
¤ £§ ¨!¤ ¢ ¢¥ ¤£¢¡ ¢¤¥¨¥£¡1¥0 ¢¢¥' ¥ ¢¥¢ § ¤£§¤¥¢¥'
¢ ¢¥' ¥ ¥©$§¡¥# ¨¥¢ )(¥ ¨§¦ ¢ ©¥4 3
)(¥ ¨§¦
¤££¤£!¥
¤£§ ¨ ¤£§ ¨ ¤£§ ¨
©£ ¨§¦ ¢ ¢¥¤£¢¡ ©£¨§¦ ¢ ¢¥¤£¢¡ ¢¤¥¨¥ £¡1¥0 ¤ £¢¥ ¤ £§¤¥¨¥©¨
¤£¥¥¤£ ¤ ¤£§ ¨ ¤ £§ £© ¤£¥¥¤£ ¤
¤£¥¥¤£ ¤ ¤ £§¤¥ ¨¥© ¨
¢ ©¥4 3
©£¨§¦ ¢¢¥¤£¢¡
Focus of this paper § ¨ ¨¡ £©£$§ £§ %
©£¨§¦ ¢ ¢¥¤£¢¡
§ ¨¨¡ £©£$§ £§ % 5 ©¥4 3 ¥¡§¥¦2
(A) Overview of the software process of (B) Business Family Domain Engineering
Business Family 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 core
architecture, namely Core Process Framework, and the Business Family Vari-
ability Summary; and (ii) Business Family Application Engineering, where we
obtain specific business information systems, that are described by means of
execution languages, such as Business Process Execution Language (BPEL). As
stated 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 represent
a 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 of
businesses and processes from scratch and apply the normal sequence of BFE
software process. In bottom-up approach, we can not apply the normal sequence
of the software process defined due to we have a set of businesses or processes de-
fined in feature models previously to apply BFE software process. In this paper
we 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 the
problem domain, (ii) Domain Design, that is focused on exploring the variability
of the system and providing the core architecture; and (iii) Domain Implemen-
tation, that is focused on defining the implementation and test details of the
architecture, such as persistence or presentation layers.
4.1 Domain Requirements Engineering
The Domain Requirements Engineering activity is focused on identifying the set
of companies and its business processes that would be members of the business
family. This step takes into account the traditional requirements elicitation ac-
tivities of software engineering, and provides as resulting artifact the documents
that reflects this elicitation, where it is included the definition of each business
process and each company. Thus, the activities of this stage are performed by a

138. Obtaining the Core Architecture of Business Information Systems Families. 9
CT DIHRRT F
`
R GI9p
FH @T BAU @Qrt@Ts FH @T BAU @Qr
8 @H R9 B@HYGTX 9 WA 9 @BC9V RA@9 G9I BQf9 e RA@9 G9I BQf9e
DI HA@9 G9 FE DCBA@987
R9RR9UTIS RR9 @BRQP RA B R9RR9UTIS RR9 @BRQP @T BAYBIUR9V @T BAYBIUR9 V
Send
RSPE [Max] Performance
Tickets
R9 B@HYGTX AND
R R9@ BRQP 8 @H
AND – AND
R9 RR9UTIS
+
R FHT Create Filter
@T BAYBIUR9V RSPE ` Search
R F98T a Tickets Tickets
@T BAYBIUR9V DCBA@987 Tickets
G9ARDc
R FHT
` (B) Goal Model of “Send Tickets”
DCBA@987 9RHX 9 Rb
DABFBhH9UHIp
R9R HX 9Rb R F98T a
using Tropos
qBIAH a
DCBA@987
variant
RI98FT W9dHAc
RI98 FT W9dHAc Travel Search by
@TBAYBIUR9V Agent Code
include
Search a Search
9AHI9 @9 Ticket by variant
`
@T BAHA BU BFE @H Search by
9UQ8TIA@7
A@9 GQUTV Agency
R @9 G9I BQf9e
DABFBhH BIH g
A@9 G9iH @H a (C) Use Case Model “Search a Ticket”
with two variants using Hallmans and
(A) Domain Requirements Engineering Overview Pohl proposal
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. In
this stage, the Requirement Engineer performs the following activities:
– Define the Companies and its Business Processes: it is focused on
obtaining a first conceptual description about the companies and its business
processes. It could be done using a free textual specification, see Section 2
for an example, or using a workflow representation of each identified business
process, such as BPMN. This activity generates two different artifacts: (i) the
Companies and Business Processes Definition, that contains the description
of the problem domain; and (ii) the Glossary of Terms, that contains a
terminology summary about the problem domain.
– Identify Elementary Business Processes (EBPs): it is focused on iden-
tifying the business processes contained into the Companies and Business
Processes Definition artifact, that are considered an EBP. Larman defines
in [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 business
and leaves the data in a consistent state is an EBP”. The objective of this
activity is to filter the processes that define tasks at a very low level, namely
atomic tasks, as are those who do not concern us. In addition, this activity
will filter those activities that require direct interaction of the user with the
system. Thus, this activity generates one artifact: the EBPs Definition, that
contains 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

139. 10 Ildefonso Montero, Joaquin Pe˜a, and Antonio Ruiz-Cort´s
n e
a system. There is an overlap between the goal and feature definitions that
motivates that some authors uses feature models, shown in Section 3.1, for
describing goals [22]. These goals are obtained from the EBPs identified in
the previous step, due to the realization of a business process covers a set of
goals [21]. However, there exists other goal-oriented representations, such as
Tropos [13,14] or i* models [16], that can be used too, depending on several
factors, such as tool support or non-functional requirements graphical rep-
resentation. Figure 4.b sketches the goal model of Send Tickets represented
using a Tropos model. In addition, the stakeholders and requirements are
defined by means of use cases. Thus, these activities generates the follow-
ing artifacts: (i) Goal Models; (ii) Use Case Models; (iii) Functional and
Non-Functional Requirements Descriptions, in a textual representation by
means of templates, as shown in [19,20], and in a graphical representation
using 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, once
these artifacts are obtained, these activities generate a Traceability Matrix
between them. This matrix represents a table that correlates requirements
with system goals and with business processes. Roughly speaking, this ar-
tifact provides a response for the following questions: What requirements
fulfill a system goal? and What system 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 identified. The
use of feature models and/or Tropos for defining system goals provides the
enough support for representing variability in system goals [15]. The aspects
that must fulfill any variability representation of a system goal are: (i) estab-
lish a hierarchical view of the goals; (ii) represent variation points, defined
at 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 that
extends the standard notation of use case diagrams, such as proposed by
Gomaa [26] or by Hallmans and Pohl [9], or proposes other notations and
languages, such as COVAMOF [27]. Figure 4.c shows an use case diagram
using the extensions proposed by Hallmans and Pohl. In addition, there ex-
ists approaches for representing variability in the textual representation of
use cases too, such as proposed by Bertolino [30] or John and Muthig [28].
We propose a combination of feature models for representing variability in
system goals and a modification of the traditional use case representation, in
order to specify variabilities. This combination allows to capture variability
and essential activities of a domain with use cases and to detail common and
variable characteristics with 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 is

140. Obtaining the Core Architecture of Business Information Systems Families. 11
– x’€h
v‚‘™ w‘ “lh
’ „€‘ y‘x…€ ‰‚‘w’ y€‚•
’„v”‘ “ ’v„ˆd
– x’€h yx€…ƒ˜
v‚ ˆ…–ˆ‚…‡
v‚‘™ v i… w‘
†…x„xƒ€x‚ € 
„v”‘ “ v‚‘™ v „ƒ€ x‚€ 
’…v ’ ’e ’…v’ ’e y‘ x…€ ‰‚‘w’ y€‚• v i… v yxwvu
†…x„xƒ€ x‚€  € v yxwvu ’vx…x„€ y‘ ‰‰‘™ …—v…y‘™k y‘j € ‘… ’v „ˆd
†‚€ ‰ ‰ˆ‡ y‘ x…€– xwx–v g‡ lh
†‚€ ‰‰ˆ‡
v i… ’v yxwvu
yx€…ƒ˜ y‘ x…x’‘g‰‘™
’v x…x„€ y‘‰ ‰‘™
y‘x…ˆ„‘ fm v i… v yxwvu
v‚‘™ yx€…ƒ˜ p‚‘ov ‰€‚n v i… w‘
†…x„xƒ€v–€‚• v „ƒ€ x‚€  ” y€ ’…v ’’e v f€‡ y‘ x…x’‘ g‰‘™
—x‚…€ “ ’…v’ ’e v „ƒ€’ ˆv d †‚‘…x’‘ gvd € ‘… yx y‘ x…€– xwx–v g‡
y‘ x…ˆ„‘ fm
„v”‘ “ v‚ˆ…€vn
Fig. 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, that
represents the output of the Domain Requirements Engineering activity as
shown in Figure 3.b. It contains all the artifacts generated in the previous
steps.
4.2 Domain Design
The Domain Design activity is focused on performing a variability summary of
the set of businesses identified at the previous step and on providing the core
architecture of the product line. Figure 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 Model
artifact, obtained at the Domain Requirements Engineering stage. For that
purpose, there exists several ways to perform a variability summary, but in
our 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 analysis
we can evaluate the percentage or probability of occurrence of a feature in
a product. If this ratio is high, we can consider that the feature is part of
the core. Thus, we introduce an optional commonality threshold for intro-
ducing some features/processes into the core of the product line [12]. Figure
1 presents the variability summary of the business family of the case study
by means of feature modeling. In addition, the commonalities summary is
provided on Figure 6.a using feature models too, and introducing Change
Itinerary, Reserve Tickets and Cancel Itinerary into the core of the family
by means of a commonality threshold, as shown in Figure 6.b. Notice that

141. 12 Ildefonso Montero, Joaquin Pe˜a, and Antonio Ruiz-Cort´s
n e
Airline Travel Threshold = 80%
Agency
COMMONALITY (%)
Change Reserve Cancel
Order Trip
Itinerary Tickets Itinerary
Verify Seats Book Reserve Send Send
Availability Tickets Seats Tickets Statement
Book
Seats
(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 Analysis
represented using feature modeling
if we did not introduce this commonality threshold this processes would not
be into the core architecture of the business family.
– Obtain Core and Variable Reusable Assets Definition: it is focused
on obtaining the reusable assets that are the basis of the core architec-
ture. For that purpose, we analyse the Variability Model and Commonality
Summary artifacts, using the operations defined in [4]. The result of this
analysis provides the set of reusable assets identified as Core and Variable
features. Once the reusable assets are obtained, we use the Traceability Ma-
trix defined at the Requirements artifact, from the Domain Requirements
Engineering stage, for obtaining the respective equivalence between features
and business process. Thus, the reusable assets are defined by means of busi-
ness process models. These assets are contained into the generated artifacts
Core and Variable Assets.
– Save Assets into a Repository: finally, once the assets are obtained and
defined by means of a business process model, we save these reusable assets
into a repository. The URI of this repository is added into the Business
Family Variability Summary artifact.
– Obtain the Basic Structure of the Core: it is focused on obtaining a
basic 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 Variabily
Model to a business process model. This derivation is based on Automata
Theory and Formal Languages by means of Context-Free Grammar Repre-
sentations [10]. The derivation process provides a mapping between feature
models and business process models that improves the design step of the
PFE approach by means of improving the maintainability of feature models
and BPMN, and eliminating errors derived from manual transformations. In
addition, we avoid the need of extending the standard notation of BPMN
with information that is present in the feature model. The mapping rules
are defined at [11]. Thus, the variability aspects identified by the PFE ap-

142. Obtaining the Core Architecture of Business Information Systems Families. 13
Variation Variation Send
Inform
Tickets
Extension Book
Point Point Point Tickets
( Number of Seats
Variants Inform by Inform by Send Send
Intranet
50 and 100 ) Variants Tickets
Quality
E-Mail Information Assurance
or about Trip
( Number of Seats
Inform 100 )
Inform Inform by Send Book
E-Mail Send Send Book
Tickets Tickets
Collapsed Tickets Tickets Tickets
Collapsed Collapsed
Inform by
Send Quality
Intranet
Info ... Assurance
Expanded Expanded Expanded
(A) Alternative Behavior (B) Parameterization (C) Inheritance (D) Extension Point
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 model
obtained in the previous variability analysis phase. In addition, these aspects
can be represented by means of the standard BPMN without providing extra
information using stereotypes. Figure 7 sketches all the variability aspects
described 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 variation
point, and the children are considered variants [22]; and a gateway Xor of
BPMN, which defines that only one subprocess controlled by this gateway,
Inform by e-mail or Inform by Intranet, must be completed for performing
the subprocess Inform; (B) Parameterization is resolved by rewriting the
condition for accepting several value ranges; (C) Inheritance is defined by
means of an Or relation on the feature model, defined at Section 3.1, and a
gateway Or of BPMN, which defines that almost one subprocess controlled
by this gateway, Send Tickets and Send Information about Trip, must be
completed 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 through
an specific characterization based on a merge operation between the Com-
monality Summary and the Variability Model, due to we consider the Core
Assets as children nodes into to Commonality Summary feature model, and
the Variable Assets as the variation points of the variability feature model
branches 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, the
assets are business processes that are defined by means of their respective
process models represented using BPMN. Figure 8 sketches an overview of
the Core Process Framework. Each business process contained into the com-
monality summary is a considered as a component into the framework. In
our case study the processes named Order Trip, Change Itinerary, Reserve
Tickets and Cancel Itinerary are the core processes that composes the ac-

143. 14 Ildefonso Montero, Joaquin Pe˜a, and Antonio Ruiz-Cort´s
n e
Specific
Business Process Inform (from Iberia)
Order Trip
BPMN Reusable Assets
Cancel
Itinerary
Change Itinerary Reserve Tickets
Airline Travel Agencies
Core Process Framework
Fig. 8. Overview of Core Process Framework
tivity named PlanBook. In addition, this framework provides the enough
linking areas for adapting specific business process from concretes compa-
nies, for example introducing into an instance of the framework the business
process Inform from Iberia. Figure 9 presents the basic structure of the Core
Process Framework of our case study in BPMN, obtained from the derivation
process.
– Define the Transformation Rules to a Non-Context Free BP Spec-
ification: it is focused on providing the rules needed to build a non-context
free 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) identify
loops 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 Requirements
Capture stage. This activity generates the artifact that contains these rules,
namely Transformation Rules.
– Define the Composition: it is focused on providing the mechanisms needed
to perform a composition of reusable assets into the Core Process Frame-
work. A composition between two or more business process models define
the order of the execution of each business process to be composed. Notice
that we must usually preserve the order of execution of each business process
model to be composed. We have determined that there exists two different
types of business process models composition: Non-Overlap Composition and
Overlap Composition. On the one hand, a Non-Overlap Composition is de-
fined as a composition between two or more business process models that
do not consume or generate any needed artifact for other. Roughly speak-
ing, these business processes could be considered as independent processes
that 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 of
a Non-Overlap Composition between the PlanBook process and the Inform
process, identified by means of an URL from the reusable assets repository

144. Obtaining the Core Architecture of Business Information Systems Families. 15
PlanBook
Change
(Core) Itinerary
Cancel
Itinerary
Airline Travel Agency
Book
Tickets
Book
Seats
Send
Tickets
Send
Statement
Verify Seats
Availaibility
Fig. 9. Basic Structure of the Core Process Framework obtained from the derivation
process
(i.e: companies.iberia.processes.variable.Inform.bpmn). On the other
hand, an Overlap Composition is defined as a composition between two or
more business process models that collaborates between them, in terms of
generating and consuming some artifacts between them that rules the de-
pendency from other to perform its activities. This type of composition can
only be done manually. Nowadays, one of the topics of our research is fo-
cused on providing algorithms for assisting these kinds of composition and
for checking the consistency of the composed business process models. For
that purpose, we take the algorithms presented in [25] as starting point for
this future work.
– Define the Evolution of the Framework: it is focused on defining the
evolving 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 business process models into
the core architecture by means of the compositions defined at the previous
step. Thus, the main difference between the process framework provided by
the PFE approach and our Core Process Framework is that PFE defines only
one product (core architecture) not variable, and our approach provides a
variable core architecture managed as a set of products using SPL techniques.
For that purpose, in order to represent this variability is needed to define
other mechanisms for describing the evolving behavior of the architecture.
We have explored the feasibility of several SPL techniques in [17], and we
consider that the variability of this architecture can be supported by means
of feature modeling techniques. Thus, this activity generates the artifact that
represents these evolutions, namely Evolution Feature Model.

145. 16 Ildefonso Montero, Joaquin Pe˜a, and Antonio Ruiz-Cort´s
n e
Fig. 10. Tool Support
5 Tooling Business Family Domain Engineering
Nowadays, we have developed an automated tool support for obtaining the basic
structure of a BPMN derived from the commonalities summary into the Business
Family Domain Engineering phase. This basic structure is the Core Process
Framework. This mapping is based on Automata Theory and Formal Languages
[10], and it has been implemented by means of MDD transformations.
For that purpose, we have performed a transformation between the FeAture
Model Analyzer (FAMA) [29] metamodel as source and the Eclipse SOA Tool
Platform 2 BPMN metamodel as target metamodel using the Atlas Transforma-
tion Language (ATL). Figure 10 presents and screenshot of this tool. It has been
published on Eclipse ATL website. ATL code and specification is available in
http://www.eclipse.org/m2m/atl/atlTransformations/#FM2BPMN.
6 Related Work
According to [2], to perform a survey in the software engineering field, we have
to 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

146. Obtaining the Core Architecture of Business Information Systems Families. 17
at DBLP, Google Scholar and ISI Web of Knowledge choosing those papers with
a higher number of cites; and finally (iii) a catalogue: we classify the approaches
in 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 for
modeling variant-rich processes and reuse its definitions into a product line archi-
tecture. This approach is introduced in Section 3.2. The PFE approach explores
the idea of using feature models for managing variability in a business infor-
mation system context, but the relationship between these feature models and
its products, defined by means of business process models, is not clearly defined
[11]. In addition, the PFE approach identifies some variability aspects in business
process models, and proposes to introduce some stereotypes for representing it.
This redefinition of the syntax implies some maintenance drawbacks identified
in Section 3.2; (ii) Van der Aalst et al. [8] proposes an extension of YAWL (Yet
Another Workflow Language), named extended workflow-nets (EWF-nets), for
performing 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 formalization
of 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 of
SPL techniques is not explored; and (iii) Ciuksys et al. [6] proposes an approach
to reuse of business processes knowledge at domain engineering. For that pur-
pose, it provides a process ontology for introducing semantic information into
a business process model. Thus, this approach propose to analyse this semantic
information for obtaining a commonality summary, but without defining how to
represent these reusable assets.
7 Conclusions and Future Work
We have explored the current reusability techniques of business process models
across several companies that shares a set of common processes. Thus, we have
detected that some Software Product Line (SPL) techniques can be exploited for
increasing the business process definitions reusability, and in addition improving
the design of highly variable business process models. The main motivation of
this paper is to provide a methodology that taking into account this techniques
makes feasible the possibility of develop families of business information systems.
For that purpose, as shown in Section 4, we provide a methodology named
Business Family Engineering, and we define the fragment of this methodology
focused on obtaining the core architecture of the family, namely Business Family
Domain Engineering. The activities proposed at this stage has been performed in
a real-life case study defined in the Web Service Choreography Interface (WSCI)
specification. In addition, as proof of concepts, we have developed an Eclipse
tool that provides support for this methodology fragment.
The main research lines of the future work derived from this paper are the
following: (i) providing a rigorous description of the activities of Business Fam-

147. 18 Ildefonso Montero, Joaquin Pe˜a, and Antonio Ruiz-Cort´s
n e
ily Application Engineering; (ii) exploring how to provide support into the Core
Process 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 and
Design 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 Empirical
Software 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. Modeling
Variant-Rich Processes. PESOA-Report No. 18/2005.
4. D. Benavides, A. Ruiz-Cortes, and P. Trinidad. Automated Reasoning on Feature
Models. LNCS, Advanced Information Systems Engineering: 17th International
Conference, 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 Business
Process 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. Configurable
workflow 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-Product
Family to Customers. Inform., Forsch. Entwickl., 18(3-4):113-131, 2004.
10. J. Hopcroft and J. Ullman. Introduction to Automata Theory, Languages, and
Computation. Addison-Wesley, Reading, Massachusetts, 1979.
11. I. Montero, J. Pe˜a, and A. Ruiz-Cortes. Improving the Design of Highly Variant-
n
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. Pe˜a, M. Hinchey, A. Ruiz-Cortes, and P. Trinidad. Building the Core Architec-
n
ture of a NASA Multiagent System Product Line. In 7th International Workshop
on 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 International
Conference 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 to
High-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.

148. Obtaining the Core Architecture of Business Information Systems Families. 19
16. AK. Ghose, G. Koliadis, A. Vranesevic, M. Bhuiyan, and A. Krishna. Combining i*
and BPMN for Business Process Model Lifecycle Management. Proceedings of the
BPM 2006 Workshop on Grid and Peer-to-Peer based Workflows, Lecture Notes
in Computing Science, 2007.
17. I. Montero, J. Pe˜a, and A.Ruiz-Cortes. Representing Runtime Variability in
n
Business-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 a
Formal 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 de
Informacion. 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 International
Conference on Computer and Information Technology (CIT 2007).
22. K. Pohl, G. B¨ckle, and F. van der Linden. Software Product Line Engineering:
o
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 Web
engineering, 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. Pe˜a, R. Corchuelo and J.L. Arjona. Towards Interaction Protocol Operations
n
for 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 Second
International Workshop on Software Product Lines: Economics, Architectures and
Implications (2001)
27. M. Sinnema, S. Deelstra, J. Nijhuis, and J. Bosch. COVAMOF: A Framework for
Modeling Variability in Software Product Families, volume 3154. Lecture Notes in
Computer Science, January 2004.
28. I. John and D. Muthig. Tailoring use cases for product line modeling. Proceedings
of 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 Description
of Requirements for Product Lines. In Proceedings of the International Workshop
on Requirements Engineering for Product Lines. September 2002.
31. A. Schnieders and F. Puhlmann. Variability Mechanisms in E-business Process
Families. Proceedings of 9th International Conference on Business Information
Systems BIS 2006.

149. Appendix B
Curriculum vitae
T he Curriculum vitae of the author of this research report is enclosed
in the following in Spanish. Further information can be provided at
request if necessary.

150. 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.

151. 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.

152. 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 SUMA 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

153. 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.

154. 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 €

155. 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.

156. 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.

157. 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

158. 102 Appendix B. Curriculum vitae

159. 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 IEEE
International 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 on
domain 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 Computer
Science, 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 feature
models. LNCS, Advanced Information Systems Engineering: 17th International
Conference, CAiSE 2005, 3520:491–503, 2005.
[8] A. Bertolino, A. Fantechi, S. Gnesi, G. Lami, and A. Maccari. Use case description
of requirements for product lines. In Proceedings of the International Workshop
on 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 de
Software 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).

160. 104 Bibliography
[11] E. Börger and B. Thalheim. A Semantical Framework for Busi-
ness Process Modeling. With an Application to BPMN. Available at
http://www.di.unipi.it/ boerger/CourseMaterial/Bpmn.pdf. 2007.
[12] A. Brown. Practical Approaches to Delivering Service-Oriented Solutions: The
Role 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 business
process 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 Template
Approach 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 process
mining and monitoring. In R. Meersman, Z. Tari, and P. Herrero, editors, OTM
Workshops (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 service
choreographies 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 BPEL
for Modeling Choreographies. In ICWS, pages 296–303. IEEE Computer Society,
2007.
[20] G. Decker and M. Weske. Local Enforceability in Interaction Petri Nets. In
Alonso et al. [2], pages 305–319.
[21] R. M. Dijkman, M. Dumas, and C. Ouyang. Formal Semantics and Automated
Analysis of BPMN Process Models. Preprint:7115, Queensland University of
Technology, 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 of
Service-Oriented Solutions Using an UML2 Profile and a Reference Petri Nets
Execution Platform. In ICIW ’08: Proceedings of the 2008 Third International
Conference 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 the
Second 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-based
software architectures. In WCAT ’07: Proceedings of the 4th Workshop on Co-
ordination and Adaptation Techniques for Software Entities, 2007.

161. Bibliography 105
[26] F. Gottschalk, W. van der Aalst, M. Jansen-Vullers, and M. L. Rosa. Configurable
workflow 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-product
family to customers. Inform., Forsch. Entwickl., 18(3-4):113–131, 2004.
[28] A. Hofstede and W. van der Alst. Workflow Patterns: On the Expressive Power
of (Petri-Net-Based) Workflow Languages. Technical report.
[29] J. Hopcroft and J. Ullman. Introduction to Automata Theory, Languages, and
Computation. 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 Product
Lines (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 and
S. Dustdar, editors, Business Process Management Workshops, volume 4103 of
Lecture Notes in Computer Science, pages 416–427. Springer, 2006.
[32] A. Koschmider and A. Oberweis. How to detect semantic business process
model variants? In SAC ’07: Proceedings of the 2007 ACM symposium on
Applied computing, pages 1263–1264, New York, NY, USA, 2007. ACM.
[33] A. Lapouchnian, Y. Yu, and J. Mylopoulos. Requirements-driven design and
configuration management of business processes. In Alonso et al. [2], pages
246–261.
[34] C. Larman. Applying UML and Patterns: An Introduction to Object-Oriented
Analysis 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 it
make 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. managing
the evolution of business-driven. In SPLC International Workshop on Dynamic
Software 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 Business
Processes. In IEEE Conference on Services Computing (SSC), volume 2, pages
605–608, Honolulu, HI, Jul 2008. IEEE Computer Society Press.
[38] I. Montero, J. Peña, and A. Ruiz-Cortés. Representing Runtime Variability in
Business-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 in
business-driven development systems - poster. In 7th Int. Conf. on Composition-
Based Software Systems (ICCBSS), page 241, Madrid, Spain, Feb 2008. IEEE
Computer Society Press.
[40] I. Montero, J. Peña, and A. Ruiz-Cortés. Towards visualisation and analysis of
runtime variability in execution time of business-driven development systems.
In 2nd. International Workshop on Variability Modelling of Software-intensive
Systems (VAMOS), pages 151–160, Universität Duisburg-Essen, Germany, Jan
2008. ICB Research Report No 22.

162. 106 Bibliography
[41] J. Peña. On Improving The Modelling Of Complex Acquaintance Organisations
Of Agents. A Method Fragment For The Analysis Phase. PhD thesis, University
of 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 Operations
for Large Multi-agent Systems. In Proceedings of FAABS’02, volume 2699 of
LNAI, 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 of
a nasa multiagent system product line. In 7th International Workshop on Agent
Oriented 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, 2nd
Dynamic 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 Software
engineering. 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. In
Alonso et al. [2], pages 408–415.
[50] A. Rozinat, A. A. de Medeiros, C. Günther, A. Weijters, and W. van der Aalst. The
need 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 process
families. In Proceedings of BIS ’06: Business Information Systems, 2006.
[52] A. Schnieders and F. Puhlmann. Variability Mechanisms in E-Business Process
Families. In H. C. M. Witold Abramowicz, editor, 9th International Conference
on 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 derivation
in e-business process families. In Technologies for Information Systems, pages
63–74. Springer, 2007.
[54] P.-Y. Schobbens, P. Heymans, and J.-C. Trigaux. Feature diagrams: A survey and
a 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 on
Web engineering, page 6, New York, NY, USA, 2006. ACM.
[56] M. Sinnema, S. Deelstra, J. Nijhuis, and J. Bosch. COVAMOF: A Framework for
Modeling Variability in Software Product Families. 2004.

163. Bibliography 107
[57] M. Sinnema, S. Deelstra, J. Nijhuis, and J. Bosch. COVAMOF: A Framework for
Modeling Variability in Software Product Families. In Proceedings of the Third
Software Product Line Conference (SPLC04), San Diego, CA, 2004.
[58] J. C. Trigaux and P. Heymans. Modelling Variability Requirements in Software
Product 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 Process
Chains. 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 for
publication. 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. From
goals to high-variability software design. In A. An, S. Matwin, Z. W. Ras, and
D. 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: A
Language for Service Behavior Modeling. In R. Meersman and Z. Tari, editors,
OTM Conferences (1), volume 4275 of Lecture Notes in Computer Science, pages
145–162. Springer, 2006.

164. 108 Bibliography

169. This document was typeset on // using RC BOO α. for LTEX2 .
– K A
Should you want to use this document class, please send mail to
contact@tdg-seville.info.