A M ETHODOLOGY F RAGMENT FOR
D EVELOPING FAMILIES OF B USINESS
      I NFORMATION S YSTEMS

I MPROVING THE D ESIGN OF B US...
A Methodology Fragment for Developing
Families of Business Information Systems
  Improving the Design of Business Families...
Support: This work has been partially supported by the European
Commission (FEDER) and Spanish Government under CICYT proj...
4
Contents

I     Preface
1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
 ...
ii                                                                                                    Contents

     3.2  ...
Contents                                                                                                         iii

    ...
iv   Contents
List of Figures

1.1   Case study scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ....
vi                                                                                                List of Figures

5.10 Do...
List of Tables

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

7.1   Summar...
viii   List of Tables
Acknowledgements

    Now that this research report comes to an end, it is time to express my
gratitude to the people who ...
x   Acknowledgements
Abstract

    Service Oriented Architectures (SOA) is a change in the approach for de-
veloping solutions and moving from ...
xii   Abstract
Resumen

    Las Arquitecturas Orientadas a Servicios (SOA) suponen un cambio en el
enfoque para el desarrollo de solucion...
xiv   Resumen
Part I
Preface
Chapter 1
                                                   Introduction



O        n the one hand, the development of B...
4                                                      Chapter 1. Introduction

1.1 Motivation

   The variability level o...
1.2. Motivating our research with a WSCI example                               5

dition, since to one of the topics of ou...
6                                                                   Chapter 1. Introduction


                I want to tr...
1.3. Research Context                                                           7

   • Increasing the business process de...
8                                                    Chapter 1. Introduction

    • Know what you got, roughly speaking, t...
1.3. Research Context                                                         9

1.3.1.1 Business Process Modeling and BPM...
10                                                                            Chapter 1. Introduction


           A
     ...
1.3. Research Context                                                        11

[21] or Pi -Calculus [48]. Concretely, in...
12                                                                                    Chapter 1. Introduction



         ...
1.3. Research Context                                                       13

   In addition, current proposals for mode...
14                                                                                                      Chapter 1. Introdu...
1.3. Research Context                                                                                             15


   ...
16                                                      Chapter 1. Introduction

       marked using a grouping box and as...
1.4. Hypothesis                                                             17

without providing extra information to the...
18                                                    Chapter 1. Introduction

   Hypothesis: The design of highly variabl...
1.5. Research Methodology                                                           19



                                ...
20                                                     Chapter 1. Introduction

       defined in the abstract layer must h...
1.6. Goals and Structure of this research report                            21




         Part 1: Preface

             ...
22                                                      Chapter 1. Introduction

Family Engineering (BFE). We focus our ef...
Part II
State of Art
Chapter 2
  Software Product Lines & Business
               Process Management




N         owadays, one of the most act...
26          Chapter 2. Software Product Lines & Business Process Management

2.1 Introduction

    The SPL field tries to o...
2.2. Process Family Engineering (PFE)                                       27

     the relationship between these featur...
28         Chapter 2. Software Product Lines & Business Process Management


            Domain Engineering
             A...
2.2. Process Family Engineering (PFE)                                      29



   Product Line Engineering (SPL)       P...
30            Chapter 2. Software Product Lines & Business Process Management




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

