Agnès Le Port
email: agnesleport@yahoo.fr

Alice Gueguen

Emmanuelle Kesse-Guyot

Maria Melchior

Cédric Lemogne

Hermann Nabi

Marcel Goldberg

Marie Zins

Sébastien Czernichow

Association between dietary patterns and depressive symptoms over time: a 10-year follow-up study of the GAZEL cohort

à la diffusion de documents scientifiques de niveau recherche, publiés ou non, émanant des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

INTRODUCTION

Mood disorders, and in particular depression, are frequent across the globe. The lifetime prevalence of depressive disorders is estimated between 10% to 20% in Europe and North America, and is two times higher in women than in men [START_REF] Angst | The depressive spectrum: diagnostic classification and course[END_REF]. In France, the lifetime prevalence of depression is estimated at 13-17 % in men and 25-30 % in women [START_REF] Gasquet | Prevalence and comorbidity of psychiatric disorders in the French general population[END_REF]. According to the World Health Organization, depression was the 4th cause of disability in the world in 2000 and will be the second cause in 2020 [START_REF]The world health report 2001 -Mental Health: New Understanding[END_REF].

Diet is related to inflammation, oxidative stress and brain plasticity and function; all of these physiological factors are potentially involved in depression [START_REF] Jacka | The association between habitual diet quality and the common mental disorders in community-dwelling adults: the Hordaland Health study[END_REF]. A recent review showed discordant results according to studies on the association between poly-unsaturated fatty acids (PUFA), fish, folate and other B vitamins and depressive symptoms [START_REF] Murakami | Dietary intake and depressive symptoms: a systematic review of observational studies[END_REF][START_REF] Appleton | Depressed mood and dietary fish intake: direct relationship or indirect relationship as a result of diet and lifestyle?[END_REF]. However, because nutrients are consumed in a combined way, the investigation of dietary patterns with a global perspective has been suggested as a more comprehensive approach than the study of specific nutrients. The effect of the overall diet may be easier to detect than the effects of individual dietary components, especially when the latter are of minor extent or when the global effect is greater than the sum of the parts. Using this approach, cross-sectional studies in Japan and Norway have shown a relationship between dietary patterns and depression in adults [START_REF] Akbaraly | Dietary pattern and depressive symptoms in middle age[END_REF][START_REF] Nanri | Dietary patterns and depressive symptoms among Japanese men and women[END_REF][START_REF] Jacka | The association between habitual diet quality and the common mental disorders in community-dwelling adults: the Hordaland Health study[END_REF]. Subjects who have a healthy diet, defined as a high consumption frequency of fish, fruits and vegetables have a lower probability of depressive symptoms. In the UK, a prospective study using a single measure of the Center for Epidemiologic Studies Depression scale (CES-D) demonstrated an increased likelihood of depression after 5 years for subjects adhering to a processed food dietary pattern and a reduced likelihood for subjects following a whole foods diet pattern (vegetables, fruits, fish) [START_REF] Akbaraly | Dietary pattern and depressive symptoms in middle age[END_REF]. An increased probability of depression has been described among Chinese adolescent with high snacking patterns [START_REF] Weng | Is there any relationship between dietary patterns and depression and anxiety in Chinese adolescents?[END_REF], while in Australia the same observation was described among adolescents consuming a western diet [START_REF] Jacka | Associations between diet quality and depressed mood in adolescents: results from the Australian Healthy Neighbourhoods Study[END_REF]. In addition, in the only prospective study on middle aged adults available in the literature, depressive symptoms were assessed at one point in time [START_REF] Akbaraly | Dietary pattern and depressive symptoms in middle age[END_REF]. Others studies using a-posteriori methods to assess dietary patterns, i.e. scores of existing and well know diets, as the Mediterranean diet, have shown relation between high score of consumption and decreased symptoms of depression [START_REF] Sanchez-Villegas | Association of the Mediterranean dietary pattern with the incidence of depression: the Seguimiento Universidad de Navarra/University of Navarra follow-up (SUN) cohort[END_REF]. Thus, it remains unclear whether the relationship between dietary patterns and depression symptoms tracks over time. Our aim was to study the longitudinal association between dietary patterns and depressive symptoms assessed four times, among publicsector employees in France who participated in the GAZEL cohort study between 1998 and 2008.

SUBJECTS AND METHODS

Subjects

The GAZEL cohort is an ongoing epidemiological study set up in 1989 among employees of France"s national Gas and Electricity Company (EDF-GDF). The study uses an annual questionnaire to collect data on health, lifestyle, social and occupational factors. At inception, the cohort was constituted by 15,011 men and 5,614 women, aged 35-50 years old. During the first 17 years of follow-up (1989)(1990)(1991)(1992)(1993)(1994)(1995)(1996)(1997)(1998)(1999)(2000)(2001)(2002)(2003)(2004)(2005), only 126 subjects (0.6%) were lost to follow-up. After a fall during the first 5 years of followup, almost 75% of the questionnaires were returned every year. As it was not always the same people who fail to respond each year, only 3.2% of the initial cohort never sent back any questionnaires during the 1989-2005 period [START_REF] Goldberg | Cohort profile: the GAZEL Cohort Study[END_REF].

Dietary assessment

Dietary data were collected in 1998 through a 35-items qualitative Food Frequency Questionnaire (FFQ) for twenty food groups (never, 1-2 times/ week or >2 times/week), eight items on low-fat food (yes/no), coffee consumption (number of cups per day) and six items on dietary behaviors like regular eating at breakfast, lunch and dinner and snacking between breakfast, lunch and dinner (never, rarely, often, every time). There was no portion size and nutrient intake assessment.

Depressive symptoms

Depressive symptoms were measured at several study phases in 1996, 1999, 2002, 2005 and 2008, using the CES-D scale [START_REF] Goldberg | Cohort profile: the GAZEL Cohort Study[END_REF]. This questionnaire includes 20 items that evaluate symptoms and behaviors characteristic of depressive order. Based on a previous French validation study, we used the following cut-off scores to define the presence of clinically significant depressive symptoms: ≥ 17/23 in men and women, respectively [START_REF] Radloff | The CES-D scale: a self report depression scale for research in the general population[END_REF][START_REF] Fuhrer | La version française de l'échelle CES-D (center for Epidemiologic Studies-Depression scale). Description and traduction de l'échelle d'auto-évaluation[END_REF]. Previous studies performed in the GAZEL cohort estimated the prevalence of high levels of depressive symptoms at 24.9% in men and 27.9% in women in 1996 and the prevalence at one year of major depressive episode at 7.6% in men and 17.9% in women [START_REF] Melchior | Using sickness absence records to predict future depression in a working population: prospective findings from the GAZEL cohort[END_REF].

Covariates

Age was taken at the inception, in 1989. The measure of occupational position was taken from the employer"s records of grade of employment at age 35 for all participants as it was prior to the measure of alimentary consumption and represented mid-career status [START_REF] Niedhammer | Psychosocial factors at work and subsequent depressive symptoms in the Gazel cohort[END_REF]. This measure has five levels, composed of executive, intermediate profession, employee, manual worker and missing at 35. Other covariates were measured at baseline in 1998, concurrently to the FFQ: body mass index (normal weight defined with a BMI <25 kg/m2, overweight with a BMI between 25 and 29 kg/m2 and obese with a BMI ≥ 30 kg/m2), marital status (single, divorced/separated/widowed or married/living with a partner), professional activity (active, on disability pension, retired, retired from EDF-GDF but still working), physical activity (at competition level, regularly, occasionally, no), smoking status (nonsmokers, 1-10 , 11-20 or 21 or more cigarettes/d), and alcohol consumption (none, 1-13 , 14-27 or 28 or more units of alcohol/w in men; none, 1-6, 7-20, 21 or more units of alcohol/w).

Statistical analyses

Dietary patterns

All analyses were conducted separately for men and women and were restricted to subjects with available FFQ data in 1998 and CES-D data in 1999. Among the initial 20,625 subjects included in the cohort, 75% returned their baseline questionnaire in 1998. Among them, 80.4% (11765/14641) had 35 items of FFQ completed (see Figure 1). We performed a simple imputation by age class, sex and job position, to obtain complete dietary data for subjects having no more than 4 missing data. Finally, all 35-items of the food frequency were completed for 12,404 subjects having simultaneously the CES-D measure in 1999, 84% of subjects having initially no missing data, 10% one missing data and 6% two to four missing data. A principal component analysis (PCA) was used to assess dietary patterns in 1998. The patterns were rotated by orthogonal transformation (varimax rotation) to maintain uncorrelated factors and greater interpretability. We considered the first eight components (all with eigenvalues greater than one).

