Jean-Vivien Millo

Robert De Simone

Refining cellular automata with routing constraints

Keywords: Cellular Automata, Synchronous, Refinement, Routing Refining cellular automata with routing constraints Automate Cellulaire, Synchrone, Raffinement, Routage

A cellular automaton (CA) is an infinite array of cells, each containing the same automaton. The dynamics of a CA is distributed over the cells where each computes its next state as a function of the previous states of its neighborhood. Thus, the transmission of such states between neighbors is considered as feasible directly, in no time. When considering the implementation of a cellular automaton on a many-cores System-on-Chip (SoC), this state transmission is no longer abstract and instantaneous, but has to follow the interconnection medium of the SoC. It is usually a grid or a mesh matching the underlying topology of the CA but finite. In order to consider such constraints at a higher level, we propose a refinement of the classical model of CA where the topology is considered as the communication medium. If the state of a cell depends on its neighbors up to a certain distance, then a given state must be broadcasted to all its neighbors at the same distance, as they all require it to compute their next state. It means routing and duplicating the state in the topology. We study the routing patterns needed to efficiently implement such state broadcasting algorithm. We provide a solution by which each router can locally predict where to redirect the states to correctly and efficiently implement this broadcasting algorithm.

Introduction

A cellular automaton (CA) is a multidimensional infinite array of cells, each containing an identical automaton. The dynamics of a CA is based on the fact that each automaton synchronously computes its next state depending on its current one as well as the current states of a selected set of neighbors.

Communications (and communication feasibility) is not a real concern in the modeling framework. One supposes that instantaneous pointwise communication is available between any two cells in such neighborhood on demand. We shall challenge this assumption here and consider a refinement where communications have to be routed according to an interconnection topology. In the case of CA, a natural interconnection topology consists of the underlying topology of the CA itself. As far as we know, there is no existing work in that direction.

The coupling of a model of computation with communication constraints is commonplace in modern computer science. In the case of CA, it allows to consider efficient implementations on multi-processors Systems-on-Chip (MP-SoC) equipped with aspecific mesh interconnection structure such as a Network-on-Chip (NoC). We consider here CA that can be seen as the infinite unfolding of a spatial periodic states structure. Such CA can be simulated/implemented on a finite-size torus.

A given cell of the CA is thus subdivised into a router component and a computation cell that contains the original automaton. While the computation cell is tightly linked to its local router (by dedicated input/output links), the router is used to 1) inject a datum (which represent the current state) from the computation cell into the network, 2) route the passing data, or 3) duplicate a datum from the network to the computation cell. For example, it pushes a datum further north from a south port.

We shall here consider only the 2-dimensional case for sake of simplicity. We shall also consider that the router has a multicasting capacity. For example, a datum from the computation cell can be sent in many directions if it is relevant to several opposite locations.

Our present goal shall be to consider how static routing schemes can be defined and made up for frequently encountered communication patterns in CA dynamics. We shall in particular use the example of cells requiring all previous states from their Moore neighborhood of radius n or less (|| d|| ∞ ≤ n where d is the offset vector of the neighbor). Many applications such as the game of life [START_REF] Gardner | The fantastic combinations of john conway's new solitaire game «life[END_REF], the class of stencil applications [START_REF] Datta | Auto-tuning the 27-point stencil for multicore[END_REF], or the Jacobi numerical method [START_REF] Press | Numerical Recipes: The Art of Scientific Computing[END_REF] match with this neighborhood dependency scheme. One can then hope to discover regular patterns through which global communication behavior can be exposed, while the various data flows combine harmoniously into global traffic.

We will study the case where at some point in time, every cell sends synchronously its current local state (as a datum) on the network. This case can be seen as the worst communication case where the network is saturated. We propose the Neighborhood Broadcasting Algorithm (NBA) to resolve the situation and we study its behavior. Our analysis focuses on two aspects: 1) Performance analysis: the timing estimation of the NBA execution and the size of the interconnection channels (between routers) required to ensure conservation of data. 2) the discovery of regular routing patterns toward the goal of expressing the propagation rule (routing directives in the routers) statically once for all the routers and once for all iterations.

Cellular automata model

The basic definitions related to CA are imported from Jarkko Kari survey [START_REF] Kari | Theory of cellular automata: A survey[END_REF]. For instance, we consider synchronous CA and the underlying topology is an infinite rectangular grid of dimension d. Each cell has the same finite set of state S. The configuration of the automaton is a mapping c : Z d → S where each cell is identified by d coordinates. The evolution of a CA occurs synchronously on discrete time steps. All cells are updated simultaneously.

Let c a and c b be two cells of the CA identified by their vector of coordinates respectively c a and c b (in the sequel, when it is clear from context, c will be used instead of c). Let x = (x 1 , x 2 , ..., x d ) be the difference between c a and c b ( x = c a -c b ).

The distance relative to the i th dimension (or coordinate) is |x i | which is the value of the vector x at the index i.

The Manhattan distance (or norm) between c a and c b is denoted || x|| 1 and is equals to

|| x|| 1 = |x 1 | + |x 2 | + • • • + |x d |
The Moore distance (or norm) between c a and c b is denoted || x|| ∞ and is equals to

|| x|| ∞ = max(|x 1 |, |x 2 |, • • • , |x d |)
We define the neighborhood of a cell based on the Moore distance. N n (c) is the neighborhood of the cell c up to a radius n (c is in its own neighborhood).

N n (c) = {c a such that || c -c a || ∞ ≤ n}

Cellular automata with routing management

We shall now consider that the transmission of a datum between cells is not instantaneous anymore. When a cell sends a datum (that represents its current state) to one of its neighbors, the datum has to travel through the underlying topology and is subject to travel durations, channel capacity limitations, and routing decisions.

In the classical model of CA, when the global clock ticks, 1) every cell sends simultaneously a datum on the network, and so every cell receives data from its neighborhood. 2) every cell computes its new state according to the update rule. Step 1 is not instantaneous, it requires many micro-steps into which every datum is propagated to all its neighbors in N n (c). It takes at least n instants to go at a Manhattan distance n. When many data travel on the same branch of the network, they are queued in FIFO channels and processed one-by-one. Thus the global clock is refined in a communication clock where every step of the global clock corresponds to a finite sequence of micro-steps.

In order to manage the communication, the cell is augmented with routing capacities. The original finite state machine become the computation cell. It is complemented with a communication cell called "router" which interfaces the computation cell with the network. The router and the computation cell are strongly connected through dedicated channels.

