Anis Boubaker

Dhouha Cherif

Abderrahmane Leshob

Hafedh Mili

Value-Chain Discovery from Business Process Models

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

The ubiquity of business processes (BPs) in nowadays corporations raises them as first class citizens by being considered corporate assets and their need for ongoing management has been recognized. BPs are captured by business process models (BPMs) to depict the set of actions that should be carried out by a given BP, in what order they should be performed and by whom. Languages such as EPC [START_REF] Scheer | Process modeling using event-driven process chains[END_REF] or BPMN [START_REF] Omg | Business Process Model and Notation (BPMN)[END_REF] define both a set of concepts and a graphical representation convention to model business processes. Therefore the focus of a BPM is on the operational and dynamic aspects of the process (i.e. How are we doing it? and Who is doing it?). However, the business intent -expressing the why's of the activities we perform -is not explicitly modeled and that is where business modeling comes in handy.

A business model (BM) is a conceptualization of the BP using pure business terms such as economic resources, economic agents and value adding activities and their relationships. It may take the form of a resource centric view of the process -called a value-chain -that exhibits the sequence of economic resource acquisitions and transformations. A value-chain let us answer questions such as [START_REF] Andersson | From Business to Process Models: a Chaining Methodology[END_REF] how is the company using up its economic resources? and (2) why are these resources consumed or relinquished? There are three main frameworks widely recognized in the literature, namely REA [START_REF] Mccarthy | The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment[END_REF], e 3 value [START_REF] Gordijn | Value-based Requirements Engineering[END_REF] and BMO [START_REF] Osterwalder | The Business Model Ontology[END_REF].

Authors have argued on the necessity of not overlooking the business rationale in BPM projects (e.g. [START_REF] Pitschke | Integrating Business Process Models and Business Logic: BPMN and The Decision Model[END_REF][START_REF] Gordijn | Business Modelling is not Process Modelling[END_REF]). Indeed, business process management is an ongoing iterative process [START_REF] Van Der Aalst | Business Process Management: A Comprehensive Survey[END_REF] and we should ensure that the evolving business processes do not deviate from higher level business objectives. Ensuring the alignment between BMs and BPMs can be achieved in one of three ways: [START_REF] Andersson | From Business to Process Models: a Chaining Methodology[END_REF] manually, (2) by reducing both views to a common view and comparing them (e.g. see [START_REF] Pijpers | Consistency checking between value models and process models: A best-of-breed approach[END_REF]), or (3) by deriving one view from the other. The latter has only been considered going from a BM to generate a BPM ([8,25,1]). The other way around had yet to be explored and this work intends to fill this gap.

Apart from business process re-engineering, business models are useful during the analysis phases of various IT projects. For example, in architectural design, the TOGAF® framework recommends the use of value-chain diagrams in its Phase A (Architecture Vision) to "quickly on-board and align stakeholders for a particular change initiative, so that all participants understand the highlevel functional and organizational context of the architecture engagement" [22, pp.382]. Furthermore, in the business activity monitoring field (BAM) or business process mining, knowledge about the business rationale can be used for realtime detection or a posteriori diagnosis of deviances from the business strategic goals (e.g. [START_REF] Maggi | Predictive Monitoring of Business Processes[END_REF]). Business models can also help in automatic BP generation approaches. In particular, our team used a value centric view of the BP in two research projects. In the first project, we used value models to perform a question based BP specialization [START_REF] Mili | Towards a Methodology for Representing and Classifying Business Processes[END_REF]. In the second project, we focused on the automatic generation of compensation processes of a BP (i.e. reversing the effects of a running process that needs to be aborted) [START_REF] Boubaker | Methodology and Tool for Business Process Compensation Design[END_REF][START_REF] Boubaker | Towards a Framework for Modeling Business Compensation Processes[END_REF]. We argued that compensation is a business problem -rather than technical -and therefore must be tackled from a business standpoint [START_REF] Mili | Towards a Methodology for Designing Compensation Processes in Long-Running Business Transactions[END_REF]. Hence, we used the value-chain of the BP as an input in order to infer compensation processes.

In this work, we propose a four-steps approach that aims to generate a valuechain expressed in REA [START_REF] Mccarthy | The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment[END_REF] from a BPM expressed in BPMN. The problem is not trivial considering the large conceptual distance between both views [START_REF] Gordijn | Business Modelling is not Process Modelling[END_REF]. Hence our purpose is to infer business intensions that are not explicit in the original BPM. We tackle this by relying on a set of structural and behavioral patterns we have identified through the analysis of a sample of BP models.

The remainder of this paper is organized as follows. In Section 2, we briefly present business modeling and the REA ontology. In Section 3 we review some existing related works then we give a high-level overview of our approach in Section 4. Sections 5 and 6 focus on the inference of REA concepts and REA economic processes based on five structural and three behavioral patterns we will introduce. The validation of our approach will be presented and discussed in Section 7, before concluding in Section 8.

Business Modeling -The REA ontology

A business model is an abstraction of the BP focusing on the business rationale, specifically on how the company intends to create added value through it's valuechain. Different ontologies have been proposed to perform value-chain modeling ( [START_REF] Osterwalder | The Business Model Ontology[END_REF][START_REF] Gordijn | Value-based Requirements Engineering[END_REF][START_REF] Mccarthy | The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment[END_REF]). In this paper, we chose arbitrarily the Resource-Event-Agent (REA) that was introduced by McCarthy in an early work and has been getting wider attention recently from the community [START_REF] Mccarthy | The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment[END_REF]. However, our approach could be applied to any of the above mentioned ontologies as the concepts used in our approach are shared among them [START_REF] Andersson | Towards a Reference Ontology for Business Models[END_REF]. McCarthy proposed the REA framework as a way of capturing the economic phenomena that needed to be accounted, from an accounting perspective. In REA, an enterprise can increase or decrease the value of its resources through either exchanges or conversions [START_REF] Hruby | Model-Driven Design Using Business Patterns[END_REF]. An exchange is a process in which an enterprise receives economic resources from external economic agents, and provides other resources in return. A conversion is a process in which an enterprise uses or consumes resources in order to produce new or modified resources.

Economic Resource

Economic