Treatment of missing data

Among subjects which completed the CESD in 1998 (baseline), only 13% (1618/12404) of subjects did not have a CES-D score at the end line in 2009. We performed Multiple Imputations by Chained Equation (MICE), which consists in imputing successively several values for each missing data item.

Imputed data were CES-D in 1996CES-D in , 2002CES-D in , 2005CES-D in and 2008. The method of MICE assigns a new value for a given variable for every missing data. Because our aim was rather explicative than descriptive, we made the assumption of an "immortal cohort" [START_REF] Sabia | High alcohol consumption in middle-aged adults is associated with poorer cognitive performance only in the low socio-economic group. Results from the GAZEL cohort study[END_REF], by allocating data after death using MICE. Five completed datasets, having the same characteristics as the observed data (variability and correlations) were generated, using linear regression to model the square root of CES-D [START_REF] Kurland | Longitudinal Data with Follow-up Truncated by Death: Match the Analysis Method to Research Aims[END_REF][START_REF] Cottrell | Multiple imputation of missing at random data: General points and presentation of a Monte-Carlo method[END_REF].The covariates used in the imputation models were the repeated CES-D and all the covariates previously described, adding physical and mental perceived health in 1998. Standard analyses were done separately on each completed dataset and then combined to obtain a global result (mi estimates, Stata v.11). Finally, 5 datasets were completed for 9,272 men and 3,132 women.

Analysis of longitudinal data

We performed all the analyses on the imputed data. To study the evolution of depression symptoms over time, according to dietary patterns in 1998, we used Generalized Estimating Equations (GEE) logistic regression for the analysis of CES-D as binary data, in order to take into account the correlation between repeated observations for the same subject [START_REF] Chavance | Modeling incomplete observations[END_REF]. We included initially all interactions terms between baseline dietary patterns and time to test for effect of baseline dietary pattern on change in depressive symptoms status. Interactions were non-significant so they were not kept in the final model. Coefficients and ORs (95CI) from these models can consequently be interpreted as averaged likelihood of being depressed over time (between 1999 and 2008). For each pattern, the GEE models included terms for pattern (in quartiles) and age in 1989, in order to obtain an averaged OR and 95CI of being depressed over time, adjusted for age (model 1). Then, the GEE models included terms for pattern, time (years), age in 1989, job position at 35 years old, marital status, physical activity, BMI, smoking status and alcohol consumption (model 2). Furthermore, to deal with reverse causality (dietary intakes modified by a pre-existing or latent depression), we performed the same analyses taking into account depression status in 1996 or 1999. The analyses were performed using Stata (version 11). For longitudinal modeling on imputed data, the mi estimates and xtgee procedures were used.

Ethical considerations

The GAZEL study received approval from the national commission overseeing ethical data collection in France (Commission Nationale Informatique et Liberté) and from the INSERM"s Institutional Review Board.

RESULTS

Study population

We selected for this analysis 12,404 subjects with complete data on diet patterns in 1998 and the CES-D in 1999 (9,272 men and 3,132 women). Among men, 1,979 subjects had up to three subsequent missing CES-D measures during follow-up and 794 among women. After multiple imputation (MICE), repeated CES-D were completed for all subjects. At baseline, men were on average 45.0 years old (SD=2.9) and women 42.2 (4.2). In men, 52.2% were overweight and 9.9% were obese; in women, the corresponding figures were 22.7% and 7.6% respectively. The proportion of subjects still in professional activity was 68% in men and 79.2% in women. Among men, 17.1% were smokers and 15.7% were heavy alcohol consumers, while among women, they were 13.9% and 4.7% respectively.

Dietary patterns

Dietary patterns assessed in 1998 by principal component analysis are presented in Table 1.

For each pattern, label was proposed based on food groups displaying factor loading >0.20. For men, on the first 8 patterns, we decide for simplicity of presentation to present 5: low-fat, healthy diet, western diet, fat-sweet and high snacking pattern. For women, we retained 6 dietary patterns: low-fat, healthy diet, traditional diet, western diet, high dessert and high snacking pattern. Other patterns as bread and butter pattern or dairy products pattern are not presented here because they were not of major interest or were not found to be associated to symptoms of depression (results available upon request).

Characteristics of the population

The description of the population, according to quartiles of dietary patterns (Q1 and Q4), is presented in E-Table 1 andE

Longitudinal association between dietary patterns and depression in men

There were no significant interaction between dietary patterns and time in relation to depressive symptoms, suggesting therefore that baseline differences remained stable over time. Indeed, crosssectional associations in 1999 and 2008 (adjusted for all covariates) are presented in Table 2.

Table 3 shows longitudinal associations between dietary pattern scores categorized in quartiles in 1998 and depressive symptoms between 1999 and 2008. Participants from the highest quartiles of the healthy diet pattern were less likely to report subsequent depression at baseline than those from the lowest quartile, when adjusting for all the covariates (model 2): OR=0.90, 95%CI (0.80-1.02), 0.78 (0.69-0.89) and 0.72 (0.63-0.83), p for trend <0.001. On the other hand, participants from the highest quartiles for the western diet, fat-sweet and high snacking pattern were at increased probability to report depression over the years (all p for trends <0.001). For the low-fat pattern, only the highest consumers (Q4) had an increased probability of depressive symptoms: OR=1.16, 95%CI (1.02-1.31).

Longitudinal association between dietary patterns and depressive symptoms in women

Cross-sectional associations for women in 1999 and 2008 (adjusted for all covariates) are presented in Table 2.

Table 4 shows longitudinal associations between dietary pattern scores categorized in quartiles in 1998 and depressive symptoms between1999and 2008. Women from the highest quartiles for the healthy pattern were less likely to report CES-D depression at baseline than those from the 1st quartile, respectively: OR=0.88, 95%CI (0.73-1.07), 0.77 (0.63-0.95) and 0.75 (0.61-0.93), p for trend <0.001.

For the traditional pattern, the protective effect was strong for all the quartiles of consumption compared to the reference (the lowest quartile): OR=0.72, 95%CI (0.59-0.88), 0.76 (0.62-0.93) and 0.63 (0.50-0.80), p for trend <0.001.

Regarding the patterns associated with an increased likelihood of depressive symptoms, only the lowfat and high snacking dietary patterns remained significantly associated with depressive symptoms at baseline in multivariate analysis in women from the highest quartile vs lowest: OR=1.39, 95%CI

(1.22-1.73) and OR=1.43, 95%CI (1.16-1.76). The western diet and the dessert pattern were not significantly associated to an increased probability of depressive symptoms at baseline.

Analysis restricted to subjects with scores of CES-D<17/23, in men and women respectively, in 1996 and 1999

To assess the possibility of reverse causality, we performed the same analysis among subjects presenting low levels of depressive symptoms simultaneously in 1996 and 1999 (data available upon request). Associations were non-significant for the healthy pattern, in men and women: OR=1.00, 95%CI (0.78-1.28) for men and OR=1.07, 95%CI (0.75-1.55) for women. However, for all other patterns, the associations remained unchanged in both men and women (including traditional diet for women).

DISCUSSION

To our knowledge, this is the first study to examine longitudinal associations between dietary patterns and repeated depressive symptoms assessment over 10 years. Several dietary patterns have been found to be associated with depressive symptoms at the start of the follow-up.

In men, the western diet was significantly associated with an increased probability of depressive symptoms. A similar result was also found with three other patterns: high snacking, high consumption of low-fat food and fat-sweet food. In women, high snacking habits and high consumption of low-fat foods were associated with an elevated probability of depressive symptoms. Conversely, a traditional pattern based on fish and fruit consumption and regularity of the meals was associated with a reduced probability of depressive symptoms. These relationships demonstrated dose-response patterns and remained robust after adjustment for a wide range of potential confounding factors. Furthermore, since all interaction terms between dietary patterns and time in relation to depressive symptoms were not significant, these associations observed at baseline remained stable over time.