Each router has four connections per dimensions. It is connected through an input and an output channels to the left and right (or up and down) neighbors. The generic behavior of a router is presented in Algorithm 1. At each micro-step, the router consumes a datum on one of its input channels and propagates it to one or many of its output channels (including the local channel to the computation cell) according to an internal propagation rule. One could also define a feeding rule to determine which input channels are considered micro-step after micro-step. It is allowed to considered many input channels simultaneously but only if the propagation rule guaranties that two data (or more) cannot be propagated on the same output channel at the same micro-step. Lastly, when a datum is propagated by a router, it can be considered by the direct neighbor only at the next micro-step. Propagation and feeding rules are data independent similarly to a cell of a Kahn process network [START_REF] Kahn | The semantics of a simple language for parallel programming[END_REF].

Figure 1 presents a 2-dimensional CA where each cell is divided in a computation cell plus a router.

Inria

Algorithm 1 describes the generic behavior of a router as a reactive process while true do in_ports = f eeding_rule(){decide which ports to read} for all in_port ∈ in_ports do data = in_port.read() destinations = propagation_rule(data){decide where to propagate data} for all out_port ∈ destinations do out_port.write(data) end for end for pause{wait for the next micro-step} end while 3 Neighborhood Broadcasting Algorithm (NBA)

Comp. cell

Comp. cell

Comp. cell

Comp. cell

Comp. cell

Comp. cell

Comp. cell

Comp. cell

Comp. cell

Comp. cell

Comp. cell

Comp. cell

Comp. cell

Comp. cell

Comp. cell

Comp. cell

In the game of life [START_REF] Gardner | The fantastic combinations of john conway's new solitaire game «life[END_REF], the state of a cell depends upon the previous states of its direct neighborhood. However there is some applications such as the class of stencil computation [START_REF] Datta | Stencil computation optimization and auto-tuning on state-of-the-art multicore architectures[END_REF] where not only the direct neighborhood are concerned but also some indirect neighbours matching a stencil. In the worst case, every cell needs to know the state of all its neighborhoods at a radius n. This operation requires a consequent exchange of data which would generate congestions on the network. NBA is a 2-dimensional propagation algorithm to simultaneously send a datum from every single cell to all their neighborhoods (up to a given radius). Thanks to the multicasting ability of the routers, a single datum is emitted once by its source cell and then broadcasted to all the other cells through the network. Informally, at the first micro-step, a router receives a datum on its local port. The datum is cloned and propagated on every port. Then, at the next micro-steps, the neighbours multicast the data straight, left, and to the local port so that after i micro-steps, all the routers at a Manhattan distance i from the source receive the data. The propagation edge forms a diamond shape as one can see on the first three pictures of Figure 2. The path from a given source to a given destination always follows one coordinate direction fully, then the other one. The data always turn left at this change of directions, i.e. counterclockwise. When a datum reaches a Manhattan distance n, the router that receives it sends it to its local port and left but does not propagate the data straight further.

On the third picture of Figure 2, the top-most, bottom-most, left-most, and right-most routers are at a Manhattan distance n(= 3) from the source. So on the fourth picture, the data are not propagated straight but left.

As a result, the northbound data spawns duplicated data that travel West (left of North) to reach all destination cells in the North-West quadrant. Similarly, the westbound data spawns duplicated data to the South-West quadrant, and so on.

The last thing to notice is that data traffics originating from North and South (resp. from East and West) never interfere in the same router. Northbound data only use up and leftward channels, southbound ones the down and rightward channels instead. So data processing along vertical directions (resp. horizontal) can be parallelized in the same micro-step. So the feeding rule is to alternate vertical and horizontal input channels.

Router

NBA is distributed amongst routers. It consists in a set of routing directives (the propagation rule) that every router follows. The resulting global behavior will be the one presented in Figure 2 but for every cell simultaneously.

Figure 3 presents the only four propagation patterns among all (modulo rotation) that are used to realize the NBA. In these four patterns, the datum is sent to the local port. In B and D, it is sent straight, lastly, in C and D it is multicasted on the left branch. As we have seen, a datum first travels on a direction fully and then turn left and travel on the secondary direction until the destination. When a datum has been emitted on vertical Inria ports (resp. horizontal ports), the main direction/coordinate is x (resp. y) and the secondary direction/coordinate is y (resp. x). The radius is denoted n.

The routing directives are the following:

1. At the first micro-step, a router broadcasts the datum from its local port in every direction, 2. At the even micro-steps, the North and South input ports are processed. At the odd micro-steps, the East and West input ports are processed. 4 Running the NBA

Performance analysis

NBA has been designed to be as fast as possible. For a radius n, NBA execution takes 2 * n * (n+1) micro-steps to complete. Every port of every router is in charge of a quadrant of size n × n + 1.

In Figure 2 the radius is 3 and the quadrant contains 12 cells. A port has to deal with one datum from each cell of its quadrant, one at each micro-step. Since horizontal (East, West) ports are sequential with vertical (North, South) ports, the completion time for a router is twice the time than for a single port. Finally, every router acts and terminates simultaneously so the completion time of a router is the one of the NBA. The capacity of the interconnection channels are derived from the following behavioral analysis. A capacity n for every channel is required. At the i t h stage of the execution, data from a Manhattan distance i are in the input channel of the router (see below for details). When i = n, the maximum is reached.

Step-by-step execution

Let us focus on the traffic generated at the input port of the routers while running NBA. First, it appears that the data arrive in the order of their Manhattan distance from their source. However, all the data with the same Manhattan distance does not come in the same order if we consider the vertical ports or the horizontal ports.

The evolution of the traffic can be divided in stages. The i st stage starts when the input channel of the studied port contains the data from a Manhattan distance i. The stage ends when all these data have been routed. As a indirect consequence, the channel contains at the end of the i st stage, the data from a Manhattan distance i + 1 but nothing else. Figure 4 shows which data are present in the channel at the beginning of each stage. Figure 4 focuses on the right top corner of a neighborhood with a raduis 5 (N 5 (r)). At the first stage, every router broadcasts the datum from their local port in every direction. Consequently, every router gets the data from its direct neighbours in each of its input port.

At the second stage, every router multicasts these data straight, left and to the local port because they come from a straight neighbour. At the end of the second stage, every router gets two data in each of its input port.

At the third stage, the first data in the channel has to be multicasted because it comes from a straight neighbour but the second should not. So it generates three data in each input port.

At stage n (Step 5 in Figure 4), each router receives a data from a straight neighbour at a Manhattan distance n. This data is propagated left but not straight. It correspond to the case (2.-(a)-i.) of the routing directives (Section 3).

At stage n + 1 onward, each router receives some data coming from the neighbours at a distance n relative to the main direction. These data are not propagated but only sent to the local port. However, the routers also receive some data that have to be forwarded straight but none of them is multicasted on the left any more.

In Figure 4, the six routers on the upper horizontal line are at a distance n from r relative to the main direction. The left most one is a straight neighbour. Table 1: N orth(r) and W est(r) for a neighborhood of radius 5.