Figure 1 shows the basic REA metamodel. Economic resources are objects that are scarce, have utility, and are under the control of an enterprise [START_REF] Mccarthy | The REA Accounting Model: A Generalized Framework for Accounting Systems in a Shared Data Environment[END_REF]. In an exchange, a resource is perceived as a set of rights (e.g.: ownership, usage, etc.) being exchanged whereas, in a conversion, it is defined by the set of properties (i.e. features contributing to resource's overall value) being altered. Economic events are defined as "a class of phenomena which reflect changes in scarce means resulting from production, exchange, consumption, and distribution" [START_REF] Yu | The Structure of Accounting Theory[END_REF]. An economic event represents either an increment or a decrement in the value of economic resources. An Economic Agent is an individual or an organization capable of having control over economic resources, and transferring or receiving that control to or from other individuals or organizations [START_REF] Hruby | Model-Driven Design Using Business Patterns[END_REF]. The duality relationship links increment events to decrement events. The set of events related by a duality relationship form a so-called REA process 1 .

In the remainder of this paper, we will use an abbreviated graphical modeling notation of REA processes. Figure 2 shows the legend of our notation.

Related Works

Generally speaking, our work lies within the scope of model transformations, and more specifically, in reverse-engineering model transformations [START_REF] Czarnecki | Classification of model transformation approaches[END_REF]. Reverse engineering is defined as "the process of analyzing a subject system to (i) identify the system's components and their interrelationships and (ii) create representations of the system in another form or at a higher level of abstraction" [START_REF] Demeyer | Object-oriented reengineering patterns[END_REF]. Indeed, our work seeks to transform an operational representation of a BP into a business view of the same BP. Although to the best of our knowledge this particular problem did not draw authors attention yet, some works were interested in BPM and BM transformations that we can classify into two classes.

The first focused on transforming BMs into BPMs. Generally, the proposed approaches followed a common transformation schema by (1) extending the BM with business process operational aspects and (2) inferring concrete business process activities and orchestration relying on a pattern library. They varied on the choice of abstraction to extend the BM and their automation degree. Andersson et al. focused on making explicit in the BM the transfers of resource custodies and evidence documents [START_REF] Andersson | From Business to Process Models: a Chaining Methodology[END_REF]. Wieringa et al. tackled the same problem by relying on what they call physical delivery models [START_REF] Wieringa | Value-driven coordination proces design using physical delivery model[END_REF]. Their claim is that while value models depict value streams between BP actors, the actual delivery of the value objects does not necessarily follow the same path. More recently, Fatemi et al. analyzed the interactions between the business actors to generate a BPMN model from an e 3 value model [START_REF] Fatemi | Value-oriented coordination process modeling[END_REF]. They proposed a taxonomy of interactions that include six classes and involve the analyst to classify the interactions and to specify who initiates each interaction. Our approach globally follows the same schema but varies (1) in the direction of the transformation (i.e. BPM into BM) and thus the information needed to extend the model, [START_REF] Andersson | Towards a Reference Ontology for Business Models[END_REF] in the generality of our patterns and (3) in the degree of automation and analyst involvement required.

The second class is about ensuring the alignment of BMs and BPMs. Pijpers et al. [START_REF] Pijpers | Consistency checking between value models and process models: A best-of-breed approach[END_REF] proposed a method based on a reduction of both models to a common metamodel with two main concepts: business units and so-called common value objects. They model the relationship between these concepts as a set of transfers of common value objects to/from business units. Although this approach can give an approximation of the alignment between both views (as mentioned by the authors, false negatives could be observed), we cannot use this approach to derive a value model from a BPM. Indeed, the reduced model disregards the relationships between value transfers (i.e. dualities in REA) that we believe is the core concept of a value model expressing the intents behind these transfers. Other approaches to ensure view alignment that do not involve model transformation (e.g. [START_REF] Bodenstaff | An approach for maintaining models of an ecommerce collaboration[END_REF]) were not reviewed. In the next section, we provide a high level view of our approach.

Approach Overview

Going from a dynamic view of the BP (i.e. BPMN) to infer a value centric view conforming to the REA ontology raises three main questions: (1) how to identify REA concepts (i.e. Resources, Events, and Agents) from a BPMN process Answering the first question involves matching between REA concepts and BPMN constructs. This constitutes the first two steps of our approach and will be discussed in Section 5. Once we have identified the concepts, we need to determine and infer the relationships between them to form a set of REA Economic Processes. Some of these relations are explicit from the BPM while others, such as dualities, need to be inferred. In Section 6 we explain how we tackle this problem using a set of structural and behavioral patterns we have identified.

In the last step of our approach, we construct the value-chain by connecting the obtained REA processes relying on a partial order over the set of occurrences of each BP resource. We derive this order from the partial order over BPM activities and the traceability links between the activities and REA economic events. Space limitation prevents us from going into further details about this step in this paper. We illustrate the global view of our approach in fig. 3.

In order to perform preliminary validations of our work and prove its feasibility, we implemented the three last steps by defining our patterns as rules in JBoss Drools rule engine. The rules implemented the transformations from the BPMN2.0 metamodel2 into our REA metamodel [START_REF] Boubaker | Methodology and Tool for Business Process Compensation Design[END_REF] defined using the Eclipse Modeling Framework.

Before going into the details of our approach, in the following subsections we present the hypothesis and assumptions on which we will base our approach. We also present a simple sale-and-delivery example of an e-retailer that we will use as a running example to illustrate our approach.

Modeling Assumptions and Hypothesis

First, we assume that the BP collaboration is modeled from the perspective of the entity under study (e.g. a company). Therefore, the BPM must include the private process of the so-called entity whereas only public processes of collaborating partners are needed. We also assume that the provided BPMN model is valid both syntactically and semantically. Syntactic validity refers to the conformance to BPMN specifications [START_REF] Omg | Business Process Model and Notation (BPMN)[END_REF] and observed best practices [START_REF] Weske | Business Process Management: Concepts, Languages, Architectures[END_REF] while semantic validity means that the model makes general operational and business sense for the entity under study.

Under these assumptions we make two hypothesis on our approach. First our approach will discover at least 80% of the REA processes that could be discovered from the input process (H1). Hence, we want to generate REA valuechains at the lowest granularity level. As we will see in the remainder of this paper, our approach will generate REA processes that are syntactically correct by construction. However we want to ensure semantic correctness and make the hypothesis that these generated REA processes are relevant and consistent with the business process under study with a precision rate of 80% or more (H2). A given REA process is relevant if it describes an economic phenomenon involving economic resources and agents that could be observed in the business process. A relevant REA process is also consistent if it describes correctly the type of phenomenon (i.e. exchange vs conversion) and shows all the economic resources that should be involved from what could be gathered from the BP.

ABCInc Sale-and-Delivery Example

We will use through this paper a simplified sale-and-delivery BP used by an e-retailer (ABCInc) that we have depicted in fig. 4 in BPMN notation. The process starts when a Customer gets online and orders books. Then ABCInc starts preparing the order by enclosing the products in a box and sticking a label with the shipping address. At the same time, ABCInc's Bank debits customer's credit account and ABCInc's account is credited the transaction amount.

Once both of these parallel operations are performed, the products are shipped to the customer by a Shipping company who provides ABCInc with a tracking number after picking-up the parcel. ABCInc will in turn send the tracking number to his Customer. Once the Shipping company delivers the parcel to the Customer, it sends ABCInc the delivery confirmation (i.e. customer's signature) and the process ends with a successful result.

Identification of REA Concepts

We presented in section 2 the REA ontology and explained its three core concepts: Resources, Events and Agents. In this section, we explain how we identify each of these concepts from a BPMN process model.

Economic Agents

REA Agents are modeled explicitly in a BPMN collaboration as Participants. Indeed, BPMN defines participants as "...specific PartnerEntity (e.g., a company) and/or a more general PartnerRole (e.g., a buyer, seller, or manufacturer) that are Participants in a Collaboration..." [START_REF] Omg | Business Process Model and Notation (BPMN)[END_REF]. External participants are modeled as process pools whereas internal participants (e.g. economic units) are represented as swimlanes within the pool of the entity under study. In our ABCInc example, ABCInc is the company under study having two internal agents: the sales department and the warehouse. The customer, the shipping company and the bank are three external agents.

Economic Resources

Economic resources involved in the BP can be explicitly modeled as objects, called in BPMN terms Item Aware Elements and defined as elements that "are subject to store or convey items during process execution" [START_REF] Omg | Business Process Model and Notation (BPMN)[END_REF]. Item Aware Elements could be either informational or physical and specialize as Data Objects, Data Object Inputs, Data Object Outputs and Data Object References. Hence, this appears to be an appropriate construct to represent economic resources. However, not all Data Objects3 involved in the BP are economic resources. For example, an order document usually appears in BP models but does not answer the scarcity property of economic resources' definition (see Section 2). Therefore, Data Objects representing economic resources must be clearly distinguished from non economic objects and we propose to stereotype them as "Economic". We do this as the first step of our approach (Step 1, fig. 3). We conjecture that all Physical Data Objects should be considered as economic resources and will be stereotyped as such automatically. However, we cannot infer systematically the economic nature of informational Data Objects. Therefore, we involve the analyst who is asked to manually stereotype all non-automatically identified economic resources. In fig. 4, we have stereotyped all relevant economic resources.

Economic Events

As seen in Section 2, economic events are actions producing changes in the economic resources (their rights or properties). Thus, we relate economic events to BPMN activities but we still need to determine, from the set of BPM's activities, which should be considered as economic events. We can intuitively filter out those activities that are not related to an economic resource (i.e. as input or output). However, this is not sufficient as some of the remaining activities may not be economic events. Let's imagine that in our ABCInc BP we wanted to weight the package before shipping. This activity would take the package as an input but will not produce any change neither in package's properties nor rights.

There are two types of economic events: the ones that transfer some resource rights and the ones that alter some resource properties. We infer the first class of events from message sending/receiving activities4 in the BPMN model (e.g. "Send Process Payment Request" from fig. 4). As BPMN only allows communications between participants through messages, the economic resource sent (resp. received) by a sending (resp. receiving) activity will be it's output (resp. input) economic Data Object (see [17, pp.48]). The second category of events implies activities producing some new resource(s) or a modified version of its input(s). Therefore an economic event will be related to each input and each output resource of the activity. From example in fig. 4, we will derive three economic events from the "Prepare order" activity.

BPMN to REA Patterns

As seen in the previous section, identifying REA concepts is a straight forward process applying simple rules. However, we cannot determine all concept instances relying solely on these rules. In our example, the "Products" leave ABCInc at some point and end-up being in the possession of the customer. We cannot determine using our rules how the Products' location got changed. There must be an economic event in charge of altering the location property but how to determine it? Intuitively we think of the shipping company being responsible of doing the transportation but does it involve any other resource? Another question we might ask is how are these REA concept instances associated? Some associations are explicit in the model as the provider/receiver relationships between agents and economic events or the associations between economic events and resources. But what about associations between economic events (i.e. dualities)?

We believe the answer to these question could be inferred as -through the analysis of a set BP collaborations -there seem to be a handful of business collaboration scenarios that we could codify as patterns. In this section we present these patterns classified into two categories: structural and behavioral patterns. Structural patterns give us a one to one mapping between a portion of the BPMN model and an REA process (or a set thereof). Behavioral patterns, on the other hand, exploit execution semantics of the BPMN model in order to refine the inferred REA processes.

Before detecting the patterns, we perform a preliminary step that replaces messages exchanged between external participants by two messages: one from the original sender to the company under study, and one from the company to the original receiver. Indeed, as mentioned in 4.1 the BPM should reflect the BP of the company under study and we assume that communications between external participants should be done on behalf of the company.

In the following, we present the structural and behavioral patterns in turn. We illustrate each pattern in its simplest form in fig. 5. However, the reader should note that each pattern may be declined into an infinite set (e.g. involving more resources, different order of activities, etc.).

Structural patterns

Conversion pattern From our ABCInc example, the "Prepare Order" activity encloses the ordered products in a box on which a shipping label is sticked. Thus we went from a pile of products to a box containing the products that is proper for shipping. This activity along with its input and output economic resources (elements on a black background in fig. 4) constitute what we call a conversion pattern. A conversion patterns occurs when an activity creates an added value by consuming and/or using some input economic resources and produces some output resources that are either new resources or an enhanced version of the inputs. In the former the created resource does not appear as an inflow resource whereas in the latter it is part of the input set. A conversion pattern will naturally be translated into an REA conversion process where input economic resources will form the inflows of the process and the output resources will form the outflow s. This pattern is illustrated in fig. 5(a). Exchange pattern ABCInc sends some products to his customer for which it gets a money payment. This "sale" is a typical example of an exchange pattern, i.e. one of the participants provides some economic resources in order to gain some other (different) economic resources in exchange. An exchange pattern is converted into an REA exchange process having the business events associated to the provided resources as inflows events and the business events related to the economic resources received by the company as outflows. We illustrate this pattern in fig. 5(b). Outsourcing and Insourcing patterns It happens that a company wants to delegate part of its production workflow to an external company. For example, in our ABCInc case, the company relies on a banking institution to transfer the money from customer's bank account into its own. We define an outsourcing as the delegation by a company of part of the value adding process to an external partner. A resource (or a set thereof) is provided to the partner in order to be transformed and received back once done. The partner does the work for a "fee" thus we expect another (different) resource being provided by the company as a payment.

An outsourcing pattern will be transformed into two REA economic processes: an REA conversion process and an REA exchange process [11, pp. 316-318]. In the conversion process the resource is transformed by the partner. The conversion will also consume an intermediate resource we'll call a "Service" resource. This service resource is acquired with the economic resource provided as a payment, thus forming the REA economic exchange. We illustrate the pattern and it's corresponding REA transformation in fig. 5(c).

We call the reciprocal the insourcing pattern in which the company alter some resource(s) for the benefit of a partner. However, the corresponding REA transformation will only contain the exchange as, in this case, the private process is known and the resource alteration will be matched as a conversion pattern. The renting pattern Say we are a car renting company and rent cars to individuals. During the rent period, we lose the usage (right) on the rented car and receive a money payment (ownership). The payment we receive covers for both our inability to rent the car to someone else as well as the wear-andtear sustained by the car. Modeling this in REA terms would involve an REA exchange process where the car's usage right is exchanged for the money, and a conversion process expressing the alteration of the car. This is what we call the renting pattern (see fig. 5d).

Generally speaking, we assume that when a resource is relinquished and leaves company's control, it will sustain alterations. However, we can envision cases where this is not true, specifically when the lent resource is non-tangible.

Consider for example a loan process: the money lent and recovered will not sustain any alteration. In such cases, the REA conversion in the transformation model on fig. 5(d) will have no effect.

Behavioral Patterns

The patterns presented above showed how to translate portions of a BPMN model into a set of REA processes relying solely on structural aspects. Conversely, behavioral patterns exploit execution semantics in order to refine the REA processes obtained from the structural patterns. Therefore, behavioral patterns are not self sufficient and must be combined with a structural pattern. For example, consider the case where a customer provides the company with the raw material in order to perform some production and the money payment for the service and, once done, the company gives back the finished good. In such a scenario, our Exchange Pattern will be matched (money and raw material exchanged for finished goods). However, the raw material should not be part of the exchange as the company do not acquire the ownership on the raw material, but will be consumed by the conversion process that produces the finished good. This is what we call the resource provisioning pattern. We have identified three more behavioral patterns: independent branches, internal responsibility and resource dependency. Due to space limitations, these patterns will be presented more thoroughly in an extended version of this paper.

Patterns detection and transformation

As we mentioned, behavioral patterns are meant to be combined with structural patterns. Therefore structural patterns along with different allowed combinations of structural patterns and behavioral patterns form an extended set of self-sustaining patterns, each with a corresponding REA transformation. This extended set forms a rule base in which each rule have the BPMN pattern as its left-hand side and the corresponding REA transformation as its right-hand side.

However, in order to perform the transformation in a rule-based system, we first need to address two problems.

The first problem concerns the non-confluence of our rules [START_REF] Küster | Validation of model transformations: first experiences using a white box approach[END_REF]. We can easily see that our rules are not confluent if we consider, for example, the exchange and the outsourcing patterns. In a sense, the outsourcing patterns "embeds" an exchange. Thus, both rules could fire, each producing a different transformation.

To address this problem, we elected to define the order in which the rules should be fired. We conjecture that more specific rules should have precedence over less specific rules. A rule A is more specific then a rule B if (1) matching A implies matching B (i.e. A embeds B ), or if [START_REF] Andersson | Towards a Reference Ontology for Business Models[END_REF] both are the same structural pattern but A has more combined dynamic patterns.

The second issue is the partial matches of the BPMN patterns. The dark greyed portion of fig. 4 concerns the handling of Money transfer by the Bank and should match an outsourcing pattern, but a resource given by ABCInc to the Bank is missing in the BP (i.e. the service fees). Indeed, a given BP does not live in isolation and paying Bank 's fees could be handled by a separate accountreceivable BP. However, we still need to account for the missing resource as it is part of the value-chain that supports the BP. Our solution to this problem is based on an heuristic that extends the original BPMN model by adding an anonymous resource flowing to/from the company to/from each of the participants. Then the rules are fired and the extension that produces the more specific pattern match is selected. If two equally specific rules are matched, we ask the analyst to resolve the conflict.

We present in fig. 6 the resulting REA model generated by our implementation after applying our approach on the ABCInc case.

Validation

We performed an experiment on a population of eight [START_REF] Fatemi | Value-oriented coordination process modeling[END_REF] graduate students from our laboratory with a research focus on electronic commerce. While all of our participants knew how to read and interpret either a BPMN model or an UML activity diagram, none of them knew about business modeling.

The experiment was divided into two phases. The first was a two hours session where the experimenter presented the REA ontology to the participants, it's objectives and modeling syntax. Following the presentation, participants were asked, as an exercise, to model the REA transformation of the ABCInc example presented in fig. 4. The session was concluded by presenting to the participants three BPMN models on which the experiment will be performed: a software engineering process (P1), a travel booking process (P2) and a manufacturing process (P3). At the end of the session, we asked each participant to annotate the three models by identifying economic resources from Data Objects. In between the two sessions, participants were asked to model the REA transformations of each of the three BPMN models relying on their intuition and understanding of the process. They were given two instructions: (1) to respect the REA modeling syntax, and (2) to model to the lowest granularity level permitted by the provided BPMN model (i.e. including as much REA processes as possible).

The second session took place a week later as one-on-one interviews. They were presented with the automatically generated transformations, with respect to their provided annotations, and were asked to answer the following questions for each REA process from the generated value models:

-(Q1) Relevancy: Should the REA process be part of the value-chain? -(Q2) Consistency: If relevant, does the REA process contains any semantic inconsistencies with respect to the BP? -(Q3) Global consistency: If relevant, is the REA process' placement within the value-chain and its relationships with other REA processes coherent?

Then they were given the opportunity to modify their annotations (e.g. by adding an economic resource they overlooked in the first session). We generated a new REA transformation according to the new annotated model and the participants were asked, for each REA process from the new generated model, to answer the previous questions, as well as:

-(Q4) Could you match the REA process to an REA process from your manual transformation?

Results

Table 1 presents the compiled results for each BPMN model of our experiment (P1, P2 and P3). The table is divided into three sections. The first two sections are related to the generated value-chains (1) from the original annotations and (2) after the annotations were revised. In each section, we compiled the average count of the answers to each of the questions presented in the previous subsection. The third section shows the average number of REA processes obtained from participants' manual transformations (#Man). Column Q4 shows the average REA processes from the manual transformations that were matched to an REA process in the generated model. The last line of the table gives the average values per process and per participant.

From these results we computed the precision (P) and recall (R) of automatic transformations after annotations were revised as P = Q2

Gen and R = Q4 M an .

Validity Threats

The major threat to the validity of our experiment lies in the limited expertise of our subjects that we mitigated by providing a two hours lecture on business modeling and divided the experiment into two sessions, giving them a hands-on experience in-between sessions. We also recognize that the small number of BPs on which we tested our approach threatens its generalizability. While we believe that the results provide a weight of evidence in support to our hypothesis, a more extensive validation involving more business processes has still to be done.

Discussion

As presented in table 1, our approach permitted to recall 91% of the REA processes identified by our study participants. Furthermore, we generated a total of 183 REA processes deemed relevant out of 133 discovered manually. This supports our hypothesis of discovering all the REA processes that could be detected from the given annotated BPM (H1). Our results also show that 96% of the discovered REA processes were judged by our participants to be relevant and consistent, thus supporting our second hypothesis (H2).

From a pragmatic standpoint, the results and interviews with participants reflected the ways in which our approach could help analysts in designing value models of business processes. First, the experiment showed that we generated 38% more relevant REA processes as compared to manual transformations. Furthermore, comparing results before and after annotations were revised allowed us to see how participants were able to refine their results. Indeed, our approach makes it easy to spot missing or erroneous annotations, enabling iterative refinements until getting a sensible value-chain. Finally, during one-on-one interviews, participants unanimously acknowledged that producing REA processes through our approach much more efficient than the manual approach.

The experiment results also helped to highlight some problems with our approach. Indeed, 7 REA processes out of 184 were deemed inconsistent. The main inconsistency that surfaced through our analysis is related to the outsourcing pattern when the participant involved is the customer of the company under study. Indeed, the customer may be involved in a given conversion process, but our participants advised that the "service" he provides should not be accounted for in the conversion. We believe this is a subjective opinion that is more related to modeling decisions and compromises made by the analyst than to the existence of the consumed service per se. We can account for such compromises by relying on a classification of process participants (i.e. customer vs. providers).

Conclusion

A business process model (BPM) cannot capture all aspects of the business process it supports as it is only one of the many viewpoints from which the process could be considered. In fact, a BPM depicts how the process should be performed and by whom. In particular, it abstracts away from questions like what is involved and why? This is answered by the business model (BM) of the process. Keeping the BPM and the BM in sync is important in order to ensure that business process execution is aligned with strategic decisions and goals.

In this work, we propose a semi-automatic systematic approach to generate a BM from a BPM and, more specifically, to transition from a BPMN model into an REA value-chain. The first step is partly manual and requires an analyst to identify economic resources from data objects in the BPMN model. The next step maps REA concepts to BPMN concepts. The third step relies on a set of structural and dynamic patterns to infer the relationships between the identified REA concept instances and obtain so-called REA processes. Finally, we construct the overall value-chain by linking the REA processes.

We applied our approach on a case study we used as a running example and performed a preliminary validation that showed a precision rate of 96% and a recall of 91%. Our major contribution lies in the definition of the set of generic business patterns that are at the heart of our approach. Our preliminary validation provides a weight of evidence in support of our approach and a thorougher validation has still to be performed.

Fig. 1 .

 1 Fig. 1. REA metamodel

Fig. 2 .

 2 Fig. 2. REA abbreviated notation

Fig. 3 .

 3 Fig. 3. Global view of our approach

Fig. 4 .

 4 Fig. 4. ABCInc sale-and-delivery simplified (and fictive) example

Fig. 5 .

 5 Fig. 5. Four structural patterns: (a) conversion, (b) exchange, (c) outsourcing and (d) renting pattern. (A B: A must precede B; A...B: the order is irrelevant)

Fig. 6 .

 6 Fig. 6. Final result of our approach applied on the ABCInc example from fig. 4.

Table 1 .

 1 Experimental results

		Automatic Transformation	Manual
		Original annotations Revised annotations Transformation
	Process Gen Q1 Q2 Q3 Gen Q1 Q2 Q3 Man	Q4	P R
	P1	12.00 11.87 11.62 10.12 12.62 12.62 12.25 12.62 8.25	7.81	0.97 0.95
	P2	3.12 3.00 2.75 2.50 4.50 4.37 4.37 4.37 4.00	3.37	0.97 0.84
	P3	5.37 5.37 5.00 4.75 5.87 5.87 5.37 5.87 4.37	4.00	0.91 0.91
	All	6.83 6.75 6.46 5.79 7.66 7.62 7.33 7.62 5.54	5.06	0.96 0.91

Note that the term "process" here do not necessarily mean the entire business process. In fact, a given business process may be decomposed into several REA processes.

http://www.eclipse.org/bpmn2-modeler/. Last accessed: March

3rd 2014.

in the remainder of this paper, we will use the terms DataObject and ItemAwareElement interchangeably.

These activities need to have an input or output economic resource as we ruled out those that do not.


Tong Li
email: tong.li@disi.unitn.it

Jennifer Horkoff
email: horkoff@disi.unitn.it

John Mylopoulos

Integrating Security Patterns with Security Requirements Analysis Using Contextual Goal Models

Keywords: Security Patterns, Security Requirements Analysis, Contextual Goal Model

Security patterns capture proven security knowledge to help analysts tackle security problems. Although advanced research in this field has produced an impressive collection of patterns, they are not widely applied in practice. In parallel, Requirements Engineering has been increasing focusing on security-specific issues, arguing for an upfront treatment of security in system design. However, the vast body of security patterns are not integrated with existing proposals for security requirements analysis, making them difficult to apply as part of early system analysis and design. In this paper, we propose to integrate security patterns with our previously introduced goal-oriented security requirements analysis approach. Specifically, we provide a full concept mapping between textual security patterns and contextual goal models, as well as systematic instructions for constructing contextual goal models from security patterns. Moreover, we propose a systematic process for selecting and applying security patterns, illustrated with a realistic smart grid scenario. To facilitate the practical adoption of security patterns, we have created contextual goal models for 20 security patterns documented in the literature, and have implemented a prototype tool to support our proposal.

Introduction

Dealing with security concerns for complex software systems is a laborious and knowledge-intensive process. Security patterns encapsulate reusable security knowledge that can support analysts with little security knowledge. Much work has been done to collect and document such patterns, resulting in several security pattern repositories, such as [START_REF] Hafiz | Organizing security patterns[END_REF][START_REF] Scandariato | Architecting software with security patterns[END_REF][START_REF] Fernandez-Buglioni | Security patterns in practice: designing secure architectures using software patterns[END_REF]. However, such security patterns have not been integrated with existing security requirements analysis techniques, making them difficult to apply as part of early system analysis and design. Analysis using security patterns mainly focuses on "how" to tackle a particular security problem, but does not address "why" a security problem needs to be treated. Effective application of security patterns requires a systematic analysis method, which is currently lacking among existing proposals.

Requirements Engineering (RE) has been increasingly focusing on securityspecific issues, arguing for an upfront treatment of security in software system design. Goal-oriented modeling techniques constitute an effective way to capture and analyze stakeholder intentions. Proposals such as Secure Tropos [START_REF] Mouratidis | Secure tropos: a security-oriented extension of the tropos methodology[END_REF], Secure-i* [START_REF] Liu | Secure-i*: Engineering secure software systems through social analysis[END_REF], and STS analysis [START_REF] Paja | Managing security requirements conflicts in sociotechnical systems[END_REF], have been used by multiple authors to analyze security requirements. In this paper, we argue that integrating goal-oriented requirements analysis with security pattern analysis can benefit both types of analysis. Goal models capture the rationale for applying security patterns and facilitate selection among alternatives, while the application of security patterns can efficiently operationalize security requirements into specific security solutions.

Our previous work deals with security requirements for socio-technical systems using a three-layered approach [START_REF] Li | Dealing with security requirements for socio-technical systems: A holistic approach[END_REF]. Our proposed framework does make use of security patterns to assist goal-based security requirements analysis. However, several challenges were revealed during that work, hindering the integration of security patterns and security requirements analysis. Firstly, there is normally more than one security pattern candidate that can potentially treat one security requirement, and analysts have to manually choose the best pattern to apply, a highly non-trivial task. Moreover, the complexity of security pattern selection grows with the number of security requirements. Secondly, creating security patterns in terms of goal models is non-trivial and time-consuming, requiring the analyst to have a full understanding of a security pattern she is about to use. Preliminary steps towards tackling these challenges have been described in a short workshop paper, which proposes to model security patterns as contextual goal models by introducing an initial concept mapping between them [START_REF] Li | Modeling and applying security patterns using contextual goal models[END_REF]. However, the concept mapping was incomplete, as only six security patterns had been analyzed by that time. Also, this work lacks a detailed methodology for selecting and applying security patterns.

In this paper, we significantly improve our previous work [START_REF] Li | Modeling and applying security patterns using contextual goal models[END_REF] in order to seamlessly integrate security patterns with our three-layer security requirements analysis approach [START_REF] Li | Dealing with security requirements for socio-technical systems: A holistic approach[END_REF]. In particular, this paper makes the following contributions:

1. Offers a complete concept mapping between the constituent concepts of security patterns and contextual goal models, as well as a detailed process for constructing contextual goal models from security patterns. 2. Proposes a systematic process for selecting the most appropriate security pattern and applying it to security goal models. The process is illustrated with a realistic smart grid scenario. 3. Sketches a prototype tool, which helps to build contextual goal models and interactively check context. We have built contextual goal models for 20 security patterns adapted from [START_REF] Fernandez-Buglioni | Security patterns in practice: designing secure architectures using software patterns[END_REF] by using this tool.

In the reminder of this paper, we first describe our research baseline on security patterns, contextual goal models, and our previous work in Section 2. In Section 3 we present a smart grid scenario used throughout the paper to illustrate our proposal, while in Section 4 we describe how to transform textual security patterns into contextual goal models. In Section 5, we present a systematic process to select and apply security patterns. We briefly introduce the prototype tool in Section 6, and then describe related work in Section 7. Finally, conclusions and future work are presented in Section 8.

Background

Security Patterns

Security patterns capture proven security solutions to known security problems. Much work has gone towards identifying security patterns [START_REF] Asnar | Organizational patterns for security and dependability: From design to application[END_REF][START_REF] Fernandez | The secure three-tier architecture pattern[END_REF], while other work focuses on summarizing catalogues of security patterns [START_REF] Schumacher | Security patterns: Integrating security and systems engineering[END_REF][START_REF] Scandariato | Architecting software with security patterns[END_REF][START_REF] Fernandez-Buglioni | Security patterns in practice: designing secure architectures using software patterns[END_REF]. In total, there are more than 100 security patterns.

In this work, we adopt the security patterns presented in [START_REF] Fernandez-Buglioni | Security patterns in practice: designing secure architectures using software patterns[END_REF], which provides detailed specifications of 68 security patterns. In particular, security patterns in [START_REF] Fernandez-Buglioni | Security patterns in practice: designing secure architectures using software patterns[END_REF] are documented in the POSA (Pattern-Oriented Software Architecture) template [START_REF] Buschmann | Pattern-oriented Software Architecture: On Patterns and Pattern Language[END_REF] with predefined sections. Among these sections, there are four essential sections as highlighted in [START_REF] Buschmann | Pattern-oriented Software Architecture: On Patterns and Pattern Language[END_REF]: Context, Problem, Force, and Solution. Table . 1 shows the Intrusion Detection System (IDS) pattern [START_REF] Fernandez-Buglioni | Security patterns in practice: designing secure architectures using software patterns[END_REF], which contains all four essential sections, as well as the Consequence section, which is also analyzed in our approach. In addition to this book, we also took into account several security patterns presented in [START_REF] Scandariato | Architecting software with security patterns[END_REF] to cover more security aspects.

A Goal-based Contextual Requirements Framework

Stakeholder requirements may vary from context to context. Ali et al. [START_REF] Ali | A goal-based framework for contextual requirements modeling and analysis[END_REF] and Lapouchnian et al. [START_REF] Lapouchnian | Modeling domain variability in requirements engineering with contexts[END_REF] argue that requirements should be analyzed in a way that reflects context settings. They propose goal-based frameworks for contextual requirements modeling and analysis, in which they relate goals and contexts.

C C

Fig. 1: Goal models with contexts We use here the proposal by Ali et al. [START_REF] Ali | A goal-based framework for contextual requirements modeling and analysis[END_REF], which extends Tropos [START_REF] Bresciani | Tropos: An agentoriented software development methodology[END_REF] with context-related concepts. In particular, contexts are treated as labels that can be attached to specific goal model elements, such as what is shown in Fig. 1. Moreover, they define semantics for contexts that are modeled within goal models. For example, in the first case of Fig. 1, goal G represents a requirement if and only if context C applies. In the other two parts of the figure, a link between two goals is part of the goal model only when context C applies. We follow their method to model contexts, but also extend it to suit our purposes.

A Three-Layer Security Requirements Analysis Framework

Our previous work proposed a three-layer security requirements analysis framework that aims to address security issues at the business layer, software application layer, and physical infrastructure layer [START_REF] Li | Dealing with security requirements for socio-technical systems: A holistic approach[END_REF]. Our framework is designed to Table 1: The specification of the Intrusion Detection System pattern [START_REF] Fernandez-Buglioni | Security patterns in practice: designing secure architectures using software patterns[END_REF] Context: Nodes for local systems that need to communicate with each other using the Internet. Problem: An attacker may try to infiltrate our system through the Internet. We need to know when an attack is happening and take appropriate response. Force: • Incomplete security. Security measures such as encryption, authentication and so on may not protect all our systems, because they do not cover all possible attacks. • Non-suspicious users. Request coming from a non-suspicious address (permitted by a firewall) could still be harmful and should be monitored further.

• Flexibility. Hard-coding the type of attack can be done easily. But it will be hard and time-consuming to adapt to attack patterns that change constantly.

Solution:

Each request to access the network is analyzed to check whether it conforms to the definition of an attack. If we detect an attack, an alert is raised and some countermeasures may be taken.

Consequence:

• Non-suspicious users. A request coming from a non-suspicious address (permitted by a firewall) is further inspected and analyzed.

• Flexibility. The detection information can be modified to include new attacks.

• There is some overhead in the addition of IDSs to a system. support analysis of both security issues within one layer and influences across layers, offering a holistic approach to security analysis.

We use the concept Security Goal to represent security requirements. A security goal is specified in a template, <Importance><Security Property>[<Asset>, <Interval>], as shown in Fig. 2. Our approach iteratively carries out security requirements analysis in each of the three layers. In particular, we iteratively refine security goals to "operationalizable" ones, among which we identify critical security goals that need to be treated. Then we operationalize critical security goals into specific security mechanisms, which can fulfill the security requirement being analyzed. Finally, we transfer related influences of selected security mechanisms into the next layer down, and further analyze security requirements in that layer. We leverage existing security patterns [START_REF] Scandariato | Architecting software with security patterns[END_REF][START_REF] Fernandez-Buglioni | Security patterns in practice: designing secure architectures using software patterns[END_REF] to help analysts without security knowledge to operationalize security requirements. In particular, we assign each security pattern a tag, which specifies the security property that a security pattern can potentially tackle. Thus, by matching the security property specified within a critical security goal and the tag of a security pattern, we can identify a number of security pattern candidates, among which the analyst must select. For example, as shown in Fig. 2, there are seven security pattern candidates that are identified to tackle the critical security goal High Application Integrity [Energy Management System, Price calculation] according to its security property Application Integrity. However, the selection among security pattern candidates is a non-trivial task, whose complexity grows with the number of critical security goals. In addition, after choosing a security pattern, the pattern needs to be manually modeled and integrated in the security goal models, which is timeconsuming for analysts.

An Illustrating Scenario

Our proposed security requirements analysis approach [START_REF] Li | Dealing with security requirements for socio-technical systems: A holistic approach[END_REF] has been applied to a smart grid scenario, which leverages information and communication technologies to enable two-way communications between customers and energy providers. Specifically, the energy provider periodically collects energy consumption data from the customer, based on which they calculate the new price and send back to the customer. Then the customer adjusts his energy usage according to the new price.

We construct a three-layer security requirements goal model for this scenario, consisting of 15 actors, 72 goals, 5 softgoals, 80 tasks, 68 refinement links, 53 operationalization links, and 13 dependency links. Fig. 3 shows part of the requirements goal model within the software application layer. In this paper, our approach will be illustrated using this smart grid scenario.

Model Security Patterns as Contextual Goal Models

In this section, we first present a contextual goal modeling language, used to define contextual goal models for security patterns. In addition, we present a detailed process for creating a contextual goal model for a given security pattern. Finally, we summarize some empirical observations derived from modeling 20 security patterns.

A Contextual Goal Modeling Language

We use the goal model concepts of our three-layer requirements analysis [START_REF] Li | Dealing with security requirements for socio-technical systems: A holistic approach[END_REF], including goal, softgoal, task, domain assumption, refine, and-refine, operationalize, contribution, mandatory, preferred (nice-to-have). Specifically, goals capture stakeholder desires, while softgoals are desires without clear-cut criteria for fulfillment; tasks describe behaviors of the system-to-be; and domain assumptions are properties of the domain that are assumed to hold. In addition, the refine and and-refine relations represent the refinement of a requirement into a simpler one; the operationalize relation indicates how a goal/softgoal is achieved by the system-to-be; the contribution relation captures the influences of tasks on softgoals; the mandatory relation indicates requirements that must be satisfied, while the preferred relation indicates "nice-to-have" requirements. On top of above goal model concepts, we introduce additional concepts to model and analyze contexts within a goal model. In particular, we specify context in terms of domain properties. A domain property is a fact related to a particular domain, while a design-time domain property is a domain property that can be verified at design time by related analysts. For example, "Computer systems on a local network connected to the Internet" is a design-time domain property, and analysts can verify this fact during design time according to the designed system infrastructure. For another example, "The number of users increases significantly" is not a design-time domain property, as it can only be verified at run-time. Since security pattern analysis is carried out at design-time, we only capture design-time domain properties to analyze design-time contexts. A particular context can be arbitrarily complex, consisting of either a single domain property or could be an aggregation of domain properties of any complexity, typically, via and/or operators.

As noted in Section 2.2, our goal models are context-dependent. For example, in Fig. 5, the softgoal Application Security is required if and only if the context C1 holds. It is worth noting that the concept domain assumption should be distinguished from the concept design-time domain property. A domain assumption is always assumed to be true during system designs, under which requirements are satisfied, and does not need to be checked. For instance, in Fig. 5, "other security measures do not cover all possible attacks" is a domain assumption.

A Process for Creating Contextual Goal Models from Security Patterns

To build contextual goal models that capture contents of security patterns, we focus on analyzing the five essential predefined sections of security patterns, as illustrated in Table . 1. For each of the five sections of the security patterns, we identify concepts within the contextual goal modeling language to capture the content of the section by considering both of their definitions [START_REF] Fernandez-Buglioni | Security patterns in practice: designing secure architectures using software patterns[END_REF][START_REF] Ali | A goal-based framework for contextual requirements modeling and analysis[END_REF]. Our analysis results in a concept mapping, shown in Fig. 4. In the rest of this section, we describe this mapping in detail. Apart from the concept mapping, we further provide detailed guidelines that constitute a systematic process for creating a contextual goal model for a given security pattern. The Intrusion Detection System pattern (Table. 1) will be used throughout this section to illustrate the mapping and instructions, with the corresponding contextual goal model shown in Fig. 5. Context Section Analysis. This section describes the initial context of the security pattern, in which the security problem occurs and is being solved. We model the context with one or multiple design-time domain properties. For example, the context C1 in Fig. 5 is the initial context, which is represented by one design-time domain property DTDP1 extracted from the context section. Note that the context C1, as the initial context, is attached to the root goal that will be extracted from the Problem Section.

Context

Problem Section Analysis. A problem is a description of a situation, for which stakeholders do not have a solution. We use one or several goals or softgoals to capture stakeholder needs concerning such a problem. As the problem is essential to a security pattern, we model the goals/softgoals that capture the problem as mandatory requirements, which have to be satisfied by security patterns.

We analyze this section sentence by sentence, each of which usually leads to the inclusion of a goal/softgoal. If there are several goals/softgoals, we need to consider the relations between sentences and determine the refinement structure of these goals/softgoals. It is worth noting that the description of the problem section may also involve domain assumptions, which should be identified and modeled within the refinement structure, such as "An attacker may infiltrate a system through the internet" shown in Fig. 5. The root element of a goal model constructed through this process must be mandatory.

To integrate the security patterns with security requirements analysis, we extract not only the specific problems that are solved by the security pattern, but also the high-level security requirements that lead to those detailed problems. If the high-level security requirements are not explicitly specified in this section, we need to do further analysis. In the IDS example, the first sentence presents a domain assumption "Attacker may infiltrate a system through internet", which also implicitly presents a high-level security requirement that the security of the software application should be protected. The next sentence "We need to know when an attack is happening" specifies a detailed problem, which is a refinement of the high-level security requirement. Thus, we obtain a model fragment as shown in the upper-right corner of Fig. 5.

Force Section Analysis. Forces are considerations, often contradictory, which have to be taken into account to determine the applicability of a pattern. These considerations are often related to non-functional requirements (NFRs), such as performance and cost. We model such forces as preferred softgoals, where Fig. 5: The contextual goal model of the IDS pattern stakeholders want to satisfy as many of such goals as possible. Other forces may belong to domain assumptions, which are always assumed to be true during the security analysis. For instance, the force Existing security measures cannot cover all attacks, shown in Fig. 5, is a domain assumption, under which the IDS security pattern operationalizes the security goals. This section is specified in an itemized manner. Each item starts with a key word, from which we can decide whether the force is a preferred softgoal (e.g. Flexibility) or a domain assumption (e.g. Incomplete Security). It is worth noting that some preferred softgoals are context-dependent, only needing to be considered in particular context. For example, the softgoal "Monitor nonsuspicious users" only holds under the context "requests from non-suspicious address could be harmful". If this context does not hold, the force does not need to consider. Therefore, we identify another context C2 and add it to this softgoal.

Solution Section Analysis. This section describes actions that are carried out by a security pattern. We model them as tasks, which specify how the "systemto-be" implements a security pattern. Similar to the analysis in the Problem section, the relations between tasks should also be identified and modeled in an appropriate structure. As shown in Fig. 5, we identify four sub-tasks, which are siblings, for applying the IDS pattern. Note that, the granularity of solutions varies from pattern to pattern. If the information provided in this section is too general, we can optionally extract additional information from other nonessential sections, such as the Structure, Dynamic, and Implementation sections.

Consequence Section Analysis. This section describes the consequences of a security pattern, which indicates both benefits and liabilities of the pattern. We capture these influences using contribution links. This section is also documented in an itemized way, and each item should correspond to one force, documented in the Force section. However, the correspondence between the Force section and the Consequence section may not be strict. The Consequence section may introduce NFRs in addition to those described in the Force section. These NFRs should also be taken into account, via inclusion as preferred softgoals, when choosing a security pattern. For example, the consequence description "There is some overhead in the addition of IDSs to a system" (Table . 1) indicates the IDS pattern hurts the performance of a system. The NFR (performance), which is not initially specified in the Force section, should be added into our model. In other cases, the preferred softgoals from the Force section may not be mentioned in the Consequence section. Thus, we need to infer the pattern's influences on those softgoals based on our understanding of the pattern, or search for related knowledge from other reliable knowledge bases. Some influences on preferred softgoals are also context-dependent. As shown in Fig. 5, the task "Detect attack" can only make the softgoal "Real time behaviour" under the context that there are sufficient and appropriate information about attacks. It is worth noting that the influences of a security pattern may also depend on its detailed implementations. For example, as described in the Authenticator pattern, the consequence "The overhead depends on the protocol used" cannot be directly modeled. We need to first model two alternative tasks "Apply a simple protocol" and "Apply a complex protocol", which refines the task "Apply an appropriate protocol" and then investigate their influences respectively.

Pattern Modeling: Empirical Observations

Thus far we have constructed contextual goal models for 20 security patterns1 described in [START_REF] Fernandez-Buglioni | Security patterns in practice: designing secure architectures using software patterns[END_REF]. During this exercise, we observed several issues, which may affect the quality of resulting models.

1. The specifications of some security patterns are incomplete, such as missing a section. 2. Not all security patterns are specified in a consistent way. For example, some patterns are specified in a threat-oriented manner, while others are in a function-oriented manner. 3. The granularity of descriptions may vary greatly among patterns. For instance, the solution section of some security pattern only describes general idea of the pattern in one sentence, while some other pattern uses several paragraphs to explain related security mechanisms.

These observations disclose that processing and modeling textual security patterns are time-consuming, and additional knowledge related to security patterns is usually required during this process. This fact further explains why security patterns are not widely applied. In the meanwhile, it justifies the value of our work, i.e. constructing reusable contextual goal models for 20 security patterns.

In addition, the above observations also expose the shortcomings in existing security pattern specifications, which should be tackled by the security pattern community.

Integrating Security Patterns with Security Requirements

Once security patterns have been modeled, we follow a systematic process to select and apply them to operationalize critical security goals that are derived from security requirements analysis [START_REF] Li | Dealing with security requirements for socio-technical systems: A holistic approach[END_REF]. Fig. 6: Security pattern analysis process As shown in Fig. 6, the process requires three types of information as input:

1) The security goal model, which captures requirements and security requirements regarding the domain. In particular, we use our three-layer security goal model (shown in Fig. 3) for this purpose. 2) The context specification describes the environments of the domain, which is composed of a list of design-time domain properties. This specification does not need to be complete at the beginning of the analysis, as it can be incrementally enriched during the application of security patterns. 3) A number of security patterns, which have been modeled in terms of contextual goal models. Note that, in Fig. 6, each input is assigned a tag, such as IN1. If the input is required by one activity, the tag of that input will be specified at the end of the description of that activity. The overall analysis process selects the best security pattern for each critical security goal, and applies the selected pattern to the security goal model, as well as updating the context specification. In the rest of this section, we describe each step of the process in detail, and finally illustrate the entire process with the smart grid scenario, described in Sec. 3. In particular, our illustration focuses on the software application layer of the scenario.