These results are concordant with other studies who demonstrated that a healthy pattern including fish consumption (like women"s traditional pattern in our study) was associated with a reduced probability and a western diet with an increased probability of depressive symptoms [START_REF] Jacka | The association between habitual diet quality and the common mental disorders in community-dwelling adults: the Hordaland Health study[END_REF][START_REF] Lipsitz | Analysis of repeated categorical data using generalized estimating equations[END_REF]. An emergent idea is that processed food diet as in westernized diets could be related to inflammation and cardiovascular diseases which are both related to the likelihood of depression [START_REF] Akbaraly | Dietary pattern and depressive symptoms in middle age[END_REF][START_REF] Jacka | Association of Western and traditional diets with depression and anxiety in women[END_REF][START_REF] Lopez-Garcia | Major dietary patterns are related to plasma concentrations of markers of inflammation and endothelial dysfunction[END_REF]. Conversely, a healthy pattern rich in omega-3 fatty acids intakes has been linked with mood regulation [START_REF] Tiemeier | Inflammatory proteins and depression in the elderly[END_REF]. Omega-3 fatty acids have anti-inflammatory properties and contribute to brain functioning and serotonin neurotransmission (e.g. providing fluidity to neurons cell membrane) [START_REF] Parker | Omega-3 fatty acids and mood disorders[END_REF]. Furthermore, there is evidence that adding omega-3 fatty acids to antidepressants may improve mood in major depression [START_REF] Kiecolt-Glaser | Stress, food, and inflammation: psychoneuroimmunology and nutrition at the cutting edge[END_REF][START_REF] Gertsik | Omega-3 fatty acid augmentation of citalopram treatment for patients with major depressive disorder[END_REF].

Although the associations between dietary pattern and depressive symptoms over time were maintained in subject with no depressive symptoms in 1999 and 1996, making reverse causality unlikely for all patterns except healthy pattern, this hypothesis cannot be formally ruled out. Indeed the prospective association between diet and depressive symptoms may result from some unmeasured confounding factors such as past history of depression or negative life events. Life stress may promote not only depressive mood but also unhealthy dietary patterns [START_REF] Freeman | Omega-3 fatty acids: evidence basis for treatment and future research in psychiatry[END_REF][START_REF] Liu | Perceived stress, depression and food consumption frequency in the college students of China Seven Cities[END_REF], presumably through its impact on the brain reward system [START_REF] Mikolajczyk | Food consumption frequency and perceived stress and depressive symptoms among students in three European countries[END_REF]. Unhealthy dietary pattern refers to eating behaviors like snacking or craving for specific food. Much of the available evidence on food cravings focused on the connection between diet and mood. A frequently proposed theory is that food is being used to ameliorate unpleasant affective states, through the increase of serotonin, a brain neurotransmitter. Women in particular report extreme craving for foods that are both sweet and high in fat (e.g., candies, pastries or ice cream) [START_REF] Adam | Stress, eating and the reward system[END_REF][START_REF] Yanovski | Sugar and fat: cravings and aversions[END_REF].

In both sexes, dietary patterns characterized by healthier diets (raw and cooked vegetables, oil and fruits) were associated with reduced probabilities of depressive symptoms. However, the protective effect observed for this pattern was reduced towards the null when the analyses were restricted to participants without elevated depressive symptoms in 1996 or 1999. This suggests the existence of possible reverse causality; depressed participants being less likely to consume healthy food (raw and cooked vegetables). Finally, subjects with the highest consumption of low-fat food could have the poorest health (like important rates of obesity), suggesting a possible selection bias.

Our results need to be interpreted in light of several limitations. First, the GAZEL cohort includes individuals who, at the time they were recruited into the cohort, held a stable job and volunteered to participate in an epidemiological cohort. Thus, one might expect that the frequency of depressive symptoms could be lower than in the general population. However, past research in this cohort showed that depressive symptoms are in fact as frequent in the GAZEL cohort as in the French population [START_REF] Drewnowski | Metabolic determinants of binge eating[END_REF]. Second, depression in our study was assessed using the CES-D, which does not allow a clinical diagnosis of major depression [START_REF] Melchior | Low socioeconomic position and depression persistence: longitudinal results from the GAZEL cohort study[END_REF]. However, this is a well-established instrument for identifying depressive symptoms, which has been shown to be reliable and valid across varied cultural and sociodemographic settings. Third, there was no portion size and nutrient intake assessment, as the food questionnaire asked only the weekly frequency of consumption for several items and the dietary questionnaire was not validated prior to use for assessing dietary patterns. However, the final purpose of the study is to analyze the strength of associations between dietary patterns and symptoms of depression. Additional limitation would be that we made two strong assumptions concerning: i) the difference between genders in terms of depressive symptomatology and dietary behaviors, ii) all the data (dietary and lifestyle habits) collected at baseline would be stable over time. However, we believe that dietary behaviors are different across gender, as well as depressive symptomatology. Moreover, our aim was to study the predictive value of dietary patterns assessed at one precise moment, over the ten following year"s period. Finally, concerning missing data, imputation models could be questionable because CES-D values could depend on other variables that were not included in the imputations models or that missing data would not be missing at random (MAR). For missing data caused by death, the choice of imputation models is even more questionable. However, mortality being not excessive (3.7% in men and 1.8% in women), we estimated that it was negligible.

On the other hand, this study has several important strengths, including the large sample size comprising subjects from both genders, the longitudinal design with repeated measures for depression over a long period of time and the inclusion of a wide range of potential confounding variables.

CONCLUSION

This is the first prospective study, using repeated CES-D measures, showing that several dietary patterns are predictive of the occurrence of depressive symptoms. In particular, we identified a traditional pattern characterized by fruits and fish consumption and regularity of the meals in women and unhealthy patterns in both sexes, as western diet, low-fat diet, high snack diet, and high dessert and fat-sweet diet. In both sexes, a healthy pattern characterized by vegetables consumption was found to be associated with a lower likelihood of depressive symptoms but there was probably an effect of reverse causality for this pattern. Finally, associations between high quartiles of healthy and unhealthy patterns and symptoms of depression remain surprisingly stable over a period of 10 years.

Figure 1 :

 1 Figure 1: Flowchart describing the selection of participants in the study, Gazel cohort, 1989-2008.

  -Table 2, for men and women respectively. The prevalence of subjects with depressive symptoms were 22.67%, 17.64%, 15.40% and 14.16% in men and 27.2%, 22.9%, 19.7% and 16.7% in women, in 1999, 2002, 2005 and 2008 respectively.

  Factors loading less than ± 0.20 are not presented for simplicity. Only food items with factor loading higher than ± 0.20 for all dietary patterns are presented in the table (butter, bread, sugar, milk and fat-free milk were omitted). For men, on the 8 th first patterns, number 4 (milk and dairy product), number 5 (bread, cheese, butter, regular breakfast) and number 8 (regular breakfast, lunch and dinner) are no presented here because of less interpretability and the absence of relation with symptoms of depression.For women, number 6 (milk and dairy product) and number 3 (bread, carbohydrates, butter, sugar) are no presented.

	% of variance explained	6.1	5.4	5.0	4.4	4.3	6.4	5.1	4.9	4.7	4.2	4.1

Table 2 :

 2 Odds-Ratio (95%CI) for probability of depressive symptoms in 1999 and 2008 for the upper quartile (Q4) (reference: 1 st quartile) of dietary patterns, in the GAZEL cohort.

	Dietary pattern	OR 1999 (95%CI)	OR 2008 (95%CI)
	MEN
	Low-fat	1.26 (1.10-1.45)	1.14 (0.97-1.34)
	Healthy diet	0.69 (0.60-0.80)	0.73 (0.62-0.87)
	Western diet	1.36 (1.18-1.57)	1.34 (1.13-1.60)
	Fat-sweet	1.35 (1.17-1.55)	1.58 (1.31-1.90)
	Snacking	1.49 (1.29-1.72)	1.58 (1.33-1.87)
	WOMEN
	Low-fat	1.37 (1.09-1.73)	1.30 (0.95-1.78)
	Healthy diet	0.80 (0.63-1.00)	0.72 (0.54-0.96)
	Traditional	0.64 (0.51-0.82)	0.64 (0.47-0.86)
	Snacking	1.51 (1.20-1.90)	1.59 (1.19-2.13)
	Western diet	0.91 (0.72-1.15)	0.96 (0.73-1.27)
	Dessert	1.14 (0.91-1.43)	1.17 (0.90-1.53)

Acknowledgements

Agnès Le Port had full access to all of the data in the study and takes responsibility for the integrity of the data and the accuracy of the data analysis. The authors express their thanks to EDF-GDF, especially to the Service Général de Médecine de Contrôle, and to the "Caisse centrale d"action sociale du personnel des industries électrique et gazière". We also wish to acknowledge the Population-based Cohort Platform, Epidemiology and Public Research Center, UMRS INSERM Versailles St-Quentin University 1018, -responsible for the GAZEL data base management. The GAZEL Cohort Study was funded by EDF-GDF and INSERM, and received grants from the "Cohortes Santé TGIR Program", Agence nationale de la recherché (ANR) and Agence française de sécurité sanitaire de l"environnement et du travail (AFSSET).

Funding/Support