Formally, let n be the radius of the neighborhood and r be a router. We give to r the South(r), East(r), and W est(r) are defined similarly to N orth(r). N orth(r) is given by Table 1.

South(r) is the same as N orth(r) except that the coordinates of the origins are the exact opposite of the ones in N orth(r).

Formally ∀ x y ∈ N orth(r) at position i, ∃ -x -y ∈ South(r)
at position i. East(r) can be computed from W est(r) with the same transformation. Table 1 also presents W est(r). Here we choose to put the main coordinate (i.e. y) on top to enhance the similitude with N orth(r). For the same reason, the second value is -x instead of x.

The order of arrival of the data in W est(r) inside a stage is the exact opposite of N orth(r).

For instance, 0 2 followed by 1 1 in the second and third position of N orth(r) but 1 1 followed by 0 2 in the second and third position of W est(r). This order inversion occurs because the feeding rule of the routers gives priority to the vertical ports at the expense of the horizontal ones.

Static scheduling of router

Table 1 gives the status of the channel in input of a router step by step. Therefore, the behavior of the routers is predictable and can be computed statically. The following algorithm generates the sequence of Table 1 but for any radius n. A similar algorithm can be written for the other ports of the router.

Algorithm 2 computes N orth(r) for any given router r and radius n Input : a radius n.

Output : N orth(r) for any router r. N orth(r) = for sum from 1 to 2n do for x from (sum <= n)?0 : sum -n to j < sum and j ≤ n do N orth(r).append( x sum -x )

end for end for return N orth(r)

From the sequence generated with Algorithm 2, the propagation rule can be symbolically applied on any given ordered list of data such as N orth(r) and one can generate the sequence of decisions that every router shall take to correctly route such data. Figure 5 gives the internal crossbar of a router for a radius 5. The crossbar connects the inputs on the left side of the figure to the outputs on the right side. The connections to the computation cell are at the bottom.

From left to right, the first demultiplexer says when a data has to be forwarded straight. The sequence of decisions is given as a binary word. Concerning the data from the North, the first tenth data are forwarded, the eleventh is not, and so on. The second demultiplexer says when a data should be forwarded left. Concerning the data from the West, the first one comes from a straight neighbour and thus is forwarded. The second is not and the third is. See Table 1 to match the complete sequence.

Experimental results

We have implemented the NBA in SystemC [START_REF]Accellera. System c[END_REF]. Our implementation is composed of:

• a module Cell which implements the structure and the behavior of a computation cell. Initially, it sends its state and then collects the states from the other cells in its neighborhood. When it has got all the data, it computes its new state and, at the next micro-step, re-sends its state.

• a module Router which implements the structure and the behavior of a router, namely the NBA.

• a module CA which is a torus with a parametric size composed of cells (router + computation cell).

The propagation rule has been implemented in two ways. First, we have implemented the dynamic routing directives given in Section 3. Secondly, these routing directives has been replaced by the static patterns given in Figure 5. The overall behavior of the system is the same whatever option has been selected. This experiment consolidates the fact that the propagation rule for a given application can be computed analytically upfront as static decisions and then inserted into the routers.

Inria

Stencil applications

We have also extended the experiments to the more general case of stencil applications [START_REF] Datta | Stencil computation optimization and auto-tuning on state-of-the-art multicore architectures[END_REF][START_REF] Datta | Auto-tuning the 27-point stencil for multicore[END_REF]. Stencil applications are a class of distributed applications where the new state of a cell depends of the current state of some of its neighbours. The map which says which neighbours are concerned and which others are not is called a stencil. Stencil applications are massively used in scientific computation.

In our implemetation, the stencil is given as a odd square matrix of booleans where the middle entry represents the concerned node. The other entries represent its neighborhood. The boolean says whether the state of the corresponding neighbor is required or not. Every router is aware of the stencil and routes the data with respect to their origin.

We ran many case studies where each stencil is characterized by the number of neighbors it involves and the moore distance to the farest neighbor. Table 2 relates the number of micro-steps required to route all the data with respect to the different cases (The number of neighbors in each stencil is noted N ). Again, whatever is the shape of the stencil, the dynamic routing conditions can be replaced by static pattern which are the same in every router. Similarly to the NBA, a pattern represents the sequence of decisions to route the data required for the current computation step. The next computation step of the stencil application repeats the same behavior.

\ N = 4 N = 8 N = 16 N = 24 N = 32 N = 48 || x|| ∞ ≤ 1 2 4 - - - - || x|| ∞ ≤ 2 4

Conclusion

In the classical model of Cellular Automata (CA), the communications between cells are assumed to be instantaneous. However if we consider the possible implementation of a 2-dimension CA on a many-cores system-on-chip, the communications take time. In order to prepare such implementation, this paper has presented a refinement of the classical model of CA where the exchance of data between cells is time-consuming. The focus is given on routing the data through the communication topology.

Every step of the global clock (the one of the classical synchronous CA) is refined as a sequence of micro-steps during which the data from each cell travels through the underlying topology toward its destination. To ensure the routing of data, each cell is augmented with routing capabilities and so is divided in the original computation cell plus a router.

In order to compute the next state of the cells when it depends upon all the neighboors up to a Moore distance n, we have proposed the Neighborhood Broadcasting Algorithm (NBA) to simultaneously broadcast the state of every cell to their respective neighborhoods. We have studied the NBA and deducted that the propagation rules in every router can be expressed as either dynamic on-line or static off-line decisions.

To go further in this scope, we would like to challenge some of the assumptions we took initially. First, our approach is limited to CA that can be seen as infinite unfolding of a spatial periodic state structure. Our approach considers that the size of a tile (a spatial periodic state structure) is less or equals to the size of the the Network-on-Chip (NoC). However, NoC size are often limited to 64 up to 128 nodes but tiles can be much bigger. By extention, we consider that the physical topology (of the NoC) matches with the topology of the CA. One could consider the mapping of a n-dimension CA on a m dimension NoC. Lastly, we consider only synchronous CA but one can consider the same challenge, routing data through the communication topology in the asynchronous CA.

Figure 1 :

 1 Figure 1: A 2-dimensional CA with bidirectional channels.

Figure 2 :

 2 Figure 2: The broadcasting pattern from a single node.

Figure 3 :

 3 Figure 3: The three data propagation patterns for the all-to-all propagation algorithm.

( a )

 a If the data comes from a straight neighbour (the secondary coordinate equals 0) : i. If the data comes from a distance n relative to the main direction, it follows Pattern C of Figure 3. ii. If the data comes from less than a distance n relative to the main direction, it follows the Pattern D of Figure 3. (b) If the data does not come from a straight neighbour : i. If the data comes from a distance n relative to the secondary direction, it follows the Pattern A of Figure 3. ii. If the data comes from less than a distance n relative to the secondary direction, it follows the Pattern B of Figure 3.

