1. Obtaining the Core Architecture of
Business Information Systems Families
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.
(Thesis Project)
2.
3. 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).
11. Acknowledgements
Now that this thesis project comes to an end, it is time to express my grat-
itude to the people who have supported me along this path. 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 report substantially.
13. Abstract
Nowadays large organizations are the result of the interrelation of many
business units which tend to be managed based on its business processes. The
development of the Information Technology (IT) infrastructure that supports
these organizations is a complex task, due to the existence of diferent versions
of the same process, namely core process, tailored in terms of each unit that ex-
ecutes it. Thus, organizations lost the matching between each version and the
original. It implies problems in the maintenance of process specifications, that
drives to an inaccurate execution of the business strategies of the organization.
The introduction of Software Product Lines (SPL) techniques into the de-
velopment of Business Information Systems (BIS) is expected to become a new
development paradigm, of what we call Business Families, maximizing reuse
and dealing with variability on process definitions. Current SPL-based pro-
posals do not solve the identified problems, because the proposed design of
the reusable core specification is not performed in a systematic way that main-
tains its traceability with derived processes.
In this PhD thesis, our main goal is to provide a methodological framework
that taking into account the identified drawbacks makes feasible to obtain,
systematically, the core architecture of a Business Information System Fam-
ily, composed by the core process and the extra information needed to derive,
systematically too, each version. For that purpose, we propose a methodology
named Business Family Engineering (BFE), and we define the fragment of this
methodology, namely Business Family Domain Engineering, that is the focus
of our research. In addition, we explore how to ensure the systematization in
the discovery, resolution and application of the transformation rules, propos-
ing a set of technological components to be implanted in the infrastructure of
the specific members of the family. The work will be validated in a case study.
15. Chapter 1
Introduction
1.1 Motivation
Bider states in [6] that any organization can be considered from a business
process perspective. In addition, is a fact that the larger the size of the orga-
nization and the number of business units with which it interacts, the more
accurate is this perspective focused on its business process and on how the
organization is managed based on its specifications.
In this context, the development of Business Information Systems (BIS) is
focused on providing techniques and mechanisms for designing software sys-
tems based on the business processes of the organizations, defined graphically
by means of business process modeling notations, mainly Business Process
Model Notation (BPMN)[7]. This software systems are commonly integrated
into the Information Technology (IT) infrastructure of the organization with
the purpose of providing support for performing its business process defini-
tions. Thus, we have identified the following situations: On the one hand,
is a fact that the process definitions are very changeable, and the existence of
several versions of the same business processes, in function of the character-
istics of the unit that performs it, is very common. On the other hand, we
must also take into account other less likely but possible situations where a
company has to put in the disposal of other its business processes definitions
so that these are shared by both (i.e: company mergers and acquisitions, cre-
ation of delegations, or situations regulated under Government Acts). Both
situations support the claim that nowadays organizations lost the matching
between different versions of the process established in each of its business
units and the original, which implies ambiguity and problems in the main-
tenance of its specifications. In addition, is a fact that the variability level of
average-size BIS is usually highly enough for making the design of this kind
16. 4 Chapter 1. Introduction
of systems a complex task.
Once the problem is identified, to maximize the level of reuse of these def-
initions is considered a core need because it can minimize: (i) the investment
that company owners must take to redefine their business processes, under a
business management perspective; and (ii), the development times and costs
of this redefinition by a process engineer, under an operational perspective.
The importance of this need is emphasized by the frequent failures in the exe-
cution of business strategies, 70-90%, identified in [22], defining strategy as the
direction, scope and goals of an organization and the set of business processes
to execute it.
To contextualize our motivation scenario, we must enter into detail of cur-
rent solutions. Mainly, there is an approach, called Process Family Engineer-
ing (PFE) [4] (See Section §1.2.3 for more details), that tries to increase the
reusability on the development of BIS using ideas from the Software Prod-
uct Lines (SPL) field [30]. 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
Feature Models (FM), that contains only features observable by the end user,
and relationships between them, showing which features are present in all the
products, called core features, and which not, called variable features. (See
Section §1.2.2 for a more detailed description). In addition, the PFE approach
identifies some variability aspects on business process models, and proposes
to extend the standard BPMN for representing it [34]. However, although the
PFE approach is quite valuable, it presents some drawbacks [25] related with
ambiguity and maintenance that are presented at Section §1.2.3.
Given the problems of the current proposal, the main motivation of our
research is to define a methodology framework focused on obtaining the
reusable core architecture of a family of BIS. Roughly speaking, the proposed
framework is composed by two different activities focused (i) on capturing
the information of the problem domain and the needs of each member of the
family; and (ii) on the design of the core architecture. This core architecture is
defined by means of the reusable process definition, namely core process, and
the extra information needed to derive each specific version from it, namely
transformation rules.
Thus, under a business management perspective, we improve the devel-
opment of business information systems reducing its complexity level in sit-
uations where is needed to perform a Business Family, using our proposed
methodology. It implies to companies owners that the traceability between
the core and reusable specification of its business processes and its variations
is better guaranteed, improving alignment between the deployed process def-
17. 1.2. Research context 5
initions for each unit, and its business strategies. In addition, under a research
perspective, we provide to process engineers an improvement based on the
systematization of their activities. In addition, our proposal 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 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.2.1 Business Process Management
Weske define in [41] 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 [8], 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
18. 6 Chapter 1. Introduction
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.2.1.2.
1.2.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) [7], Petri-net based process modeling lan-
guages [19], UML activity diagrams [1] or event-driven process chains [39].
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 [7] as a flow chart based notation for defining busi-
19. 1.2. Research context 7
ness 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.1 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.1.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.1.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
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.1.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.1.d. show these
elements.
20. 8 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.1: Business Process Model Notation subset.
Although BPMN is a graph-based model, it can be defined by mathemat-
ical and theoretical foundations and formalisms, such as CSP [42], Petri-nets
[15] or Pi -Calculus [32]. 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 [4, 33]. 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.2.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 [12].
Choreography models represents the observable behavior of business part-
ners defined by means of interaction contracts. Several industry initiatives are
21. 1.2. Research context 9
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.
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 [40] . Figure §1.2 describes the big-picture of the choreography design
and implementation phases defined in [41]. 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 [14]. In addition, there exists
several proposals of specific choreography modeling languages such as Let’s
Dance [43] or BPEL4Chor [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
†1
http://www.hl7.org/
†2
http://www.omg.org/cgi-bin/doc?bmi/08-09-04
23. 1.2. Research context 11
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 [30].
One of the most accepted techniques to represent the set of products of
an SPL are Feature Models (FM) [10]. 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.3 shows the
feature model of our case study. A FM establishes a parental relationship be-
tween each feature, as shown in Figure §1.3, 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 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.
24. 12 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.3: Feature Model of Web Service Choreography Interface (WSCI)
specification Airline Travel Agency example [40].
1.2.3 Process Family Engineering
The Process Family Engineering (PFE) [4] 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,
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 [20].
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.4.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-
25. 1.2. Research context 13
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.4: Variability aspects defined by the PFE approach.
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.4.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.4.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.4.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
26. 14 Chapter 1. Introduction
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 [25]. 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
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.3 Structure of the document
This PhD Thesis project is structured as follows: Chapter 2 present our
hypothesis, research questions and goals. A brief description of the state of
the art and our contributions so far is presented in Chapter 3. We describe
the research methodology to be used in Chapter 4. Chapter 5 summarizes our
work plan and main milestones. Finally, we summarize our conclusions in
Chapter 6.
27. Chapter 2
Hypothesis and Goals
2.1 Hypothesis
In this section, we state the hypothesis and research questions that moti-
vate our 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 is feasible, improving
the current SPL-solutions. For that purpose, our hypothesis states that it is
possible to define a methodological fragment that makes feasible to obtain,
systematically, the core architecture of a Business Information System Family,
composed by the core process and the extra information needed to derive, sys-
tematically too, each version. In addition, our methodological fragment could
be partially supported by means of an automated treatment.
In order to demonstrate our hypotesis, our PhD dissertation must answer
some questions. In the following we state some of them and envision their
possible answers:
• Business Families. Does it makes sense? : Increasing the business pro-
cess definitions reusability is an active field of research in the Business
Driven-Development (BDD) community [3, 9, 17, 20, 35, 36]. The answer
is that business families are feasible. Its main benefit is that software
companies that provide BDD solutions, can reuse process in a system-
atic way, thus reducing costs (in time and money) and improving the
quality of their products, since they are tested for several clients. We ex-
plore this topic in [23], thus, this issue is closed, but we are planning to
28. 16 Chapter 2. Hypothesis and Goals
elevate this discussion to higher research communities, as for example
the BPM conference†1 .
• 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, variability is one of the most active topics in several
academic and industry communities [31, 37, 38]. We have explored in
[24] and [26] that the main benefits of SPL and BPM together are focused
on increasing the reusability 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 improving the development of self-adaptative appli-
cations, such as [29].
• 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
propose the use of SPL techniques. We have explored this approach in
several contributions [23, 24, 26, 28], and an improvement of its design
phase has been proposed in [25]. 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 [25]. In
addition, this issue is covered in this research report. Thus, it is closed.
†1
http://bpm2011.isima.fr
29. 2.2. Goals 17
• 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 [26], 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 [28]. 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 [16] 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-
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 [16] 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 [14].
2.2 Goals
The goals of this PhD Thesis are:
• Elaboration of the PhD Thesis document. Our main goal is the elabo-
ration of our PhD Dissertation.
• Publication of results. One of our priorities is to promote our work
through a number of both national and international publications. So
far, we have published 6 technical papers in international and national
conferences and workshops. In the near feature, we plan to continue
submitting works to the main journals and forums in the area.
30. 18 Chapter 2. Hypothesis and Goals
• Transference of Results: We will integrate the results of our PhD Thesis
in e-MaCMAS, a Spin Off of University of Seville.
31. Chapter 3
Background
3.1 Relevant Contributions
3.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 [25].
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
32. 20 Chapter 3. Background
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 [26].
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-
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. [27].
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-
33. 3.1. Relevant Contributions 21
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
3.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 . [28].
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-
34. 22 Chapter 3. Background
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,
2007 [24].
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.
3.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 [23].
Abstract: Nowadays most companies in whichever field have a soft-
ware system that helps managing all the aspects of the company, from
35. 3.2. Other Contributions 23
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.
3.2 Other Contributions
3.2.1 Eclipse M2M Transformation Project Contribution
The Eclipse Model to Model (M2M) Transformation project†1 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) †2 .
We have performed a transformation between the FeAture Model Ana-
lyzer (FAMA) †3 metamodel as source and the Eclipse SOA Tool Platform2
BPMN metamodel †4 as target metamodel using the ATL language. Figure
§3.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.
†1
http://www.eclipse.org/m2m
†2
http://www.eclipse.org/m2m/atl
†3
http://www.isa.us.es/fama
†4
http://www.eclipse.org/stp
36. 24 Chapter 3. Background
Figure 3.1: Tool Support.
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=52&action=singlenews&idN=8
Screencast:
http://www.isa.us.es/uploads/screencasts/demo.htm
37. 3.3. Summary of Contributions 25
Context No Publications DBLP
International Conference 3 3
National Conference 0 0
International Workshop 2 1
National Workshop 1 0
Other 1 0
Table 3.1: Summary of Contributions.
3.3 Summary of Contributions
A summary of our contributions is presented in Table §3.1. Rows show the
different research contexts in which our contributions were presented. The
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.
39. Chapter 4
Methodology
4.1 Methodology
Based on the experience of our research group in research and transfer of
results, we have decided to combine two methodologies, the Action Research
and the Unified Process. On the one hand, Action Research [11] is an approach
provided by our research group as a contribution to the debate about the prob-
lems in software engineering research [5]. In this methodology two important
factors to be considered are research results dissemination and technological
transfer. On the other hand, the Unified Process [21] is a framework that pro-
vides an iterative and incremental development process. It is highly appro-
priated for our project, since we aim for a dynamic development by applying
constantly knowledge updating in a controlled way.
The first two phases of our methodology are based on Unified Process as
follows:
• Inception. At this phase, we define what the problem that we will solve
is. Once identified the work to be done, we have to identify the key
points of it. Based on our previous experience in the research context of
our work, we define a possible solution. This phase was finnished on
the research period in which the Advanced Studies Diploma (DEA) was
obtained. We carried out this activity through meetings with the PhD
Thesis’s supervisors.
• Elaboration. The main goal of this phase is to identify and define the
relevant work packets and their tasks. At this phase we develop a coarse-
grained project plan for the Action Research methodology. During the
40. 28 Chapter 4. Methodology
execution of the work project, those tasks are reviewed and refined in
order to achieve the best solution.
We consider that the next two phases of the Unified Process, the Construc-
tion and Transition phases, are embedded in the Action Research methodol-
ogy. At this point we use this methodology because it is focused on research
results dissemination and technological transfer. Then, for each task defined
in the elaboration phase we proceed with the following phases:
• Research. At this phase, for each task defined in the work packets we
review the literature, design a solution and validate it by means of tools,
prototypes or validation tests. In addition, we determine the workshops,
conferences or journals where the Research Result (RR) can be dissem-
inated. After the validation of the RR, we disseminate it in the forums
previously identi?ed. The work method used to define steps and objec-
tives during this phase is through periodic meetings with PhD Thesis’s
supervisors and research reports. In this way, the researcher will present
and document the advances achieved, whether they are research results
or conclusions about literature reviewed.
• Apply Research Results. At this point we establish a transfer planning
of RR to the interested companies as Transfer Result (TR). We apply our
main RR to real contexts, converting them into TR.
• Follow-up. At this phase, we are ready to transfer our main results to the
research project’s Observer and Promoter Companies (EPOs) in which is
placed this thesis. At this point another important step is essential, to
redefine our strategy based on the feedback obtained from the interested
companies.
41. Chapter 5
Work plan
5.1 Work plan
Our thesis work plan is structured in five main stages, some of which, have
already been passed completed. These are:
• Doctoral courses.[Finished ] The student passed successfully the doc-
toral courses in 2007.
• Research period.[Finished ] The research period took place during 2008.
As a result, a research report was presented containing most part of our
study in 2009.
• Publications and Proof of Concepts.[In execution ] This is the activity
that has more scope in the timetable. The objective of this activity is to
publish all results to be obtained throughout the course of our research.
The dissemination of our research results is an important task in our
research methodology. In addition, several proposals of tool support as
proof of concepts has been defined and developed.
• PhD Thesis dissertation. In mid-2012, we intend to have a preliminary
version of the thesis dissertation, indicated at Preliminary version. Later
in the timeline we set Final version, the point at which we believe that
the final version of the thesis will be ready to submit to the doctoral
committee.
• Knowledge transfer. Once obtained the PhD, we plan to focus on trans-
ferring our knowledge to the society by means of the collaboration with
the EPOs of the research projects supporting our work.
43. Chapter 6
Conclusions
The development of the Information Technology (IT) infrastructure that
supports business processes of large organizations is a very complex task, due
to the existence of different versions of the same process defined in terms of
the units that execute it. This variability claims that maximizing the reuse of
these definitions is a core need.
In our PhD dissertation we propose a methodological framework named
Business Family Engineering, and we define the fragment focused on obtain-
ing, systematically, the reusable core architecture of a business family, namely
Business Family Domain Engineering. The main contributions of our ap-
proach can be decomposed into two perspectives: (i) contributions for busi-
ness management, focusing on minimizing the deviation in the definition of
the core process regarding its variants and to improve the matching between
them. It implies an improvement in the alignment between the different ver-
sions deployed in all the units and its business strategies [22]; and (ii) research
contributions, focusing on minimizing the development times and costs, and
improving current proposals, such as Process Family Engineering (PFE), by
means of the proposed systematization and eliminating its ambiguity prob-
lems.
Thus, we summarise 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 [23, 24]. In addition, we define a
methodology for performing business families named Business Family
Engineering.
44. 32 Chapter 6. Conclusions
• 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 [25,
26]. In addition, our proposal makes feasible to visualise and analyse
variability in this context [28].
• 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
identified on Section §2.1, and on the other hand, on to remark our novel po-
sition on providing a methodology fragment that makes feasible the devel-
opment of families of Business Information Systems into the Service-Oriented
Computing context.
45. Appendix A
Curriculum vitae
The Curriculum vitae of the author of this PhD Thesis Project is enclosed
in the following in Spanish. Further information can be provided at request if
necessary
47. Appendix B
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
Process 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] J. Bayer, W. Buhl, C. Giese, T. Lehner, A. Ocampo, F. Puhlmann, E. Richter,
A. Schnieders, J. Weiland, and M. Weske. Process Family Engineering. Mod-
eling Variant-Rich Processes. Technical report.
[5] D. Benavides and M. Toro. Aplicando la filosofia de las ciencias de la compleji-
dad a la ingenieria del software. In 1st. Workshop en Metodos de Investigacion y
Fundamentos Filosoficos en Ingenieria del Software MIFISIS 2002, pages 97106.
Universidad Rey Juan Carlos, Spain, 2002.
[6] I. Bider. Striving for Better Administrative Quality as a Stimulus for Business
Process Change. In 10th Workshop on Business Process Modeling, Develop-
ment, and Support (BPMDS), co-located with CAISE, 2009.
[7] BPMI. Business Process Modeling Notation BPMN version 1.0 - may 3, 2004.
Object Management Group (OMG).
[8] 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.
[9] D. Ciuksys and A. Caplinskas. Ontology-Based Approach to Reuse of Busi-
ness Process Knowledge. Informacijos Mosklai ISSN:1392-0561, (42-43):168–174,
2007.
[10] K. Czarnecki and M. Antkiewicz. Mapping Features to Models: A Template
Approach Based on Superimposed Variants. 2005.
48. 36 Bibliography
[11] M. M. D.E. Avison, F. Lau and P. Nielsen. Action Research. Commun. ACM,
42(1): 9497, January 1999.
[12] G. Decker, O. Kopp, F. Leymann, K. Pfitzner, and M. Weske. Modeling Ser-
vice 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.
[13] G. Decker, O. Kopp, F. Leymann, and M. Weske. BPEL4Chor: Extending BPEL
for Modeling Choreographies. In ICWS, pages 296–303. IEEE Computer Society,
2007.
[14] G. Decker and M. Weske. Local Enforceability in Interaction Petri Nets. In
Alonso et al. [2], pages 305–319.
[15] 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.
[16] 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.
[17] 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.
[18] G. Halmans and K. Pohl. Communicating the Variability of a Software-Product
Family to Customers. Inform., Forsch. Entwickl., 18(3-4):113–131, 2004.
[19] A. Hofstede and W. van der Alst. Workflow Patterns: On the Expressive Power
of (Petri-Net-Based) Workflow Languages. Technical report.
[20] 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.
[21] P. Kruchten. The Rational Unified Process: An Introduction (3rd Ed.). Addison-
Wesley Longman Publishing, Boston, MA, USA, 2004.
[22] W. M. M. Morgan, R. E. Levitt. Executing Your Strategy. How to Break It Down
and Get It Done. Harvard Business School Press, 2007.
[23] 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
Software (PNIS), pages 34–40, Zaragoza, Spain, Sep 2007.
[24] I. Montero, J. Peña, and A. Ruiz-Cortés. Business Family Engineering. Manag-
ing the Evolution of Business-Driven Development Systems. In SPLC Interna-
tional Workshop on Dynamic Software Product Line (DSPL), pages 33–40, Ky-
oto, Japan, Sep 2007.
[25] 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.
[26] 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.
49. Bibliography 37
[27] I. Montero, J. Peña, and A. Ruiz-Cortés. Representing Runtime Variabil-
ity 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.
[28] I. Montero, J. Peña, and A. Ruiz-Cortés. Towards Visualisation and Analysis of
Runtime Variability in Execution Time of Business-Driven Development Sys-
tems. In 2nd. International Workshop on Variability Modelling of Software-
intensive Systems (VAMOS), pages 151–160, Universität Duisburg-Essen, Ger-
many, Jan 2008. ICB Research Report No 22.
[29] 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.
[30] K. Pohl, G. Böckle, and F. van der Linden. Software Product Line Engineering:
Foundations, Principles and Techniques. Springer, September 2005.
[31] 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.
[32] F. Puhlmann. On the Suitability of the Pi-Calculus for Business Process Man-
agement. In Technologies for Business Information Systems. Berlin, Springer-
Verlag. 2007.
[33] A. Rodríguez, E. Fernández-Medina, and M. Piattini. Towards CIM to PIM
Transformation: From Secure Business Processes Defined in BPMN to Use-
Cases. In Alonso et al. [2], pages 408–415.
[34] 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.
[35] A. Schnieders and F. Puhlmann. Variability Mechanisms in E-Business Process
Families. In Proceedings of BIS ’06: Business Information Systems, 2006.
[36] 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.
[37] M. Sinnema, S. Deelstra, J. Nijhuis, and J. Bosch. COVAMOF: A Framework for
Modeling Variability in Software Product Families. 2004.
[38] 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.
[39] W. van der Aalst. Formalization and Verification of Event-Driven Process
Chains. Technical report.
[40] W3C. Web Service Choreography Interface (WSCI) 1.0, nov. 2002. www.
w3.org/tr/wsci.
[41] M. Weske. Business Process Management: Concepts, Languages, Architectures.
Springer Verlag, first edition, November 2007.
[42] 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.
50. 38 Bibliography
[43] 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.
51.
52.
53.
54.
55. 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.
