Obtaining the Core Architecture ofBusiness Information Systems Families Ildefonso Montero Pérez, 75760309-B firstname.lastname@example.org 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 fulﬁlmentof 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).
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.
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 speciﬁcations, 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 deﬁnitions. Current SPL-based pro-posals do not solve the identiﬁed problems, because the proposed design ofthe reusable core speciﬁcation 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 identiﬁed 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 deﬁne 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 speciﬁc members of the family. The work will be validated in a case study.
Chapter 1 Introduction1.1 Motivation Bider states in  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 speciﬁcations. 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, deﬁned graphicallyby means of business process modeling notations, mainly Business ProcessModel Notation (BPMN). This software systems are commonly integratedinto the Information Technology (IT) infrastructure of the organization withthe purpose of providing support for performing its business process deﬁni-tions. Thus, we have identiﬁed the following situations: On the one hand,is a fact that the process deﬁnitions 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 deﬁnitionsso 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 speciﬁcations. 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 identiﬁed, 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 redeﬁne their business processes, under abusiness management perspective; and (ii), the development times and costsof this redeﬁnition 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%, identiﬁed in , deﬁning 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)  (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) ﬁeld . Roughly speaking, the SPL ﬁeld 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 approachidentiﬁes some variability aspects on business process models, and proposesto extend the standard BPMN for representing it . However, although thePFE approach is quite valuable, it presents some drawbacks  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 deﬁne 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 isdeﬁned by means of the reusable process deﬁnition, namely core process, andthe extra information needed to derive each speciﬁc 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 speciﬁcation 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 aspectsidentiﬁed 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 deﬁnitions and considerations about (i) Business Process Management(BPM), concretely about designing Business Information Systems (BIS), mod-eling speciﬁcations, and choreography models; (ii) the Software Product Line(SPL) ﬁeld; and (iii) the Process Family Engineering (PFE) approach.1.2.1 Business Process Management Weske deﬁne in  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 ﬁrst step for deﬁn-ing a Business Process (BP) could be that a BP is considered as a set of theseactivities. In addition, Brown establish, in , 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-ﬁned 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 deﬁnition of speciﬁcic 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 ﬁeld, 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 deﬁned in BPM. Thus, a new kind of soft-ware system is deﬁned: Business Information Systems (BIS). A BIS is a soft-ware system which is based on a business process design, usually a modelspeciﬁcation, that is deployed into a process engine that executes it. Thus,the Business-Driven Development (BDD) ﬁeld is focused on providing tech-niques and mechanisms for deﬁning 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) ﬁeld. Once the main research context is deﬁned, we explore the set of modelsneeded for designing a BIS: (i) a business process diagram, which deﬁnesa business process by means of several notations, such as Business ProcessModel Notation (BPMN), that is deﬁned in the following subsection; and (ii)a choreography and collaboration models, deﬁned in Section §126.96.36.199.188.8.131.52 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 deﬁning business process diagrams, such as BusinessProcess Modeling Notation (BPMN) , Petri-net based process modeling lan-guages , UML activity diagrams  or event-driven process chains . 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 deﬁned by the Object Man-agement Group (OMG) in  as a ﬂow chart based notation for deﬁning 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 ﬁres 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 ﬁgure. A gateway is used to control the divergence or con- vergence of ﬂows as logic doors. In our research we focus on three dif- ferent gateways: (i) And : which deﬁnes that all the subprocesses con- trolled by this gateway must be completed for performing a task, (ii) Xor : which deﬁnes that only one subprocess controlled by this gateway must be completed for performing a task, and (iii) Or : which deﬁnes that almost one subprocess controlled by this gateway must be completed for performing a task. The speciﬁcation 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 ﬂows 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 deﬁned by mathemat-ical and theoretical foundations and formalisms, such as CSP , Petri-nets or Pi -Calculus . Concretely, in our research we explore the capabilityof BPMN for implementing ﬁnite 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 speciﬁcation for provid-ing support for variability aspects into the design of business families and thedrawbacks of extending the standard notation.184.108.40.206 Choreography Models In the Business Driven-Development (BDD) ﬁeld, 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 .Choreography models represents the observable behavior of business part-ners deﬁned 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 identiﬁed. • 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 reﬁned 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 deﬁned as a process orchestration for implementing thechoreography, using the Web Service Choreography Interface (WSCI) speciﬁ-cation  . Figure §1.2 describes the big-picture of the choreography designand implementation phases deﬁned in . 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. speciﬁcation †2 , explores new notations for rep-resenting it, since to some drawbacks has been identiﬁed on modeling chore-ographies using the current BPMN speciﬁcation . In addition, there existsseveral proposals of speciﬁc choreography modeling languages such as Let’sDance  or BPEL4Chor . 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
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 . One of the most accepted techniques to represent the set of products ofan SPL are Feature Models (FM) . 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 deﬁned as mandatory, it must be included in every product that contains the parent; • Optional: if a child feature node is deﬁned 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 deﬁned 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 deﬁned 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 ﬁnal 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)speciﬁcation Airline Travel Agency example .1.2.3 Process Family Engineering The Process Family Engineering (PFE)  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 speciﬁc process. However, the syn-tax of this notation is redeﬁned for providing support for representing highlyvariable business process models, namely variant-rich business process mod-els . The PFE approach deﬁnes a variant-rich business process model as a pro-cess model that represents how to deal with some identiﬁed variability as-pects: • Alternative behaviors: it deﬁnes when there exists several different ways for performing an activity into a business process deﬁnition. Fig- ure §1.4.a shows an example about a reﬁnement of the Inform business process from the WSCI case study, represented using BPMN. When the Airline Trafﬁc 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 deﬁning 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 deﬁned by the PFE approach. sented as a puzzle piece into the activity; and (iii) ≪Implementation≫, for describing a new kind of ﬂow not deﬁned 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 deﬁnes 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 ﬂow deﬁned with a new stereotype named ≪Parameterization≫. • Inheritance: it deﬁnes a modiﬁcation of an existing subprocess by adding or removing elements regarding to speciﬁc rules. This allows for realizing alternative variation points. As shown in Figure §1.4.c, the business process Send Tickets has been modiﬁed 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 deﬁned using the stereotype ≪Inheritance≫. • Extension Points: it deﬁnes 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 ﬁeld 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 conﬁguration 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 ﬁnal 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 . Anotherconsideration is the need of redeﬁning 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 deﬁne 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 deﬁnitions reusability is an active ﬁeld 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 beneﬁt 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 , 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) ﬁeld has a lot of beneﬁts and Business Process Management too, How many beneﬁts 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  and  that the main beneﬁts of SPL and BPM together are focused on increasing the reusability level of the business process deﬁnitions, 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 . • How many approaches explores the idea of introduce SPL techniques in the Business-Driven Development (BDD) ﬁeld? : We have identiﬁed some approaches that explores how to increase the reusability of busi- ness process deﬁnitions, 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 . 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 deﬁning business processes? : On exploring the PFE approach, we have explored the vari- ability aspects identiﬁed 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 . We have proposed an au- tomated transformation between both models, based on several abstract foundations, such as automata theory and formal languages in . 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 deﬁnition of a BIS and how are them represented? : We have identiﬁed at least two kinds of variability, static and dynamic variability, also named design-time and runtime variability. Current approaches for supporting variability in the deﬁnition 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 , 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 . These proposals are in a very preliminar stage, and they should be revised and reﬁned 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  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  as starting point for deﬁning a choreography model, and it is based on an UML2.0 proﬁle deﬁned 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 deﬁned in .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 . 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) ﬁeld. Roughly speaking, they propose to, ﬁrst, 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 deﬁnes 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 . Abstract: Business-Driven Development(BDD) is a research ﬁeld 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. . 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 . . 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 beneﬁts provided by the use of SPL. In this paper, we present our ﬁrst 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 speciﬁc 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 . Abstract: Nowadays most companies in whichever ﬁeld 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) ﬁeld, 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 ﬁrst 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 . Abstract: Nowadays most companies in whichever ﬁeld 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) ﬁeld, 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 identiﬁed and some of the key aspects needed to enable this new ﬁeld.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 speciﬁcation 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 Uniﬁed Process. On the one hand, Action Research  is an approachprovided by our research group as a contribution to the debate about the prob-lems in software engineering research . In this methodology two importantfactors to be considered are research results dissemination and technologicaltransfer. On the other hand, the Uniﬁed Process  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 ﬁrst two phases of our methodology are based on Uniﬁed Process asfollows: • Inception. At this phase, we deﬁne what the problem that we will solve is. Once identiﬁed 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 deﬁne a possible solution. This phase was ﬁnnished 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 deﬁne 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 reﬁned in order to achieve the best solution. We consider that the next two phases of the Uniﬁed 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 deﬁnedin the elaboration phase we proceed with the following phases: • Research. At this phase, for each task deﬁned 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 deﬁne 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 redeﬁne 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 ﬁve 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 deﬁned 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 ﬁnal 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 deﬁned in terms ofthe units that execute it. This variability claims that maximizing the reuse ofthese deﬁnitions is a core need. In our PhD dissertation we propose a methodological framework namedBusiness Family Engineering, and we deﬁne 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 deﬁnition 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 ; 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 deﬁne a set of Business Information Systems (BIS) which shares common business processes deﬁnitions. 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 deﬁne 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 . • 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 deﬁnitions 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 ofﬁcial Eclipse project repository. • Dealing with Variability on Choreography Modeling: we propose a choreography modeling technique based on an UML proﬁle from the Agent-Oriented Software Engineering (AOSE) ﬁeld, 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 issuesidentiﬁed 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 Uniﬁed Modeling Language. 2.1.1 edition, feb 2007. Object Management Group (OMG). 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. 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. 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. D. Benavides and M. Toro. Aplicando la ﬁlosoﬁa de las ciencias de la compleji- dad a la ingenieria del software. In 1st. Workshop en Metodos de Investigacion y Fundamentos Filosoﬁcos en Ingenieria del Software MIFISIS 2002, pages 97106. Universidad Rey Juan Carlos, Spain, 2002. 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. BPMI. Business Process Modeling Notation BPMN version 1.0 - may 3, 2004. Object Management Group (OMG). 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. 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. K. Czarnecki and M. Antkiewicz. Mapping Features to Models: A Template Approach Based on Superimposed Variants. 2005.
36 Bibliography M. M. D.E. Avison, F. Lau and P. Nielsen. Action Research. Commun. ACM, 42(1): 9497, January 1999. G. Decker, O. Kopp, F. Leymann, K. Pﬁtzner, 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. G. Decker, O. Kopp, F. Leymann, and M. Weske. BPEL4Chor: Extending BPEL for Modeling Choreographies. In ICWS, pages 296–303. IEEE Computer Society, 2007. G. Decker and M. Weske. Local Enforceability in Interaction Petri Nets. In Alonso et al. , pages 305–319. 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. J. Fabra, J. Pena, A. Ruiz-Cortés, and J. Ezpeleta. Enabling the Evolution of Service-Oriented Solutions Using an UML2 Proﬁle 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. F. Gottschalk, W. van der Aalst, M. Jansen-Vullers, and M. L. Rosa. Conﬁgurable Workﬂow Models. BETA Working paper 222, Eindhoven University of Technol- ogy, The Netherlands, June 2007. G. Halmans and K. Pohl. Communicating the Variability of a Software-Product Family to Customers. Inform., Forsch. Entwickl., 18(3-4):113–131, 2004. A. Hofstede and W. van der Alst. Workﬂow Patterns: On the Expressive Power of (Petri-Net-Based) Workﬂow Languages. Technical report. 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. P. Kruchten. The Rational Uniﬁed Process: An Introduction (3rd Ed.). Addison- Wesley Longman Publishing, Boston, MA, USA, 2004. W. M. M. Morgan, R. E. Levitt. Executing Your Strategy. How to Break It Down and Get It Done. Harvard Business School Press, 2007. 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. 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. 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. 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 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. 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. 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. K. Pohl, G. Böckle, and F. van der Linden. Software Product Line Engineering: Foundations, Principles and Techniques. Springer, September 2005. 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. F. Puhlmann. On the Suitability of the Pi-Calculus for Business Process Man- agement. In Technologies for Business Information Systems. Berlin, Springer- Verlag. 2007. A. Rodríguez, E. Fernández-Medina, and M. Piattini. Towards CIM to PIM Transformation: From Secure Business Processes Deﬁned in BPMN to Use- Cases. In Alonso et al. , pages 408–415. 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. A. Schnieders and F. Puhlmann. Variability Mechanisms in E-Business Process Families. In Proceedings of BIS ’06: Business Information Systems, 2006. 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. M. Sinnema, S. Deelstra, J. Nijhuis, and J. Bosch. COVAMOF: A Framework for Modeling Variability in Software Product Families. 2004. 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. W. van der Aalst. Formalization and Veriﬁcation of Event-Driven Process Chains. Technical report. W3C. Web Service Choreography Interface (WSCI) 1.0, nov. 2002. www. w3.org/tr/wsci. M. Weske. Business Process Management: Concepts, Languages, Architectures. Springer Verlag, ﬁrst edition, November 2007. 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 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 email@example.com.