Figure 4 :

 4 Figure 4: The origin of the data in input of the North port of a router r stages after stages.

coordinate 0 0 .

 0 The coordinates iterate positively toward resp. the North and East. Let Inria N orth(r) be the ordered list of data going through the FIFO channel in input of the North port of r. N orth(r) of the source of the first data entered in the channel and x y are the coordinates of the second. Initially, N orth(r) = [∅].

Figure 5 :

 5 Figure 5: The internal crossbar of the router with the switching conditions.

Table 2 :

 2 Experimental results of routing duration for stencil applications

			4	12	16	-	-
	|| x|| ∞ ≤ 3	6	8	18	18	18	24

RR n°8051


Emmanuelle Rouillé
email: erouille@sodifrance.fr

Benoît Combemale
email: benoit.combemale@irisa.fr

Olivier Barais
email: olivier.barais@irisa.fr

David Touzet
email: dtouzet@sodifrance.fr

Jean-Marc Jézéquel
email: jean-marc.jezequel@irisa.fr

Leveraging CVL to Manage Variability in Software Process Lines

Variability on project requirements often implies variability on software processes. To manage such variability, Software Process Lines (SPLs) can be used to represent commonality (i.e., common practices) and variability (i.e., differences) of a set of related software processes. To this end, some Software Process Modeling Languages (SPMLs) natively integrate variability mechanisms. Nevertheless, such a coupling between the SPML and the variability mechanisms i) requires to interpret the requirements variability in terms of the processes variability, ii) limits the reuse of the requirements variability for other purposes (e.g., the development itself), and iii) is a barrier to the use of advances from the field of variability management. In this paper, we propose an approach to apply the Common Variability Language (CVL from the OMG consortium) for requirement variability modeling and its binding to the processes. This work is illustrated on a family of industrial Java development processes. Our approach enables the definition of an SPL and the automatic derivation of a process from this SPL according to the requirements of a given project. The variability is managed separately from the process model and benefits from existing tools coming from process modeling community and CVL.

I. INTRODUCTION

A software development process captures the sequence of steps to perform in order to realize a software engineering project. Processes are a mean for capturing the know-how that companies acquired during projects. Inherent variability on project requirements often implies variability on software processes that are still complex to capture. Moreover, the more variants of a software artifact there are, the more the management of variability reduces development costs and time to market [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF]. This is also true in context of processes. Some approaches for modeling process variability and for enabling the reuse of process model rely on Software Process Line Engineering (SPLE) [START_REF] Rombach | Integrated software process and product lines[END_REF]. Indeed, SPLE enables the definition and reuse of common and variable parts between processes. These approaches also use the Model-Driven Engineering (MDE) in order to define a Software Process Line (SPL), which is a set of processes that captures commonalities and variabilities between these processes [START_REF] Ternité | Process Lines: A Product Line Approach Designed for Process Model Development[END_REF]. However, existing contributions are dependent of a process metamodel. Indeed, some of them modify a process metamodel with a variability concern, in order to model places in processes that vary and the possible variations. This prevents the reuse of the variability concern with other process metamodels without adapting it. This also requires the development of new tools (e.g. tools for process modeling, execution, checking) for managing the modified process metamodel. Other contributions do not modify the process metamodel but transform the process model into a pivot structure that captures the variability concern. These contributions are also dependent of the process metamodel because they require the definition of a transformation for each process metamodel. We still miss an approach for automatically reusing processes according to projects requirements that is independent of the process metamodel.

As stated in the specification of the Common Variability Language (CVL) 1 , CVL is a "domain-independent language for specifying and resolving variability". Therefore, CVL would address this limitation. Indeed, CVL is an OMG2 standardization effort for the product lines definition. It enables to reference process elements defined in every process model whose metamodel conforms to the Meta-Object Facility (MOF) 3 metametamodel and it provides operators to specify how to derive a process.

In this article we answer the following research questions:

1) Rq1: how to use CVL in the context of processes? 2) Rq2: does CVL enable the management of processes variability? 3) Rq3: is CVL independent of the process metamodel?

To answer these research questions, we lead an experiment with Sodifrance4 , a software and computing services company. Sodifrance performs different kinds of projects that are development, modernization and software maintenance projects. This experiment consists in modeling and/or refactoring existing software development processes to enable their reuse according to commonalities in projects requirements. For this experiment, we use the Software Process Engineering Metamodel (SPEM) 2.0 [START_REF] Omg | Software and Systems Process Engineering Metamodel Specification (SPEM) Version 2.0[END_REF] as process metamodel. Indeed, SPEM 2.0 is an OMG standard and commercial modelers exist. However, we could choose any other process metamodel according to one's needs and preferences. We perform this experiment and illustrate our approach on a process line of Java development processes.

This paper is organized as follows. Section II presents our illustrative example. Section III presents SPEM 2.0 and CVL. Sections IV, V and VI respectively answer the research questions rq1, rq2 and rq3. Section VII presents the related work. We conclude in Section VIII.

II. ILLUSTRATIVE EXAMPLE

In this section, we present a simplified Java development process of the Sodifrance company as an illustrative example.

A. The Most Often Used Java Development Process

The most often used Java development process of the Sodifrance company is as follows. During the first task, the customer produces a specifications document defining the technical and functional specifications of the application to develop, according to the project's requirements. The following task, the development, consists of manually writing the Java code of the application. It takes as input the specifications document and produces as output the Java code. During the tests task, the developers test the application under development. If there are errors, then the process flow goes back to the development task in order to correct the errors. If there is no error, then the process flow goes to the production task, which consists of deploying the application on the customer environment. During the development task, the developers have to use the Eclipse IDE and a version control system, which is SVN in this example. They also use MySQL as database during the development task. Modelling the process permits to create the initial configuration of a new project: building eclipse IDE, generating the maven project object models, initializing the source code repository, . . .

B. Variability in the Java Development Process

There are variants of the Java development process. For instance, if the customer uses Oracle as database, then developers will use Oracle instead of MySQL. If there is no data to persist, then there is no database. If the customer provides the specifications into a formal language (e.g., UML 2.x), then a code generation task occurs before the development task. It consists of generating the code which is similar for all the entities of the application. It produces some generated Java code as output. When the code generation task occurs, then the development task takes the generated Java code as additional input and consists of manually writing the non generated code.

III. BACKGROUND

In this section, we present SPEM 2.0 and CVL.

A. SPEM 2.0

We use the SPEM 2.0 process metamodel to model the Java development process example. The SPEM 2.0 specification defines a metamodel whose general idea is that roles perform activities, that take work products as inputs and outputs. The peculiarity of SPEM 2.0 is that it separates the definition of the process elements (the method content) from their use into processes (the process structure).

Figure 1 shows an extract of the SPEM 2.0 metamodel we use in the following. However, one can use every SPEM 2.0 concepts with our methodology.