products (a set of core and variable fe...
32                      Chapter 2. Software Product Lines & Business Process Management


 Environment                    ...
2.2. Process Family Engineering (PFE)                                        33

   • Scope: It is focused on providing bu...
34        Chapter 2. Software Product Lines & Business Process Management


                          Scoping
            ...
2.2. Process Family Engineering (PFE)                                           35

     the process engineer must review ...
36        Chapter 2. Software Product Lines & Business Process Management

       models are devoted to represent design-t...
Chapter 3
 Variability in Business Information
                      System Design




I   n common language use, the term...
38               Chapter 3. Variability in Business Information System Design

3.1 Introduction

    Variability is one of...
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Montero Dea Camera Ready
Upcoming SlideShare
Loading in …5
×

Montero Dea Camera Ready

9,557 views

Published on

Published in: Business, Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
9,557
On SlideShare
0
From Embeds
0
Number of Embeds
68
Actions
Shares
0
Downloads
34
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Montero Dea Camera Ready

  1. 1. A M ETHODOLOGY F RAGMENT FOR D EVELOPING FAMILIES OF B USINESS I NFORMATION S YSTEMS I MPROVING THE D ESIGN OF B USINESS FAMILIES FOR S ERVICE O RIENTED A RCHITECTURES I LDEFONSO M ONTERO P ÉREZ RESEARCH REPORT M ARCH 17, 2009 BibTex
  2. 2. A Methodology Fragment for Developing Families of Business Information Systems Improving the Design of Business Families for Service Oriented Architectures. Ildefonso Montero Pérez, 75760309-B monteroperez@us.es Supervised by Prof. Dr. Joaquin Peña and Prof. Dr. Antonio Ruiz-Cortés Thesis project submitted to the Department of Computer Languages and Systems of the University of Sevilla in partial fulfilment of the requirements for the degree of Ph.D. in Computer Engineering. (Research report)
  3. 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). 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.
  4. 4. 4
  5. 5. Contents I Preface 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Motivating our research with a WSCI example . . . . . . . . . . . . . . . . 5 1.3 Research Context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3.1 Business Process Management . . . . . . . . . . . . . . . . . . . . . . . . 7 1.3.2 Software Product Lines and Feature Models . . . . . . . . . . . . 13 1.3.3 Process Family Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . 14 1.4 Hypothesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 1.5 Research Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 1.6 Goals and Structure of this research report . . . . . . . . . . . . . . . . . . . 20 II State of Art 2 Software Product Lines & Business Process Management 25 2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 2.2 Process Family Engineering (PFE) . . . . . . . . . . . . . . . . . . . . . . . . . . 27 2.2.1 Research Context: the PESOA project . . . . . . . . . . . . . . . . . . 27 2.2.2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 2.2.3 Main differences between the SPL and PFE fields . . . . . . . 29 2.2.4 Conceptual Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 2.2.5 The PESOA Process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33 2.2.6 Drawbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 3 Variability in Business Information System Design . . . . 37 3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
  6. 6. ii Contents 3.2 Variability Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 3.2.1 BPMN Extensions for Dealing with Variability . . . . . . . . . . 39 3.2.2 Basic Variability Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 40 3.2.3 Variability Mechanisms Derived . . . . . . . . . . . . . . . . . . . . . . 41 3.3 Summary of Variability Aspects . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 3.4 Variability Binding Times . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 III Our Approach 4 Business Family Engineering . . . . . . . . . . . . . . . . . . . . . . . . 47 4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.2 Business Families and BFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.2.1 Rigorous Definition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 4.2.2 Integration with Process Family Engineering . . . . . . . . . . . 49 4.2.3 Graphical Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 4.3 Software Process of BFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 5 Business Families Domain Design . . . . . . . . . . . . . . . . . . . 53 5.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.2 Preliminaries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 5.2.1 Redefining Feature Models . . . . . . . . . . . . . . . . . . . . . . . . . . 55 5.2.2 Feature Model Grammars . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.2.3 Mapping a Feature Model to a BPMN Structure . . . . . . . . 60 5.3 Business Family Domain Engineering . . . . . . . . . . . . . . . . . . . . . . . 62 5.3.1 Domain Requirements Engineering . . . . . . . . . . . . . . . . . . . 64 5.3.2 Domain Design . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 6 Business Families Choreographies Design . . . . . . . . . . . . 73 6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6.2 Choreography Modeling in BFE . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74 6.3 Transformation Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78 IV Contributions 7 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85 7.1 Relevant Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
  7. 7. 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
  8. 8. iv Contents
  9. 9. 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
  10. 10. vi List of Figures 5.10 Domain Design overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 5.11 Commonalities summary of the case study obtained in Variability Anal- ysis represented using feature modeling . . . . . . . . . . . . . . . . . . . . . . . . . 68 5.12 Variability aspects described by the PFE approach, represented at the derivation stage of Building Core Process Framework . . . . . . . . . . . . . 69 5.13 Overview of Core Process Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 70 5.14 Basic Structure of the Core Process Framework obtained from the deriva- tion process . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71 6.1 Order Trip subprocess Choreography Model using BPMN 2.0 . . . . . . 75 6.2 Order Trip Choreography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76 6.3 Data Object Exchange in our Pool . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79 6.4 Data Object Exchange between Pools . . . . . . . . . . . . . . . . . . . . . . . . . . . 80 6.5 Messages Exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81 6.6 Collaboration and Behavioral Interface obtained from the Transforma- tion Catalog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82 6.7 ATL definition of mapping between MaCMAS and BPMN . . . . . . . . . 82 7.1 Tool Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90 7.2 Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92 7.3 Total of contributions by defined layers in our holistic framework . . 93
  11. 11. List of Tables 2.1 Mapping between the SPL and PFE fields . . . . . . . . . . . . . . . . . . . . . . . 29 7.1 Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
  12. 12. viii List of Tables
  13. 13. 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.
  14. 14. x Acknowledgements
  15. 15. 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.
  16. 16. xii Abstract
  17. 17. 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.
  18. 18. xiv Resumen
  19. 19. Part I Preface
  20. 20. 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.
  21. 21. 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-
  22. 22. 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
  23. 23. 6 Chapter 1. Introduction I want to travel to Ulm Traveler Travel Agent WSCI WSCI Interface Interface Plan and Book Trip WSCI Interface Airline Reservation System Figure 1.1: Case study scenario. this business process. In other words, these travel agencies share the common business process of Plan&Book. In addition, is feasible that these companies share other set of business processes, and also, performs a set of specific pro- cesses from each company. Taking into account the previous consideration, we are going to extend the WSCI case study providing specific business processes from any possible air- line travel agency. Thus, we introduce the following business processes: (i) Inform : it defines the steps needed to provide to the Traveler and to the Travel Agent the information about flights (delays, connections, etc.) obtained from an Airline Traffic Control System (we have introduced a new participant in addition); and (ii) Extras : it defines the steps needed to provide to the Trav- eler the information related with some extra services from an airline agency. In this case study, we have decomposed this business process into two sub- processes named: Restaurant and Travel Card, that define the restaurant on fly subprocess and the management of travel cards respectively. Once the scenario is defined, we have analyzed the feasibility of develop a family of airline travel agencies using our approach: Business Family Engi- neering (BFE). Our research motivation address into the following issues, that are covered in this report:
  24. 24. 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 :
  25. 25. 8 Chapter 1. Introduction • Know what you got, roughly speaking, the services that the company provides to the market, also named business goals; • Know who is doing what, in other words, the set of business partners that performs several business processes in the company; • and Know when things change and what it means, which means that the business processes of the company must deal with the implicit variabil- ity of the market, since to companies must adapt to continuous market changes. Taking into account these considerations, a Business Process (BP) is de- fined as a set of well known activities of a company, performed by a set of business partners (may own the company or not), for realizing a business goal. In addition, the definition of specificic business processes must be able to be adapted when company changes. Business Process Management provides the techniques and methods to support the analysis, design and implementation of business processes. Is a fact that most companies, in whichever field, have a software system that helps managing all the aspects of the company. Consequently, the Infor- mation Technology (IT) infrastructure that supports it must provide support for the techniques and methods defined in BPM. Thus, a new kind of soft- ware system is defined: Business Information Systems (BIS). A BIS is a soft- ware system which is based on a business process design, usually a model specification, that is deployed into a process engine that executes it. Thus, the Business-Driven Development (BDD) field is focused on providing tech- niques and mechanisms for defining the development of Business Information Systems. Our research work is focused on improving the design of Business Infor- mation Systems when reuse across several businesses can be exploited. Thus, our main research context is the Business-Driven Development (BDD) field. Once the main research context is defined, we explore the set of models needed for designing a BIS: (i) a business process diagram, which defines a business process by means of several notations, such as Business Process Model Notation (BPMN), that is defined in the following subsection; and (ii) a choreography and collaboration models, defined in Section §1.3.1.2.
  26. 26. 1.3. Research Context 9 1.3.1.1 Business Process Modeling and BPMN Business Process Models are expressed in Business Process Diagrams. Each business process diagram consists of a set of modeling elements. These elements allow expressing business processes and are easy to comprehend, so that process designers can use them without extensive training. Several nota- tions are introduced for defining business process diagrams, such as Business Process Modeling Notation (BPMN) [10], Petri-net based process modeling languages [28], UML activity diagrams [1] or event-driven process chains [58]. While these modeling languages focus on different levels of abstraction, ranging from a business level to a more technical level, BPMN aims at sup- porting the complete range of abstraction levels, including business levels and software technology levels. Thus, our research is focused on this notation, but it also can be translated to other one. Business Process Model Notation (BPMN) is defined by the Object Man- agement Group (OMG) in [10] as a flow chart based notation for defining business processes. BPMN provides (i) a graphical notation based on Business Process Diagram (BPD); and (ii) a formal mapping to an execution language: Business Process Execution Language (BPEL). Figure §1.2 depicts the subset of the most commonly used BPMN elements. These elements can be grouped by the following categories: • Swimlanes: a set of symbols that allows us to organize the model. This set contains the elements named Pool and Lane, as shown in Figure §1.2.a. A pool represents a participant in a process and acts as a con- tainer of elements. A lane represents a sub-partition of a pool and are used to organize and categorize activities. • Flow objects: a set of symbols that represents the core elements of a busi- ness process model. Usually this elements are contained in a swimlane. This set contains the elements named Task, Event and Gateway. Figure §1.2.b show these elements. A task, also called activity or sub-process, is the basic element of a work in an organization, it can be atomic or non- atomic. Event is something that happens in our process that fires the execution of one or more activities. There exists a lot of events grouped by: start, intermediate or end event, as for example message events, as shown in figure. A gateway is used to control the divergence or con- vergence of flows as logic doors. In our research we focus on three dif- ferent gateways: (i) And : which defines that all the subprocesses con- trolled by this gateway must be completed for performing a task, (ii) Xor : which defines that only one subprocess controlled by this gateway
  27. 27. 10 Chapter 1. Introduction A A1 A2 A Sequence Flow Sub-Process Start Intermediate End Message Flow A Association Start Intermediate End Flow Message MessageMessage (C) Connection Objects Expanded Sub-Process Events A Gateway Gateway Group Collapsed Sub-Process XOR Tasks Artifact / Data Object Lane Gateway Gateway AND OR Comment / Text Pool Annotation Gateways (A) Swimlanes (B) Flow Objects (D) Artifacts Figure 1.2: Business Process Model Notation subset. must be completed for performing a task, and (iii) Or : which defines that almost one subprocess controlled by this gateway must be completed for performing a task. The specification of BPMN does not provide any con- straint about the order of performing this subprocesses in this situations, it can be done as a sequence or parallel. • Connection objects: a set of symbols that represents the connections be- tween the rest of objects in the model. It often represents the messages between two objects from different swimlanes. Figure §1.2.c depicts this set, which contains the elements named flows such as, sequences, asso- ciations and messages. • Artifacts: a set of additional elements that represents information about the model or output artifacts of a process represented in it. This elements are very useful to represent additional information to the reader of the BPMN, as group, comments or artifacts, also named, data objects gen- erated or consumed by a business process. Figure §1.2.d. show these elements. Although BPMN is a graph-based model, it can be defined by mathemat- ical and theoretical foundations and formalisms, such as CSP [62], Petri-nets
  28. 28. 1.3. Research Context 11 [21] or Pi -Calculus [48]. Concretely, in our research we explore the capability of BPMN for implementing finite state machine representations. However, although BPMN is a good choice for modeling business pro- cesses, there exists a several number of proposals which provides very inter- esting additional elements or extensions to the standard notation [6, 49]. Our research explore the feasibility of the current BPMN specification for provid- ing support for variability aspects into the design of business families and the drawbacks of extending the standard notation. 1.3.1.2 Choreography Models In the Business Driven-Development (BDD) field, and specially in Service- Oriented Computing (SOC), choreography models are acquiring a special im- portance. A choreography lists all possible interactions between a set of busi- ness partners, together with the behavioral constraints between them [18]. Choreography models represents the observable behavior of business part- ners defined by means of interaction contracts. Several industry initiatives are in place for establishing standarized choreographies in particular domains, such as Health Level Seven (HL7) for heath care services †1 . Process choreographies describe the interaction of multiple business pro- cesses and, as such, are an important concept for supporting business-to- business collaboration. Thus, modeling choreographies is considered a core need for designing Business Information Systems. The activities needed for develop a choreography model are described as follows: • High-level Structure Design: in this activity the participant roles as well as their communication structures are identified. • High-level Behavioral Design: this activity is focused on specifying the goals, also named milestones, of the collaboration and the order in which the goals are reached. • Collaboration Scenarios: in this activity the high-level choreographies are refined by introducing dedicated collaboration scenarios that relate the reaching of goals to the communication between process partici- pants. • Behavioral Interfaces: from these collaboration scenarios, for each par- ticipant role, a behavioral interface is derived in this activity. †1 http://www.hl7.org/
  29. 29. 12 Chapter 1. Introduction Domain scoping Participant Milestone definition identification M. Weske: Business Process Management, © Springer-Verlag Berlin Heidelberg 2007 Business Scenario modelling Engineer Design System Message Choreography Architect identification definition Implementation Deve- Behavioural Behavioural loper interface 1 interface n Process Process orchestration 1 orchestration n Figure 1.3: Phases during Choreography Design and Implementation from [61]. Once the choreography is designed, the behavioral interface of each busi- ness partner can be defined as a process orchestration for implementing the choreography, using the Web Service Choreography Interface (WSCI) specifi- cation [60] . Figure §1.3 describes the big-picture of the choreography design and implementation phases defined in [61]. Since to our research is focused in the design of Business Information Systems, in this context, we focus on the choreography design phase. However, although choreography modeling is considered a core need in our research context, there not exists an standard notation for that purpose. Latest drafts for BPMN 2.0. specification †2 , explores new notations for rep- resenting it, since to some drawbacks has been identified on modeling chore- ographies using the current BPMN specification [20]. In addition, there exists several proposals of specific choreography modeling languages such as Let’s Dance [64] or BPEL4Chor [19]. †2 http://www.omg.org/cgi-bin/doc?bmi/08-09-04
  30. 30. 1.3. Research Context 13 In addition, current proposals for modeling choreographies does not pro- vide any support for introducing variability aspects into the design of busi- ness families. Thus, other contribution of this research work is two-fold. In the one hand, we propose a choreography model based on an UML2 pro- file used on Agent-Oriented Software Engineering (AOSE) field that makes feasible the variability support; and in the other hand we provide a transfor- mation between this choreography model and BPMN elements for improving the design of what we call business families, by means of the Business Family Engineering approach without extending the current notation of BPMN. 1.3.2 Software Product Lines and Feature Models Pohl et al. define in [27, 46] that Software Product Line (SPL) develop- ment aims at and achieves pro-active, constructive reuse, based on the idea to develop software products which share a significant amount of character- istics, namely features. Thus, a feature is a characteristic of the system that is observable by the end user. Roughly speaking, SPL systematizes the reuse across the set of similar products, defined by means of their features, that a software company provides. The SPL approach is devoted to overcome complexity providing all the techniques needed for enabling the mass production of software in a certain application domain. The variability concept appears in SPL to represent the differences and commonalities inside an application domain. Variability is one of the critical aspects of SPL and it must be managed at all the stages of SPL development. Thus, the software process of SPL is divided into two main stages: Domain Engineering, which is in charge of providing the reusable core assets that are exploited during the derivation of products, done at a second stage named Application Engineering [46]. One of the most accepted techniques to represent the set of products of an SPL are Feature Models (FM) [16]. The main goal of feature modeling is to identify commonalities and differences among all products of an SPL. A feature model is a compact representation of all potential products of an SPL showing a set of features in an hierarchical structure where it is shown which features are present in a product of the product line. Figure §1.4 shows the feature model of our case study. A FM establishes a parental relationship be- tween each feature, as shown in Figure §1.4, that can be: • Mandatory: if a child feature node is defined as mandatory, it must be included in every product that contains the parent;
  31. 31. 14 Chapter 1. Introduction A A Airline Travel Agency B B Mandatory Optional relation relation A Change Reserve Cancel Inform Extras Order Trip Itinerary Tickets Itinerary B1 B2 B3 Alternative relation Travel Verify Seats Book Reserve Send Send Restaurant Card Availability Tickets Seats Tickets Statement A B1 B2 B3 Book Seats Or relation Figure 1.4: Feature Model of our case study. • Optional: if a child feature node is defined as optional, it can be included or not when its father feature appears in a product; • Alternative: if the relationship between a set of children nodes and their father is defined as alternative, only one of the children features could be included in every product that contains the parent; • Or: if the relationship between a set of children nodes and their father is defined as or, one or more of them could be included in every product that contains the parent. Our approach for developing families of business information systems is based on introducing some SPL techniques. For that purpose, the feature model is used in our approach for describing the set of business informa- tion systems that are members of the business family, and for representing the variability of each business information system. In addition, the introduction of SPL techniques implies a reduction of development times and costs and a quality improvement of the final products. 1.3.3 Process Family Engineering The Process Family Engineering (PFE) [6] approach explores the idea of applying SPL philosophy for managing the variability of business information systems. In PFE, feature models are used for representing the set of processes contained into a business. In addition, a business process diagram notation,
  32. 32. 1.3. Research Context 15 Number of Seats <<VarPoint >> <<Null>> << Abstract >> > 100 Send Tickets Book Tickets Inform <<Parameterization >> <<Implementation >> <<Implementation >> Number of Seats > 50 <<Inheritance >> <<Extension>> << VarPoint >> <<VarPoint >> << Default >> Inform by Inform by Send Tickets Intranet and Information E-Mail Quality about Trip Assurance (A) Alternative Behavior (B) Parameterization (C) Inheritance (D) Extension Point Figure 1.5: Variability aspects defined by the PFE approach. such as BPMN, is used for representing an specific process. However, the syn- tax of this notation is redefined for providing support for representing highly variable business process models, namely variant-rich business process mod- els [32]. The PFE approach defines a variant-rich business process model as a pro- cess model that represents how to deal with some identified variability as- pects: • Alternative behaviors: it defines when there exists several different ways for performing an activity into a business process definition. Fig- ure §1.5.a shows an example about a refinement of the Inform business process from the WSCI case study, represented using BPMN. When the Airline Traffic Control System submit some information to the Travel Agencies it could be done by e-mail, publishing the information as a new into the Intranet, etc. As shown, the PFE approach introduces some stereotypes: (i) Abstract , for defining the activity that has an al- ternative behavior; (ii) VarPoint , for identifying the activities that implements each possible behavior, this stereotype sometimes is repre- sented as a puzzle piece into the activity; and (iii) Implementation , for describing a new kind of flow not defined in the standard BPMN notation, that represents that an activity marked as VarPoint imple- ments the behavior of other activity marked as Abstract . In addi- tion, the default implementation can be provided introducing the stereo- type Default . • Parameterization: it defines that each BPMN attribute can be parameter- ized to support a range of values. Figure §1.5.b shows how to represent possible ranges of the value Number of Seats, into the subprocess Ver- ify Seats Availability from the case study of this paper. This attribute is
  33. 33. 16 Chapter 1. Introduction marked using a grouping box and associated to other possible values by means of a new association flow defined with a new stereotype named Parameterization . • Inheritance: it defines a modification of an existing subprocess by adding or removing elements regarding to specific rules. This allows for realizing alternative variation points. As shown in Figure §1.5.c, the business process Send Tickets has been modified to Send Tickets and In- formation about Trip since to the Travel Agency has a contract with some tourism companies for providing information about them when it sends tickets to the Traveler. This situation is marked with a new association defined using the stereotype Inheritance . • Extension Points: it defines an optional behavior. Figure §1.5.d depicts how an optional behavior from Book Tickets subprocess could be in- cluded for quality assurance of this activity. This situation is marked using the stereotype Extension . The main difference between SPL and PFE is that the SPL field provides a set of different products that shares common features, and the PFE approach provides only one product, which represents a business, that evolves at run- time, and each possible configuration of this business is managed as a product that contains a subset of processes enabled at a certain moment of the execu- tion. On the one hand, the SPL products are implemented by software arti- facts. For each of them there exists a feature selection phase that generates the final products (a set of core and variable features). On the other hand, the PFE products are implemented by processes. For each product, the system can evolve to another product increasing or decreasing the variable set of features thus, each product is a software system based on processes. However, although the PFE approach proposes a methodology for design- ing highly variable business processes, based on overcoming the complexity derived from variability, by means of applying software product lines for man- aging it; this approach presents some drawbacks. For example, the use of fea- ture models and the derivation of business processes from it presents some problems, such as ambiguity, that has been explored for us in [37]. Another consideration is the need of redefining the BPMN syntax introducing some in- formation about variability which is also present in the feature models, thus, information is duplicated with the obvious problems for maintenance. In ad- dition, there not exists support for this new syntax of BPMN, because it is not an standard notation. Our approach overcomes the variability of the business information sys- tems using SPL techniques, taking into account the PFE approach ideas and
  34. 34. 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.
  35. 35. 18 Chapter 1. Introduction Hypothesis: The design of highly variable business process models of a Business Information System, member of a business family, could be partially supported by means of an automated treatment. Nowadays, variability is one of the most active topics in several academic and industry communities [47, 55, 57]. Introducing variability support in the BDD field raises the following research questions: • What kind of variability aspects can be performed on defining business processes? A preliminary survey about the variability aspects identified on the de- sign of a business process should be defined. This survey should include the methods and techniques used to define these variability aspects and its advantages and drawbacks. • How many approaches provides variability support on designing Busi- ness Information Systems (BIS)? The related work of this topic should be revised, studying the advan- tages and drawbacks of the current proposals and exploring how to in- tegrate them into our approach. • How many kinds of variability are present in the definition of a BIS and how are them represented? A discussion about how many kinds of variability are present in the def- inition of a BIS should be provided. A company evolves continuously, thus not only static variability should be supported in our approach. In addition, the representation techniques used to describe these kind of variability should be revised. Another important issue is to study the treatment of these variability definitions (manually or automated) and its main benefits and drawbacks including topics such as variability analysis and visualization. Hypothesis: Current proposals for modeling choreographies does not pro- vide any support for introducing variability aspects into the design of busi- ness families. Our hypothesis states that defining a choreography model using Agent-Oriented Software Engineering (AOSE) techniques makes feasible the variability support and an automated treatment for obtaining collaboration scenarios and behavior interfaces. Modeling choreographies is one of the most active and recent topics in the Business-Driven Development field†3 [19, 20, 23, 64]. Our hypothesis raises the following research questions: †3 http://www.omg.org/cgi-bin/doc?bmi/08-09-04
  36. 36. 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
  37. 37. 20 Chapter 1. Introduction defined in the abstract layer must have its equivalent representation by means of at least one of these considered specifications. • Operational Layer: this layer provides the set of development paradigms that are exploited in our approach. The operational paradigm layer de- pends on the standard specification defined in the previous characteristic layer used to define some elements of our approach. Our approach must satisfy the constraints of these paradigms without adapting or extending its elements for our purpose. • Implementation Layer: this layer provides a real implementation of the operational paradigms used. In this layer a set of implementation tech- niques and software tools are contained. As far as possible, the aim should be to make use of generic techniques and tools that are not nec- essary to adapt to our needs. 1.6 Goals and Structure of this research report The goals of this research report are defined as follows: • Provide a review of the State of Art: Based on the hypothesis and re- search questions presented in Section §1.4, we identify several topics whose state of the art must be revised. • Propose an approach for designing business families: Taking into ac- count the main advantages and drawbacks of revised proposals, to pro- vide an approach for making feasible the design of business families is considered a goal of this report. • Overview of our contributions: Although the results of our research are still in a very preliminary stage we already have made some contribu- tions. Giving a brief overview of them is also one of the goals of this report. • Future work: Conclude this research report with the main conclusions of this work by means of the answer to the research questions and a dissertation about our future work, is a goal of this report. This research report is structured in four parts: Preface, State of Art, Our Approach, and Contributions. Figure §1.7 depicts the recommended reading process of this report.
  38. 38. 1.6. Goals and Structure of this research report 21 Part 1: Preface Research Motivation Hypothesis Goals Context Part 2: State of Art Part 3: Our Approach Business SPL and BPM Family Engineering Variability in Business BIS Design Families Domain Design Part 4: Contributions Relevant Business Publications Families Choreographies Definition Other Contributions Future Work Figure 1.7: Recommended reading process of this report. The first part is focused on providing a brief summary about the motiva- tion of our research and the hypothesis and research questions that underlie our work. In the second part, we review the state of art of our research context. In Chapter §2, we explore the current proposals based on the introduction of SPL ideas into BPM in order to perform a systematic generation and reuse of business processes across different companies. After that, a summary about how many kinds of variability are present in the definition of a BIS is provided in Chapter §3. The third part is divided into the Chapters §4, §5, and §6. In this part, we provide our approach for performing business families, named Business
  39. 39. 22 Chapter 1. Introduction Family Engineering (BFE). We focus our efforts on providing a BFE software process definition for obtaining the core architecture of a business family, and exploring how to deal with variability on choreography modeling of business families using our approach. Finally, in the last part, in Chapter §7, we provide a brief description of our current contributions in this research context and, in addition, we summarize our main conclusions and describe our future work.
  40. 40. Part II State of Art
  41. 41. Chapter 2 Software Product Lines & Business Process Management N owadays, one of the most active topics in the Business Process Man- agement (BPM) research community is exploring how to increase the reuse of business process definitions. For that purpose, several approaches has been proposed. The main motivation of this chapter is to provide a revision of these approaches, concretely exploring those which proposes the use of Soft- ware Product Lines (SPL) techniques. In Section §2.1, we present a summary of all the proposals that explore the reuse of business processes. Then, the rest of the chapter focuses on the Process Family Engineering (PFE) approach, which is the only one that pro- pose the introduction of SPL techniques in the traditional design of Business Information Systems.
  42. 42. 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
  43. 43. 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-
  44. 44. 28 Chapter 2. Software Product Lines & Business Process Management Domain Engineering Analysis Design Implementation Process Family Infrastructure Analysis Design Implementation Application Engineering Figure 2.1: Process Family Engineering Overview. tation of a Process Family Engineering platform. This project is focused in two domains: E-Business and automotive †1 . 2.2.2 Overview The Process Family Engineering (PFE) approach is defined as a method- ological foundation for dealing with highly variable business process defini- tions. This methodological foundation consists on: (i) a Conceptual Model for variant-rich processes, which defines the conceptual requirements needed for defining variant-rich processes in the E-Business and automotive domains; and (ii) a process engineering process called the PESOA Process, which pro- vides an approach for developing, using and maintaining families of processes defined by means of their conceptual model. Figure §2.1 depicts the overview of the PFE approach. It is composed by two activities named Domain and Application Engineering, based on the ac- tivities performed in the SPL field (defined previously in Section §2.1), and in a Process Family Infrastructure, which performs the management of the prod- †1 http://www.pesoa.de
  45. 45. 2.2. Process Family Engineering (PFE) 29 Product Line Engineering (SPL) Process Family Engineering (PFE) Product Line Infrastructure Process Family Infrastructure Product Line Artifact Variant-Rich Processes Artifact Element BIS Definition Feature Models Variability Models Table 2.1: Mapping between the SPL and PFE fields. uct line defined. As shown in Figure, both domain and application engineer- ing activities are composed by three phases, which are defined as follows: (i) Analysis : focused on obtaining the requirements of the process family mem- bers; (ii) Design : focused on the design of the process family members, de- fined as variant-rich processes by means of the conceptual model proposed; and (iii) Implementation : focused on providing an executable definition of the variant-rich business processes. Table §2.1 defines the mapping between the concepts from the SPL field and the PFE approach. First, we explore the equivalence between the prod- uct line and the process family infrastructure. Both elements are focused on providing technical and organizational support of domain and application en- gineering. The difference between them is focused on the products that both manage. On the one hand, in the SPL field, the product line artifacts are com- monly software artifacts definitions composed on artifact elements (require- ments, design, code, etc.) and represented by means of feature models. On the other hand, in the PFE approach, the artifacts are variant-rich processes which are part of a BIS defined by means of variability models (commonly feature models too). However, although some equivalence between both re- search fields has been explored, there exists several diferences between them which are defined in the following section. 2.2.3 Main differences between the SPL and PFE fields In the same way that the SPL approach provides all the techniques needed for enabling the mass production of software in a certain application domain, the PFE approach provides all the techniques needed for enabling the mass production of processes in a certain business. However, althougth both fields are similar, the SPL approach produces a
  46. 46. 30 Chapter 2. Software Product Lines & Business Process Management Approaches Software Process Family Product Line Engineering Implemented by Implemented by Assets Assets Product Line Artifact 1 Variant Rich Process 1 Artifacts Product Line Artifact 2 Variant Rich Process 2 Product Line Artifact 3 Variant Rich Process 3 ... ... Product Line Artifact n Variant Rich Process n Select features ... Select features Select features Products BIS (state 1) BIS (state 2) BIS (state m) Product 1 Product 2 Product m Core Processes Core Processes Core Processes Core Artifacts Core Artifacts Core Artifacts ... ... Variation Variation Variation Variation Variation Variation Variation Variation m products; m > 0 1 product Figure 2.2: SPL and PFE approaches. set of software systems while the PFE approach produces only one Business Information System (BIS), defined by means of variant-rich business process designs. These business processes definitions represent all possible states for which the BIS can evolve during its activity. Roughly speaking, in PFE, each product represents an evolution of the BIS (at runtime). In this context, the term product is defined as a set of features that are enabled/disabled at a certain moment, and the term evolution is defined as a transition from one product to another. Although there exists several products, only one software system is produced by means of the PFE approach: a BIS which evolves at runtime. Figure §2.2 sketches how SPL and PFE products are generated. In SPL a product is composed of a set of common features and a set of variable fea- tures. Common features appears in all products and variable features appears under demand of products’s consumers. Observing a certain product of a SPL, although it is described as a set of fixed features, some features can be in use in a certain moment and some not. Thus, in SPL the evolution of the system at runtime is not taken into account in the feature model. In PFE each feature is a process and all of them appear into the product, but at runtime there exists a set of products based on selection of features/processes. As can be observed in Figure §2.2, where we depict how SPL and PFE prod- ucts are generated, SPL products are implemented by software artifacts that for each of them there exists a feature selection phase that generates the final
  47. 47. 2.2. Process Family Engineering (PFE) 31 products (a set of core and variable features). PFE products are implemented by processes that for each of them there exists an evolution in execution time incrementing or decrementing the variable set of features. Each product is a software system based on processes. In addition, as stated previously, PFE considers that sometimes a feature represents an activity, sometimes a busi- ness process, but without providing an equivalence definition. Thus, we can say that in PFE there not exist a mapping relationship between feature models and business process models. This ambiguity implies some drawbacks iden- tified in the design phase of PFE that we define in Section §2.2.6. 2.2.4 Conceptual Model The conceptual model of the PFE approach is devoted to deal with vari- ability in the representation of business processes in the E-Business and the automotive domain. Roughly speaking, this model contains all the elements that can vary in the definition of a BIS in the specified domains. Figure §2.3 presents the conceptual model as an UML static structure. The elements of the conceptual model are defined as follows: • Process: It is the core element of the model. For each process definition the partner who performs the process (attribute Role ) and the execution state of the process (attribute Execution State ) must be provided . The PFE approach states that processes can vary. Regarding our case study (See Section §1.2): Reserve Tickets subprocess could provide support for different mechanisms for paying a reserve. The process Reserve Tickets contains a variation point that offers three choices to resolve the variabil- ity. Such choices can be: Reserve Tickets with Credit Card, Reserve Tick- ets with Bank Transfer and Reserve Tickets per Telephone. Depending on the choice selected by the user the Reserve Tickets will be resolved. Thus, it implies that at design time the process engineer should know all the possible choices or variations of a process. As shown in Figure §2.3, a process is considered as activities and a composition of them specified such as a Sequence, Parallel, Choice or Iteration • Input/Output: These elements specify data objects that are gener- ated/consumed in a process. Regarding the example: assuming a client has selected to Reserve Tickets with Bank Transfer, the input form might vary depending on the country where the bank belongs to. For example, American bank codes might differ from the European ones. In addi- tion, the invoices to be generated might have different representations depending on where the order is delivered.
  48. 48. 32 Chapter 2. Software Product Lines & Business Process Management Environment Non-Functional Properties State RealTime Safety Security 1 * Variable QoS * * Control Flow 1 - acquires 0..1 1 1 CompositeActivity Sequence 1 Scope Process * * * + Role + Execution State Parallel - throws - catches * 1 1 Activity * Choice Event * Data Flow 0..* 0..* * * Iteration Input Output 1 0..* 1 0..* Exception * * 1 1 - throws * DataSource DataSink Figure 2.3: Conceptual Model of the PFE approach. • Data Source/Data Sink: Data sources produce data used as input, as for example the return of an invocation to a web service. Data Sink con- sume data produced as outputs, as for example a database that stores results. In our case study, assuming that the client who has selected to Reserve Tickets with Bank Transfer, has an account in an American bank, a data source produced could be the account code in American format provided by a third-party web service from his bank. A data sink for our example could be a Content-Management System such as Alfresc o†2 as a repository where store the invoices. • Quality of Service: It is focused on providing some non-functional prop- erties in order to improve a concrete business process, as for example providing a security layer on Reserve Tickets with Bank Transfer process using an standard specification such as WS-Security †3 . The proposed conceptual model only takes into account Security, Safety and Real Time as non-functional properties. †2 http://www.alfresco.com †3 http://www.oasis-open.org/committees/wss/
  49. 49. 2.2. Process Family Engineering (PFE) 33 • Scope: It is focused on providing business environments. Roughly speaking, it provides some functionalities into the business process de- pending on its attribute Role, as for example a set of permissions de- pending on an authenticated business partner, such as an administrator. Regarding our example, only an authenticated Travel Agent can Verify Seats Availability. • Variable: A variable is associated to a scope and a set of variables defines a state. Variables hold data of process attributes (inputs, outputs, data sources, data sinks, roles, and nonfunctional properties). In our case study, a variable could be a reserved ticket identification number. • State: A state is a situation during the execution of a process, which is characterized by the current variable assignments of its contained pro- cesses. In the conceptual model, this is reflected by the aggregation from the state concept to the variable concept, and through the relationship between the scope and the process concepts. For example, in our case study the state of a reserving transaction at a given time could be de- scribed by: the process Reserve Tickets, and the payment method Bank Transfer. • Event: An event can be thrown by a data source or a process. In the case of a data source, an event is thrown, when a special value or threshold defined for the data source has been reached. Something similar can be assumed for a process that reaches a certain state. For example, in our case study, the Order Trip process is triggered when is received a message from a Traveler who wants to travel to an specific destiny. One special kind of event is the exception. An exception can be used to define a possible error in the execution of a process. Once the elements has been explored, the PFE approach states that the aim of this conceptual model is to provide a metamodel for modeling business processes. For that purpose, this approach explores the use of several model- ing notations such as UML Activity Diagrams or Business Process Modeling Notation (BPMN) extending it depending on their domain needs. 2.2.5 The PESOA Process This section presents in more detail the PESOA process proposed by the PFE approach. Figure §2.4 presents a product flow view of the domain frag- ment of the PESOA process, which is the focus of our research. (A more de-
  50. 50. 34 Chapter 2. Software Product Lines & Business Process Management Scoping Product Set Domain Scoping Domain Scope Definition Domain Analysis Model Features Feature Model Identify Process Processes Requirements Domain Design Design Processes Variant Rich Processes Variation Points Set Model Configuration Configurations Model Domain Implementation Implement DS Generator DS Generator Implement DS DS Components Components Figure 2.4: Domain Fragment of the PESOA Process. tailed description of the overall PESOA process is provided in [6]). This frag- ment is divided into the following phases: • Scoping: The main purpose of this process is to provide a requirements capture of the desired Business Information System. For that purpose,
  51. 51. 2.2. Process Family Engineering (PFE) 35 the process engineer must review into the Process Family Infrastructure availables reusable definitions, denoted as Product Set in Figure §2.4. As result, process engineers obtain a Domain Scope Definition. The PFE approach does not provide any element and constraints for documenting this definition. • Domain Analysis: The main purpose of this process is to provide a rep- resentation of the desired Business Information System by means of a variability model, such as a feature model. The domain scope definition is used as input for identifying consists-of relationships among features. Once the feature model is defined, the process engineer must identify the processes from this representation in order to provide a business process model definition. For that purpose, a process requirements summary must be provided too. • Domain Design: The main purpose of this process is to derive a busi- ness process model definition that deals with the variability of the de- sired Business Information System. Thus, process engineers must de- rive this representation from the feature model and the process require- ments obtained in the domain analysis phase. Once this representation is obtained, the variants and variation points of the business processes are identified. Roughly speaking, the process engineer identify the pro- cesses and the choices to resolve its variability as stated in Section §2.2.4. Finally, this set of variation points is used as input for obtaining a con- figuration model for each of the members of the family. • Domain Implementation: The main purpose of this process is to de- ploying the business process model specifications into a process engine that executes it and produces the desired Business Information System. For that purpose, the PFE approach proposes the use of domain-specific generators and components. 2.2.6 Drawbacks Although PFE may be the solution to obtain Business Information Systems (BIS) based on variant-rich business process definitions and to manage its evo- lution, the Design step of this approach, concretely the use of feature models and the derivation of business processes from it, presents three main draw- backs, defined as follows: • Ambiguity: PFE uses feature models to show the variability derived from enabling/disabling feature/process; however, given that feature
  52. 52. 36 Chapter 2. Software Product Lines & Business Process Management models are devoted to represent design-time variability and not runtime variability [25, 38], the approach redefine the semantics of feature mod- els implicitly, but without providing a definition for it. • Maintenance: PFE extends the notation of BPMN to add information about variability which is also present in the feature models, thus, in- formation is duplicated with the obvious problems for maintenance. In Chapter §3, we explore this extension and the drawbacks that it implies. • Manual derivation: the relationship between a feature model and its corresponding business process is not rigorously defined, and the devel- opment of the business process is performed manually using as input the feature model, what makes this activity error-prone and hinders the maintainability of both kind of models. In addition, as shown in Section §2.2.3, the PFE approach does not provide a family of software systems, only one BIS (the final product) which evolves at runtime. This evolution is managed by means of SPL techniques but PFE does not provide any representation for modeling it.
  53. 53. 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.
  54. 54. 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.

×