The GAZEL study is supported by the Caisse Centrale d"Activité Sociale des Entreprises Electriques et Gazières (CCAS) and the Caisses Mutuelles Complémentaires d"Activité Sociale des Entreprises Electriques et Gazières (CMCAS).


Alexandre Feugas
email: alexandre.feugas@inria.fr

Sébastien Mosser
email: mosser@i3s.unice.fr

Laurence Duchien
email: laurence.duchien@inria.fr

A Causal Model to predict the Effect of Business Process Evolution on Quality of Service

Keywords: D.2.5 [Software Engineering]: Testing and Debugging-Monitors, D.2.9 [Software Engineering]: Management-Life cycle, D.2.4 [Software Engineering]: Software/Program Verification Business Process, Evolution, Quality of Service, Causal Model

Managing Quality of Service (QoS) of Service-based systems is a key challenge to produce systems that fulfill their requirements. Verifying the respect of a QoS contract in a system becomes more and more difficult as systems are more and more complex. Moreover, systems have to evolve in order to fulfil constantly changing requirements. As QoS properties are influenced by hidden factors such as connection rate or the system execution itself, determining the cause of a performance degradation is not mainstream. We propose in this paper to identify the causal relations to make explicit the hidden factors of influence. We more specifically focus on the consequences of system evolution with respect to QoS properties: using causal relations, we aim at predicting the possible overhead caused by an evolution. This paper shows through an example of Business Process how our evolution analysis helps to understand the effect of evolution on QoS property such as the Response Time. We show its efficiency by comparing the prediction with measured values.

INTRODUCTION

Quality of Service (QoS) is one of the main concerns in building and processing software. We consider in this paper QoS as "the measurable, quantifiable properties of a software product" [START_REF] Crnkovic | Concerning Predictability in Dependable Component-Based Systems: Classification of Quality Attributes[END_REF]. An example of such property is the Response Time (RT), defined as "the time spent between the reception of a request and the sending of the reply". A QoS property characterises the system, or a part of the system. It is possible to determine the QoS of software by static analysis at design time, or by monitoring the system at runtime [START_REF]Test and Analysis of Web Services[END_REF]. This analytical process produces a measure, called Property Value (PV). However, even if the QoS property value is known, understanding the meaning of a PV is complex due to the presence of hidden factors of influence. In the case of Response Time, the QoS property value of a given activity fluctuates considerably depending on system elements (e.g., input of a service, coding style) or on external factors such as the number of simultaneous connections, the congestion of the network or the number of exchanged messages [START_REF] Lelli | Client side estimation of a remote service execution[END_REF]. The causal relations among elements of the system, or with external factors are not explicit, leading to a misunderstanding of the system behaviour.

Service Oriented Architectures (SOA) define maintainable systems around the concept of service. Services can be composed in a Business Process (BP), an ordered set of activities, to implement larger services [START_REF] Cardoso | Quality of service for workflows and web service processes[END_REF]. We consider evolution of a SOA system as the process of changing the state of a system to fulfil new user requirements. Evolutions can be local (e.g., by only changing a parameter of a service call). However, independently of how small the modification is, an evolution has consequences on the QoS of the entire system. Moreover, it is difficult for the BP architect to predict the QoS of a Business Process composed by hundreds of activities.

The contribution of this paper is to explicit the hidden causal relations between BP elements w.r.t QoS properties. We define causal relations [START_REF] Pearl | Causality: models, reasoning and inference[END_REF], helping the BP architect to control the effect of an evolution on the QoS of a Business Process. Causal relations are part of our tool named SMILE (Service Modeling for Impact of evoLution framEwork ), that analyses QoS properties at design and runtime.

The remainder of the paper is as follows: Section 2 motivates our proposal with the presentation of our running example and the resulting challenges. Section 3 introduces causal modeling. In Section 4, we present a first causal model based on the execution of the system, and show its usage to perform an evolution analysis. Section 5 details a QoSenrichment of the causal model to improve the evolution analysis. We validate the approach in Section 6 and compare it with related work on Section 7, before concluding with a summary and future work.

MOTIVATION AND CHALLENGES

Running Example

PicWeb is a Business Process that follows SOA methodological guidelines [START_REF] Papazoglou | Service Oriented Design and Development Methodology[END_REF], positioning it as a typical use of SOA for experimental purposes. This BP is a sub-part of a larger legacy system that is deployed and daily used in three institutions (70kLoC). Its implementation relies on partners such as Flickr (Yahoo!) or Picasa (Google) to store and retrieve pictures. It allows one to retrieve a set of pictures with a given keyword from existing partner services. In the scope of this paper, we focus on the following evolution, depicted in Fig. 1. PicWeb evolved to support an alternative picture provider (the first one was Picasa), as shown in Fig. 1(b). Such provider is called in parallel of the Picasa one. Their results are concatenated in the reply. After making the evolution, not only PicWeb but the entire system slowed down, forcing to stop and re-deploy an older version of the system. If the reason of the performance degradation was obviously the evolution, it took time for the BP architect to understand why and how the modification affected the entire system.

Challenges

The goal of this paper is to present an approach insuring a QoS-safe evolution of Business Processes. In other words, the BP architect must control that an evolution will not have unplanned effects on the overall system performance. To properly maintain QoS during the evolution process and to avoid QoS degradation, the BP architect needs to be supported. This consists into the following challenges:

1. How to ensure the preservation of a given QoS property while making a BP evolve? (See Section 3)

2. How to identify the system elements that have been affected by an evolution? (See Section 4)

3. How to model a QoS property in order to identify relevant hidden causal relations? (See Section 5)

To reach this goal, we propose an analysis that makes explicit the hidden causal relations inside a Business Process. The analysis helps to predict the chain reaction of an evolution on the QoS property values.

Assumptions

We assume in this paper that a QoS expert (in charge of the study of QoS properties) cooperates with a BP architect (responsible of the design of the BPs). We focus here on QoS properties that are composable, quantifiable, and defined on a single dimension. Where models like Palladio [START_REF] Becker | The Palladio Component Model for Model-Driven Performance Prediction[END_REF] focus on performance analysis, we assume here that the BP architect studies the QoS of the system without assessing any performance model.

A CAUSAL MODEL TO ANALYSE THE EFFECT OF AN EVOLUTION

In this section, we motivate the need of a causal model. We first introduce the concept of evolution and explain why a causal analysis is needed. Then, we present the model of our system that is finally analysed to build the causal model.

Definition of an Evolution

Several definitions in the literature introduce the term of evolution. The first to introduce it was Lehman [START_REF] Lehman | Program evolution: processes of software change[END_REF]. Calinescu et al. consider evolution as "changes in the environment or the specification causing changes in the implementation" [START_REF] Calinescu | Self-adaptive software needs quantitative verification at runtime[END_REF]. In the context of this paper, we call BP evolution an ordered set of changes made on the BP such as the add, deletion or update of activities (and/or their inner elements). But analysing the consequences of an evolution is not as mainstream as expected. In fact, checking the QoS of activities manipulated during the evolution is not sufficient. The common way to deal with the evolution is to re-check the entire system for each QoS property. With BPs made of hundreds of activities, it takes a considerable time to do such a re-check.

We propose an alternative method to determine the effect of an evolution on QoS . This method relies on the computation of a Causal Model representing the causal effects of a change in a system state. The evolution analysis uses the causal model to determine which elements of the system have been affected by the evolution. With this approach, we reduce the number of re-checks to perform on the system by considering only causally related elements. A full re-check of the system is no longer necessary. We will see in the following what a causal model is and how to define it.

Definition of the Universe

Performing an evolution consists in the modification of elements of the Universe. We consider here that a Universe represents the entire ecosystem of the SOA application. It is composed of three kinds of element:

• System Elements -It includes every element composing the system, e.g., BPs, activities, variables. Activities represents the reception of a message, the invocation of a service, or any task involved in the definition of a • Property Elements -Every Property Value computed using the QoS property definition. A property value could be the measure or the application of a formula on a specific System Element (see Section 5.1).

• Resource Elements -The system uses resources (e.g., memory, network). In this category, we represent every factor related to the system, such as the workload or the users. Each element of the Universe can act on other elements, causing a change in their states. It is necessary to model explicitly the actions of Universe elements on others in order to capture the entire effect of an evolution. Our evolution analysis relies on the Universe. By establishing the Universe elements directly involved in the evolution, and by following the causal relations starting from them, we isolate the Universe elements that have been impacted. Thus re-checking only the QoS of these elements is sufficient to determine the effect of an evolution, without re-checking the entire system.

Causal Model