The method content part contains method content elements (MethodContentElement) for defining role definitions (RoleDefinition), that perform task definitions (TaskDefinition), using a tool definition (ToolDefinition). A task definition uses work product definitions (WorkProductDefinition) as inputs and outputs.

The process structure part contains work breakdown structures (BreakdownElement and WorkBreakdownElement) and structures for describing workflows (Activity, Process and DeliveryProcess). A delivery process (DeliveryProcess) describes a complete project lifecycle. An activity (Activity) is a container for breakdown elements (BreakdownElement). Subtypes of the class named MethodContentUse use subtypes of the class named MethodContentElement through corresponding references. A role use (RoleUse) performs a task use (TaskUse), which uses a work product use (WorkProductUse) as input or output. The parameter type (attribute named parameterType) of a process parameter (ProcessParameter) defines a work product use of a task use.

We use UML 2 [START_REF]Documents Associated With UML Version 2.0[END_REF] activity diagrams to model the flow of task uses because the class named TaskUse is a stereotyped UML 2 Action.

Figure 2 shows the concrete syntax we use to represent SPEM 2.0 and activity diagram model elements.

Figure 3 shows the SPEM 2.0 model of the most often used Java development process of our illustrative example.

B. CVL

We use CVL to define an SPL and automatically derive a process according to the project's requirements from this SPL. Figure 4 summarizes CVL and illustrates it in the context of processes. CVL proposes to define a base model, which is an instance of any metamodel conforming to the MOF. The base model is a base process model in our case. Then, CVL provides constructs to capture the variability (the Variability Abstraction Model (VAM)). For instance, the VAM specifies the projects requirements variability. CVL also provides constructs to define the realization of this variability on the base model (the Variability Realization Model (VRM)). The VRM is the original part of CVL. It allows designer to explicit the mapping between the VAM (that can be compared to a feature model) and the assets (the base model). In this mapping, the VRM defines which base model elements are impacted with a specific variation point but also how these base model elements are impacted. CVL provides in the VRM several types of variation point that capture the derivation semantics. The main benefits of this model is the ability to capture the variability requirement in the VAM and its materialization in the base model using the VRM. In our case, the VRM defines a binding between the projects requirements variability and the processes variability. CVL provides constructs to resolve CVL can be executed. A CVL model composed of a VAM, a VRM and a RM contains enough information to provide a resolved base model without variability. The resolved model is thus another instance of the metamodel that the base model conforms to. In our context, the resolved model is a resolved process model. Thereafter, we present the CVL metamodel according to its three parts (variability abstraction, variability realization and resolution). Figure 5 details the excerpt of the CVL metamodel that we use in the following.

The variability abstraction part defines variability through variability specifications (VSpec). A variability specification can be a choice (Choice), i.e. a feature that will belong or not to the resolved model depending on whether it is resolved to true or false. A variability specification may contain children. Children can be resolved to true only if their parent is resolved to true. A variability specification also has a group multiplicity (groupMultiplicity) defining the minimal and maximal (attributes named lower and upper of the class Figure 5: Excerpt of the CVL metamodel named MultiplicityInterval) numbers of direct children that can be resolved to true. If a choice is implied by its parent (attribute named isImpliedByParent equals true), then it must be resolved to true if its parent is resolved to true, expressing a mandatory feature. The variability abstraction model provides the same expression power than a feature model. Xor, Card, Or, Alt, or Mandatory can be expressed using the groupMultilplicity reference and the isImpliedByParent attribute.

The variability realization part defines the variation points (VariationPoint), that are operations to perform on the base model in order to derive a resolved model. A variation point is performed when its binding variability specifications (bindingVSpecs) are resolved to true. CVL defines several types of variation points. Each of them can be seen as a reusable function that can be applied on the base model during the derivation. Among variation points, an object substitution (ObjectSubstitution) replaces an object of the base model, the placement object (placementObject), by another one, the replacement object (replacementObject), and deletes the placement object. A link assignment (LinkAssignment) sets a reference of the base model, the link end identifier reference, to a new end (newEnd). A link object (link) contains the reference, identified by its name (linkEndIdentifier). An object existence (ObjectExistence) specifies that an optional object (optionalObject) of the base model will still exist in the resolved model. The optional object is removed from the resolved model if at least one binding variability specification is resolved to false. Thus, object existences execute in negative variability. This means that the objects belong to the base model if they belong to a configuration. They are deleted during derivation if they do not belong to the selected configuration. On the contrary, positive variability means that all the objects are not in the base model and they are created during derivation. The link handle (LinkHandle) and the object handle (ObjectHandle) model elements reference an object of the base model through their attribute named MOFRef, which corresponds to the URI of the object to reference.

The resolution part contains choice resolutions (ChoiceResolution) that resolve their resolved choices (resolvedChoice) to true or false.

Figure 6 shows the concrete syntax we use to represent the CVL model elements.

We now detail the part of the derivation algorithm which is useful to understand the example of Section IV. The CVL derivation engine performs each variation point whose binding variability specifications are resolved to true. The derivation applies on a copy of the base process model. To perform a link assignment, it retrieves from the base process model copy the link object. If its link end identifier reference has a upper bound of one, it updates the link end identifier reference to the new end. If the link end identifier has an infinite upper bound, it adds the new end to the list of links that instantiate the link end identifier reference. To perform an object substitution, it retrieves from the base process model copy the placement object and applies all its incoming references to the replacement object. It then deletes the placement object from the base process model copy. For an object existence, the derivation engine removes the optional object from the base process model copy if at least one of the binding variability specifications of the object existence is resolved to false. Finally, it serializes the modified copy of the base process model into a new file, giving the resolved process model. Our implementation of the CVL derivation engine relies on the Eclipse Modeling Framework (EMF) 5 API to load, manage and save the models 6 .

IV. APPROACH

In this section, we answer rq1 by presenting our approach to use CVL in the context of processes. Figure 7 shows an overview of this approach. It involves two roles: a process expert, who knows the different processes of a company and their context of use, and an engineer, who is involved into a project and needs a process specific to this project. The process expert captures the requirements variability and its binding to the SPL (steps 1 to 3). Then, the engineer automatically derives a process from this SPL according to the requirements of a given project (steps 4 and 5). Steps 4 and 5 occur each time the engineer wants to derive a process. In our approach, the process expert and the engineer use the CVL tooling to perform steps 2 to 5. Any SPML can be used to perform step 1, even if we focus in this paper on the use of SPEM. Our approach preserves the separation between projects requirements and processes. It also directly binds projects requirements to processes, instead of interpreting requirements variability in terms of processes variability. In Figure 6: CVL concrete syntax Figure 7: Overview an approach using CVL to bind the requirements variability to the process variability the following of this section, we detail the different steps of our approach, ranging from the SPL definition to the process derivation. We illustrate them thanks to the illustrative example introduced in Section II.