Generating Security Pattern Candidates

The security goal model contains a number of critical security goals, which are analyzed one by one in our analysis process. To apply appropriate security patterns to treat each critical security goal, we first identify security pattern candidates, which can potentially tackle the security goal. Particularly, we match the security property of the security goal with the root goal of the contextual goal model of each security pattern (e.g. Application Security in Fig. 5) to determine whether a security pattern can be a candidate solution to the critical security goal. The results of this match will reveal an initial set of security pattern candidates. It is worth noting that the match process takes the hierarchy of security property into account, such as described in [START_REF] Firesmith | Specifying reusable security requirements[END_REF][START_REF] Scandariato | Architecting software with security patterns[END_REF]. For example, the security property Application Integrity is a specialization of Application Security.

Thus, a security pattern that can tackle Application Security can also be applied to tackle the Application Integrity problem, such as the IDS pattern.

Security Pattern Selection

Once we have the initial set of the security pattern candidates, which typically contains more than one pattern, we carry out context-based selection to choose the most appropriate security pattern. To this end, we need to check each context to determine whether it holds within a particular domain.

As contexts attached to different elements have different effects when they do not hold, we define the context that is attached to root goal of a contextual goal model as a primary context, while define the context that is attached to preferred softgoal or contribution links as a secondary context. The primary context is essential to the applicability of a security pattern. Such as is shown in the IDS pattern (Fig. 5), here if the primary context C1 does not hold, the root goal will be deactivated, and the task "apply IDS pattern" will be deactivated accordingly, i.e., the pattern becomes inapplicable. In contrast to the primary context, the secondary context mainly affects the quality of the security pattern in terms of its contributions to the preferred softgoals. For instance, in the IDS pattern example, if the context C2 does not hold, its corresponding preferred softgoal will be deactivated, as well as the contribution links connected to the softgoal.

