Montero Dea Camera Ready

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

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 fulﬁlment
of the requirements for the degree of Ph.D. in Computer Engineering.

(Research report)

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.

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 ﬁelds . . . . . . . 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

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 Deﬁnition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 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 Redeﬁning 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

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

List of Figures

1.1 Case study scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Business Process Model Notation subset . . . . . . . . . . . . . . . . . . . . . . . . 10
1.3 Phases during Choreography Design and Implementation from [61] 12
1.4 Feature Model of our case study . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.5 Variability aspects defined by the PFE approach . . . . . . . . . . . . . . . . . . 15
1.6 Proposed Holistic Framework . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.7 Recommended reading process of this report . . . . . . . . . . . . . . . . . . . . 21

2.1 Process Family Engineering Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2 SPL and PFE approaches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.3 Conceptual Model of the PFE approach . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4 Domain Fragment of the PESOA Process . . . . . . . . . . . . . . . . . . . . . . . . 34

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

4.1 PEM approach defining a business evolution by F∆ function in t and t+1
50
4.2 Software process of BFE in SPEM notation . . . . . . . . . . . . . . . . . . . . . . . 51

5.1 A feature model, its grammar and its propositional formula representa-
tion by Batory [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
5.2 PFE Feature Model and its CFG representation . . . . . . . . . . . . . . . . . . . 57
5.3 PFE Feature Model Grammar Representation Composition . . . . . . . . 58
5.4 Mapping Grammars to Finite State Machines . . . . . . . . . . . . . . . . . . . . 59
5.5 Finite State Machines and its CFG definition . . . . . . . . . . . . . . . . . . . . . 60
5.6 BPMN Gateways and its Finite State Machine equivalence . . . . . . . . . 60
5.7 Feature Model to BPMN Mapping Catalog Proposed . . . . . . . . . . . . . . 61
5.8 Business Family Domain Engineering Overview . . . . . . . . . . . . . . . . . 63
5.9 Domain Requirements Engineering Overview and models obtained 65

vi List of Figures

5.10 Domain Design overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.11 Commonalities summary of the case study obtained in Variability Anal-
ysis represented using feature modeling . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.12 Variability aspects described by the PFE approach, represented at 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 deﬁnition of mapping between MaCMAS and BPMN . . . . . . . . . 82

7.1 Tool Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
7.2 Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
7.3 Total of contributions by deﬁned layers in our holistic framework . . 93

List of Tables

2.1 Mapping between the SPL and PFE ﬁelds . . . . . . . . . . . . . . . . . . . . . . . 29

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

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.

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.

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.

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.

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-

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


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:

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 :


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


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


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


[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/


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


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;


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,


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


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

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.


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

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


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.

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 ﬁrst 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 deﬁnition 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


Family Engineering (BFE). We focus our efforts on providing a BFE software
process deﬁnition 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.

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 deﬁnitions. 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.

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

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-


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


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


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


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.


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 speciﬁcation 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/


• 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-


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,


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


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.

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.

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.

Montero Dea Camera Ready

Empfohlen

Empfohlen

Weitere ähnliche Inhalte

Was ist angesagt?

Was ist angesagt? (18)

Ähnlich wie Montero Dea Camera Ready

Ähnlich wie Montero Dea Camera Ready (20)

Mehr von Ildefonso Montero Pérez

Mehr von Ildefonso Montero Pérez (10)

Kürzlich hochgeladen

Kürzlich hochgeladen (20)

Montero Dea Camera Ready