A. The SPL Definition 1) Methodology for Process Elements Modeling (step 1): This step allows the process expert to model the process elements required to define the expected family of processes. The process expert performs this step using any modeler based on its favorite SPML.

The process expert first models the most often used process of the company into a base process model (called base model in CVL). Then, the process expert provides all other process elements that do not belong to the most often used process (called external process elements). These external process elements are added in the same base process model, without linking them to the most often used process. Even if several processes use the same external process element, it is modeled only once in the base process model. Consequently, when a process element common to several processes evolves, it has to be updated only once. The different processes that use an external process element often require different settings of the properties of this external process element. In this case, the process expert only sets the properties as the most often used of these processes requires.

Using SPEM 2.0 as SPML, the process expert starts by modeling the method content elements upon which the most often used process and the external process elements will be defined. The process expert then models the most often used process and the external process elements in different delivery processes. This way, there is no operation to perform on the Figure 8: Method content elements of the illustrative example base process model to derive the most often used process. Indeed, in SPEM 2.0, a process describing a complete project life cycle is described into a delivery process, and there the most often used process is already described in a delivery process.

While Figure 3 shows the most often used process of our Java development process example, Figure 8 shows the corresponding method content elements. As for the external process elements, we model only their properties that correspond to the most often used process that uses these method content elements. For instance, we model that the task definition named Development uses the tool definition named MySQL and not the Oracle one.

Figure 9 shows the process fragment representing the external process elements of the Java development process example. Note that the outgoing control flow from the task use named Code generation is invalid w.r.t the metamodel since it does not have any target. Nevertheless, this control flow is useful because getting a Java development process with ) do not enable the modeling of invalid process elements, we rely on approaches that handle model fragments (e.g., [START_REF] Ramos | Matching model-snippets[END_REF]) for such a purpose.

2) Projects Requirements Variability Specification (step 2): In the second step of our approach, the process expert uses the CVL variability abstraction metamodel to specify the projects requirements variability in the VAM.

The right part of Figure 10 shows the VAM of the requirements for the different Java development projects of our illustrative example. A project uses a database or not, and if yes, it is either a MySQL one or an Oracle one. Moreover, a project uses code generation or not to produce the code of the application to deliver.

In addition to the concepts used in the illustrative example, CVL enables the specification of variability about the number of fragment instances. Furthermore, CVL enables the expression of constraints on the variability resolution that are not in a parent-child relationship. To this end, CVL provides the way to express constraints using first order logic (including universal and existential quantifications), as well as arithmetic constraints. CVL also enables to automatically infer the resolution of variability specifications from the resolution of other variability specifications, according to the constraints imposed on their resolution.

3) Projects Requirements and Processes Binding (step 3): In the third step of our approach, the process expert defines in the VRM the binding between projects requirements variability (the VAM defined in step 2) and processes (the base model defined in step 1).

The center part of Figure 10 shows the VRM of our illustrative example. This VRM specifies the configuration of a delivery process used by an engineer according to the possible requirements. The activity named Java development process represents the delivery process of the most often used process. For a project with a MySQL database and without code generation, the VRM does not modify the delivery process that contains the most often used process (cf. Figure 3). For a project with an Oracle database, it replaces the tool definition named MySQL by the one named Oracle. For a project without database, it deletes the tool definition named MySQL. For a project with code generation, the VRM adds the task use named Code generation, its outgoing control flow, In addition to the concepts used in the illustrative example, CVL provides various constructs to specify the VRM that are useful in the context of processes. A construct assigns the value of an attribute of a process element (slot assignment). Some constructs specify the existence of an attribute or of a link of a process element (slot value existence, link existence). Constructs enable to specify a value to assign or an object to substitute into the RM (parametric link assignment, parametric slot assignment, parametric object substitution). These constructs are useful when the process expert does not know the variants of a process element at the time of the VRM's edition. Some constructs replace a process fragment by another one (fragment substitution, repeatable fragment substitution) and create several instances of a process fragment (repeatable fragment substitution). Figures 11a and11b respectively illustrate a fragment substitution and a repeatable fragment substitution. On the other hand, some process metamodels enable the reuse of objects. For instance, SPEM 2.0 introduces the notion of process pattern, which factorizes a process fragment common to several activities. Then, these activities can reuse this process pattern. When a process pattern contains variability, different activities can require different resolutions of this process pattern to reuse it. However, an activity cannot reuse a resolved process pattern if it is not resolved appropriately. This problem applies to any object that contains variability and that is reused with different variability resolutions in a model. The CVL specification calls such an object a configurable container object. To this end, CVL introduces constructs that specify a configurable container object (configurable unit) and that clone the configurable container object, resolve variability on the clone and finally redirect the link of the base model object (that uses the resolved clone) to the resolved clone (configurable unit usage). Figure 11c illustrates the configurable unit and configurable unit usage variation points with the example of process patterns. Finally, the process expert can define new variation points using a model to model transformation (opaque variation point).

B. Process Derivation According to the Requirements of a Project 1) Projects Requirements Variability Resolution (step 4):

The engineer uses the CVL resolution metamodel to select in an RM the requirements of a given project among those that the VAM specifies. We refer to this action as projects requirements variability resolution. The right part of Figure 10 also shows an RM for a Java development project that requires code generation and no database (see √ for the choices selected by the engineer and X for the implicitly unselected ones) .

2) Automatic Process Derivation (step 5): Finally, the last step of our approach consists in automatically deriving the process corresponding to the requirements of a given project. For this purpose, we use the CVL derivation engine to allow an engineer to derive a new process model from the base process model (step 1), and according to the requirements selected in the RM (step 4), and the variability realization captured in the VRM (step 3). This step produces a resolved process model.

Figure 12 shows the resolved process model corresponding to the RM depicted in Figure 10. In the resolved process model, the CVL derivation engine has deleted the database and it has introduced the code generation task to the most often used Java development process.

If there are unlikely recurrent project specific needs, the engineer can manually adapt the derived process to these needs. Indeed, there is no need to capitalize on project specific needs into the process line if they are unlikely recurrent.

V. USE OF CVL TO BRIDGE THE GAP BETWEEN THE REQUIREMENTS VARIABILITY AND THE PROCESSES VARIABILITY In this section, we answer rq2 by discussing the capacity of our CVL-based approach to capture the processes variability according to the requirements variability.

According to our approach, the VAM captures the requirements variability, while the VRM specifies the binding between the requirements variability and the base process model. These three models (VAM, VRM and base process model) thus constitute the definition of an SPL.