Having the two types of contexts, we propose two steps for selecting security patterns. As shown in Fig. 6, we first check the primary context of the security pattern candidates to filter inapplicable security patterns. After that, if there is more than one applicable security pattern left, we check the secondary contexts to determine the quality of each security pattern and do further selection. In particular, we quantify contribution links {make, help, hurt, break} as {2, 1, -1, -2} respectively to evaluate the effect a pattern has on the satisfaction of preferred softgoals, aiding in selection. Note that other more complicated goal satisfaction analysis techniques can also be used for this selection, such as those compared and evaluated in [START_REF] Horkoff | Comparison and evaluation of goal-oriented satisfaction analysis techniques[END_REF] As manual checking whether a context applies is a non-trivial task, especially for complex and large models, we propose an interactive process that semiautomates this task. We first formalize check rules for each context in Datalog and automatically check them against the context specification by using our tool. For example, the context C1 (in Fig. 5) can be formalized as below: R1: holdpc1q : ´NodepN1q, NodepN2q, communicatepN1, N2, internetq R2: not_holdpc1q : ´NodepN1q, NodepN2q, dis_communicatepN1, N2, internetq R3: undecidablepc1q : ´not holdpc1q, not not_holdpc1q If neither hold/not-hold can be inferred for a context, i.e. it is undecidable, the system turns to the user and infers the state of a context on the basis of user answers to a list of yes/no system questions.