To control the effect of an evolution on the system, it is necessary to make explicit the influence a Universe element can have on other elements of the Universe. For example, changing the content of the input message of a service influences its execution. We call such relation between elements Causal Relations. Let (a, b) ∈ Universe Element. We define a causal relation a r -→ b, the fact that if the state of a changes, then the state of b changes as well. Based on causal relations, we build a causal model that makes explicit causal relations of interest between elements of the Universe. A Causal Model is a digraph V(E,R) where E is the set of the Universe elements and R represents the set of causal relations applied to the BP. The evolution analysis uses the causal model to determine the elements directly affected by a given evolution. Then, by following every causal relation starting from them (i.e., by processing their transitive closure), the evolution analysis determines which elements have been indirectly affected.

Using this method, the Evolution architect can determine the set of affected elements, in order to re-check only their QoS property value. Our method restricts the number of elements to re-check and gives insights about the reasons of a possible performance degradation thanks to the chain of consequences represented by causal relations.

The following focuses on the causal model reasoning part of the evolution analysis (depicted in Fig. 6) to determine the set of BP elements whom had their QoS property values affected by an evolution. We detail the different steps of the method and illustrate them with the evolution of PicWeb.

A PROCESS TO ANALYSE THE EFFECT OF AN EVOLUTION

In this section, we present our evolution analysis that predicts the effect of an evolution on the QoS of a Business Process. The evolution analysis is an automated process that relies on a Causal Model. We introduce the overall approach of the evolution analysis, before introducing the causal relations extractable from the system execution, and applying the evolution analysis on PicWeb.

Overall Approach of Evolution Analysis

Fig. 3 depicts the overall process used to perform an evolution. The process is initiated by the User, who changes the requirements of the system. The BP architect defines a modification to make the system evolve. The proposed evolution is analysed: using the causal model, evolution analysis collects affected system elements and performs a QoS recheck of these elements to get the property value of the evolved Business Process. If the Evolution architect is satisfied, the evolution is accepted and the new version is deployed. Otherwise, the evolution is discarded and results of the analysis are used to design a better evolution.

Evolution Definition

The SMILE Evolution Engine provides a set of actions to express BP evolution. This set of actions (which has been established empirically) is extensible, making possible to connect any evolution engine (such as Adore [START_REF] Mosser | ADORE, a Logical Meta-model Supporting Business Process Evolution[END_REF] or Praxis [START_REF] Blanc | Detecting Model Inconsistency through Operation-based Model Construction[END_REF]) with SMILE, as long as this evolution engine translates its behaviour into SMILE evolution actions. With our engine, it is possible to add or remove activity, variable, invocation parameters, or partial order. The following describes the effect of each evolution operation:

• addActivity(act)/delActivity(act): this action adds/deletes the activity act to the process. • addVar(var) / delVar(var): this action adds/deletes the variable var to the process.

• addInPar(var,act,pos) / delInPar(var,act,pos): this action adds/deletes the variable var as an input parameter of the activity act at position pos.

• addOutPar(var,act,pos) / delOutPar(var,act,pos): this action adds/deletes the variable var as an output parameter of the activity act at position pos.

• addRelation(act1,act2) / delRelation(act1,act2): this action adds/deletes a partial order between activities act1 and act2.

Evolution Analysis

The evolution analysis takes as input an evolution, and uses the causal model to compute the set of affected system elements. The causal model is the key of the analysis: it is initially defined by the application of the causal rules on the initial system, and enriched for each evolution. For each operation of the evolution, the analyser determines the system elements that are directly manipulated, i.e., whose state is changed. Then, system elements that are affected by this change are collected by following causal relations present in the causal model. Performing the analysis of an evolution is an automated process composed of several tasks (described in Sect. 4.3):

1. Modification of the System: The evolution is applied on the system to modify its structure.

Evolution Architect Decision:

Based on the analysis results, the Evolution architect decides if the evolution has the desired effect and if he/she wants to effectively apply the evolution: (a) If the evolution does not produce a performance degradation, the system is deployed and can be used. (b) In case of performance degradation, the Evolution architect can choose to discard the evolution. The Business Process is restored to its state before the evolution, as well as the causal model. This is the only step of the process that requires the intervention of the Evolution architect.

Building the Causal Model of a System

We present in this part how the causal relations are determined for a given system. One way to define causal relations is to study the system, and to manually establish each causal relation that exists in the system. This method is timeconsuming and error-prone. Instead, we introduce the notion of Causal Rule. A Causal Rule describes how to select under a specific condition the couples (a, b) ∈ U niverseElement that are causally related. For example, one kind of causal relation is the influence of an input on the processing of a service. The following rule describes how to build every relations of this kind for a given system:

(Var,Act) ∈ (Variable×Activity):

Var ∈ input(Act) implies Var r -→ Act.
Using this rule, SMILE analyses the Business Process to collect and build the different causal relations. We call these relations Execution Engine Causal Relations. This kind of rules is specific to the execution engine. We assume that they are provided with its specification, or written by an expert of the execution engine. In the same way, another rule collects variables and activities to represent the fact that an output is influenced by the execution of its activity. By applying these rules on PicWeb, SMILE generates the causal model. Fig. 5 depicts the causal model of PicWeb after evolution, obtained by application of the rules.

!"#$"%&'( )'*+,#-!"#$"%&'( .$/0.$/"0" !"#$"%&'( .$/01&$/2# !"#$"%&'( .$/0 !"#$"%&'( .$/01 !"#$%&'% ()*)+#&%,-./)011%,-%2) 3.%4%"-')56..%,-#6" 72287&#79.%:;#,'<#,7'7= 2%.>?-<7&74%-%&:<#,7'7@;#,'@A= 722>?-<7&74%-%&:<#,7'7@;#,'<#,7'7@A= BBB 462#C%' 57?'7.) D62%.

462#C%' E)*)3$6.?-#6" 57?'7.)0"7./'#' F)*)D62#C,7-#6")61 -G%)!"#$%&'% FH)*)57?'7.)D62%. !;27-% I)*)3$6.?-#6") 0&,G#-%,-)+%,#'#6" J%-KJ/'-%43.%4%"-L ,6..%,-' The causal model defines the causal chains of the system. It is now possible, from one element, to obtain the causal chain of the changing of its state, and to collect which elements are indirectly affected by the change of state.

!"#$%&'#( )*+,'&-+& >M I7)*)+%;.6/)"%N) 8%&'#6" "6-)>M O)*)P6J)&%*,G%,Q 61)011%,-%2)3.%4%"-' I9)*)+#',7&2) 3$6.?-#6" &%$%&-' &%$%&-' J%-K!"#$%&'% 3.%4%"-L 3$6.?-#6") R7'Q D7"#;?.7-%2) !"#$%&'%)0&-#17,- D7"#;?.7-%2) !"#$%&'%)0&-#17,-

Application of the Evolution Analysis

We focus in this part on the evolution analysis, noted as step III in Fig. 3. The analysis reads the evolution script to collect system elements that are directly manipulated. From these elements, the evolution analysis uses the causal model to collect everything that is causally related and needs to be re-checked. It can be other system elements, but also property values or resources. Fig. 6 gives a closer look of steps II-IV of the evolution process. We explain in the following the different steps of the analysis, and apply it on PicWeb:

Collection of Directly Affected Elements: Evolution -→ Set<SystemElement> -SMILE analyses the evolution in order to collect the Directly Affected Elements. These elements are the starting points of the causal analysis, as these entities are the ones that have their state explicitly changed. Evolution operations can be classified into adding/removing operations. In the case of an add, a new system element is inserted, potentially having a causal effect on the system. The causal model must be checked from this system element. In the case of a deletion, a system element is removed. The effect this element had on the system is no longer established: as a consequence, if the element was in part responsible of other elements states, In our example (Fig. 4), the evolution is composed of ten adding operations (lines 1, 3-13) and one deletion operation (line 2). Operations related to the order (lines [START_REF] Luckham | Specification and analysis of system architecture using rapide[END_REF][START_REF] Mayerl | Definition of metric dependencies for monitoring the impact of quality of services on quality of processes[END_REF][START_REF] Mosser | ADORE, a Logical Meta-model Supporting Business Process Evolution[END_REF][START_REF] Mukherjee | Determining QoS of WS-BPEL Compositions[END_REF][START_REF] Omg | Uml profile for marte: Modeling and analysis of real-time embedded systems[END_REF] are not considered as we are not focused on the order of the execution. Considering the rules in Tab. 1, adding operations are analysed to collect PicsPicasa, PicsFlickr, Flickr, Helper, Keyword. In the case of the delOutParameter operation (line 2), analysis leads to the adding of every activity using variable Pics.

The unification of the analysis of the evolution operations produces the set <PicsPicasa,PicsFlickr, Keyword, Flickr, Helper>. The analyser can determine from them which elements are potentially affected.

Evolution Causal Analysis Set<SystemElement> -→ Set<UniverseElement> -This step collects elements indirectly affected by the evolution. This task is done by following causal relations in the causal model, starting from each element of the Directly Affected Elements set. An example of causal relation modelled in the causal model is the influence of an input on the execution of a service (called serviceCall relations). The goal of this step is to use causal relations to identify system elements that are not manipulated by the evolution itself, but are affected due to a causal effect. By performing a transitive closure of the causal relations starting from directly affected elements, the analysis collects directly related elements, but also indirectly related elements.

From the variables of the DAE set, following causal relations allows the analyser to collect every activity for which a change in the input impacts the Response Time. As a result, the analysis collects several activities that are already in the DAE set (Flickr, Picasa, Helper), but also the Format activity: indeed, the Helper activity processes now a bigger number of pictures, which implies the Response Time of the Format activity to be different. Moreover, as Response Time of basic activities has changed, their aggregation is also affected. By following aggregation relations, the indirectly affected aggregation property values are Flow, Sequence and PicWeb.

QoS PV re-check of Affected Elements Set<UniverseElement> -→ Set<Property Value> -This step determines the new QoS property values of affected elements. SMILE equips the Business Process with targeted monitoring facilities and deploys it to capture the information. In the example, SMILE needs to monitor the Response Time of activities of the Indirectly Affected Element set. The monitored values show that globally, activities directly affected by the evolution does not take more time. However, the Format activity, which was not in the set of Directly Affected Elements, had a serious increase in its Response Time. We will see in the next section that this is due to the time-consuming Computation Time necessary to process each picture. The increase of the Computation Time caused the slowing down of the entire Business Process.

In this section, we have detailed how the causal model can be used by SMILE to predict the effect of an evolution on a given property value. By computing the transitive closure of the system elements directly related to the evolution, the evolution analysis identifies a subset of the system that is affected and that need to be re-checked. This identification brings a solution to challenge 2: the BP architect knows from the analysis what is the effect of the evolution on the overall QoS of the system. Our solution is fully automated to get from an evolution and the causal model of the BP if the system's performances have been degraded or not.

QOS ENRICHMENT OF THE CAUSAL MODEL

We presented in the previous section a causal model built upon the causal effect of the execution engine due to the assumption that executing a BP modifies the state of system elements. This approach is efficient to capture the minimal effect of the execution. However, the level of details is not enough to understand the causal effects at the level of a QoS property. We need also to represent the causal relations relating directly property values, in order to express effect of a property value. The execution engine itself represents the main causal effect, but external factors such as network, users, etc., need to be considered as well to capture effects such as workload. In this section, we improve the causal model with QoS-specific relations. The goal of this enhancement is to capture a more precise set of elements affected by introducing QoS causal relations that show the effect of property values on other elements. This reduces the number of re-check and enables a better understanding of the effect of an evolution. First, we present how a QoS expert defines a QoS property. Then, we explain how QoS-specific causal relations can be deduced from the QoS Description. Finally, we show how the enhancement is applied on PicWeb, and its benefits.

Definition of a QoS Property

We consider in this paper QoS as a quantifiable metric that can be measured, determined by analysis, or computed through a mathematical formula, based on other property values [START_REF] Barbacci | [END_REF][START_REF] Crnkovic | Concerning Predictability in Dependable Component-Based Systems: Classification of Quality Attributes[END_REF]. The mathematical formula is applied on a system element, to compute a Property Value. In SOA, a common way to determine the QoS property value of a Business Process is to compute the property values of its basic elements (such as invoke activities), and to compose them using an aggregation formula [START_REF] Mukherjee | Determining QoS of WS-BPEL Compositions[END_REF]. Thus the QoS expert needs to define a way to compute basic elements property value, and a formula to aggregate them. To express a QoS property, we define a Domain Specific Language (DSL). In the following, we detail each element of the description on an example, namely the Response Time. This property is a derived property, defined as the sum of the time to transmit messages (Transmission Time) and the time to execute the service itself (Computation Time). Fig. 7 is the description of Response Time provided by the QoS expert, written using our DSL. All the information must be declared once, and are then automatically applied by SMILE on any system to compute property values. They are usual information to manage the QoS property of a system.

A QoS property is defined as: Declaration of the Property Unit and Range Since QoS property values are numeric values, they must be characterised by a unit and a range. Unit of Response Time is defined as an amount of milliseconds which is always positive.

Determination of QoS Property Values for Basic Elements

The QoS processing technique is composition-based, that is to say that property values are computed at the lowest level, and then composed for higher level Universe elements. For example, the size of a message is computed by composition of the size of its inner variables. In this case, variables are Basic Elements. There are three ways to compute a PV for Basic Elements: i) static analysis at design time.

Static analysis analyses the BP at design time to compute

PVs. This kind of technique is well-suited for properties like reachability or liveness [START_REF] Gerede | Static analysis of business artifact-centric operational models[END_REF]. ii) monitoring at runtime. In the case where information needed to compute PVs are not available at design time (e.g., the number of elements of an array), monitors are positioned to observe the values at runtime. This kind of technique is well-suited for properties like Message Size or Availability, which need information only observable at runtime [START_REF] Zeng | Monitoring the QoS for Web services[END_REF]. iii) computation based on other property values. Some QoS properties are called Derived Properties [START_REF] Crnkovic | Concerning Predictability in Dependable Component-Based Systems: Classification of Quality Attributes[END_REF]. These properties are defined as a The declaration of static analysers or monitors enables SMILE to automatically perform the analysis, or to position monitors in the system. In our case, RT is defined as a derived property, and CT and TT are measured using provided monitors.

Determination of QoS Property Values for composite elements

To compute a QoS PV of a composite activity, the QoS expert describes an aggregation formula, that can be found in litterature [START_REF] Mukherjee | Determining QoS of WS-BPEL Compositions[END_REF] (reminded in Tab. 2). Such formula computes a PV for a composite activity, based on the PVs of its inner elements. For example, the QoS expert defines in Applica-tionPoint the aggregation formulae for Sequence, Flow and Loop composite activities. It is important to notice that not every QoS property fits the aggregation principle, as stated in [START_REF] Crnkovic | Concerning Predictability in Dependable Component-Based Systems: Classification of Quality Attributes[END_REF].

Influence of other factors The previously defined formula gives a way of computing a Property Value (PV ) for each element of the system. However, this formula does not make explicit that a PV can be influenced by external factors. Modelling that a specific resource influences a PV enables to include this in our evolution analysis. Here, the QoS expert writes other factors dependencies of the PV . For example, the QoS expert defines that Transmission Time of an activity is influenced by the delay of the network.

Extraction of QoS-Specific Causal Relations

A QoS property can be computed based on the property value of the inner elements, the architecture of the software, sub-properties, the usage profile and the system environment [START_REF] Crnkovic | Concerning Predictability in Dependable Component-Based Systems: Classification of Quality Attributes[END_REF]. These elements influence the QoS PV and should be represented in the causal model. In fact, such causal relation is implicit in the causal model presented in section 4: collecting system elements and re-checking them means to re-compute all their PVs. In this part, we propose a finergrained modelling approach to represent QoS-specific causal relations, in order to avoid a complete re-check of a system element's PVs. We present this improvement in two steps: first, we present the existing causal relations among property values. Then, we explain the relations there is between system elements and property values. Finally, we apply the presented causal relations on PicWeb.

Tab. 3 depicts the mapping between Property Kind [START_REF] Crnkovic | Concerning Predictability in Dependable Component-Based Systems: Classification of Quality Attributes[END_REF] and our QoS Property Description, and illustrates it. For example, a Derived Property like Response Time depends on other properties (CT and TT). This information is provided in the QoS Property Description, in the BasicComputation section. SMILE uses it to generate causal relations such as TT(Act) → RT(Act), meaning that the RT of Act is influenced by its TT. SMILE supports four cases. We do not support Usage-Dependent Properties, because the Usage Profile has to be provided manually for each activity. With our approach, we wanted a QoS Description to be as independent of the system as possible. A Usage-Dependent Property would require a consequent additional modelling effort from the BP architect.

The mapping between QoS description and causal relations is done automatically by SMILE: the QoS expert describes the property, and SMILE uses it to generate the PVs and to get the QoS-specific causal relations of the system. The causal model is enriched with QoS-specific causal relations, that can be used to tune the evolution analysis and produced a more precise set of affected elements.

Enhanced Evolution Analysis