Then, CVL allows an engineer i) to select the requirements of a given project in a realization model (RM), and ii) to automatically derive a process model from a given RM and the base process model. In our illustrative example, we were able to capture the requirements of 384 Java development projects of the Sodifrance company and their corresponding processes. The Sodifrance's Java development projects vary on the version control system (SVN or CVS), the database (MySQL, Oracle, Postgresql, or no database), the GUI framework (Struts, JSF, Flex, or GWT), the build tool (Ant or Maven), the development (with code generation or not) and the delivery (delivery of the source code, of the compiled code or installation of the application on the customer environment by a Sodifrance engineer). Following our approach, the SPL is composed of 86 model elements (48 SPEM process elements, 21 Variability Specifications and 17 Variation Points). In comparison, the modeling of the different processes in extension (i.e., without factorizing the common parts between processes) would have required the modeling of 384 processes, each of them made of at least 30 process elements. Thus, it would have led to the modeling of at least 11 520 process elements.

Basic Feature Models (BFMs) [START_REF] Kang | Feature-Oriented Domain Analysis (FODA) Feasibility Study[END_REF] and Orthogonal Variability Models (OVMs) [START_REF] Pohl | Software Product Line Engineering: Foundations, Principles and Techniques[END_REF] would also enable the specification of the projects requirements variability thanks to a dedicated variability model. However, they do not provide a mechanism to link the variability model (here, the requirements) to the design models (here, the processes). On the contrary, the VAM enables the capture of the requirements variability and the VRM enables to directly reflect this variability on processes.

VI. USE OF CVL INDEPENDENTLY OF PROCESS METAMODEL

In this section, we answer rq3 by analyzing the independence promoted by CVL with respect to the metamodel on which it is used (in our case, SPEM).

Since uses a string in the object handle and the link handle to reference a model element, CVL is independent of the language on which it is applied. Nevertheless, we observe that the CVL derivation operator can produce an invalid resolved process model, while the VAM, the VRM and the RM are valid. In the following, we identify the possible sources of such an invalidity, and we classify them according to the way to prevent them.

The first errors we observe occur during assignments (i.e., link assignment, slot assignment, parametric link assignment, parametric slot assignment) or substitutions (i.e., object substitution, parametric object substitution, fragment substitution, repeatable fragment substitution) that do not respect the type compatibility with the base model. These possible errors constitute the first category we have identified. These errors arise because CVL does not constrain the specification of the VRM according to the metamodel to which it applies. Nevertheless, the use of CVL could be forced by constraints generically expressed on its metamodel, thus ensuring the validity of the VRM with respect to the resolved models. For example, the type compatibility mentioned above in the context of a link assignment could be avoided by using the following constraint expressed with the Object Constraint Language (OCL) [START_REF] Omg | Documents associated with Object Constraint Language, Version 2.2[END_REF] on the CVL metamodel: The second error is when there are dandling references in the resolved model, i.e. when a link refers to an object that does not exist anymore. This occurs during an object existence, when an object is deleted but not its incoming links. In order to avoid this error, the following constraint must be satisfied: when an object is deleted, its incoming links must be deleted. A link existence enables the deletion of the incoming links. We are going to see in the following paragraph the error related to the link existence and how to avoid it.

The third error concerns the non-respect of the multiplicity of a reference. For instance, when a reference with a lower bound of n and a upper bound of p is instantiated by m links, with m < n or m > p. This occurs when a (parametric) link assignment (respectively a link existence) creates (respectively deletes) a link that makes the number of links instantiating a reference greater (respectively lower) than the upper (respectively lower) bound of this reference. This also occurs during a fragment substitution, because CVL enables the assignment of new outgoing and incoming links to the replacement fragment, as well as the deletion of existing links, without ensuring the respect of the multiplicity of the references that the links instantiate. Moreover, the error occurs during a repeatable fragment substitution, when the incoming links to which the replacement fragments are bound cannot reference as much replacement fragments as the RM defines. Finally, this occurs during a configurable unit usage, when the container of the configurable container object cannot contain as much configurable container objects as the ones that are created by configurable unit usages. In order to avoid this error, constraints must be satisfied. A new link can instantiate a reference whose upper bound is strictly upper than one only if the number of links already instantiating this reference is strictly lower than the upper bound of the reference. A link can be deleted only if the reference it is instantiating before its deletion has a number of links strictly upper than its lower bound. A process fragment can be duplicated only if its incoming links can also be duplicated while ensuring the respect of the multiplicity of the reference they instantiate. For a configurable unit usage, the container of the configurable container object must be able to contain one more configurable container object.

The second and third errors constitute the second category we have identified. These errors occur because CVL does not constrain the specification of the VRM according to the base model to which it applies and according to the metamodel of the base model. A solution to ensure the constraints of the second and third errors would be a generic static analysis tool that would check before the derivation if the constraints are satisfied. By generic we mean metamodel independent. If the constraints are not satisfied, the tool would inform the engineer of the error, of the variation point that introduces it and of the constraint that is violated. Then, the process expert and the engineer would have to correct the errors to start the derivation.

The fourth error is when the resolved process model conforms to its metamodel but is semantically inconsistent. Figure 13 illustrates this error. In SPEM 2.0, a work sequence specifies the dependencies about the execution of activities. The work sequence of kind finishToFinish means that the activity named B can finish when the activity named A finishes. The work sequence of kind finishToStart means that the activity named B start when the activity named A finishes. Here the work sequence of kind finishToFinish is useless. In order to avoid this error, we must ensure that there is no semantic inconsistencies in resolved process model. This fourth kind of error constitutes the third category we have identified. As for the second category, these errors also occur because CVL does not constrain the specification of the VRM according to the base model to which it applies and according to the metamodel of the base model. However, in this case, the errors are specific to a metamodel and cannot be generalized. A solution would be to implement a SPEM-specific derivation engine. It would ensure during derivation that SPEM-specific constraints are satisfied, on top of performing the same operations than the CVL derivation engine. When a SPEM-specific constraint is not satisfied, the SPEM-specific derivation engine would inform the engineer of the error, of the derivation step that has introduced the error and of the constraint that is violated. One approach for reusing processes provides a technique for the retrieval of processes stored into a repository [START_REF] Lu | On the Discovery of Preferred Work Practice Through Business Process Variants[END_REF]. The Debus-Booch prototype [START_REF] Song | Engineering Software Design Processes to Guide Process Execution[END_REF] enables to select a software design process from a family of such processes and to execute it. These approaches define the different processes in extension. Therefore, when a part common to several processes evolves, it has to be updated in all the processes it belongs to, is error prone and time consuming.