Security Pattern Application

Thanks to the reusable goal model we have constructed for security patterns, analysts do not need to manually construct the goal model of a security pattern each time they want to apply it. Thus, after selecting the best security pattern, the analyst can directly insert the goal model of the security pattern to the security requirements goal model, as illustrated in Fig. 7. Note that the red cross indicates the context C3 does not hold, and the corresponding contribution link is deactivated. To correctly integrate the goal model of a security pattern into the security goal model, firstly, the analyst needs to merge the softgoals newly introduced by the security pattern with the original softgoals by following the techniques proposed by Niu and Easterbrook [START_REF] Niu | So, you think you know others' goals? a repertory grid study[END_REF]. For example, in Fig. 7, the new softgoal Flexibility has been merged with the original softgoal Flexible. Secondly, the analyst should do a pairwise comparison of all the old elements with all the new elements to find what new contributions should be present. As shown in Fig. 7, two new contributions links are identified with regard to the new softgoal performance.

Security Goal Model Security Pattern Goal Model

Case Study Statistics

We apply our approach to the application layer of the three-layer security goal model that is built for the smart grid scenario (Sec. 3) to further exemplify our approach. In this security goal model, we have identified five critical security goals, which need to be treated by specific security patterns. The security properties of these critical security goals, which are essential for initially generating security pattern candidates, are listed in Table . 2. In total we have 20 security patterns that have been modeled as contextual goal models. In the first analysis step, we identify 6-8 security pattern candidates for each of these security patterns. Then, we apply the two-step context analysis to select the most appropriate security pattern, the results of which are shown in Table . 2. Note that some security goals may have no suitable security patterns to apply. In such a case, the security goals will be transferred to the next layer of the three-layer model (physical layer), and are further analyzed there. Finally, we apply each selected security pattern by integrating its goal model into the security goal model.