Using the previous causal relations, SMILE can build a new causal model that considers relations to PVs. With this enhanced model, we reduce the number of re-checks and improve the preciseness of the causal model. The causal model is now composed of relations between elements of the entire Universe. To illustrate the enhancement, we consider the defined RT on a simple call to a service S, taking a variable a as input, and producing a result stored in variable c. The Evolution architect decided to evolve this service call by adding another parameter as input, b. Fig. 8(a) is the causal model version 1, Fig. 8(b) is the QoS-enriched causal model. While evolution analysis of version 1 collects S and c, causing to re-check every QoS property value of S, the enhanced evolution analysis collects directly the CT and RT property values, avoiding to re-check the TT of S. This avoids to re-check unnecessary property values, and enables via the chain reaction to understand that the cause of a possible RT degradation would be the CT, and not the TT.

As a result, instead of re-checking every PV of an affected system element, the enhancement proposes to analyse only the PVs affected. In this way, the number of elements to recheck is reduced. Moreover, it enables a better understanding of the effect of an evolution, by pointing out directly which QoS property is affected. As an illustration, Fig. 9 depicts In this section, we an improvement of the previous causal model to give more information about the causal relations among QoS property values and to reduce the number of re-checks. However, if this method gives more details about causality in a system, it also increases the size of the model and the execution time of the evolution analysis.

VALIDATION

In this section, we evaluate our approach empirically on a Crisis Management System (CMS) [START_REF] Kienzle | Crisis management systems: a case study for aspect-oriented modeling[END_REF]. The goal of the experiment is to compare the different kinds of evolution analysis on a more consequent system.

Experiment

The Crisis Management System has been designed to help rescuers in the task of handling a crisis. The system is implemented by a set of four Business Processes and thirty-three services, positioning it as a representative example of a reallife system. Ten evolutions have been applied on the system to handle different extensions of the use cases. We took these evolutions as input of our evolution analysis. The goal of the experiment is to show the efficiency of our evolution analysis compared to traditional methods, based on a real case study. We performed the evolutions of the different Business Processes and analyse them.

The CMS is implemented in BPEL and executed on a SCA platform, namely FraSCAti1 [START_REF] Seinturier | A Component-Based Middleware Platform for Reconfigurable Service-Oriented Architectures[END_REF], using the Intent mechanisms to dynamically monitor its activities. Intents are codes that are weaved on a service call to be executed before, in parallel or after the service call. We developed a Response Time Intent that takes the current time when a request is received (t1), and after the reply is sent (t2). The intent deduces the Response Time of the invocation by subtracting t1 to t2. Our experiment consists into the simultaneous handling of a set of three crisis, triggered by a call from three witnesses. The different version of the system are monitored to capture the response time of the activities.

Interpretation of the Results

We compared four methods: -the re-checking of the entire system, -the checking of elements directly affected by the evolution only, -the evolution analysis based only on system rules, and -the complete evolution analysis based on the causal relations extracted from the QoS Property Description.

Tab. 4 regroups the results of the experiment. We collected the number of property values that have to be re-checked in each case. There are several lessons to learn about this experiment: Full Re-check is resource-consuming. As stated in the table, the full re-check is the method having the most PVs to re-check. Moreover, the bigger the Business Process is compared to the evolution, the bigger the difference between this method and the others will be. On the other hand, this method insures not to forget anything. QoS enhancement provides better results than system causal model. As the QoS enhancement checks only the Computation Time and re-computes the Response Time, there is 1/3 less PVs to re-check for each activity. Most of the time, the evolution analysis based on the system is as efficient as checking the evolution only. This fact is due to the configuration of our experiment. Most of the evolution performed are "self-contained", in the sense that they do not affect variables that are re-used in the original Business Process. However, it is important to notice that the UnavailableIntResource is not self-contained: the evolution has a causal effect out of the scope of the evolution elements. As a result, the causal analysis produces results that are bigger than the re-check of the evolution, but they do include system elements that have been affected. Checking only the evolution is not sufficient. As stated in the previous point, the re-check of the elements of the evolution can forget causal effects, leading to a mistake in the prediction. In general, our methods provide better results than a full re-check, and similar or better results than a re-check of the evolution, with a better accuracy.

Threats to Validity

The experiment2 showed that our prediction tool effectively determined activities affected by the evolution on our case study. We showed that the more the causal model is explained, the more accurate the analysis is. However, the accuracy has Moreover, the level of detail of the causal model leads to an increase in its memory size, which may have to be taken into consideration in the case of systems composed of hundreds of activities. Last but not least, the accuracy of the evolution analysis relies also on the correctness of the QoS Description. If some causal relations were not taken into consideration, it may be the case that the set of affected elements may differ from reality. We recommend to prefer an analysis encompassing too much elements than an analysis that could forget a causal effect that would lead to a non-QoS-safe evolution.

RELATED WORK

Causal approaches -Causal relations among elements of processes have already been studied. Luckham et al. introduced the notion of causality to study Software Architectures [START_REF] Luckham | Specification and analysis of system architecture using rapide[END_REF]. Mayerl et al. established metrics dependencies, with a specific focus on performance properties [START_REF] Mayerl | Definition of metric dependencies for monitoring the impact of quality of services on quality of processes[END_REF]. Their approach is very similar to ours. However, their work does not focus on the evolution of a BP. Other work focus on impact analysis of software evolution. For instance, Elbaum et al. present an empirical study on the effect of software evolution on code coverage testing [START_REF] Elbaum | The Impact of Software Evolution on Code Coverage Information[END_REF]. They show that even a small modification of the software can impact code instructions involving to retest the code. We aim at applying the same approach on BPEL processes at runtime. Performance prediction -Other QoS prediction techniques have been previously presented. The Palladio component model [START_REF] Becker | The Palladio Component Model for Model-Driven Performance Prediction[END_REF] is specialised into performance prediction. It defines a model of component behaviour and resource usage using parametric formula to estimate the QoS level of a system by simulation. If this approach is more precise in terms of property values due to their strong system and statistical models, we aimed with SMILE at reducing as much as possible the modelling effort without the task of writing several models such as performance, resource usage, etc.. In our approach, only the QoS Description has to be written. Still, SMILE is precise enough to determines the PVs to re-check. Moreover, SMILE has been designed to analyse evolution, which was not the intent of the Palladio Component Model. We could combine the preciseness of SMILE with Palladio, by importing Palladio's resource QoS model, and generated a causal model from it. Similarly, the MARTE UML profile [START_REF] Omg | Uml profile for marte: Modeling and analysis of real-time embedded systems[END_REF] can be used for performance modelling. It provides the Software architect with facilities to model time, resources and causality to perform performance analysis. However, as Palladio, it requires the definition of several performance models to predict efficient property values, and is not oriented on evolution analysis. Koziolek et al. present the Q-Impress methodology which partially relies on Palladio and evaluate it on an industrial case [START_REF] Koziolek | An Industrial Case Study on Quality Impact Prediction for Evolving Service-Oriented Software[END_REF]. They study code legacy to have a model of the system. Using it, they annotate components with their resources usage. These additional information help them to evaluate different architectural evolution strategies considering quality attributes. If their approach is more accurate in terms of QoS prediction than ours, we are more time efficient since we reduce the number of elements of the system to recheck while they recheck the entire system. Ivanovic et al. determine both at design time and runtime if Service Level Agreements (SLA) of an orchestration can be violated [START_REF] Ivanovic | Constraint-Based Runtime Prediction of SLA Violations in Service Orchestrations[END_REF]. As us, they focus on QoS metrics that are measurable and can be aggregated. They express the different constraints as a Constraint Satisfaction Problem that they solve with constraint logic programming. This approach detects possible violations and determines the possible cause of such violation. However, it does not consider the evolution part of the development cycle.

CONCLUSION AND FUTURE WORK

We presented in this paper an approach to study the evolution of a Business Process with a specific focus on QoS. Our approach relies on the definition of the causal model of a BP, as a key to determine the effect of an evolution by identifying affected system elements. We defined an analysis of the evolution to predict its effect on the overall QoS property value, validated empirically by comparing the prediction with effective values and with other methods. Our approach allows a reduction of the re-checking of QoS property values after evolution, and give clues about the origin of a QoS contract violation by depicting the chain of consequences of the evolution. We enable the possibility to qualify the effect of an evolution and to determine the cause of a potential overhead.

However, our approach is profitable as long as the time spent on computing the set of affected elements is lower than the time to verify the entire system. We need to determine the threshold under which our method creates an overhead compared to a complete re-check of the system. This challenge remains in our perspective. Moreover, we took the decision in this paper to study QoS property independently, without considering relationships between properties. Modelling these relationships would enable to build a hierarchy of properties and to detect if two properties are antagonist. Using this hierarchy of property would also help to propagate the effect of evolution among properties to avoid a systematic rechecking of every property. In the future, we will continue the development of SMILE to support QoS properties that are represented on several dimensions or that need a performance model to be studied. We will improve our tool to automate the property values determination and the selective monitoring. We also plan to use a probabilistic causal model to represent potential causality, using Bayesian Belief Network [START_REF] Pearl | Causality: models, reasoning and inference[END_REF].