The following approaches address this problem by defining an SPL, in order to model places in processes that vary and the possible variations. However, they are dependent of the process metamodel because they modify the process metamodel with variability mechanisms. In the field of software processes, one approach relies on the variability mechanisms that SPEM 2.0 provides in order to model a general process model with variability [START_REF] Hurtado Alegría | An MDE Approach to Software Process Tailoring[END_REF]. The vSPEM approach [START_REF] Martínez-Ruiz | Towards a SPEM v2.0 Extension to Define Process Lines Variability Mechanisms[END_REF] extends SPEM 2.0 with variability mechanisms empirically evaluated as more understandable [START_REF] Martínez-Ruiz | Modelling Software Process Variability: an Empirical Study[END_REF]. Still in the field of software processes, another approach [START_REF] Ternité | Process Lines: A Product Line Approach Designed for Process Model Development[END_REF] provides a metamodel for an SPL, that must be specialized according to the process metamodel and the variability to capture. In the field of business processes, approaches extend the Event-driven Process Chain (EPC) process metamodel to model variability into an EPC reference process. The reference process captures all the different processes using conditional branching. Configurable EPC (C-EPC) [START_REF] Rosemann | A Configurable Reference Modelling Language[END_REF] expresses variability on the functions and connectors EPC model elements. The approach in [START_REF] Rosa | Beyond Control-Flow: Extending Business Process Configuration to Roles and Objects[END_REF] extends C-EPC with the concepts of role and object and specifies variability on these concepts. Aggregate EPC (aEPC) [START_REF] Reijers | Improved Model Management with Aggregated Business Process Models[END_REF] links process elements to the configurations that use them. The PROcess Variants by OPtions (Provop) approach [START_REF] Hallerbach | Capturing Variability in Business Process Models: the Provop Approach[END_REF] copes with the non distinction between branching nodes that are part of a process and the ones that denote different processes in a reference process. It proposes to model one process and the operations to perform on it to derive the different processes. Still in the field of business processes, approaches [START_REF] Kulkarni | Business Process Families Using Model-Driven Techniques[END_REF], [START_REF] Schnieders | Variability Mechanisms in E-Business Process Families[END_REF] extend the BPMN metamodel for modeling places where variability occurs in processes and their possible resolutions. Another approach [START_REF] Derguech | Reuse-Oriented Business Process Modelling Based on a Hierarchical Structure[END_REF] captures process variability into a hierarchical structure and provides support for variant process elements management and reuse. Other approaches [START_REF] Gottschalk | Configurable Workflow Models[END_REF]- [START_REF] Santos | A Goal-Oriented Approach for Variability in BPMN[END_REF] partially address the problem of the dependence towards the process metamodel by transforming a process model into a pivot structure to define variability. However, these approaches require the definition of a transformation for each process metamodel. Finally, the Adaptive Business Process Modeling in the Internet of Services (ABIS) approach [START_REF] Weidmann | Adaptive Business Process Modeling in the Internet of Services (ABIS)[END_REF] introduces constructs for managing variability in BPMN 2.0 processes without modifying the BPMN 2.0 [START_REF] Omg | Documents Associated with Business Process Model and Notation (BPMN) Version 2.0[END_REF] metamodel. This approach is also dependent of the process metamodel. Indeed, the variability constructs need to be adapted in case of the use of another process metamodel.

The following approaches specify variability independently of the process metamodel. However, they do not provide all the mechanisms for automatically deriving a process. One approach [START_REF] Simmonds | Modeling Variability in Software Process Lines[END_REF] proposes to model process variability separately from the process model, using BFMs or OVMs. However, BFMs do not provide a binding mechanism between the BFM and the process model. OVMs provide a binding mechanism with the model for which variability is specified (e.g., the process model). However, this binding mechanism implies modifying the metamodel of the model for which variability is specified. Furthermore, OVMs do not provide a mechanism to automatically derive a process. Other approaches are similar to ours. One approach [START_REF] Simidchieva | Representing Process Variation with a Process Family[END_REF] proposes to model one process and to augment it with process elements selected according to a process goals specification, in order to obtain a particular process. The notion of process goals specification is close to our notion of requirements of a project. Our approach goes further by providing mechanisms to automate the derivation of a process according to the requirements of a project. Another [START_REF] Rosa | Questionnaire-driven Configuration of Reference Process Models[END_REF] provides a questionnaire-driven method for selecting a process from a reference process model. Actions are performed on the reference process model to derive a process according to the answers to the questions. Our approach goes further by providing a language to define actions on process models whatever their metamodel is.

To conclude, approaches for reusing processes to our knowledge either define the different processes in extension, or are dependent of the process metamodel, or do not provide all the mechanisms for automatically deriving a process.

VIII. CONCLUSION AND PERSPECTIVES

We propose an approach to use CVL in the context of processes and we perform an experiment (i) to understand how to use this new variability modeling language in this context, (ii) to discuss if CVL enables the management of processes variability, (iii) and to discuss if CVL enables the management of processes variability while being independent of the process metamodel. The lessons learned from this experiment are mainly that CVL enables the definition of an SPL and the automatic derivation of a process from this SPL according to the requirements of a project. CVL is also independent of the process metamodel, but this can be a source of errors in the resolved process model.

Using CVL to model process lines has the advantage of being independent of the process metamodel. This enables the reuse of the approach with every process metamodel as well as the reuse of process metamodel specific tools. The current limitation of the use of CVL for modeling process lines is that models are difficult to edit and maintain. Indeed, processes other than the most often used one are not visible in the SPL due to the structure of the base process model and the variability management. Implementing a tool that enables processes and variability modeling into the same diagram would address this limitation.

As perspectives of work, we are implementing a generic static analysis tool and a derivation engine plugin for SPEM, in order to automatically ensure the satisfaction of the constraints for deriving a valid resolved process model.

Figure 1 :

 1 Figure 1: Excerpt of the SPEM 2.0 metamodel

Figure 3 :

 3 Figure 3: Illustrative example: most often used Java development process

Figure 4 :

 4 Figure 4: Using CVL for SPLs

Figure 9 :

 9 Figure 9: A process fragment representing the external process elements of the illustrative example

  7 http://marketplace.eclipse.org/content/spem-designer-helios-version the work product use named Generated Java code to the delivery process of the most often used process. It then redirects the outgoing control flow from the task use named Specifications to the task use named Code generation and redirects the outgoing control flow from the task use named Code generation to the task use named Development. It finally puts the work product use named Generated Java code as input of the task use named Development. To this end, the VRM adds a process parameter to the task use named Development and puts the work product use named Generated Java code as parameter type of this process parameter.

Figure 10 :

 10 Figure 10: The VAM, the VRM, and one possible RM of the illustrative example

Figure 11 :

 11 Figure 11: Overview of other CVL variation points

Figure 12 :

 12 Figure 12: Complete resolved model according to the RM of Figure 10

Figure 13 :

 13 Figure 13: Over-specified work sequence

http://www.omgwiki.org/variability/

http://www.omg.org/

http://www.omg.org/mof/

http://www.sodifrance.fr/

http://www.eclipse.org/modeling/emf/

CVL derivation engine can be downloaded http://goo.gl/ifGFD