Tool Support

We extend our prototype tool MUSER [START_REF] Li | A prototype tool for modeling and analyzing security requirements from a holistic viewpoint[END_REF], which has been designed to support the three-layer security requirements analysis approach, with a number of features to implement the approach presented in this paper 2 . The enhanced tool allows us to:

-Graphically model contextual goal models for security patterns; -Automatically check the contexts of security patterns against the domainspecific context, and ask for manual check if necessary; -Apply selected security pattern by inserting its corresponding contextual goal models into the security goal models.

Related Work

There are several approaches that model security patterns as goal models. Mouratidis et al. extend their security analysis approach Secure Tropos by integrating four security patterns [START_REF] Mouratidis | Modeling secure systems using an agentoriented approach and security patterns[END_REF]. Yu et al. [START_REF] Yu | Enforcing a security pattern in stakeholder goal models[END_REF] propose to formally specify role-based access control as a security pattern in terms of i* models, and implement a tool to automatically detect contexts and apply security patterns. However, these approaches do not address the pattern selection issues. In addition, only a limited number of security patterns are presented in their work, and no details are provided on how to model security patterns as goal models. Araujo and Weiss [START_REF] Araujo | Linking patterns and non-functional requirements[END_REF] apply the Non-Functional Requirement (NFR) framework as a complementary representation for security patterns, which helps to analyze the tradeoffs between forces. In particular, they define the force hierarchy to represent interactions between forces, and model such hierarchy for 14 security patterns. We can extend their results to build the contextual goal models for those security patterns. Asnar et al. [START_REF] Asnar | Organizational patterns for security and dependability: From design to application[END_REF] propose a method to design organizational patterns from SI* models, which deals with system security and dependability. Their approach proceeds in the opposite way of ours, they aim to extract security patterns from goal models, while we aim to apply security patterns into goal model analysis.