!

  "#$%&'()*&"+",-"./ 0,+123*()* 0,+414(5"60,+1.!"#$%&'/ &"78#.0,+1923/ !"#$%&'()*&"+",-"./ 0,+10,+41423*()* 0,+414(5"60,+1.!"#$%&'/ 0,+198,+:&23*()* 98,+:&(5"60,+1.!"#$%&'/ 0,+123*()*;"87"&(<%,=.0,+10,+41423>*0,+198,+:& 23/ ?+6,-,6# @0*?+6,-,6# ?+6,-,6# ?+6,-,6#*4''"'* 'A&,=5*6B"*"-%8A6,%= ( 0,+19*)*C%&D46.0,+123/ &"78#.0,+1923/ 0,+19*)*C%&D46.0,+123/ !"#$%&'()*$+, !*#$%&'()*$+-

Figure 1 :

 1 Figure 1: Evolution of PicWeb

Fig. 1 .

 1 (a) depicts the initial version of PicWeb using an UML activity diagram. At the beginning, the BP fetches pictures matching a given keyword. The BP receives the keyword, invokes the Picasa service to retrieve matches, format them to have pictures with an appropriate dimension to fit the display screen, and returns them as result. During its life-cycle which started eight years ago, PicWeb evolved several times to respond to changes in users requirements.

Figure 2 :

 2 Figure 2: Extract of the Universe Meta-Model

Fig. 2

 2 Fig. 2 is an excerpt of our Universe meta-model. The System Elements are established by importing BPs into our tool. Property Elements store the value of a System Element for a given QoS property. They are positioned automatically by SMILE.Each element of the Universe can act on other elements, causing a change in their states. It is necessary to model explicitly the actions of Universe elements on others in order to capture the entire effect of an evolution. Our evolution analysis relies on the Universe. By establishing the Universe elements directly involved in the evolution, and by following the causal relations starting from them, we isolate the Universe elements that have been impacted. Thus re-checking only the QoS of these elements is sufficient to determine the effect of an evolution, without re-checking the entire system.

Figure 3 :

 3 Figure 3: Overall Process to Evolve a System

1 addVariable ( P i c s P i c a s a ) 2 delOutParameter 5 addVariable ( P i c s F l i c k r ) 6 addActivity ( F l i c k r ) 7 addInParameter 10 addActivity ( H e l p e r ) 11 addInParameter 15 addRelationFigure 4 :

 125671011154 Figure 4: Script of the PicWeb evolution

Fig. 4

 4 Fig. 4 is the script describing the evolution performed in Fig. 1. It is composed of four parts: lines 1-3 update the Picasa activity by changing its output by a new variable, PicsPicasa. Lines 5-8 add the Flickr activity. Lines 10-13 are responsible of the call of the Helper activity, which concatenate PicsPicasa and PicsFlickr into Pics. Finally, lines 15-19 set up a new partial order, as depicted in Fig. 1.

Figure 5 :

 5 Figure 5: Causal Model of PicWeb after Evolution

Figure 6 :

 6 Figure 6: Overall Approach to Analyse an Evolution

Figure 8 :

 8 Figure 8: (a) Original Causal Model -(b) QoS-Enriched Causal Model

Figure 9 :

 9 Figure 9: QoS-Enhanced Causal Model of PicWeb

!"#$%&'(%&%)$

	*+,
	!"#$%&'()*+,-

-%+$"./(0% 10#2)%## *+,3%## 4%(/$2,)

		,"6%&'()*+,-
		./+2/7(%
		)45%&'()*+,-
	2//0	53$262$"
	"3)1
	.//0
	*%#1

8)26%+#%'(%&%)$ *+,-%+$"'(%&%)$

		2
		9:,%*
			.//0 !"#$%1
	.//0
	!"*1
	.//0 +,1	.//0 9$)1	,"6%&'()*+,-*+,-%+$"
	#%7)	*+-8)

!%90%)3% :(,; <,,- 4%3%26% =)6,>% 4%-(" 4%#,0+3%'(%&%)$

%&'()%( *+)$ ,-./0('.1 #$%&'()%(

		@#&0(+?
	!#$#120,34#'5# 6748 94:)+84;4,*7	!!!#$#%&'()*+',# -,0(<7+7 #$&0(+? !!#$#%&'()*+',# =4>,+*+', !"	!"#$#%&'()*+',# -..(+/0*+',

  For example, adding the Flickr invocation implies for SMILE to create a Response Time property value for the invoke activity. Moreover, because the determination of affected elements is a computation made on the causal model, SMILE has to update it. QoS Re-check of Affected Elements: The causal analysis points out the affected elements. It is necessary to re-measure or to re-check them in order to get their new property values and to quantify the effect of the evolution. SMILE uses analysers described in the QoS Property Definition (see Sect. 5) and deploys a new version of the system to monitor the new property values.

	2. Directly Affected Elements Collection: The
	evolution analysis takes as input the elements that
	are directly manipulated during the evolution. This
	step analyses the evolution operations to extract every
	system element manipulated by the evolution.
	3. Evolution Causal Analysis: Starting from the previ-
	ously collected elements, the analysis browses the causal
	model to collect every Indirectly Affected Element. The
	analyser computes the transitive closure of causal rela-
	tions starting from the Directly Affected Elements and
	collects every system element of the closure.
	4.

For each system element, SMILE insures the Universe consistency by creating every missing model element, like property values.

Table 1 :

 1 Matching Between Universe and Causal Model Evolution Operations removing the element cancels the action it had, thus causing a change in the state of previously affected elements. As a result, every previously causally related element must be re-checked as well. Tab. 1 regroups the rules used to collect DAEs. These rules have to be provided once by the Evolution architect if the Evolution Engine is extended.

	Operation	Description	Collected Element
	addActivity(act)	act is added to the Uni-	act
		verse
	delActivity(act)	act is removed from the	act
		Universe
	addVar(var)	var is added to the Uni-	var
		verse
	delVar(var)	var is removed from the	var
		Universe
	addInPar(act,var,pos)	var is added as a param-	var
		eter of act
	delInPar(act,var)	var is removed from act	act
		parameters
	addOutPar(act,var,pos)	var is added in the re-	var
		turn value of act
	delOutPar(act,var)	var is removed from the	elements related to var
		return value of act

1

  Property RT{ 2 Unit : ms ; 3 Range : p o s i t i v e ; 4 BasicComputation : CT + TT; 5 ApplicationPoint : 6 Sequence i s Sum( c h i l d r e n ) ; 7 Flow i s Max( c h i l d r e n ) ; 8 Loop i s k × c h i l d r e n ;

	9 }
	10
	11 Property CT{ 12 Unit : ms ;
	13 Range : p o s i t i v e ; 14 BasicComputation : monitor ;
	15 IsInfluencedBy : Inp ut ( a ) ;
	16 }
	17
	18 Property TT{ 19 Unit : ms ; 20 Range : p o s i t i v e ;
	21 BasicComputation : monitor ; 22 IsInfluencedBy : Network ;
	23 }
	Figure 7: Expression of Response Time

Table 2 :

 2 Response Time Aggregation Formulae mathematical function of other sub-properties. The property values are computed based on a composition formula. For example, the Response Time of an activity A can be defined as RT (A) = T T (A) + CT (A). TT stands for Transmission Time, the time spent to send the request and to receive the reply. CT is the Computation Time of the service called.

Table 3 :

 3 Collection of Factors of Influence deduced from the QoS Property Description

	!"#$%&'#$()*$)(%	89%*)$12,'8,:1,%'.%/0$12,
	;0)#0/'.%/0$12,'
	<55%5'0=$%('842/)$12,	!"#$%&'+,-)%,*%'.%/0$12,
	6>#'$2'(%?*@%*A	3%(14%5'6(27%($"'.%/0$12,

Table 4 :

 4 Number of elements to re-check for each analysis method a cost: it is necessary for the QoS expert to give extra details about the definition of the QoS property.

http://frascati.ow2.org

available at http://smile.gforge.inria.fr/experiment.html

ACKNOWLEDGMENTS

This work is partially funded by the French Ministry of Higher Education and Research, Nord-Pas de Calais Regional Council and FEDER through the Contrat de Plan Etat Region Campus Intelligence Ambiante (CPER-CIA) 2007-2013.