• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Montero thesis-project
 

Montero thesis-project

on

  • 2,768 views

 

Statistics

Views

Total Views
2,768
Views on SlideShare
2,768
Embed Views
0

Actions

Likes
0
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Montero thesis-project Montero thesis-project Document Transcript

    • Obtaining the Core Architecture ofBusiness 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ésThesis project submitted to the Department of Computer Languages and Systems of the University of Sevilla in partial fulfilmentof the requirements for the degree of Ph.D. in Computer Engineering. (Thesis Project)
    • Support: This work has been partially supported by the EuropeanCommission (FEDER) and Spanish Government under CICYT project Web-Factories (TIN2006-00472) and by the Andalusian Government under projectISABEL (TIC-2533).
    • ii
    • Contents1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Research context . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.1 Business Process Management . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2.2 Software Product Lines and Feature Models . . . . . . . . . . . . 11 1.2.3 Process Family Engineering . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.3 Structure of the document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162 Hypothesis and Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.1 Hypothesis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 2.2 Goals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193 Background . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1 Relevant Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.1 International Conferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 3.1.2 International Workshops . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.1.3 National Workshops . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24 3.2 Other Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 3.2.1 Eclipse M2M Transformation Project Contribution . . . . . . 25 3.3 Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 4.1 Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 295 Work plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 5.1 Work plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
    • iv ContentsA Curriculum vitae . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35B Bibliography . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
    • List of Figures1.1 Business Process Model Notation subset . . . . . . . . . . . . . . . . . . . . . . . . . 81.2 Phases during Choreography Design and Implementation from [41] 101.3 Feature Model of Web Service Choreography Interface (WSCI) specifica- tion Airline Travel Agency example [40] . . . . . . . . . . . . . . . . . . . . . . . . . 121.4 Variability aspects defined by the PFE approach . . . . . . . . . . . . . . . . . . 143.1 Tool Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
    • vi List of Figures
    • List of Tables3.1 Summary of Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
    • viii List of Tables
    • 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, Iwould like to thank to my family and friends for their support when it was sonecessary. Thus, I would like to thank to Lucia, for her endless patience andlove. 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.
    • x Acknowledgements
    • Abstract Nowadays large organizations are the result of the interrelation of manybusiness units which tend to be managed based on its business processes. Thedevelopment of the Information Technology (IT) infrastructure that supportsthese organizations is a complex task, due to the existence of diferent versionsof 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 theoriginal. It implies problems in the maintenance of process specifications, thatdrives 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 newdevelopment paradigm, of what we call Business Families, maximizing reuseand dealing with variability on process definitions. Current SPL-based pro-posals do not solve the identified problems, because the proposed design ofthe 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 frameworkthat 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 methodologynamed Business Family Engineering (BFE), and we define the fragment of thismethodology, namely Business Family Domain Engineering, that is the focusof our research. In addition, we explore how to ensure the systematization inthe discovery, resolution and application of the transformation rules, propos-ing a set of technological components to be implanted in the infrastructure ofthe specific members of the family. The work will be validated in a case study.
    • 2 Acknowledgements
    • Chapter 1 Introduction1.1 Motivation Bider states in [6] that any organization can be considered from a businessprocess 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 moreaccurate is this perspective focused on its business process and on how theorganization is managed based on its specifications. In this context, the development of Business Information Systems (BIS) isfocused on providing techniques and mechanisms for designing software sys-tems based on the business processes of the organizations, defined graphicallyby means of business process modeling notations, mainly Business ProcessModel Notation (BPMN)[7]. This software systems are commonly integratedinto the Information Technology (IT) infrastructure of the organization withthe 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 ofseveral 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, wemust also take into account other less likely but possible situations where acompany has to put in the disposal of other its business processes definitionsso that these are shared by both (i.e: company mergers and acquisitions, cre-ation of delegations, or situations regulated under Government Acts). Bothsituations support the claim that nowadays organizations lost the matchingbetween different versions of the process established in each of its businessunits and the original, which implies ambiguity and problems in the main-tenance of its specifications. In addition, is a fact that the variability level ofaverage-size BIS is usually highly enough for making the design of this kind
    • 4 Chapter 1. Introductionof 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 investmentthat company owners must take to redefine their business processes, under abusiness management perspective; and (ii), the development times and costsof 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 thedirection, scope and goals of an organization and the set of business processesto 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 thereusability on the development of BIS using ideas from the Software Prod-uct Lines (SPL) field [30]. Roughly speaking, the SPL field systematizes thereuse across the set of similar products that a software company provides.For that purpose, this approach requires to describe the products by means ofFeature Models (FM), that contains only features observable by the end user,and relationships between them, showing which features are present in all theproducts, called core features, and which not, called variable features. (SeeSection §1.2.2 for a more detailed description). In addition, the PFE approachidentifies some variability aspects on business process models, and proposesto extend the standard BPMN for representing it [34]. However, although thePFE approach is quite valuable, it presents some drawbacks [25] related withambiguity and maintenance that are presented at Section §1.2.3. Given the problems of the current proposal, the main motivation of ourresearch is to define a methodology framework focused on obtaining thereusable core architecture of a family of BIS. Roughly speaking, the proposedframework is composed by two different activities focused (i) on capturingthe information of the problem domain and the needs of each member of thefamily; and (ii) on the design of the core architecture. This core architecture isdefined by means of the reusable process definition, namely core process, andthe extra information needed to derive each specific version from it, namelytransformation 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 proposedmethodology. It implies to companies owners that the traceability betweenthe core and reusable specification of its business processes and its variationsis better guaranteed, improving alignment between the deployed process def-
    • 1.2. Research context 5initions for each unit, and its business strategies. In addition, under a researchperspective, we provide to process engineers an improvement based on thesystematization of their activities. In addition, our proposal provides a basicstructure of the business process model that supports the variability aspectsidentified by the PFE approach, without the need of extending the standardnotation of BPMN.1.2 Research context In order to clarify the context of this research, in this section we provide aset of definitions and considerations about (i) Business Process Management(BPM), concretely about designing Business Information Systems (BIS), mod-eling specifications, and choreography models; (ii) the Software Product Line(SPL) field; and (iii) the Process Family Engineering (PFE) approach.1.2.1 Business Process Management Weske define in [41] that Business Process Management (BPM) is based onthe observation that each product that a company provides to the market isthe outcome of a number of activities performed. Thus, a first step for defin-ing a Business Process (BP) could be that a BP is considered as a set of theseactivities. In addition, Brown establish, in [8], as a core need that a companymust be able to manage what is called the 3-K : • Know what you got, roughly speaking, the services that the 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 ofbusiness partners (may own the company or not), for realizing a business goal.In addition, the definition of specificic business processes must be able to be
    • 6 Chapter 1. Introductionadapted when company changes. Business Process Management provides thetechniques and methods to support the analysis, design and implementationof business processes. Is a fact that most companies, in whichever field, have a software systemthat helps managing all the aspects of the company. Consequently, the Infor-mation Technology (IT) infrastructure that supports it must provide supportfor the techniques and methods defined in BPM. Thus, a new kind of soft-ware system is defined: Business Information Systems (BIS). A BIS is a soft-ware system which is based on a business process design, usually a modelspecification, that is deployed into a process engine that executes it. Thus,the Business-Driven Development (BDD) field is focused on providing tech-niques and mechanisms for defining the development of Business InformationSystems. Our research work is focused on improving the design of Business Infor-mation Systems when reuse across several businesses can be exploited. Thus,our main research context is the Business-Driven Development (BDD) field. Once the main research context is defined, we explore the set of modelsneeded for designing a BIS: (i) a business process diagram, which definesa business process by means of several notations, such as Business ProcessModel Notation (BPMN), that is defined in the following subsection; and (ii)a choreography and collaboration models, defined in Section §1.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. Theseelements allow expressing business processes and are easy to comprehend, sothat process designers can use them without extensive training. Several nota-tions are introduced for defining business process diagrams, such as BusinessProcess Modeling Notation (BPMN) [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 andsoftware technology levels. Thus, our research is focused on this notation, butit also can be translated to other one. Business Process Model Notation (BPMN) is defined by the Object Man-agement Group (OMG) in [7] as a flow chart based notation for defining busi-
    • 1.2. Research context 7ness processes. BPMN provides (i) a graphical notation based on BusinessProcess Diagram (BPD); and (ii) a formal mapping to an execution language:Business Process Execution Language (BPEL). Figure §1.1 depicts the subsetof the most commonly used BPMN elements. These elements can be groupedby the following categories: • Swimlanes: a set of symbols that allows us to organize the model. 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.
    • 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) ArtifactsFigure 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 capabilityof BPMN for implementing finite state machine representations. However, although BPMN is a good choice for modeling business pro-cesses, there exists a several number of proposals which provides very inter-esting additional elements or extensions to the standard notation [4, 33]. Ourresearch explore the feasibility of the current BPMN specification for provid-ing support for variability aspects into the design of business families and thedrawbacks of extending the standard notation.1.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
    • 1.2. Research context 9in place for establishing standarized choreographies in particular domains,such as Health Level Seven (HL7) for heath care services †1 . Process choreographies describe the interaction of multiple business pro-cesses and, as such, are an important concept for supporting business-to-business collaboration. Thus, modeling choreographies is considered a coreneed for designing Business Information Systems. The activities needed fordevelop a choreography model are described as follows: • High-level Structure Design: in this activity the participant roles as 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 thechoreography, using the Web Service Choreography Interface (WSCI) specifi-cation [40] . Figure §1.2 describes the big-picture of the choreography designand implementation phases defined in [41]. Since to our research is focused inthe design of Business Information Systems, in this context, we focus on thechoreography design phase. However, although choreography modeling is considered a core need inour research context, there not exists an standard notation for that purpose.Latest drafts for BPMN 2.0. specification †2 , explores new notations for rep-resenting it, since to some drawbacks has been identified on modeling chore-ographies using the current BPMN specification [14]. In addition, there existsseveral proposals of specific choreography modeling languages such as Let’sDance [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
    • 10 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 nFigure 1.2: Phases during Choreography Design and Implementation from[41].the one hand, we propose a choreography model based on an UML2 pro-file used on Agent-Oriented Software Engineering (AOSE) field that makesfeasible the variability support; and in the other hand we provide a transfor-mation between this choreography model and BPMN elements for improvingthe design of what we call business families, by means of the Business FamilyEngineering approach without extending the current notation of BPMN.1.2.2 Software Product Lines and Feature Models Pohl et al. define in [18, 30] that Software Product Line (SPL) develop-ment aims at and achieves pro-active, constructive reuse, based on the ideato develop software products which share a significant amount of character-istics, namely features. Thus, a feature is a characteristic of the system thatis observable by the end user. Roughly speaking, SPL systematizes the reuseacross the set of similar products, defined by means of their features, that asoftware company provides.
    • 1.2. Research context 11 The SPL approach is devoted to overcome complexity providing all thetechniques needed for enabling the mass production of software in a certainapplication domain. The variability concept appears in SPL to represent thedifferences and commonalities inside an application domain. Variability isone of the critical aspects of SPL and it must be managed at all the stages ofSPL development. Thus, the software process of SPL is divided into two mainstages: Domain Engineering, which is in charge of providing the reusable coreassets that are exploited during the derivation of products, done at a secondstage named Application Engineering [30]. One of the most accepted techniques to represent the set of products ofan SPL are Feature Models (FM) [10]. The main goal of feature modeling isto identify commonalities and differences among all products of an SPL. Afeature model is a compact representation of all potential products of an SPLshowing a set of features in an hierarchical structure where it is shown whichfeatures are present in a product of the product line. Figure §1.3 shows thefeature 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 isbased on introducing some SPL techniques. For that purpose, the featuremodel is used in our approach for describing the set of business informa-tion systems that are members of the business family, and for representing thevariability of each business information system. In addition, the introductionof SPL techniques implies a reduction of development times and costs and aquality improvement of the final products.
    • 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 relationFigure 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 ofapplying SPL philosophy for managing the variability of business informationsystems. In PFE, feature models are used for representing the set of processescontained into a business. In addition, a business process diagram notation,such as BPMN, is used for representing an specific process. However, the syn-tax of this notation is redefined for providing support for representing highlyvariable business process models, namely variant-rich business process mod-els [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-
    • 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 PointFigure 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 aset of different products that shares common features, and the PFE approach
    • 14 Chapter 1. Introductionprovides only one product, which represents a business, that evolves at run-time, and each possible configuration of this business is managed as a productthat contains a subset of processes enabled at a certain moment of the execu-tion. On the one hand, the SPL products are implemented by software arti-facts. For each of them there exists a feature selection phase that generatesthe final products (a set of core and variable features). On the other hand, thePFE products are implemented by processes. For each product, the system canevolve to another product increasing or decreasing the variable set of featuresthus, each product is a software system based on processes. However, although the PFE approach proposes a methodology for design-ing highly variable business processes, based on overcoming the complexityderived from variability, by means of applying software product lines for man-aging it; this approach presents some drawbacks. For example, the use of fea-ture models and the derivation of business processes from it presents someproblems, such as ambiguity, that has been explored for us in [25]. Anotherconsideration is the need of redefining the BPMN syntax introducing some in-formation about variability which is also present in the feature models, thus,information is duplicated with the obvious problems for maintenance. In ad-dition, there not exists support for this new syntax of BPMN, because it is notan standard notation. Our approach overcomes the variability of the business information sys-tems using SPL techniques, taking into account the PFE approach ideas andwithout providing extra information to the standard notation used to repre-sent the business process models. In addition, as stated previously, each PFEproduct is considered as an evolving system. Our approach takes into accountthis advantage for representing the evolution of the business information sys-tems of the family.1.3 Structure of the document This PhD Thesis project is structured as follows: Chapter 2 present ourhypothesis, research questions and goals. A brief description of the state ofthe art and our contributions so far is presented in Chapter 3. We describethe research methodology to be used in Chapter 4. Chapter 5 summarizes ourwork plan and main milestones. Finally, we summarize our conclusions inChapter 6.
    • Chapter 2 Hypothesis and Goals2.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 oneproduct to another. Our hypothesis states that the reuse across businessesby means of Software Product Line (SPL) techniques is feasible, improvingthe current SPL-solutions. For that purpose, our hypothesis states that it ispossible 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 couldbe partially supported by means of an automated treatment. In order to demonstrate our hypotesis, our PhD dissertation must answersome questions. In the following we state some of them and envision theirpossible 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
    • 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
    • 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.
    • 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.
    • Chapter 3 Background3.1 Relevant Contributions3.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
    • 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-
    • 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: B3.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-
    • 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
    • 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 Contributions3.2.1 Eclipse M2M Transformation Project Contribution The Eclipse Model to Model (M2M) Transformation project†1 is focusedon providing a framework for Model-Driven Development (MDD) model tomodel transformation languages. Nowadays, there exist three transformationengines that are developed in the scope of this project. One of this transforma-tion engines is the ATLAS Transformation Language (ATL) †2 . We have performed a transformation between the FeAture Model Ana-lyzer (FAMA) †3 metamodel as source and the Eclipse SOA Tool Platform2BPMN metamodel †4 as target metamodel using the ATL language. Figure§3.1 presents an screenshot of this contribution. It has been published on theEclipse ATL Transformation Scenarios zoo. ATL code and specification is de-scribed in the following research report: • ATL Transformation: Feature Models for representing runtime vari- ability in BIS to Business Process Model Notation. I. Montero, J. Peña, A. Ruiz-Cortés. ISA Research Group Report, 2008. †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
    • 24 Chapter 3. BackgroundFigure 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
    • 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 0Table 3.1: Summary of Contributions.3.3 Summary of Contributions A summary of our contributions is presented in Table §3.1. Rows show thedifferent research contexts in which our contributions were presented. Thenumber 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.
    • 26 Chapter 3. Background
    • Chapter 4 Methodology4.1 Methodology Based on the experience of our research group in research and transfer ofresults, we have decided to combine two methodologies, the Action Researchand the Unified Process. On the one hand, Action Research [11] is an approachprovided by our research group as a contribution to the debate about the prob-lems in software engineering research [5]. In this methodology two importantfactors to be considered are research results dissemination and technologicaltransfer. 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 applyingconstantly knowledge updating in a controlled way. The first two phases of our methodology are based on Unified Process asfollows: • 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
    • 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 researchresults dissemination and technological transfer. Then, for each task definedin 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.
    • Chapter 5 Work plan5.1 Work plan Our thesis work plan is structured in five main stages, some of which, havealready 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.
    • 30 Chapter 5. Work plan
    • Chapter 6 Conclusions The development of the Information Technology (IT) infrastructure thatsupports business processes of large organizations is a very complex task, dueto the existence of different versions of the same process defined in terms ofthe units that execute it. This variability claims that maximizing the reuse ofthese definitions is a core need. In our PhD dissertation we propose a methodological framework namedBusiness Family Engineering, and we define the fragment focused on obtain-ing, systematically, the reusable core architecture of a business family, namelyBusiness 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 ofthe core process regarding its variants and to improve the matching betweenthem. It implies an improvement in the alignment between the different ver-sions deployed in all the units and its business strategies [22]; and (ii) researchcontributions, focusing on minimizing the development times and costs, andimproving current proposals, such as Process Family Engineering (PFE), bymeans 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.
    • 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 issuesidentified 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-OrientedComputing context.
    • Appendix A Curriculum vitae The Curriculum vitae of the author of this PhD Thesis Project is enclosedin the following in Spanish. Further information can be provided at request ifnecessary
    • 34 Appendix A. Curriculum vitae
    • 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.
    • 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.
    • 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.
    • 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.
    • 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.