Security patterns have been applied to various models. Shiroma et al. [START_REF] Shiroma | Model-driven security patterns application based on dependences among patterns[END_REF] focus on applying security patterns to UML diagrams, and they define transformation rules to automate this application. Sánchez-Cid and Maña [START_REF] Sanchez-Cid | Serenity pattern-based software development life-cycle[END_REF] provide a language, which describes security solutions to assist software engineers to implement security patterns into software applications.

Several methods have been discussed for classifying security patterns [START_REF] Hafiz | Organizing security patterns[END_REF], which are essential for navigating and selecting security patterns, such as security properties, logic tiers, security concepts, system viewpoints and so on. Our approach use security properties for pattern classification. We specify the interrelationships among security patterns by using the refinement and contribution relations, with which we can identify relevant patterns that need to apply.

Other work has also been done on systematically analyzing textual patterns. Gross and Yu [START_REF] Gross | From non-functional requirements to design through patterns[END_REF] specify a systematic way to represent, analyze and apply design patterns by using NFR framework. They illustrate their method and experiences regarding to processing textual design pattern in detail, some of which are similar to our systematic guidelines. However, their approach does not analyze the context of a pattern and provide no support for pattern selections. Supaporn et al. [START_REF] Supaporn | An approach: Constructing the grammar from security pattern[END_REF] focus on generating security grammars, which are specified in extended-BNF formats, by analyzing descriptions of security patterns. Specifically, they build grammar trees to represent the semantics of security patterns, which could help us to better understand and process the textual security patterns as part of our framework.

Conclusions and Future Work

In this paper, we propose to integrate security patterns with our previous security requirements analysis technique by modeling security patterns as contextual goal models. Our approach contributes to both the operationalization of security requirements and the adoption of security patterns. In particular, we define concept mappings between security patterns and contextual goal models, and provide a detailed process for modeling security patterns as contextual goal models. Moreover, we propose a systematic process to select and apply security patterns, and illustrate the process with a realistic smart grid scenario. We have implemented a prototype tool, which supports the application of our approach.

Thus far, we have built contextual goal models for 20 security patterns, and we plan to model more patterns in the future. Our current approach is built on our previous work, and we intend to further generalize it to accommodate other goal-based security requirements analysis techniques. Furthermore, when applying a security pattern model, the newly introduced model may influence different parts of the existing model in various ways and make the application process very hard. Thus, we aim to propose new techniques that facilitate this process. Finally, we plan to carry out further, large-scale empirical evaluations of our approach in order to evaluate its validity and usability.

Fig. 2 :

 2 Fig. 2: Security requirements operationalization exampleWe leverage existing security patterns[START_REF] Scandariato | Architecting software with security patterns[END_REF][START_REF] Fernandez-Buglioni | Security patterns in practice: designing secure architectures using software patterns[END_REF] to help analysts without security knowledge to operationalize security requirements. In particular, we assign each security pattern a tag, which specifies the security property that a security

Fig. 4 :

 4 Fig. 4: Concept mappings between contextual goal models and security patterns

Fig. 7 :

 7 Fig. 7: Applying IDS pattern to the goal model of the smart grid scenario

Table 2 :

 2 Statistics of applying 20 security patterns to the smart grid scenario

	Security Goal	Security Property	All Candidates Applicable Applied
	SG1	Application Integrity 20	7	5	1
	SG2	Application Integrity 20	7	0	0
	SG3	Application Integrity 20	7	2	1
	SG4	Data Confidentiality 20	6	4	1
	SG5	Application Availability 20	8	0	0

The full list of models can be found at http://goo.gl/u539CV

Details of the tool can be found at: http://disi.unitn.it/~li/MUSER/

Acknowledgements This work was supported in part by ERC advanced grant 267856, titled "Lucretius: Foundations for Software Evolution".